On Feb 6, 2010, at 2:54 AM, Hiram Chirino wrote:
On Sat, Feb 6, 2010 at 5:17 AM, Guillaume Nodet <[email protected]>
wrote:
On Fri, Feb 5, 2010 at 21:01, David Jencks <[email protected]>
wrote:
For the geronimo 3 amq integration I've been working on getting
amq 5.4 to
run in de-springified osgi/buleprint using the xbean-blueprint
NamespaceHandler I ported. I think I have at least a basic broker
starting
up.
I'd like to make a few changes so this will work better:
1. Several classes use what I think are obsolete spring-isms namely
implementing the spring interfaces InitializingBean,
DisposableBean, and
FactoryBean to tell spring stuff. IIUC a more up-to-date
technique is to
set this in the xml or, using xbean, using InitMethod and
destroyMethod
annotations. For the classes that are otherwise not spring-
dependent I'd
like to switch to the xbean annotations. The classes involved are:
activemq-pool/src/main/java/org/apache/activemq/pool/
PooledConnectionFactoryBean.java
activemq-camel/src/main/java/org/apache/activemq/camel/component/
CamelEndpointLoader.java
activemq-core/src/main/java/org/apache/activemq/spring/
ActiveMQConnectionFactory.java
activemq-core/src/main/java/org/apache/activemq/spring/
SpringSslContext.java
activemq-core/src/main/java/org/apache/activemq/spring/
ActiveMQXAConnectionFactory.java
(has other spring-isms)
activemq-core/src/main/java/org/apache/activemq/broker/util/
LoggingBrokerPlugin.java
activemq-core/src/main/java/org/apache/activemq/broker/util/
CommandAgent.java
activemq-core/src/main/java/org/apache/activemq/filter/
DestinationMapEntry.java
I guess we should also annotate those methods with @PostConstruct and
@PreDestroy annotation.
Are these spring annotations? I'd rather not insert yet more spring-
isms if not really necessary.
I guess I'm slightly worried that our users configurations will jsut
stop working or behave badly without
much warning about it. Can xbean or spring automatically detect such
annotations and do the necessary
processing ?
But I'm ok with the principle.
Yeah i worry about that too.. Another approach could be to take the
class thats using spring interfaces.. lets call it X. (1) rename it to
Y. (2) remove the interfaces from Y. Sub class Y and call it X and
add the interfaces back in.
That way you get a new Y class which is free from the spring
dependency yet you still have the original X class with the same
interface definition so that we can maintain a high degree of backward
compatibility.
That's certainly a possibility. However, these xbean psuedo-
annotations work with xbean-spring as well as xbean-blueprint so the
only people who would see a behavior change would be those who are not
using xbean xml. Is this a large enough audience to keep happy to
make this additional complexity worthwhile? If the @PostConstruct and
@PreDestroy annotations are the even more up to data spring-ism would
using those be adequate?
In addition, I need to expose
activemq-core/src/main/java/org/apache/activemq/broker/
BrokerService.java
to xbean.
2. To allow other bundles to interact with amq in osgi, it looks
like
org.apache.activemq.util.osgi.Activator needs to be run. One
possibility
would be to just install it as the bundle activator for activemq-
core, this
is what I've tried and appears to work OK. If this doesn't seem
like a good
idea to everyone I think I can just install it as a blueprint bean
in a
geronimo bundle.
What would the activator do ?
The activator is already there. I'm not sure exactly what it does,
but it appears to result in connector objects being created using
classes consistent with the broker.
A few I was thinking about for a better activemq / osgi integration
are:
* make sure we use version ranges everywhere and define which
range we want to
use for our activemq imports (in camel, we use [2.1,2.2) range
for camel imports and [2,3)
for other imports
this seems pretty doable...
* rework the discovery mechanism for transports and such so that
it's more OSGI friendly
I haven't thought about this yet.
I guess those are quite independant on the blueprint stuff you're
working on.
I think so.
thanks
david jencks
Comments?
thanks
david jencks
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
