activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: amq 5.4 and osgi/blueprint
Date Tue, 09 Feb 2010 20:25:50 GMT
I think it would make sense to make the Activator class the real osgi
activator for activemq-core.
I don't really see why we would not do that, given it's the only way
to use additional transports or other extensions afaik.

On Tue, Feb 9, 2010 at 21:05, David Jencks <david_jencks@yahoo.com> wrote:
> See AMQ-2601, rev 908182.
>
> Plain spring recognizes the common annotations @PostConstruct and
> @PreDeploy.
> xbean-spring recognizes the xbean javadoc annotations InitMethod and
> DestroyMethod
> xbean-blueprint now recognizes both.
>
> I did some testing to check xbean-spring still works but it wasn't very
> thorough so if anyone sees a problem please speak up right away.
>
> Also, I added a constructor to the Activator class so it can be used as a
> blueprint bean, and this seems to work just as well as it being an actual
> BundleActivator.
>
> thanks
> david jencks
>
> On Feb 6, 2010, at 8:01 AM, David Jencks wrote:
>
>>
>> On Feb 6, 2010, at 2:54 AM, Hiram Chirino wrote:
>>
>>> 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.
>>
>> 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/
>>
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message