<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 08/15/2012 02:25 PM, Stuart Douglas
wrote:<br>
</div>
<blockquote
cite="mid:2CC33C95-99F2-4FF2-B649-2BA2D1675FD8@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 15/08/2012, at 9:32 PM, Thomas Diesler <<a
moz-do-not-send="true"
href="mailto:thomas.diesler@jboss.com">thomas.diesler@jboss.com</a>>
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"> <br>
<div class="moz-cite-prefix">On 08/15/2012 11:20 AM, Stuart
Douglas wrote:<br>
</div>
<blockquote
cite="mid:7FAB89A5-233F-49DA-9177-44461AE7F8DA@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 15/08/2012, at 6:59 PM, Thomas Diesler <<a
moz-do-not-send="true"
href="mailto:thomas.diesler@jboss.com">thomas.diesler@jboss.com</a>>
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>> 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>
</div>
</blockquote>
<tt>Yes, this is a long outstanding issue [<a
moz-do-not-send="true"
href="https://issues.jboss.org/browse/AS7-378">AS7-378</a>].
I still have no guarantee that all bundles in a given set
have been INSTALLED (in OSGi terminology) / have completed
the Phase.REGISTER phase (in AS7 terminology) when the one
bundle hits the BundleResolveProcessor. The framework
records the persistent bundle state and on restart it is a
requirement that all persistent bundles reach their
respective target state for successful framework
initialization. There is a little more detail to it and
I'd be more than happy to work with you to find a
consistent solution. We can take up this topic in another
osgi specific thread if you like.<br>
</tt></div>
</blockquote>
<div><br>
</div>
<div>That would be good. It will probably be a long running
thread, but this is something that I think we really need to
sort out.</div>
</div>
</blockquote>
<br>
Thanks. I'd ping you late Aug when I get back from holiday. We could
start with a short call where I can fill you in on the details.<br>
<blockquote
cite="mid:2CC33C95-99F2-4FF2-B649-2BA2D1675FD8@gmail.com"
type="cite">
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> </tt>
<blockquote
cite="mid:7FAB89A5-233F-49DA-9177-44461AE7F8DA@gmail.com"
type="cite">
<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. <br>
</div>
</div>
</blockquote>
<tt>Considering use case: moduleA depends on moduleB. On
restart both deployments are processed in parallel. Even
with 100 other deployments in between it is guaranteed
that moduleA wont run into "missing service on next phase"
error because the module service for B has not been
installed? If so I take back the above prediction on
restart, but still hold the unmanageable claim because
ordering is delegated to the user (i.e. he must get it
right the first time).<br>
<br>
</tt></div>
</blockquote>
<div><br>
</div>
<div>EE deployments generally don't have 100 other deployment
dependencies. If they are complicated the user can simply stop
the server and dump them all into the deployments directory,
or deploy them in a composite op. Either way, it is
deterministic, and it will fail hard on error, it will not
just proceed with reduced functionality if something is
missing. There is definitely still functionality that could
be added here though, such as the ability to wait for another
deployment before proceeding, rather than simply failing if it
is not present. <br>
</div>
</div>
</blockquote>
The fail if not present is my concern if the missing deployment is
part of the same set.<br>
<blockquote
cite="mid:2CC33C95-99F2-4FF2-B649-2BA2D1675FD8@gmail.com"
type="cite">
<div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> </tt>
<blockquote
cite="mid:7FAB89A5-233F-49DA-9177-44461AE7F8DA@gmail.com"
type="cite">
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> <br>
> 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>
</div>
</blockquote>
<tt><br>
If they fail to resolve it would be because a requirement
specified by the JDBC driver cannot be satisfied (e.g.
wrong execution environment, missing package wire). I'd
say the deployment of that driver should fail at resolve
time because it would not work anyway because of the
missing wire to a valid capability. Please don't forget
that the requirements given by author should be honoured
and satisfied if you want the driver to work - they should
not be ignored or replaced by some made up hard wires that
happen to work. In this respect a JDBC driver is no
different to any other OSGi bundle.<br>
<br>
</tt></div>
</blockquote>
<div><br>
</div>
<div>Yes, but in most cases the end user does not expect any
JDBC/OSGI interaction. As far as they are concerned they are
just deploying a database driver, it would not even occur to
them that it has OSGI implications.</div>
</div>
</blockquote>
Agreed, the user should not care - but the runtime should care about
the requirements authored into the driver. It should process them
accordingly and fail if they cannot be satisfied. Otherwise the
driver may not work as intended by the author. <br>
<blockquote
cite="mid:2CC33C95-99F2-4FF2-B649-2BA2D1675FD8@gmail.com"
type="cite">
<div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> </tt>
<blockquote
cite="mid:7FAB89A5-233F-49DA-9177-44461AE7F8DA@gmail.com"
type="cite">
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"> <br>
<tt>> 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>
> 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. <br>
</div>
</div>
</blockquote>
<tt>The purpose of OSGi integration in AS7 is to make
middleware services that come with AS7 available to
modular applications that use the OSGi standard and vice
versa (i.e. make OSGi services available to EE
components). We are not trying to build a standalone OSGi
runtime and compete with <a moz-do-not-send="true"
href="http://www.eclipse.org/virgo/">Virgo</a>, <a
moz-do-not-send="true" href="http://karaf.apache.org/">Karaf</a>,
etc. Instead, we are competing against WebSphere,
WebLogic, Glassfish - which AFAIK all use OSGi as their
bottom most layer and increasingly so make this tech
available to user deployments. From the business
perspective the ability to architect non-trivial modular
applications in a standard way is a requirement on the
product sheet. <br>
</tt></div>
</blockquote>
<div><br>
</div>
<div>If you are just worried about the product sheet then having
this available as a separate profile does not really make any
difference. It is still something that we are capable of, its
just not in the default profile (like JMS and CORBA for
instance). <br>
</div>
</div>
</blockquote>
Yes, we could have the profile discussion. A possibility is an OSGi
profile with all the subsystems that are supposed to be able to
handle bundle deployments (i.e. web, ejb3, cdi, connector)<br>
<blockquote
cite="mid:2CC33C95-99F2-4FF2-B649-2BA2D1675FD8@gmail.com"
type="cite">
<div>
<div><br>
</div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> </tt>
<blockquote
cite="mid:7FAB89A5-233F-49DA-9177-44461AE7F8DA@gmail.com"
type="cite">
<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>
</blockquote>
<tt>I have download stats on sourceforge for the jbosgi
umbrella which are <a moz-do-not-send="true"
href="http://sourceforge.net/projects/jboss/files/JBossOSGi/stats/timeline?dates=2012-01-01+to+2012-08-15">around
3000/month</a>. I also know of a few large EAP accounts
that are using this tech or have it as a decision maker
for EAP yes/no. The reason that many JDBC drivers have
OSGi metadata is because they *are* OSGi bundles and want
their requirements to be honoured in a given runtime. OSGi
subsystem startup should be quick and flawless and those
driver bundles should work seamless in AS7. They currently
do AFAIK - if not I'd be interested in the details. </tt></div>
</blockquote>
<div><br>
</div>
<div>I just want to make sure that OSGI gives both deterministic
behaviour for OSGI deployments, and does not force other
subsystems to have to work around it with the if(module ==
null) hack.</div>
</div>
</blockquote>
I agree its a hack. It would go away if any deployment could have
its RESOLVE state deferred. Out of this might also fall the ability
to start/stop any deployment - whatever that may mean in the context
of the deployment.<br>
<blockquote
cite="mid:2CC33C95-99F2-4FF2-B649-2BA2D1675FD8@gmail.com"
type="cite">
<div>
<div><br>
</div>
<div>I think that if there is never going to be a module then it
needs to go through its own deployment chain, as it is just
going to cause problems for every other processor in
POST_MODULE onwards that expects there will be one. If there
is potentially going to be a module at some point then the
chain should wait for the module to be available, because to
do otherwise basically invites non-determistic behaviour which
is really not something we want.</div>
</div>
</blockquote>
Yes, the chain should wait for the module. The deploy management op
should succeed with a descriptive status. The management API should
support "just install", "install+activate", "activate/deactivate" -
resolve can be implicit.<br>
<blockquote
cite="mid:2CC33C95-99F2-4FF2-B649-2BA2D1675FD8@gmail.com"
type="cite">
<div>
<div> </div>
<div><br>
</div>
<div>Just to be clear, I have nothing against OSGI, but I really
thing we need to make sure it 'plays nice' with everything
else. <br>
</div>
</div>
</blockquote>
Great ;-)<br>
<blockquote
cite="mid:2CC33C95-99F2-4FF2-B649-2BA2D1675FD8@gmail.com"
type="cite">
<div>
<div><br>
</div>
<div>Another thought, if we do implement passive deployments
(i.e. deployments that wait for a service to become available)
this code is also needed for HA singleton deployments, and any
sort of inter-deployment dependency mechanism above the class
loading level that we already have, so this solution
potentially has other uses. <br>
</div>
</div>
</blockquote>
Yes, that would certainly narrow the gap between osgi and other type
of deployments. I believe that any runtime that supports modular
user deployments would naturally have similar
requirements/functionality as an OSGi runtime.<br>
<blockquote
cite="mid:2CC33C95-99F2-4FF2-B649-2BA2D1675FD8@gmail.com"
type="cite">
<div>
<div><br>
</div>
<div>Stuart</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> <br>
</tt>
<blockquote
cite="mid:7FAB89A5-233F-49DA-9177-44461AE7F8DA@gmail.com"
type="cite">
<div>
<div><br>
</div>
<div>Stuart</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt><br>
</tt><tt>> 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 moz-do-not-send="true"
href="https://issues.jboss.org/browse/AS7-2777">Add
notion of start/stop for deployments</a>". It
builds on top of "<a moz-do-not-send="true"
href="https://issues.jboss.org/browse/AS7-3694">Allow
management client to associate metadata with
DeploymentUnit</a>", which is waiting to get <a
moz-do-not-send="true"
href="https://github.com/jbossas/jboss-as/pull/2790">pulled</a>.<br>
<br>
> 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 moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:thomas.diesler@jboss.com"><thomas.diesler@jboss.com></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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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>
</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>
</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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
</pre>
</body>
</html>