<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 15/08/2012, at 6:59 PM, Thomas Diesler &lt;<a href="mailto:thomas.diesler@jboss.com">thomas.diesler@jboss.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <div text="#000000" bgcolor="#FFFFFF">
    <tt>&gt; Why would the OSGI bundle not be able to resolve, is it
      because is waiting for another OSGI bundle to be installed?<br>
      <br>
      This is by virtue of the API - BundleContext.install() does not
      resolve the bundle. As the method name suggests, it just installs
      the bundle. <br>
      <br>
      In the hot-deployment case it is debatable whether bundle
      resolution and later bundle activation should be attempted or not.
      By design, the order of bundle deployment is not the
      responsibility of the user but that of the framework. For a
      complex graph of interdependent bundles the user cannot possibly
      be asked to deploy them in the "right order". Instead the API
      allows to INSTALL the complete set (i.e. make the metadata
      available to the resolver) and later activate the bundles as
      needed. There are other triggers for bundle resolution too (e.g.
      resource access)<br>
      <br>
      We currently do resolve/activate during DUP processing on a trial
      basis. For a bundle that only has dedependencies on already
      installed bundles the resolve/activation works fine and the
      services become available. I guess this is the expected hot-deploy
      behaviour. A bundle that cannot resolve - for various reasons, one
      being the user says so - we dont attempt to start the bundle
      either. It would still run through all remaining DUPs but does not
      have a module attached.<br></tt></div></blockquote><div><br></div><div>This sounds very non-deterministic. Just to clarify, are you saying that if the user has a complex bundle deployment with lots of inter-dependencies on startup some may be resolved and some won't, and this may change on subsequent startups depending on the order in which they start?</div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><tt>
      <br>
      Non-OSGi deployments that use jboss-modules metadata to define
      their dependencies (i.e. Dependencies clause in the manifest) have
      that problem too, but worse. A complex system of interdependent
      module deployments is likely not manageable because of this
      ordering issue. Even if the user gets the ordering right the first
      time, on server restart the notion of deployment order is lost and
      very likely initial deployments will fail with no osgi involved.
      Granted that this describes a use case that is not intended to be
      used for user deployments. <br></tt></div></blockquote><div><br></div><div>No, JBoss modules uses MSC services to resolve the dependencies. At container start all deployments are now run as part of the boot ops, so as long as all deployments are present this will always work. We do need a more specified way of saying "Don't start this deployment until another deployment is done", but this is mainly for things like EJB's, not for class loading.&nbsp;</div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><tt>
      <br>
      &gt; the classic one is deployment of JDBC drivers that have an
      OSGI manifest<br>
      <br>
      We already removed the hack that disables OSGi for this case. The
      JDBC driver *is* an OSGi bundle because it contains valid OSGi
      metadata. It gets processed as such and should work as expected.
      All DUP processing is identical as before except the way module
      dependencies are computed and how the Module service is created.
      The only case where an OSGi bundle gets treated as a library jar
      is when it is located in an EAR/lib directory. Bundles contained
      in EARs are otherwise processed as OSGi sub deployments.</tt><br></div></blockquote><div><br></div><div>It sounds like because we have removed the hack JDBC drivers now will not work if they fail to resolve?</div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    <tt>&gt; we should not be allowing the presence of the OSGI
      subsystem to provide a different experience for users that are
      only after EE functionality
      <br>
      <br>
      Agreed, EE deployments should not be effected - and I don't think
      they are. The OSGi subsystem is not activated unless #1 you do so
      by management op #2 you deploy a bundle #3 some component is an
      injection target for the system BundleContext<br>
      <br>
      &gt; We remove OSGI from the default profile, and provide a
      standalone-osgi.xml for users that wish to use OSGI<br>
      <br>
      AFAICS this would remove a few services that are already lazy and
      a few DUPs that deal with bundle deployments. W</tt><tt>e already
      have t</tt><tt>he configuration for a pure OSGi runtime as you
      suggest. Removing the OSGi subsystem from the default profile
      would not solve the need for DUP authors to be aware of OSGi
      deployments and code for the case of unresolved bundle
      deployments.<br></tt></div></blockquote><div><br></div><div>Even if we resolve the module issue I still think that it would be worth making this a separate profile. Like Jaikiran I really don't like the idea of other subsystems having to code around OSGI. Another possibility we could potentially explore is a separate deployment chain for OSGI, so these DUP's do not even run if it is an OSGI deployment.&nbsp;</div><div><br></div><div>Do we have any usage data on how many of our users actually use OSGI? The more I think about it the more I think it makes sense to leave it out of the default profile. Even though you say 'it is not active unless you deploy a bundle', the thing is that many JDBC driver have OSGI metadata, so users that simply want to setup a datasource will still have OSGI activating, which is usually not what they would want.</div><div><br></div><div>Stuart</div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><tt><br>
    </tt><tt>&gt; OSGI deployment that cannot be resolved pause the
      deployment process until such time as they can be
      <br>
      <br>
      Yes, this is very much in line with what I think how it should
      work. The management API should allow the user to specify whether
      a deployment should get resolved/activated too. As a desired side
      effect this could introduce life cycle for any AS7 deployment
      (i.e. start/stop decoupled from deploy/undeploy). I already did
      some work in this direction related to in "<a href="https://issues.jboss.org/browse/AS7-2777">Add notion of
        start/stop for deployments</a>". It builds on top of "<a href="https://issues.jboss.org/browse/AS7-3694">Allow management
        client to associate metadata with DeploymentUnit</a>", which is
      waiting to get <a href="https://github.com/jbossas/jboss-as/pull/2790">pulled</a>.<br>
      <br>
      &gt; which means that there will always be a Module available
      <br>
      <br>
      YES ;-)<br>
      <br>
      cheers<br>
      --thomas<br>
    </tt><br>
    <div class="moz-cite-prefix">On 08/15/2012 07:26 AM, Stuart Douglas
      wrote:<br>
    </div>
    <blockquote cite="mid:2ABFD913-B778-4469-83B8-607BE9BDC902@gmail.com" type="cite">
      <pre wrap="">Why would the OSGI bundle not be able to resolve, is it because is waiting for another OSGI bundle to be installed? And if so, wouldn't it make more sense to pause the deployment process until the bundle can be resolved? Otherwise the behaviour will be different depending on when the bundle is resolved (e.g. if a bundle is resolved late it will not have EJB's deployed, if it is resolved early it will). 

I really hate the way that OSGI takes over and prevents the module being created, I am pretty sure that the number of users that this has caused problems for is larger than the number of users that actually use OSGI (the classic one is deployment of JDBC drivers that have an OSGI manifest). 

I think we really need a solution for this for AS 7.2, because as it currently stands we are primarily an EE app server, and we should not be allowing the presence of the OSGI subsystem to provide a different experience for users that are only after EE functionality. 

To this end, I propose the following: 

- We remove OSGI from the default profile, and provide a standalone-osgi.xml for users that wish to use OSGI, this way OSGI cannot affect users that simply want EE functionality
- OSGI deployment that cannot be resolved pause the deployment process until such time as they can be, by making the POST_MODULE DeploymentUnitPhaseService passive, which means that there will always be a Module available. 

What do you think?

Stuart

On 15/08/2012, at 3:05 PM, Thomas Diesler <a class="moz-txt-link-rfc2396E" href="mailto:thomas.diesler@jboss.com">&lt;thomas.diesler@jboss.com&gt;</a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">Folks,

a quick reminder that you cannot assume a valid Module attachment in 
Phase.POST_MODULE or after.

An OSGi deployment that cannot resolve won't have a Module attached to 
the DU. There is talk about aligning the deployment phase names with 
Bundle life cycle terminology. IMHO Phase.POST_MODULE and Phase.INSTALL 
are not so lucky names because they imply meaning that may not be true. 
For suggested improvement see <a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/AS7-3585">https://issues.jboss.org/browse/AS7-3585</a>

This is related to: <a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/AS7-5376">https://issues.jboss.org/browse/AS7-5376</a>

cheers
--thomas

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________
jboss-as7-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a>
</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>
  </div>

</blockquote></div><br></body></html>