tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Gallimore <>
Subject Re: OpenEJB and OSGi
Date Thu, 02 Jul 2009 22:04:01 GMT
Hi Deryck,

I was just about to type something up about OSGi when I found your e-mail -
sorry I missed it, I was on holiday and forgot to reply when I got back.

Thanks for getting back to me on this. I have been playing around with this
some more, and I've managed to get around using the FileLocator API I think,
by grabbing what we need from the bundle and creating a temporary jar and
deploying that. If I then temporarily comment out the Variables code, I now
have something that starts in both Equinox and Felix.

I think the variable expansion code is definitely nice to have - I'll see if
I can refactor it so that if the variables bundle is available then we use,
otherwise we try and carry on without it. I'll try wrapping it in a
syncronized block too, and see if that sorts out the exception I was having.

I'm also going to see if I can add something to start the various daemons
that you get in "remotable" mode, it seems that xbean-finder can't find the
OpenEJB service classes inside an OSGi bundle, so you need to create these
manually at the moment. I might see if I can patch xbean-finder, or if I
can't, add some code to start these service manually in the
org.apache.openejb.server bundle.

As OSGi support has been discussed a few times now, and we have a pretty
good OSGi bundle now, I think it would be quite nice to make these
improvements, extend our support to other OSGi containers, and add to our
documentation (I'm thinking of a screencast demonstrating all of this in

Anyone have any thoughts on any of this?


On Thu, Jun 11, 2009 at 9:01 AM, Brown, Deryck <>wrote:

> Hi Jonathan,
> Sorry for not responding sooner. This is what happens when you have
> email rules to put postings in a separate folder, and only scan them
> briefly...
> On the issues you encountered:
> Does the ConcurrentModificationException go away if you wrap the body of
> addPropertyVariables in a "synchronized (properties) {...}" block?
> The effect of not adding the System properties to the variables will
> simply prevent variable expansion of these property names in OpenEJB
> properties. So no "${user.home}" in your database URL for example.
> I agree that the use of FileLocator is an unfortunate feature of getting
> Eclipse plug-ins to work with OpenEJB. An alternative would require
> OpenEJB to understand the "bundle:" URI protocol at a much deeper level
> (I'm sure I've seen previous posts on this subject), but I'm not sure
> how you can avoid mapping URIs to real files/paths at some point in the
> process of deploying an application.
> The code that requires org.eclipse.core.variables just relates to my
> need to expand property values with references to values such as
> "${user.home}". It would be possible but tedious to implement variable
> expansion in the plug-in directly (I think I had a version that did this
> originally), but why keep re-inventing the wheel?
> We could probably refactor the code so that org.eclipse.core.variables
> was optional, and the plug-in only loads it when the application
> actively uses variable expansion because properties contain embedded
> references.
> Regards,
> Deryck
> -----Original Message-----
> From: Jonathan Gallimore []
> Sent: 10 May 2009 14:34
> To:
> Subject: Re: OpenEJB and OSGi
> ...
> A couple of issues I noticed when putting this together:
> * I encountered a ConcurrentModificationException caused by adding
> System.getProperties() to a IStringVariableManager, commenting out line
> 44:
> addPropertyVariables(System.getProperties()); in OpenEjbPlugin resolved
> this, and everything seemed to work, but I don't know what the effect of
> this will be - Deryck, do you have any thoughts on this?
> * We make a fair bit of use org.eclipse.core.runtime.FileLocator which
> converts URLs of resources in OSGi bundles to URLs on the file system -
> I think I'm right in thinking that this is an Equinox / Eclipse specific
> thing and probably won't work in other OSGi implementations. I think it
> would be nice if we can find a way of not requiring
> org.eclipse.core.runtime or org.eclipse.core.variables.
> Jon

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message