I can't think of any potential problems either, so I gave it back its
default constructor and made it the Bundle-Activator for activemq-core.
many thanks
david jencks
On Feb 9, 2010, at 12:25 PM, Guillaume Nodet wrote:
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 <[email protected]>
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
<[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/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
