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?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
>
>
--