You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Mike Haney <tx...@gmail.com> on 2010/04/04 12:34:19 UTC
Embedding felix - will this approach work?
Brief history - we initially wrote this app last year as pure OSGi running
on Spring DM Server. For a variety of reasons, that didn't work for us, and
we ended up refactoring into a monolithic web app in a single WAR file. We
kept the modularity mostly intact, knowing we needed to go back to a plug-in
based model in the near future - basically we are using our spring
application context as a surrogate for the service registry.
Now it's time to add the plugin capabilities back in, and our goal is to
keep 70% of the functionality in the main web app itself, and just use OSGi
to manage plugins for customizing and extending this app. I've been reading
the page on embedding and playing with a sample project, and so far so
good. Now the tricky part is how to deal with 3rd party libraries used both
within the webapp and within the OSGi environment. Here's where I need to
verify my approach before I dive into the abyss.
As a simple, concrete example, we want to be able to contribute Wicket
components as plugins (this is just one of many plugin areas depending on
3rd party libraries - Drools and Hibernate are 2 other biggies). Since the
wicket jars already exist on the web application classpath, it looks like I
should be able to just pass all the wicket packages (along with any
transitive dependencies) to Felix using the
org.osgi.framework.system.packages.extra property. My understanding is this
will make all those packages available as part of the system bundle, which
conceptually seems like the same thing many frameworks like DM Server do for
things like the servlet api, spring, etc. Am I on the right track here?
A few specific questions:
1) What kind of classpath issues would I need to be aware of using this
approach.
2) Will the system.packages.extra property take wildcards in the value,
similar to a manifest import-package statement? IOW, can I just list
"org.apache.wicket.*", or do I have to list out every single package in
wicket? Also, can I specify versions on these packages like in a manifest?
3) I've already separated out our application-specific interfaces into a
separate bundle, which is included in both the main web app and the bundle
dependencies. I assume this is the correct approach, based on my reading.
4) What about build-time dependencies on 3rd party jars like wicket within
the bundles themselves? It seems like it should be sufficient to just
include the wicket, etc. dependencies in the pom so it can compile against
those classes, but at runtime they will actually be resolved through the
system bundle. Any problems with that, or should I create another bundle
used just for building that exports all of the 3rd party interfaces (i.e.
with a proper OSGi manifest)?
5) The other big hiccup I can see is debugging in Eclipse. Debugging the
main webapp on Tomcat is a no brainer, but I'm trying to figure out the best
method to drop the plugins into our debugged instance of Tomcat, short of
having to do a Maven build each time, then copy the plugins to an autodeploy
directory. Any suggestions for streamlining this process? I think Pax had
a project that let you deploy bundles from an exploded directory instead of
a jar, but I think it relied on the PaxRunner stuff to work. Anything else
similar to this? If I could just point our embedded Felix instance at our
source directory, that would save a lot of time.
Thanks in advance for any advice.
Mike
Re: Embedding felix - will this approach work?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/5/10 1:03, Mike Haney wrote:
> Thanks Richard for your quick response.
>
> Since you are an "internals" guy, could I get your opinion on something
> else? Felix seems to be pretty lightweight as far as the base framework
> goes. I'm thinking about embedding several instances of the framework, to
> break up the work along layer boundaries and provide a better separation of
> concerns. I would probably be looking at 4-5 instances embedded in my app.
> Does this sound feasible without putting undue memory constraints on the
> application? We all know how Java apps can be very memory hungry in
> production environments, and I don't want to make the problem worse.
>
Well, clearly five instances will be worse than one, but I don't think
this should be a significant burden. The overhead for data structures
for holding bundle info shouldn't be much different whether the bundles
are installed into one or N frameworks, but there will be some extra
overhead for framework-related info.
However, we do try to share across instances where possible (e.g., the
event dispatching thread, but we don't currently share all threads). If
you run into any issues, definitely let us know, but other people have
certainly used the Felix framework this way.
-> richard
> On Sun, Apr 4, 2010 at 8:05 AM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> On 4/4/10 6:34, Mike Haney wrote:
>>
>>
>>> Brief history - we initially wrote this app last year as pure OSGi running
>>> on Spring DM Server. For a variety of reasons, that didn't work for us,
>>> and
>>> we ended up refactoring into a monolithic web app in a single WAR file.
>>> We
>>> kept the modularity mostly intact, knowing we needed to go back to a
>>> plug-in
>>> based model in the near future - basically we are using our spring
>>> application context as a surrogate for the service registry.
>>>
>>> Now it's time to add the plugin capabilities back in, and our goal is to
>>> keep 70% of the functionality in the main web app itself, and just use
>>> OSGi
>>> to manage plugins for customizing and extending this app. I've been
>>> reading
>>> the page on embedding and playing with a sample project, and so far so
>>> good. Now the tricky part is how to deal with 3rd party libraries used
>>> both
>>> within the webapp and within the OSGi environment. Here's where I need to
>>> verify my approach before I dive into the abyss.
>>>
>>> As a simple, concrete example, we want to be able to contribute Wicket
>>> components as plugins (this is just one of many plugin areas depending on
>>> 3rd party libraries - Drools and Hibernate are 2 other biggies). Since
>>> the
>>> wicket jars already exist on the web application classpath, it looks like
>>> I
>>> should be able to just pass all the wicket packages (along with any
>>> transitive dependencies) to Felix using the
>>> org.osgi.framework.system.packages.extra property. My understanding is
>>> this
>>> will make all those packages available as part of the system bundle, which
>>> conceptually seems like the same thing many frameworks like DM Server do
>>> for
>>> things like the servlet api, spring, etc. Am I on the right track here?
>>>
>>>
>>>
>> Sounds like it.
>>
>>
>> A few specific questions:
>>
>>> 1) What kind of classpath issues would I need to be aware of using this
>>> approach.
>>>
>>>
>>>
>> As long as the class loader that loads the framework classes has access to
>> the packages you want to provide, then it should work.
>>
>>
>> 2) Will the system.packages.extra property take wildcards in the value,
>>
>>> similar to a manifest import-package statement? IOW, can I just list
>>> "org.apache.wicket.*", or do I have to list out every single package in
>>> wicket? Also, can I specify versions on these packages like in a
>>> manifest?
>>>
>>>
>>>
>> Neither Import-Package, nor system.packages.extra support wildcards. You
>> have to specify them all. The same syntax for Import-Package is used, so you
>> can specify versions.
>>
>>
>> 3) I've already separated out our application-specific interfaces into a
>>
>>> separate bundle, which is included in both the main web app and the bundle
>>> dependencies. I assume this is the correct approach, based on my reading.
>>>
>>>
>>>
>> Sounds like it.
>>
>>
>> 4) What about build-time dependencies on 3rd party jars like wicket within
>>
>>> the bundles themselves? It seems like it should be sufficient to just
>>> include the wicket, etc. dependencies in the pom so it can compile against
>>> those classes, but at runtime they will actually be resolved through the
>>> system bundle. Any problems with that, or should I create another bundle
>>> used just for building that exports all of the 3rd party interfaces (i.e.
>>> with a proper OSGi manifest)?
>>>
>>>
>>>
>> I don't think that is necessary. You could get some benefits if you had a
>> regular bundle and you are using maven-bundle-plugin or BND to generate your
>> bundles, since it will include proper versions for your bundle imports.
>> Also, if there are some packages you do not want your bundles to have access
>> to, then you could exclude them from the exports of your libraries, but
>> otherwise it probably doesn't really matter.
>>
>>
>> 5) The other big hiccup I can see is debugging in Eclipse. Debugging the
>>
>>> main webapp on Tomcat is a no brainer, but I'm trying to figure out the
>>> best
>>> method to drop the plugins into our debugged instance of Tomcat, short of
>>> having to do a Maven build each time, then copy the plugins to an
>>> autodeploy
>>> directory. Any suggestions for streamlining this process? I think Pax
>>> had
>>> a project that let you deploy bundles from an exploded directory instead
>>> of
>>> a jar, but I think it relied on the PaxRunner stuff to work. Anything
>>> else
>>> similar to this? If I could just point our embedded Felix instance at our
>>> source directory, that would save a lot of time.
>>>
>>>
>>>
>> I am not sure the best way to streamline this. The Felix framework supports
>> installing an exploded bundle directory, but you'd still need to manually
>> perform an update inside the framework once the contents changed. Maybe
>> someone has created something to automate that as part of the build process.
>>
>> I admit to not having a lot of practical experience with bundle projects,
>> since I spend most of my time hacking on low-level framework issues, so
>> maybe someone else has better advice on all of these issues.
>>
>> -> richard
>>
>>
>> Thanks in advance for any advice.
>>
>>> Mike
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Embedding felix - will this approach work?
Posted by Mike Haney <tx...@gmail.com>.
Thanks Richard for your quick response.
Since you are an "internals" guy, could I get your opinion on something
else? Felix seems to be pretty lightweight as far as the base framework
goes. I'm thinking about embedding several instances of the framework, to
break up the work along layer boundaries and provide a better separation of
concerns. I would probably be looking at 4-5 instances embedded in my app.
Does this sound feasible without putting undue memory constraints on the
application? We all know how Java apps can be very memory hungry in
production environments, and I don't want to make the problem worse.
On Sun, Apr 4, 2010 at 8:05 AM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 4/4/10 6:34, Mike Haney wrote:
>
>> Brief history - we initially wrote this app last year as pure OSGi running
>> on Spring DM Server. For a variety of reasons, that didn't work for us,
>> and
>> we ended up refactoring into a monolithic web app in a single WAR file.
>> We
>> kept the modularity mostly intact, knowing we needed to go back to a
>> plug-in
>> based model in the near future - basically we are using our spring
>> application context as a surrogate for the service registry.
>>
>> Now it's time to add the plugin capabilities back in, and our goal is to
>> keep 70% of the functionality in the main web app itself, and just use
>> OSGi
>> to manage plugins for customizing and extending this app. I've been
>> reading
>> the page on embedding and playing with a sample project, and so far so
>> good. Now the tricky part is how to deal with 3rd party libraries used
>> both
>> within the webapp and within the OSGi environment. Here's where I need to
>> verify my approach before I dive into the abyss.
>>
>> As a simple, concrete example, we want to be able to contribute Wicket
>> components as plugins (this is just one of many plugin areas depending on
>> 3rd party libraries - Drools and Hibernate are 2 other biggies). Since
>> the
>> wicket jars already exist on the web application classpath, it looks like
>> I
>> should be able to just pass all the wicket packages (along with any
>> transitive dependencies) to Felix using the
>> org.osgi.framework.system.packages.extra property. My understanding is
>> this
>> will make all those packages available as part of the system bundle, which
>> conceptually seems like the same thing many frameworks like DM Server do
>> for
>> things like the servlet api, spring, etc. Am I on the right track here?
>>
>>
>
> Sounds like it.
>
>
> A few specific questions:
>>
>> 1) What kind of classpath issues would I need to be aware of using this
>> approach.
>>
>>
>
> As long as the class loader that loads the framework classes has access to
> the packages you want to provide, then it should work.
>
>
> 2) Will the system.packages.extra property take wildcards in the value,
>> similar to a manifest import-package statement? IOW, can I just list
>> "org.apache.wicket.*", or do I have to list out every single package in
>> wicket? Also, can I specify versions on these packages like in a
>> manifest?
>>
>>
>
> Neither Import-Package, nor system.packages.extra support wildcards. You
> have to specify them all. The same syntax for Import-Package is used, so you
> can specify versions.
>
>
> 3) I've already separated out our application-specific interfaces into a
>> separate bundle, which is included in both the main web app and the bundle
>> dependencies. I assume this is the correct approach, based on my reading.
>>
>>
>
> Sounds like it.
>
>
> 4) What about build-time dependencies on 3rd party jars like wicket within
>> the bundles themselves? It seems like it should be sufficient to just
>> include the wicket, etc. dependencies in the pom so it can compile against
>> those classes, but at runtime they will actually be resolved through the
>> system bundle. Any problems with that, or should I create another bundle
>> used just for building that exports all of the 3rd party interfaces (i.e.
>> with a proper OSGi manifest)?
>>
>>
>
> I don't think that is necessary. You could get some benefits if you had a
> regular bundle and you are using maven-bundle-plugin or BND to generate your
> bundles, since it will include proper versions for your bundle imports.
> Also, if there are some packages you do not want your bundles to have access
> to, then you could exclude them from the exports of your libraries, but
> otherwise it probably doesn't really matter.
>
>
> 5) The other big hiccup I can see is debugging in Eclipse. Debugging the
>> main webapp on Tomcat is a no brainer, but I'm trying to figure out the
>> best
>> method to drop the plugins into our debugged instance of Tomcat, short of
>> having to do a Maven build each time, then copy the plugins to an
>> autodeploy
>> directory. Any suggestions for streamlining this process? I think Pax
>> had
>> a project that let you deploy bundles from an exploded directory instead
>> of
>> a jar, but I think it relied on the PaxRunner stuff to work. Anything
>> else
>> similar to this? If I could just point our embedded Felix instance at our
>> source directory, that would save a lot of time.
>>
>>
>
> I am not sure the best way to streamline this. The Felix framework supports
> installing an exploded bundle directory, but you'd still need to manually
> perform an update inside the framework once the contents changed. Maybe
> someone has created something to automate that as part of the build process.
>
> I admit to not having a lot of practical experience with bundle projects,
> since I spend most of my time hacking on low-level framework issues, so
> maybe someone else has better advice on all of these issues.
>
> -> richard
>
>
> Thanks in advance for any advice.
>>
>> Mike
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Embedding felix - will this approach work?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/4/10 6:34, Mike Haney wrote:
> Brief history - we initially wrote this app last year as pure OSGi running
> on Spring DM Server. For a variety of reasons, that didn't work for us, and
> we ended up refactoring into a monolithic web app in a single WAR file. We
> kept the modularity mostly intact, knowing we needed to go back to a plug-in
> based model in the near future - basically we are using our spring
> application context as a surrogate for the service registry.
>
> Now it's time to add the plugin capabilities back in, and our goal is to
> keep 70% of the functionality in the main web app itself, and just use OSGi
> to manage plugins for customizing and extending this app. I've been reading
> the page on embedding and playing with a sample project, and so far so
> good. Now the tricky part is how to deal with 3rd party libraries used both
> within the webapp and within the OSGi environment. Here's where I need to
> verify my approach before I dive into the abyss.
>
> As a simple, concrete example, we want to be able to contribute Wicket
> components as plugins (this is just one of many plugin areas depending on
> 3rd party libraries - Drools and Hibernate are 2 other biggies). Since the
> wicket jars already exist on the web application classpath, it looks like I
> should be able to just pass all the wicket packages (along with any
> transitive dependencies) to Felix using the
> org.osgi.framework.system.packages.extra property. My understanding is this
> will make all those packages available as part of the system bundle, which
> conceptually seems like the same thing many frameworks like DM Server do for
> things like the servlet api, spring, etc. Am I on the right track here?
>
Sounds like it.
> A few specific questions:
>
> 1) What kind of classpath issues would I need to be aware of using this
> approach.
>
As long as the class loader that loads the framework classes has access
to the packages you want to provide, then it should work.
> 2) Will the system.packages.extra property take wildcards in the value,
> similar to a manifest import-package statement? IOW, can I just list
> "org.apache.wicket.*", or do I have to list out every single package in
> wicket? Also, can I specify versions on these packages like in a manifest?
>
Neither Import-Package, nor system.packages.extra support wildcards. You
have to specify them all. The same syntax for Import-Package is used, so
you can specify versions.
> 3) I've already separated out our application-specific interfaces into a
> separate bundle, which is included in both the main web app and the bundle
> dependencies. I assume this is the correct approach, based on my reading.
>
Sounds like it.
> 4) What about build-time dependencies on 3rd party jars like wicket within
> the bundles themselves? It seems like it should be sufficient to just
> include the wicket, etc. dependencies in the pom so it can compile against
> those classes, but at runtime they will actually be resolved through the
> system bundle. Any problems with that, or should I create another bundle
> used just for building that exports all of the 3rd party interfaces (i.e.
> with a proper OSGi manifest)?
>
I don't think that is necessary. You could get some benefits if you had
a regular bundle and you are using maven-bundle-plugin or BND to
generate your bundles, since it will include proper versions for your
bundle imports. Also, if there are some packages you do not want your
bundles to have access to, then you could exclude them from the exports
of your libraries, but otherwise it probably doesn't really matter.
> 5) The other big hiccup I can see is debugging in Eclipse. Debugging the
> main webapp on Tomcat is a no brainer, but I'm trying to figure out the best
> method to drop the plugins into our debugged instance of Tomcat, short of
> having to do a Maven build each time, then copy the plugins to an autodeploy
> directory. Any suggestions for streamlining this process? I think Pax had
> a project that let you deploy bundles from an exploded directory instead of
> a jar, but I think it relied on the PaxRunner stuff to work. Anything else
> similar to this? If I could just point our embedded Felix instance at our
> source directory, that would save a lot of time.
>
I am not sure the best way to streamline this. The Felix framework
supports installing an exploded bundle directory, but you'd still need
to manually perform an update inside the framework once the contents
changed. Maybe someone has created something to automate that as part of
the build process.
I admit to not having a lot of practical experience with bundle
projects, since I spend most of my time hacking on low-level framework
issues, so maybe someone else has better advice on all of these issues.
-> richard
> Thanks in advance for any advice.
>
> Mike
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org