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
Eclipse).
Anyone have any thoughts on any of this?
Jon
On Thu, Jun 11, 2009 at 9:01 AM, Brown, Deryck <deryck.br...@ziebel.biz>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 [mailto:jonathan.gallim...@gmail.com]
> Sent: 10 May 2009 14:34
> To: users@openejb.apache.org
> 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
>
