Weird JMS behavior with InitialContext

2000-12-07 Thread Vidur Dhanda


I just ran into a rather interesting problem.  For my application,
I decided to write a Swing login panel.  This panel is called at client
application startup and calls new InitialContext(Hashtable).  Once
the InitialContext is created, the application saves it for future use. 
And the application can successfully use remote EJBs after logging in.
However, when the application first attempts to reposnd to a Publish/SubscribeJMS
message, (and causes a server request), the default Orion login panel is
again displayed.
If I don't use the application specific login panel, then the default
Orion login panel shows up once and things work as expected.
Here's the call stack (and I promise, the application was able to access
EJBs before this call stack; sorry its an image from the debugger). 
How can I force the client application to login only once?
Thanks,
Vidur

 
 


jms behavior

2000-10-02 Thread Luis M Bernardo



hello,

I've had some trouble understanding how the orion implementation of jms
works. first of all, and as some other people pointed out, we cannot
specify a topic connection factory in the jms.xml file but instead we have
to rely on the default one (named I think theTopicConnectionFactory,
although that seems to be irrelevant). also, we don't seem to need to
specify topics and a default one will be assigned. the difference with the
topic connection factory is that nothing bad happens if we define topics
in the jms.xml file, but we get an exception if we try to define a topic
connection factory in that file.

I have an application with a publisher in the ejb tier. this publisher
publishes to 3 topics: A, B and C. in the web tier I have the
subscribers. one subscriber subscribes to topics A and B, and a different
subscriber subscribes to topic C. I defined the three topics in the
jms.xml file.

the behavior I noticed is that the jms implementation mangles the
topics. say, the subscriber that only subscribes to topic C will also
receive messages published to the other topics (my subscribers implement
the MessageListener onMessage method). so my solution was to use selectors
with the subscriber. for instance, for the subscriber of topic C I have to
set a selector that filters out messages sent to the other topics even
though those messages should never be present in topic C. the other
anomalous behavior is that this only works if I set the noLocal variable
in the TopicSession.createSubscriber() method to false. it should be
irrelevant if I set it to false or true since my subscribers are not
publishers.

anyway, I was wondering if someone else found this. it took me a while to
understand what was going on, and I think the implementation may not be
perfect.

cheers,
luis