So far I have determined that the < is being
stripped out on the CLIENT side of the blaster code.
Specifically, in QueryKeySaxFactory.
In my diagnostics I notice that the < is
transformed to < in the init call below (which
actually does the parse):
/**
* Parses the given xml Key and returns a
QueryKeyData holding the data.
* Parsing of update() and subscribe() key is
supported here.
* at param the XML based ASCII string
*/
public synchronized QueryKeyData readObject(String
xmlKey) throws XmlBlasterException {
if (xmlKey == null) {
xmlKey = "<key/>";
}
System.out.println("\n\n\nBEFORE QueryKeyData:
"+queryKeyData+"\n"+character.toString());
queryKeyData = new QueryKeyData(glob, this,
xmlKey);
System.out.println("\n\n\nAFTER QueryKeyData:
"+queryKeyData+"\n"+character.toString()+"\n\n\n");
init(xmlKey); // use SAX parser to parse it (is
slow)
System.out.println("\n\n\nPOST init():
"+queryKeyData+"\n\n\n");
return queryKeyData;
}
The class is a ContentHandler so its implemented
methods are called during the sax parse. I will
continue on but just wanted to let you know what I
have found in the moments that I have had to devote to
the problem this morning.
Thanks Again,
Vaughn
--- Marcel Ruff <mr at marcelruff.info> wrote:
Jan Petranek wrote:
Hi Vaughn,
Am Samstag, 16. April 2005 14:05 schrieb Vaughn
Combs:
Many Thanks. I tried it and it seems like they are
transforming < to < at some point.
Question is, where does this substitution happen.
Here is the predicate that I am submitting:
Submitted Predicate:
/xmlBlaster/key[metadata/BasicTemporal/beginning_date_time_
group/hour_time < 22 ]
and the exception that it pushes back is:
org.infospherics.commonAPI.impl.exception.PlatformFailureException:
XmlBlasterEx
ception errorCode=[resource.configuration]
serverSideException=true location=[Sa
xHandlerBase.parse()] message=[#exported Error
while
SAX parsing :3:-1 : org.xml
.sax.SAXParseException: The content beginning "< "
is
not legal markup. Perhaps
the " " () character should be a letter.]
[See
URL http://www.xmlblaster.or
g/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#resource.config
urati on]
at
mil.af.rl.jbi.platform.shared.capi.core.plugin.xmlblaster.BlasterList
ener.<init>(SubscriberSequenceReceptor.java:184)
at
mil.af.rl.jbi.platform.shared.capi.core.plugin.xmlblaster.SubscriberS
equenceReceptor.init(SubscriberSequenceReceptor.java:80)
at
mil.af.rl.jbi.platform.client.capi.core.plugin.xmlblaster.SubscriberS
equence.activateSequence(SubscriberSequence.java:301)
at
mil.af.rl.jbi.platform.client.capi.impl.SubscriberSequence.activateSe
quence(SubscriberSequence.java:316)
at
mil.af.rl.jbi.commonAPI.impl.jms.tests.sub.SubTest.main(SubTest.java:
140)
I wonder if there is something wrong in how I am
invoking the interface. Here is the code:
System.out.println("\n\n\nSubmitted Predicate:
"+submitPredicate+"\n\n\n");
this.con.subscribe("<key
oid='"+this.type+"#"+this.version+"'
queryType='XPATH'>"+
submitPredicate+"</key>", "<qos/>");
If it works for you then I must be doing something
wrong. Any ideas would be greatly appreciated.
It seems to work, but I use the C-API and the
socket-connection. The
transmitted subscription is:
[client] Subscribe key: <key
queryType='XPATH'>//*[local-name()='Impact' and
number(text())<1]</key>
^^^
[client] Subscribe qos: <qos>
<content>true</content>
<persistent>false</persistent>
<notify>false</notify><updateOneway>true</updateOneway></qos>
[client] Subscribe success, returned status is '
<qos>
<subscribe
id='__subId:XPATH1113674459065000000'/>
<isSubscribe/>
</qos>'
This seems to work here, whereas a subscription
with
[client] Subscribe key: <key
queryType='XPATH'>//*[local-name()='Impact' and
number(text())<1]</key>
produces pretty much the same error as you
receive.
It seems, the Java-API substitutes the entities,
before the SAX-Parser gets
it. You might try to find out, if it is the
client, who substitutes the
entities by running a network sniffer (e.g.
ethereal) to monitor the
subscription. (This is pretty straightforward with
the socket-API, as the
subscription messages are in plain text).
just start
java org.xmlBlaster.Main -dump[socket]
and
java <your client> ... -protocol SOCKET
-dump[socket]
to see all messages in plain text.
Which connections do you use?
These differences between the C-API and the
JAVA-API could indicate a bug in
the Java-API. Well, until somebody fixes this, you
could just write your
subscription
x<y
as
y>x
This is just an ugly work-around, sorry I don't
have a real solution.
:-), nice hack!
Marcel
Enjoy your weekend nevertheless,
Jan Petranek
--
http://www.xmlBlaster.org
__________________________________
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide