mindwalker2076 / variman Goto Github PK

It is recommended that the search results "SHOULD be returned in a consistent 
order based on an ordering of the KeyField of the Resource".

This patch adds an ORDER BY clause for the KeyField column if an Offset is 
requested.

This patch intended to be applied after the patches in issues #6 and #7 have 
been applied.

Enhancement Request: Allow the GetObjectRoot (<get-object-root> in 
rets-config.xml) to reference a URL and fetch the media from http server. The 
only prefix recognized will be "http".

Requested by NYMLS/Cloverswift Solutions.

I can see everyone standing around going should I shouldn't I, someone has to 
say it.

When are we applying the 1.8 specification?
I guess this has to be addressed at some point. 

Do we have any roadmap or are you aware of any major obstacles perhaps?

+1 on the 1.5 deprecation and move to 1.7 \o/

Latest tomcat 6.0.x stands on 6.0.37 or if we take on Servlet 3.0 jsp 2.2 then 
the 7.0.x release would be 7.0.41. But that is merely the most obvious of the 
dependencies and lots has changed over the last 3 years. Do we even want to 
hold on to some of these dependencies like hibernate, king of the crop back 
then but now theres JCA and several new kids on the block. It even seems odd 
not to find lucene in the mix which has became common place on these stacks, am 
I wrong?

@Mark I picked up from your discussions that you are weary of breaking anything 
but by the look of things that might be just what we need. I can assure you 
things will break if we replace the stack but isn't that the best thing to do 
at this junction. What says yous?


LOL Yes they say when it rains it pours =) it's been quiet foc so long and I 
for one am relieved to see some action since I am new to the party. Colour me 
impressed Mark you've managed to keep tabs on things all this time. Kudos!  
Well done!

The No Records Found RETS-STATUS response is not returned when no matching 
records were found. This patch takes into account the Offset and Limit 
parameters when determining matching records.

The link for variman at http://www.crt.realtors.org/projects/rets/ has gone 
stale.

Internal Server error occurs when user requests a Resource/Class combo to which 
they have no accessible fields. Many times the user makes this mistake because 
the metadata still returns ALL the resources and classes available on the RETS 
server regardless if the user has access to any of the fields for that 
resource/class. The metadata only filters out the fields the user does not have 
access to.

This patch replies with a RETS error letting the user know that they requested 
a resource/class combo to which they have not accessible fields.

A NullPointerException occurs when the required User-Agent request header is 
missing from the request. This causes a new entry in the logs to be created, 
returns a 500 Internal Server error, and gives no indication to the user what 
their client is doing wrong.

The attached patch replies with a RETS error message indicating that their 
client is missing the required User-Agent header. An error is logged at the 
debug level so that production logs won't get cluttered with errors caused by 
the client.

Roll to Tomcat 6.0.32 to pick up security fixes.

This happens randomly and appears to be an issue with concurrent access by 
multiple queries.

The RetsConfigChangedMonitor and MetadataChangedMonitor timer threads silently 
die when an exception occurs during the run method. This patch catches the 
exception and logs it. This allows the thread to live on and logs the cause of 
the problem.

TableGroupFilter is returning the union of include and exclude filters, thereby 
returning fields that shouldn't be returned in certain circumstances.

Issue reported by Joe Kirby.

The COUNT tag returns the wrong value when the Limit request parameter is used. 
If the requested limit is smaller than the number of records that match the 
criteria, then the value for Limit is returned.

For example, given some search criteria that matches 50 records and a Limit of 
10 is specified, something similar to the following is returned:

<RETS ReplyCode="0" ReplyText="Operation Successful">
<COUNT Records="10"/>
...
</RETS>

but should have returned something like:

<RETS ReplyCode="0" ReplyText="Operation Successful">
<COUNT Records="50"/>
...
</RETS>

Attached is a patch file that fixes this problem. This patch is intended to be 
applied after the patch in Issue #6.

I have installed the Variman RETS server on our Web server and am unable to 
access the activation page.  I am unable to access the entire Variman project 
section on the CRT web site.  Any ideas as to what is going on?

What steps will reproduce the problem?
1. Unpack the "server-jre-7u21-windows-x64.gz" file into C:\Program Files 
(x86)\java folder.
2. Add the classpath to the PATH environment variable.
3. Restart the computer.
4. Run the Variman Installer.

What is the expected output? What do you see instead?
The expected behavior is to allow installation to continue.  java and javac can 
both be run from the command line.  Installer fails.

What version of the product are you using? On what operating system?
Variman-3.2.2 on Windows Server 2008 R2.

Java Version: 
http://www.oracle.com/technetwork/java/javase/downloads/server-jre7-downloads-19
31105.html

When variman tries to determine the mime type for media, it only recognizes 
"gif" and "jpg" extensions (lower case). Add case insensitive parsing of the 
filename and include "png" and "tif" as well.

The GetObject transaction replies with a 20513 Miscellaneous Error when the 
object is unavailable. This error message doesn't give any indication to the 
user that they requested an object that is currently unavailable. In this case, 
the RETS spec suggests that a 20409 Object Unavailable reply should be sent.

Many times the object is unavailable because the file is not found. Therefore, 
this patch replies with a 20409 Object Unavailable when a FileNotFoundException 
is caught during the GetObjectTransation.