Andrew Smallbone wrote:
> 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?
Then we mandate that user specify all type of classnames. He doesnt need
to. It is perfectly okay to have an RA deployment with only
QueueConnectionFactoryClassName.
Ya... Its a thin line... It can be on either side.
- Binod.
>
>
> 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?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>
>>--
>>
>>
>>
>>
>>
>
>
>
--