<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>We are talking about subsystem foo being able to handle OSGi
deployments. The umbrella issue is <a
href="https://issues.jboss.org/browse/AS7-5051">AS7-5051</a> it
is for example already possible to put OSGi metadata in your WAR
(which makes it a Bundle) and deploy that onto JBossWeb. Large
webapps can be modularized in a standard way and use the OSGi
service model to react dynamically to service availability. For
example a webapp may provide payment functionality and choose to
delegate that to OSGi service. Each payment method (i.e. visa,
paypal, etc) could be implemented by a separate bundle which
registers a payment service. At any time payment services can be
added/removed/updated - the webapp would react accordingly.<br>
<br>
Another benefit of deploying a webapp as Bundle is the OSGi Bundle
Lifecycle. From the management console you can start/stop the
webapp (without doing the full deploy/undeploy cycle). This would
change the availability of the web context.<br>
<br>
For this to work the web subsystem has to know whether it is
dealing with an OSGi bundle deployment. The module is setup by the
OSGi layer and not by the web subsystem alone. Currently, we only
need to add a few DUPs and go some different code paths in the web
DUPs. See <a
href="https://github.com/tdiesler/jboss-as/commit/746a95780c916d39ca2fd6be253fa97941b0a299">[AS7-5052]
Allow WAR deployments as OSGi bundles</a>. <br>
<br>
The general idea is that the Module that is associated with a
deployment unit may be provided by the OSGi layer. Further DU
processing should not need to care how the module got created. In
case of an OSGi module dependency resolution is governed by the
OSGi resolver - the thing that guarantees to for consistent class
spaces. <br>
<br>
cheers<br>
-thomas<br>
<br>
</tt>
<div class="moz-cite-prefix">On 07/12/2012 03:55 PM, Bill Burke
wrote:<br>
</div>
<blockquote cite="mid:4FFED763.1040303@redhat.com" type="cite">
<pre wrap="">Just curious,
Are you talking about deployed application EJBs, WARs, etc? or the
actual subsystem modules themselves? For the former, why do the
subsystems need to know about OSGi as it pertains to application
deployments? Wouldn't OSGi class scoping metadata be handled at the
JBoss MOdules level? For the latter, why would subsystems need to
integrate with OSGi when we already have a kernel model and a class
scoping project (jboss modules)?
On 7/11/12 12:16 PM, Thomas Diesler wrote:
</pre>
<blockquote type="cite">
<pre wrap="">If there is no recommended alternative I would add optional dependencies
to integration modules to the osgi subsystem.
On 07/11/2012 05:22 PM, Thomas Diesler wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The poor man's approach could be to promote the org.osgi.core and and
some org.osgi.service APIs to core modules similar to javax.*
On 07/11/2012 05:14 PM, Thomas Diesler wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Folks,
related to [web,ejb,cdi,etc]/osgi integration an issue came up whereby
those ee subsystems don't want to have a dependency on osgi because osgi
is not a core component of the server. Likewise, osgi should not have a
dependency on these ee subsystems because it may be configured to run
independently.
More general if foo and bar are both optional subsystems where do we put
the code that integrates foo and bar. foo-bar integration might require
to add a some DUPs. How are these registered?
cheers
-thomas
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
</pre>
<br>
<br>
</body>
</html>