activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: amq 5.4 and osgi/blueprint
Date Sat, 06 Feb 2010 10:54:27 GMT
On Sat, Feb 6, 2010 at 5:17 AM, Guillaume Nodet <gnodet@gmail.com> wrote:
> On Fri, Feb 5, 2010 at 21:01, David Jencks <david_jencks@yahoo.com> 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.
> 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.

>
>>
>> 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 ?
>
> 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
>  * rework the discovery mechanism for transports and such so that
> it's more OSGI friendly
> I guess those are quite independant on the blueprint stuff you're working on.
>
>> 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/

Mime
View raw message