axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Stafford <>
Subject Re: jms URL
Date Thu, 08 Jan 2004 04:00:24 GMT

I have attached the requested patch for the changes I made against the 
JMS packages. I have finished a full publish thread from client to 
Server, but not much else. The changes are soley in the publish side 
since the additional properties are mostly for the comms-routing of the 
messages and not meant to be content to the receiving object. If we do 
need additional access to the JMS properties on the receiving side, it 
will more than likely involve an upgrade the the SimpleJMS classes provided.

The URL properties are passed as Strings. I also did not change Stub 
generation to all the caller an overloaded method to pass the per-Call 
properties through the static Stub.

The following is a summary of what changes exist:
* org.apache.axis.client.Stub.extractAttachements() - defended against 
NullPointerException when no response message present

* org.apache.axis.components.JMSVendorAdapter - populate MessageContext 
with application-specific properties from the jmsurl, the 
MessageContext, and Call.

* org.apache.axis.transport.jms.JMSConstants - added a few properties to 
identify application-specific property prefix in URL and Map of 
properties within the MessageContext properties.

* org.apache.axis.transport.jms.JMSServer - expanded the role of 
createSendProperties() such that it grabs the application-specific 
properties as well as the JMS-defined.

* - added ability to 
separately track/process application-specific properties as well as 
re-generate itself into a String again.

Once general comment I found annoying was the use of classes versus 
interfaces when it came to HasMap versus Map. Many times Map would have 
been sufficient, but the code required a HashMap type. I was wondering 
if there was any hidden intent in making it a class type versus an 
interface type?


Glen Daniels wrote:

>Since the JMS transport isn't used by all that many people yet, if you can get a version
of this ready to go in the next day or two, I think we can get it into 1.2 (we're gonna release
1.2 beta probably at the end of this week).  Jim, would you be willing to generate a patch
against the latest CVS version and send it to axis-dev so that Jaime and others can check
it out and then commit it?  This seems like good functionality to me.
>Original message:
>---------------From:Jaime Meritt <>
>To:Jim Stafford <>
>Cc:Jim Stafford <>, Glen Daniels <>,
"David A. Chappell" <>, Keith Fisher <>
>Great to see you hacking away at the code!!!  I would prefer a version
>that fits in the Axis tree as opposed to using subclasses because it is
>generically useful functionality that I see no purpose in specializing
>for.  I would be happy to review the code and once we agree that it is
>ready I will commit it as well. However, we may have to wait until after
>1.2 releases to see a productized version of it (1.3 I would imagine).
>From: Jim Stafford []=20
>Sent: Tuesday, January 06, 2004 12:10 AM
>To: Jim Stafford
>Cc: Jaime Meritt; Jim Stafford; Glen Daniels; David A. Chappell; Keith
>Subject: Re: jms URL
>I have finished working on a version of the JMS software that handles
>the processing side:
>2004-01-05 23:46:49 [MSG:129] received from user=3D'anonymous': =
>71 msgID=3D'ID:siteBlitz_hub.12283BB3A08C:3' Time=3D1073364409345
>mode=3DNON_PERSISTENT topic=3D'topics.general' =
>JMSDestination=3D{TOPIC:'topics.general'} =
>JMSPriority=3D{4} JMSMessageID=3D{ID:si
>teBlitz_hub.12283BB3A08C:3} JMSTimestamp=3D{1073364409345}}
>Properties=3D{"prop2"=3D{string:'value2'} "prop1"=3D{string:'value1'}
>"callProp1"=3D{string:'aValue'}} Body=3D{byte[]:652 bytes}
>* callProp1 comes from code interacting with the Call=20
>        Map appProps =3D new HashMap();
>        appProps.put("callProp1", "aValue");
>* EWMService, prop1, and prop2 come from the WSDL URL
>I have two versions
>1) edits the ws-axis CVS tree
>2) sub-classes and other extensions with no modification to the Axis
>Which form would you be interested in and would you be interested in
>viewing either solution before I get things more finalized for our demo?
>Jim Stafford wrote:
>	Jaime,
>	We are interested in creating and contributing what is needed to
>do this and are motivated by a short term proof of concept demo on our
>end to get things going quickly. What do you normally need (functional
>specs, design proposals?) for such a change; besides code and what isn't
>documented on the axis contribution web page?
>	I will try to further spell out my/our intentions to make sure
>this is where you want the product to head and help solicit pointers of
>where you would or would not implement some of this.
>	--
>	We have a system of JMS Servers that integrate collaborators in
>various parts of the world and with varying access to bandwidth. Various
>application-specific JMS properties are useful/necessary to route or
>limit the route of messages to certain remote locations as well as
>having replies find their way back to the requestor. We are working on a
>data-driven system, where the publishers/senders of messages are
>ignorant of the location of the receivers/subscribers of the messages.
>Systems cannot be hard-wired to share a single queue or topic and may
>not be part of the same JMS Server system. We have this working with
>pure-JMS clients.=20
>	We are now making the next step where we'd like to propose a
>message format standard for these JMS clients. For open interoperability
>reasons, we are leaning towards XML and specifically SOAP with
>attachements. The JAX-RPC Call API seems a bit more natural than the
>pure SOAP API. The WSDL generated static stubs seems even nicer for
>clients who want to stay removed from the details of Web Services.
>	The 1.2alpa org.apache.axis.transport.jms release goes a long
>way towards meeting the above goals. I have only worked my way through
>the send side of the product, but the only glaring issue I've found is
>the diffuculty in being able to supply application-specific properties.
>We tend to have several types:
>	* Service-specific properties (e.g, location=3DUSA|Europe,
>	* Client-specific properties (e.g., location,
>	* Call-specific properties (e.g., business-priority (versus JMS
>priority), conversation sequence (versus JMS sequence), privacy labels)
>	Some might be able to argue that the call-specific properties
>could be limited to expression within the JMS message and not exposed as
>a JMS property. However, at this point in our research/development, such
>constraints would seem very risky.
>	It appears we need to make changes to
>	1) allow application-specific properties to be specified for the
>service (done in WSDL and processing chains), the client (through
>collaboration with the Locator/runtime URL and processing chains), and
>the call (using Call.addProperty).
>	2) allow users of the WSDL-generated static stubs to also be
>able to provide call-specific, application-specific properties (e.g.,
>provide a non-standard overload of each method call that accepts a Map
>of application-specific properties to be merged with the client and
>server supplied properties.
>	thoughts?
>	jim
>	Jaime Meritt wrote:
>		There is definitely interest in this issue.  Perhaps we
>		collaborate on a patch that adds your functionality into
>the main
>		distribution.
>	=09
>		Thanks,
>		Jaime=20
>	=09
>		-----Original Message-----
>		From: Jim Stafford []=20
>		Sent: Monday, January 05, 2004 9:54 AM
>		To: Glen Daniels
>		Cc: David A. Chappell; Jaime Meritt;
>		Subject: Re: jms URL
>	=09
>		Glen,
>	=09
>		Thanks. I've learned a lot about the
>package and the Axis
>		JMS Transport in the last few days.
>	=09
>		I've gotten the JMS/SOAP working satisfactorily since
>then, but now am
>		trying to grasp how best to issue some of our custom JMS
>		I've posted a message to the axis-dev to determine if
>there is interest
>		in this issue and why application-specific properties
>have been
>		specificially excluded.
>	=09
>		jim
>	=09
>		Glen Daniels wrote:
>	=09
>		 =20
>			Hi Jim, all:
>		=09
>			Dave forwarded me a note in which you were
>asking about protocol=20
>			handlers and using the jms: URL prefix.  As you
>discovered, the=20
>			protocol.handler.pkgs system property is the way
>to deal with that, but
>			   =20
>	=09
>		 =20
>			there is an easier way than just using the
>command line to set it. =20
>			Axis needs to set the property itself so it can
>use URLs for the=20
>			built-in transports like local: and jms:, so we
>have the=20
>			Call.addTransportPackage() API.  If you take a
>look at the Call source,
>			   =20
>	=09
>		 =20
>			you'll find an initialize() static method which
>sets up our transports,
>			   =20
>	=09
>		 =20
>			including adding "org.apache.axis.transport" to
>the system property via
>			   =20
>	=09
>		 =20
>			addTransportPackage().  We do this automatically
>whenever Calls are
>			   =20
>		used, so out of the box you can do this:
>		 =20
>			   Call call =3D new Call("jms:/testQueue");
>		=09
>			If you want to use 'new URL("jms:/testQueue")',
>just manually call=20
>			"Call.initialize()" first and it will work.
>This is much more=20
>			convenient than the command line.
>		=09
>			Happy New Year,
>			--Glen
>		=09
>		=09
>			=20
>		=09
>			   =20
>	=09
>	=09
>	=09
>	=09
>	=09
>		 =20

View raw message