On Jan 23, 2010, at 2:14 PM, Andy wrote:
Ok, I was kidding myself. My test was somewhat flawed.
However, I am sure that I have it covered now, including poms.
If someone in authority could check my suggested trunk patch I'd be
grateful.
(against - http://svn.apache.org/repos/asf/openejb/trunk/openejb3)
The 'challenge' was actually within the BrokerFactory implementation -
static final private FactoryFinder brokerFactoryHandlerFinder
= new FactoryFinder("META-INF/services/org/apache/activemq/broker/");
...defines the discovery location prefix of the properties file to
load in order to determine which handler class to load.
Reflection is required to call the appropriate methods on the
available BrokerFactoryHandler.
For this purpose I created an ActiveMQFactory which masks either
ActiveMQ5Factory or ActiveMQ4Factory
depending on the available library.
This resolves the broken 'BrokerFactory.BrokerFactoryHandler'
interface issue between versions 4 and 5.
The broker properties file prefix name must be determined at runtime
- i.e. 'openejb4:' or 'openejb5:'.
The ActiveMQFactory provides this name via
ActiveMQFactory.getBrokerMetaFile() which returns
the available/loaded prefix.
I created a new project - OpenEJB :: Container :: Legacy (Which
could actually host other legacy issues).
This project hosts the ActiveMQ4Factory and tests against ActiveMQ
4.1.1 rather than 5.0.3.
The jar this creates can remain in the release as it will only load
mq4 if the mq4 jars are on the classpath and
the mq5 jars are removed - mq5 jars take precedence.
I hope this helps, and doesn't tread on anyone's toes!
No, this is fantastic! Can you attach the patch to this jira?
https://issues.apache.org/jira/browse/OPENEJB-1227
Primary reason is we need you to check that little box that says you
agree we can include it in the source before we can check this in.
Really great. If you want to hack on any EJB 3.1 stuff, feel free.
The project can always use more good help.
-David
