Binod wrote:
>It is possible that for normal operations, application will use an xa queue
>connection factory and for dead message queue, it want to use a topic.
But wouldn't this work by using using properties:
DestinationType = javax.jms.Queue
DeadMessageDestinationType = javax.jms.Topic
Which will result in use of classnames defined in properties:
TopicClassName and QueueClassName.
Or am I missing something?
Andrew
On 9/21/05, Binod P G <Binod.Pg_at_sun.com> wrote:
>
>
> Andrew Smallbone wrote:
> > I'm getting a better understanding of genericjmsra.
> > reply below.
> >
> > On 9/15/05, Sivakumar Thyagarajan <Sivakumar.Thyagarajan_at_sun.com> wrote:
> >
> >>As far as I can see, there is no real difference in creating DMDs from
> >>normal destinations, except in the fact that DMD's properties are
> >>defined via the MDB ActivationSpec. So, with the new model, we would
> >>perform "[Some means to get the appropriate MPOF].createFOO(props)" in
> >>EndpointConsumer to create a DMD, where FOO would be based on the
> >>destinationType defined for the DMD.
> >
> >
> >>The only conversion we might need to do is to have a conversion method
> >>to convert a String to a GenericJMSRAProperties so that this could be
> >>passed to createFOO. Am I missing something?
> >
> >
> > How would this work?
> > The JavaBean/JNDI versions of:
> > MessageProviderObjectFactory.createQueue(GenericJMSRAProperties )
> > Require either a DestinationProperties or DestinationJNDIName property
> > (from ActivationSpec) how can this be passed through?
> > Should it be createQueue(ActivationSpec)?
> > This complicates DestinationAdapter which has its own way of
> > specifying destinations
>
> Siva will be the right person to answer this part.
> >
> > Also why isn't DeadMessage specified by type (DeadMessageDestinationType)
> > rather than class name - would there ever be a case when the dead
> > message destination wouldn't be the same as that used in 'normal'
> > destinations : {Topic,Queue}ClassName
>
> It is possible that for normal operations, application will use an xa
> queue connection factory and for dead message queue, it want to use a topic.
>
> - Binod.
>
> >
> > regards
> > Andrew
> >
> > On 9/15/05, Sivakumar Thyagarajan <Sivakumar.Thyagarajan_at_sun.com> wrote:
> >
> >>Responses inline. This is turning out to be a huge thread. We probably
> >>need to summarize once we come to a conclusion :)
> >>
> >>Thanks
> >>--Siva.
> >>
> >>Andrew Smallbone wrote:
> >>
> >>>reply inline:
> >>>
> >>>On 9/14/05, Sivakumar Thyagarajan <Sivakumar.Thyagarajan_at_sun.com> wrote:
> >>>
> >>>
> >>>>Hi Andrew
> >>>>[Copying the project dev alias]
> >>>>
> >>>>+1 for this. I agree that this would enhance code readability by making
> >>>>it simple.
> >>>>
> >>>>
> >>>>>Thus hiding the ObjectBuilder/ObjectBuilderFactory from the rest of
> >>>>>the code.
> >>>>
> >>>>How would the appropriate MessageProviderObjectFactory implementation be
> >>>>picked up without a class similar to ObjectBuilderFactory?
> >>>
> >>>
> >>>Good point. Could the ObjectBuilderFactory just have a
> >>>getMessageProviderObjectFactory(props) that would return the relevant
> >>>ObjectFactory or even move that to GenericJMSRAProperties?
> >>>
> >>
> >>A Factory of factories ... Oh my! This sounds fine as of now. I shall
> >>send an email later, if I see any issues with this.
> >>
> >>>>If I understand you correctly, this is how a destination object creation
> >>>>would happen
> >>>>DestinationAdapter.initialize() > [Some means to get the appropriate
> >>>>MPOF].createFOO(props) where FOO is either Queue|Topic|Destination
> >>>
> >>>
> >>>Exactly, one issue I've notice is when creating the DeadMessageDestination
> >>>Destination - it has it's own property, should createFOO() have an
> >>>additional argument for the specific destination properties? or can
> >>>this be done some other way?
> >>>
> >>
> >>As far as I can see, there is no real difference in creating DMDs from
> >>normal destinations, except in the fact that DMD's properties are
> >>defined via the MDB ActivationSpec. So, with the new model, we would
> >>perform "[Some means to get the appropriate MPOF].createFOO(props)" in
> >>EndpointConsumer to create a DMD, where FOO would be based on the
> >>destinationType defined for the DMD.
> >>
> >>The only conversion we might need to do is to have a conversion method
> >>to convert a String to a GenericJMSRAProperties so that this could be
> >>passed to createFOO. Am I missing something?
> >>
> >>>
> >>>>One advantages of the earlier ObjectBuilder approach was that we could
> >>>>have common builder logic housed in the abstract ObjectBuilder class. I
> >>>>am assuming something similar to this would happen in the new approach.
> >>>
> >>>
> >>>The {JavaBean|JNDI}ObjectFactory would use the ObjectBuilder (or
> >>>contain its logic)
> >>>The Tib provider I've started reuses ObjectBuilder logic
> >>>
> >>>
> >>>
> >>>>Please let me know should you need any assistance while making these
> >>>>changes.
> >>>
> >>>
> >>>Will do, I'm worried that the amount of changes required will break
> >>>things. I'll start with changing EndpointConsumer and send the
> >>>changes for review.
> >>>
> >>
> >>Sure.
> >>
> >>>regards
> >>>Andrew
> >>>
> >>>
> >>>
> >>>
> >>>>Thanks
> >>>>--Siva.
> >>>>
> >>>>Andrew Smallbone wrote:
> >>>>
> >>>>
> >>>>>Sorry for not responding (was on vacation).
> >>>>>I've started implementing MessageProviderObjectFactory and a tib
> >>>>>implementation to get a better idea of how this would work.
> >>>>>
> >>>>>Making the rest of genericjmsra use it now means making changes
> >>>>>everywhere - so there would be "if (bean) {...} else if (custom) {...}
> >>>>>else if (jndi) {...}" Statements every where.
> >>>>>
> >>>>>Would a further refactoring make things simpler:
> >>>>>Rather than adding a createUsingCustomPolicy() to ObjectBuilderFactory
> >>>>>what about creating a JavaBeanObjectFactory and JndiObjectFactory
> >>>>>implementations of MessageProviderObjectFactory contain all the
> >>>>>javabean and jndi code respectively.
> >>>>>Thus hiding the ObjectBuilder/ObjectBuilderFactory from the rest of the code.
> >>>>>
> >>>>>If I'm not missing something this would work and greatly simplify the code.
> >>>>>Does this seem a good idea?
> >>>>>
> >>>>>Andrew
> >>>>>
> >>>>>
> >>>>>On 9/1/05, Sivakumar Thyagarajan <Sivakumar.Thyagarajan_at_sun.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Sorry I jumped on that. Yes, we should have a mechanism by which we pass in
> >>>>>>
> >>>>>>the configured properties to MessageProviderObjectFactory implementation.
> >>>>>>We could modify the interface template I sent earlier to accept an object
> >>>>>>that implements GenericJMSRAProperties, and the MPOF implementation could
> >>>>>>use the configured properties as it seems fit.
> >>>>>>
> >>>>>>public interface MessageProviderObjectFactory {
> >>>>>> public javax.jms.TopicConnectionFactory
> >>>>>>createTopicConnectionFactory(GenericJMSRAProperties gp);
> >>>>>> ...
> >>>>>> public javax.jms.Queue createQueue(GenericJMSRAProperties gp);
> >>>>>> ...
> >>>>>>}
> >>>>>>
> >>>>>>Thanks
> >>>>>>--Siva.
> >>>>>>
> >>>>>>Sivakumar Thyagarajan wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>I assume the new interface will have a way to accept the properties
> >>>>>>>>configured by the application server administrator also, including
> >>>>>>
> >>>>>>some
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>custom properties specific to the MessageProviderObjectFactory.
> >>>>>>>>
> >>>>>>>
> >>>>>>>In an earlier discussion in this thread, we had discussed that the
> >>>>>>>following change would handle this.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>_GenericJMSRAProperties_
> >>>>>>>>>>>- allow providerIntegrationMode to accept a value: "custom"
> >>>>>>>>>>>- add an javabean property that allows specification of a class
> >>>>>>
> >>>>>>that
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>>>implements MessageProviderObjectFactory, when the provider
> >>>>>>>
> >>>>>>>integration
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>mode is "custom".
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>setMessageProviderObjectFactoryImpl(String).
> >>>>>>>>>>>
> >>>>>>>>>>>- add a javabean property that allows specification of a generic
> >>>>>>>>>>>name-value pair list [comma-separated ?]
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>setMessageProviderObjectFactoryProperties(String).
> >>>>>>>
> >>>>>>>
> >>>>>>>--Siva.
> >>>>>>>
> >>>>>>>Binod P G wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Sivakumar Thyagarajan wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Hi Andrew
> >>>>>>>>>
> >>>>>>>>>Response inline.
> >>>>>>>>>
> >>>>>>>>>Thanks
> >>>>>>>>>--Siva.
> >>>>>>>>>
> >>>>>>>>>Andrew Smallbone wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>This makes more sense to me now (beware I'm not fully comfortable
> >>>>>>>>>>with JCA yet)
> >>>>>>>>>>
> >>>>>>>>>>Would the MessageProviderObjectFactory interface would be "Object
> >>>>>>>>>>build();"?
> >>>>>>>>>>If there was a single implementation for each MoM how would this
> >>>>>>>>>>determine what
> >>>>>>>>>>object it was creating?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>I was thinking we could have one MessageProviderObjectFactory
> >>>>>>>>>interface with methods for creating Queue/Topic/Destination/QCF/TCF/CF
> >>>>>>>>>public interface MessageProviderObjectFactory {
> >>>>>>>>> public javax.jms.TopicConnectionFactory
> >>>>>>>>>createTopicConnectionFactory();
> >>>>>>>>> ...
> >>>>>>>>> public javax.jms.Queue createQueue();
> >>>>>>>>> ...
> >>>>>>>>>}
> >>>>>>>>
> >>>>>>>>I assume the new interface will have a way to accept the properties
> >>>>>>>>configured by the application server administrator also, including some
> >>>>>>>>custom properties specific to the MessageProviderObjectFactory.
> >>>>>>>>
> >>>>>>>>- Binod.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>and ObjectFactory could have createUsingCustomPolicy() accepting a
> >>>>>>>>>method on the MsgProvObjFac as a param [This is just a suggestion,
> >>>>>>>>>how we tie the appropriate method to call is implementation detail]
> >>>>>>>>>
> >>>>>>>>>I also like the other approach where we could have a generic Object
> >>>>>>>>>build() and switch between one of the many MoM specfic
> >>>>>>>>>implementations, but however think that the former is better, as with
> >>>>>>>>>the former approach a MoM provider vendor needs to author just one
> >>>>>>>>>class as against six classes [Q/T/D/QCF/TCF/CF] wiht the latter.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>Or could the factory be specific to each object type. So instead of
> >>>>>>>>>>a single
> >>>>>>>>>>factory you'd define one for each object type (So if property
> >>>>>>>>>>"QueueClassName"
> >>>>>>>>>>wasn't defined the system would look for "QueueClassFactoryName"
> >>>>>>>>>>which would
> >>>>>>>>>>implement build() and return a Queue etc.).
> >>>>>>>>>>This would get around the problem of when you just want to customize
> >>>>>>>>>>the
> >>>>>>>>>>creation of one MoM specific object without having to create a
> >>>>>>>>>>factory for
> >>>>>>>>>>every.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>The Spring approach appears very flexible, but wouldn't configuring
> >>>>>>>>>>>such
> >>>>>>>>>>>an XML file for creation of each JMS resource be complex for an
> >>>>>>>>>>>administrator? Also, how would a user provide a pointer to such an
> >>>>>>
> >>>>>>XML
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>>>file [though it is generic and very extensible] to an application
> >>>>>>>>>>>server
> >>>>>>>>>>>deployment facility, during RAR creation?
> >>>>>>>>>>
> >>>>>>>>>>Yes the spring format is very powerful but exposes things at a very
> >>>>>>>>>>low level
> >>>>>>>>>>which can be hard to understand (although you can 'inherit'
> >>>>>>>>>>definitions to
> >>>>>>>>>>simplify things). And yes to get into a RAR you would have to
> >>>>>>>>>>create a name
> >>>>>>>>>>property version of the XML or somehow refer to another file (I
> >>>>>>>>>>don't know how
> >>>>>>>>>>this would work) I wasn't suggesting it as an approach that would
> >>>>>>>>>>work in
> >>>>>>>>>>genericjmsra just an example of how other systems do it.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>regards
> >>>>>>>>>>Andrew
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>On 8/29/05, Sivakumar Thyagarajan <Sivakumar.Thyagarajan_at_sun.com>
> >>>>>>>>>>wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>Hi Andrew
> >>>>>>>>>>>[Copying Binod in this thread]
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>So rather than specifying all the implementation classes their would
> >>>>>>>>>>>>be a single factory with createDestination(), createConnection()
> >>>>>>
> >>>>>>etc.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>>>>methods?
> >>>>>>>>>>>
> >>>>>>>>>>>Yes, I was thinking of something similar. I have provided more
> >>>>>>>>>>>information below. This is just a suggestion on how this could be
> >>>>>>>>>>>implemented.
> >>>>>>>>>>>
> >>>>>>>>>>>We could have a factory interface [MessageProviderObjectFactory] that
> >>>>>>>>>>>would be referred to (if specified via a property in the RA) while
> >>>>>>>>>>>creating administered object/MCF etc. We could add a property in
> >>>>>>>>>>>GenericJMSRAProperties that could accept generic name=value pairs
> >>>>>>
> >>>>>>list
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>>>and these proeprties could be used by the factory class(as seems
> >>>>>>>>>>>fit by
> >>>>>>>>>>>teh factory class) to construct the object.
> >>>>>>>>>>>
> >>>>>>>>>>>This is how it might work:
> >>>>>>>>>>>_GenericJMSRAProperties_
> >>>>>>>>>>>- allow providerIntegrationMode to accept a value: "custom"
> >>>>>>>>>>>- add an javabean property that allows specification of a class that
> >>>>>>>>>>>implements MessageProviderObjectFactory, when the provider
> >>>>>>
> >>>>>>integration
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>>>mode is "custom".
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>setMessageProviderObjectFactoryImpl(String).
> >>>>>>>>>>>
> >>>>>>>>>>>- add a javabean property that allows specification of a generic
> >>>>>>>>>>>name-value pair list [comma-separated ?]
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>setMessageProviderObjectFactoryProperties(String).
> >>>>>>>>>>>
> >>>>>>>>>>>_ObjectBuildFactory_
> >>>>>>>>>>>- enhance to support a CustomObjectBuilder, that inturn delegates
> >>>>>>>>>>>to the
> >>>>>>>>>>>configured MessageProviderObjectFactoryImpl
> >>>>>>>>>>>
> >>>>>>>>>>>We could then have a TibcoMessageProviderObjectFactoryImpl, that
> >>>>>>>>>>>provides custom implementation for creating MCF/AO for Tibco. User
> >>>>>>>>>>>while
> >>>>>>>>>>>deploying the RA could set ProviderIntegrationMode as custom,
> >>>>>>>>>>>MessageProviderObjectFactoryImpl as MessageProviderObjectFactoryImpl,
> >>>>>>>>>>>and while creating the dest. admin object provide additional
> >>>>>>>>>>>properties
> >>>>>>>>>>>that would be used by TibcoMessageProviderObjectFactoryImpl to create
> >>>>>>>>>>>the admin object based on its own implementation logic. Hope this is
> >>>>>>>>>>>clear. Please let me know should you need more information.
> >>>>>>>>>>>
> >>>>>>>>>>>The Spring approach appears very flexible, but wouldn't configuring
> >>>>>>>>>>>such
> >>>>>>>>>>>an XML file for creation of each JMS resource be complex for an
> >>>>>>>>>>>administrator? Also, how would a user provide a pointer to such an
> >>>>>>
> >>>>>>XML
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>>>file [though it is generic and very extensible] to an application
> >>>>>>>>>>>server
> >>>>>>>>>>>deployment facility, during RAR creation?
> >>>>>>>>>>>
> >>>>>>>>>>>Thanks
> >>>>>>>>>>>--Siva.
> >>>>>>>>>>>
> >>>>>>>>>>>Andrew Smallbone wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>So rather than specifying all the implementation classes their would
> >>>>>>>>>>>>be a single factory with createDestination(), createConnection()
> >>>>>>
> >>>>>>etc.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>>>>methods?
> >>>>>>>>>>>>How would this be configured?
> >>>>>>>>>>>>
> >>>>>>>>>>>>Spring (which I'm using) gets around the issue by creating objects
> >>>>>>>>>>>>using an xml bean (object) creation definition (it's possible to
> >>>>>>>>>>>>create factories for objects if they need it and set properties by
> >>>>>>>>>>>>calling methods on other objects etc..)
> >>>>>>>>>>>>
> >>>>>>>>>>>><bean id="destination" class="com.tib.....">
> >>>>>>>>>>>><constructor-arg>arg1</constructor-arg>
> >>>>>>>>>>>><constructor-arg>arg2</constructor-arg>
> >>>>>>>>>>>><property name="propX" ref="otherObject"/>
> >>>>>>>>>>>></bean>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>regards
> >>>>>>>>>>>>Andrew
> >>>>>>>>>>>>
> >>>>>>>>>>>>On 28 Aug 2005 17:21:03 -0000, sivakumart_at_dev.java.net
> >>>>>>>>>>>><sivakumart_at_dev.java.net> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>https://genericjmsra.dev.java.net/issues/show_bug.cgi?id=6
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>------- Additional comments from sivakumart_at_dev.java.net Sun Aug
> >>>>>>>>>>>>>28 17:21:03 +0000 2005 -------
> >>>>>>>>>>>>>Andrew,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>Suggest adding support for specifying constructor properties in
> >>>>>>
> >>>>>>the
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>>>>>ActivationSpec.
> >>>>>>>>>>>>>This issue could be solved using the above mechanism. However,
> >>>>>>>>>>>>>wouldn't it be
> >>>>>>>>>>>>>more useful if we could have a generic mechanism for solving such
> >>>>>>>>>>>>>customizations. In one of our earlier discussions while starting
> >>>>>>>>>>>>>the project,
> >>>>>>>>>>>>>one idea was to have a generic factory based implementation to
> >>>>>>>>>>>>>create CF/Admin
> >>>>>>>>>>>>>Objects etc. We could have MoM product-specific factory
> >>>>>>>>>>>>>implementations
> >>>>>>>>>>>>>(classes) [i.e an implementation for Tibco, one for Sonic MQ and
> >>>>>>>>>>>>>so on] that
> >>>>>>>>>>>>>could have their own custom means of creating and initializing
> >>>>>>>>>>>>>these objects.
> >>>>>>>>>>>>>Users could then while configuring the RA choose which MoM-Factory
> >>>>>>>>>>>>>implementation they want to work with and properties specific to
> >>>>>>>>>>>>>that Factory
> >>>>>>>>>>>>>implementation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>Would this approach be useful? Could we consider this as well
> >>>>>>>>>>>>>while fixing this
> >>>>>>>>>>>>>issue?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>
> >
> >
>
> --
>
>
>
>
>
--
Andrew Smallbone <andrew_at_rocketnumbernine.com>