Embedding Felix into an existing web application

[Don Brown <do...@gmail.com>]

I'm working on several related projects using the same basic approach
- embed Felix into an existing web application.  For my day job, I'm
working on embedding Felix to form the core of a new plugin module,
where plugins are deployed as OSGi bundles.  Our goal is to support
complex, dynamically reloadable plugins that may need to depend on
other plugins, and at the same time, be selectively isolated from the
web application's dependencies.  OSGi seems to be a good fit here.

Our first hurdle was determining how the host application and bundles
would interact without resorting to setting the application
classloader as the parent classloader in Felix.  The solution I
devised used a new project, pkgscanner [1], which scans your classpath
looking for packages to auto-generate the Export-Package directive for
the system bundle.  This allows you to easily expose the packages in
your web application to felix bundles with minimal effort, yet retain
all the benefits of versioned package resolution.

Since I'd like to hide the complexities of OSGi for simple plugins, I
plan to use the bnd tool to auto-generate the manifest, if none
detected, when a plugin is uploaded via the UI.  This will allow
simple plugins to be jars with code and the plugin XML file, and
nothing else.  Advanced users will still have the full capabilities of
OSGi.

Anyways, I'm just about done spiking the design, and thought I'd see
if anyone else was doing anything similar or could foresee any major
roadblocks.

Don

[1] http://pkgscanner.googlecode.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Embedding Felix into an existing web application

[Erik Peterson <ep...@ardec.com>]

Sounds like we are looking to use felix in a similar scenario. I'm not  
familiar with Pax runner so I'll have to check it out. I just did a  
first pass at turning H2 database into an ipojo bundle. It was really  
pretty easy to do given my newness to osgi/felix. Now that osgi  
provides all this flexibility I'm trying get a handle on best  
practices for using it. For example:

1) Testing: We use JUnit and TestNG, how do we integrate them into an  
osgi develop/test/deploy process?
2) What are the good "organizational" principles for deciding how to  
break apart a system into services: horizontal, vertical, hierarchal,  
and mixed strategies are available. How granular should the services be?
3) How can we really push this to do hot-deploy of all services?
4) Consider persistence layer changes. Can we hot-deploy even with  
domain changes? Should we look to make entity/table relationships more  
loosely coupled by delegating the relationship mapping to a separate  
table?
5) Can we deploy on Terracotta? When does it make since to do this and  
what architectural impact might this have.

More questions than answers at this point...

Best,

Erik


On May 31, 2008, at 4:57 AM, Karl Pauls wrote:

>> I'm working on several related projects using the same basic approach
>> - embed Felix into an existing web application.  For my day job, I'm
>> working on embedding Felix to form the core of a new plugin module,
>> where plugins are deployed as OSGi bundles.  Our goal is to support
>> complex, dynamically reloadable plugins that may need to depend on
>> other plugins, and at the same time, be selectively isolated from the
>> web application's dependencies.  OSGi seems to be a good fit here.
>>
>> Our first hurdle was determining how the host application and bundles
>> would interact without resorting to setting the application
>> classloader as the parent classloader in Felix.  The solution I
>> devised used a new project, pkgscanner [1], which scans your  
>> classpath
>> looking for packages to auto-generate the Export-Package directive  
>> for
>> the system bundle.  This allows you to easily expose the packages in
>> your web application to felix bundles with minimal effort, yet retain
>> all the benefits of versioned package resolution.
>
> Cool, I did write something similar a while back but never published
> it because i didn't have the time to polish it enough. I think this is
> a useful tool for certain scenarios.
>
>> Since I'd like to hide the complexities of OSGi for simple plugins, I
>> plan to use the bnd tool to auto-generate the manifest, if none
>> detected, when a plugin is uploaded via the UI.  This will allow
>> simple plugins to be jars with code and the plugin XML file, and
>> nothing else.  Advanced users will still have the full capabilities  
>> of
>> OSGi.
>
> Interesting. Sounds like a good approach.
>
>> Anyways, I'm just about done spiking the design, and thought I'd see
>> if anyone else was doing anything similar or could foresee any major
>> roadblocks.
>
> I don't think there is somebody doing quite that but there is some
> releated work namely, the pax runner and the maybe the pax war
> extender.
>
> As of roadblocks, in my experience it is often not a good idea to just
> make everything available from the classpath as well as exporting
> everything from a bundle. You might run into version problems when
> different bundles export the same package without doing proper
> versioning. In other words, I'd probably would use bnd only to
> generate the imports a given simple plugins needs but not exporting
> anything. Still you might run into some problems when packages are
> available in different versions because you don't know what version a
> simple plugin needs.
>
> Ultimately, it sounds like an interesting approach. Definitely keep us
> posted :-)
>
> regards,
>
> Karl
>
>> Don
>>
>> [1] http://pkgscanner.googlecode.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
> -- 
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> 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 into an existing web application

[Karl Pauls <ka...@gmail.com>]

> I'm working on several related projects using the same basic approach
> - embed Felix into an existing web application.  For my day job, I'm
> working on embedding Felix to form the core of a new plugin module,
> where plugins are deployed as OSGi bundles.  Our goal is to support
> complex, dynamically reloadable plugins that may need to depend on
> other plugins, and at the same time, be selectively isolated from the
> web application's dependencies.  OSGi seems to be a good fit here.
>
> Our first hurdle was determining how the host application and bundles
> would interact without resorting to setting the application
> classloader as the parent classloader in Felix.  The solution I
> devised used a new project, pkgscanner [1], which scans your classpath
> looking for packages to auto-generate the Export-Package directive for
> the system bundle.  This allows you to easily expose the packages in
> your web application to felix bundles with minimal effort, yet retain
> all the benefits of versioned package resolution.

Cool, I did write something similar a while back but never published
it because i didn't have the time to polish it enough. I think this is
a useful tool for certain scenarios.

> Since I'd like to hide the complexities of OSGi for simple plugins, I
> plan to use the bnd tool to auto-generate the manifest, if none
> detected, when a plugin is uploaded via the UI.  This will allow
> simple plugins to be jars with code and the plugin XML file, and
> nothing else.  Advanced users will still have the full capabilities of
> OSGi.

Interesting. Sounds like a good approach.

> Anyways, I'm just about done spiking the design, and thought I'd see
> if anyone else was doing anything similar or could foresee any major
> roadblocks.

I don't think there is somebody doing quite that but there is some
releated work namely, the pax runner and the maybe the pax war
extender.

As of roadblocks, in my experience it is often not a good idea to just
make everything available from the classpath as well as exporting
everything from a bundle. You might run into version problems when
different bundles export the same package without doing proper
versioning. In other words, I'd probably would use bnd only to
generate the imports a given simple plugins needs but not exporting
anything. Still you might run into some problems when packages are
available in different versions because you don't know what version a
simple plugin needs.

Ultimately, it sounds like an interesting approach. Definitely keep us
posted :-)

regards,

Karl

> Don
>
> [1] http://pkgscanner.googlecode.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>



-- 
Karl Pauls
karlpauls@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org