<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/17/2012 10:01 AM, Neubauer. Rico
wrote:<br>
</div>
<blockquote
cite="mid:0AE708E31B1FC34CB1946AB080198368CF485DA6@dedcexch02.seeburger.de"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<style>
<!--
@font-face
{font-family:Calibri}
@font-face
{font-family:Tahoma}
@font-face
{font-family:Consolas}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif"}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline}
pre
{margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New"}
tt
{font-family:"Courier New"}
span.HTMLVorformatiertZchn
{font-family:"Consolas","serif"}
span.E-MailFormatvorlage20
{font-family:"Calibri","sans-serif";
color:#1F497D}
.MsoChpDefault
{font-size:10.0pt}
@page WordSection1
{margin:70.85pt 70.85pt 2.0cm 70.85pt}
div.WordSection1
{}
-->
</style>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">Hi all,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">Monitoring this discussion for a
while now and wanted to share my experience as a software
integrator from the user perspective - based on JBoss
7.1.1.FINAL and 7.1.2.EAP.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">Some figures: We have a quite
complex system, consisting of currently 243 OSGi-bundles, 60
enterprise bundles (mostly EARs, some WARs and SARs) and
about 5 JBoss-modules with heavy dependency relations
between them. Especially we have EARs depending upon
bundles, as well as bundles accessing enterprise
functionalities.</span></p>
</div>
</blockquote>
<small><tt>Thanks Rico, just the feedback we need ;-)</tt><br>
</small>
<blockquote
cite="mid:0AE708E31B1FC34CB1946AB080198368CF485DA6@dedcexch02.seeburger.de"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">In the meantime, after having
resolved a bunch of issues , we are quite happy with the
OSGi-deployment. This is true for 7.1.1, not yet for 7.1.2
(Thomas maybe you remember me reporting a bunch of bugs on
that version). Deployment of OSGi-bundles works fine, all
get activated correctly and all their dependencies get
resolved.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">However the deployment of the
enterprise archives gave us head-aches and currently is only
possible by a workaround for us. The problem is that the
enterprise archives DO need to be deployed in the correct
order, or they will fail due to missing dependencies, which
then gets not resolved in the end. The way we are actually
doing this is to start-up with deployment attribute
enabled=”false” for the enterprise deployments and then
handle their activation on our own during runtime after the
OSGi-container finished its deployment.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">So to sum it up:</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">- Am I satisfied with
OSGi-bundle-deployment? Yes.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">- Am I satisfied with how the
overall app-server starts up with all its sub-systems and
deployments: Not at all.</span></p>
</div>
</blockquote>
<small><tt>Ok. We all agree that this needs to get sorted a.s.a.p.
Due to the parallel nature in which we handle our deployment its
a non-trivial task. As a temporary work around we could consider
resolving all persistent bundles in one go on server restart.
With this the resolver would at least have a chance to produce a
consistent result, it may however not be the same as with the
last server run. What do you think? <br>
</tt></small>
<blockquote
cite="mid:0AE708E31B1FC34CB1946AB080198368CF485DA6@dedcexch02.seeburger.de"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">So I encourage you to have a
look into the integration of the sub-systems, so they work
together in seamless and predictable a way, I think this is
what an app-server user expects.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">One personal word regarding the
short discussion about “should we take out the
OSGI-container of the default profile”: From my pov, this
will not solve anything. From my experience major vendors
(also us) going into OSGi’s direction, so this is sth. that
will definitely need to get supported by a recent
app-server.</span></p>
</div>
</blockquote>
<small><tt>Agreed. It should stay in the default profile and we
should promote modularity for non-trivial apps. Our competition
is going in that direction too, IMHO because it makes sense.
Yes, OSGi should work seamless with the other subsystems. OSGi
services should be able to take advantage of the midleware
services the appserver provides and EE components should be able
to leverage functionality coming from OSGi services.<br>
<br>
Please continue to make your issues known - this is very helpful
;-)<br>
</tt></small>
<blockquote
cite="mid:0AE708E31B1FC34CB1946AB080198368CF485DA6@dedcexch02.seeburger.de"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">Best Regards,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US">Rico Neubauer (JBoss forum
screen name MrEasy)</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D" lang="EN-US"> </span></p>
<div>
<div style="border:none; border-top:solid #B5C4DF 1.0pt;
padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:35.4pt"><b><span
style="font-size:10.0pt;
font-family:"Tahoma","sans-serif""
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;
font-family:"Tahoma","sans-serif""
lang="EN-US"> <a class="moz-txt-link-abbreviated" href="mailto:jboss-as7-dev-bounces@lists.jboss.org">jboss-as7-dev-bounces@lists.jboss.org</a>
[<a class="moz-txt-link-freetext" href="mailto:jboss-as7-dev-bounces@lists.jboss.org">mailto:jboss-as7-dev-bounces@lists.jboss.org</a>] <b>On
Behalf Of </b>Stuart Douglas<br>
<b>Sent:</b> Fri</span><span style="font-size:10.0pt;
font-family:"Tahoma","sans-serif"">day,
August 17, 2012 2:16 AM<br>
<b>To:</b> Thomas Diesler<br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>
<b>Subject:</b> Re: [jboss-as7-dev] NPE in POST_MODULE
processors</span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">On
17/08/2012, at 1:42 AM, Thomas Diesler <<a
moz-do-not-send="true"
href="mailto:thomas.diesler@jboss.com">thomas.diesler@jboss.com</a>>
wrote:</p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><tt><span
style="font-size:10.0pt">Regarding ...</span></tt></p>
<p class="MsoNormal" style="margin-left:35.4pt"><tt><i><span
style="font-size:10.0pt">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?</span></i></tt></p>
<p class="MsoNormal" style="margin-left:35.4pt"><tt><span
style="font-size:10.0pt">With a complex set of bundle
deployments the user will have to deploy them in a
known order (which is a problem in itself). There is
pull request
<a moz-do-not-send="true"
href="https://github.com/jbossas/jboss-as/pull/2790">#2790</a>
waiting that will allow the management client to have
control over the auto start behaviour. So a user could
first install the complete set in multiple operations
and later explicitly start a selected set of bundles.
This would overcome the order issue on first deploy.</span></tt></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">I really
don't like this solution. I think that the best solution
here is passive deployments, that don't start POST_MODULE
until all their dependencies are available. In this case
it does not have to be a explicit dependency on potential
future bundles, but you you could have a 'resolved'
service that acts as a gate, once OSGI has resolved the
bundle it creates this service, which will then trigger
the deployment to continue.</p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:10.0pt; font-family:"Courier
New""><br>
<tt>Once the bundles are installed and activated the
framework records their respective state. On server
restart these persistent bundles are deployed in an
arbitrary order but there is a guarantee backed into
the Framework integration layer that ensures that the
first resolve attempt is made after all persistent
bundles have been installed. From the resolve
perspective order also matters - you might get
different wiring results depending on the order you
resolve the bundles. One possible approach might be to
resolve the full set of persistent bundles at once,
but the guarantee for an identical wiring is still
weak. A better approach would be to always resolve in
a known order (i.e. sort by bundle id). The still
better solution would be to persist the last known
wiring graph and restore that on startup. Currently,
the persistent bundles are resolved in the order they
hit the BundleResolveProcessor which is arbitrary
AFAIK.</tt></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">I think that
this needs to be deterministic, otherwise we will end up
with a situation where deploying the same thing to a
domain results in different wirings for each server in the
domain. Persisting the wiring does not really help in this
case. IMHO any form of non-determinism is a serious bug.</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Stuart</p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<div>
<p class="MsoNormal" style="margin-right:0cm;
margin-bottom:12.0pt; margin-left:35.4pt">
<span style="font-size:10.0pt; font-family:"Courier
New""><br>
<tt>I have written up the complete subsystem activation
process in <a moz-do-not-send="true"
href="https://community.jboss.org/wiki/OSGiSubsystemActivationProcess">
this article</a>. It contains the known issues and
ideas for possible solutions. Perhaps we can start
from there to find a more consistent solution.</tt></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<div>
<p class="MsoNormal" style="margin-right:0cm;
margin-bottom:12.0pt; margin-left:35.4pt">
<tt><span style="font-size:10.0pt">cheers</span></tt><span
style="font-size:10.0pt; font-family:"Courier
New""><br>
<tt>--thomas </tt></span></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">On
08/15/2012 01:32 PM, Thomas Diesler wrote:</p>
</div>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">On
08/15/2012 11:20 AM, Stuart Douglas wrote:</p>
</div>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">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:</p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><tt><span
style="font-size:10.0pt">> Why would the
OSGI bundle not be able to resolve, is it
because is waiting for another OSGI bundle to
be installed?</span></tt><span
style="font-size:10.0pt;
font-family:"Courier New""><br>
<br>
<tt>This is by virtue of the API -
BundleContext.install() does not resolve the
bundle. As the method name suggests, it just
installs the bundle.
</tt><br>
<br>
<tt>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)</tt><br>
<br>
<tt>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.</tt></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">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?</p>
</div>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt"><tt><span
style="font-size:10.0pt">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.</span></tt><span
style="font-size:10.0pt; font-family:"Courier
New""><br>
<br>
</span></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:10.0pt; font-family:"Courier
New""><br>
<tt>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. </tt></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">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.
</p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><tt><span
style="font-size:10.0pt">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).</span></tt><span
style="font-size:10.0pt; font-family:"Courier
New""><br>
<tt> </tt><br>
<br>
</span></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:10.0pt; font-family:"Courier
New""><br>
<tt>> the classic one is deployment of JDBC
drivers that have an OSGI manifest</tt><br>
<br>
<tt>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></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">It
sounds like because we have removed the hack JDBC
drivers now will not work if they fail to resolve?</p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:10.0pt; font-family:"Courier
New""><br>
<tt>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.</tt><br>
<br>
<br>
</span></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<tt><span style="font-size:10.0pt">> we should
not be allowing the presence of the OSGI
subsystem to provide a different experience for
users that are only after EE functionality
</span></tt><span style="font-size:10.0pt;
font-family:"Courier New""><br>
<br>
<tt>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</tt><br>
<br>
<tt>> We remove OSGI from the default profile,
and provide a standalone-osgi.xml for users that
wish to use OSGI</tt><br>
<br>
<tt>AFAICS this would remove a few services that
are already lazy and a few DUPs that deal with
bundle deployments. We already have the
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.</tt></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">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.
</p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><tt><span
style="font-size:10.0pt">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. </span>
</tt><span style="font-size:10.0pt;
font-family:"Courier New""><br>
<br>
</span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">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.</p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><tt><span
style="font-size:10.0pt">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.
</span></tt><span style="font-size:10.0pt;
font-family:"Courier New""><br>
<br>
</span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Stuart</p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<div>
<p class="MsoNormal" style="margin-right:0cm;
margin-bottom:12.0pt; margin-left:35.4pt">
<span style="font-size:10.0pt;
font-family:"Courier New""><br>
<tt>> OSGI deployment that cannot be resolved
pause the deployment process until such time as
they can be
</tt><br>
<br>
<tt>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>.</tt><br>
<br>
<tt>> which means that there will always be a
Module available </tt><br>
<br>
<tt>YES ;-)</tt><br>
<br>
<tt>cheers</tt><br>
<tt>--thomas</tt></span></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">On
08/15/2012 07:26 AM, Stuart Douglas wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;
margin-bottom:5.0pt">
<pre style="margin-left:35.4pt">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). </pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">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). </pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">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. </pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">To this end, I propose the following: </pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">- 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</pre>
<pre style="margin-left:35.4pt">- 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. </pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">What do you think?</pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">Stuart</pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">On 15/08/2012, at 3:05 PM, Thomas Diesler <a moz-do-not-send="true" href="mailto:thomas.diesler@jboss.com"><thomas.diesler@jboss.com></a> wrote:</pre>
<pre style="margin-left:35.4pt"> </pre>
<blockquote style="margin-top:5.0pt;
margin-bottom:5.0pt">
<pre style="margin-left:35.4pt">Folks,</pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">a quick reminder that you cannot assume a valid Module attachment in </pre>
<pre style="margin-left:35.4pt">Phase.POST_MODULE or after.</pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">An OSGi deployment that cannot resolve won't have a Module attached to </pre>
<pre style="margin-left:35.4pt">the DU. There is talk about aligning the deployment phase names with </pre>
<pre style="margin-left:35.4pt">Bundle life cycle terminology. IMHO Phase.POST_MODULE and Phase.INSTALL </pre>
<pre style="margin-left:35.4pt">are not so lucky names because they imply meaning that may not be true. </pre>
<pre style="margin-left:35.4pt">For suggested improvement see <a moz-do-not-send="true" href="https://issues.jboss.org/browse/AS7-3585">https://issues.jboss.org/browse/AS7-3585</a></pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">This is related to: <a moz-do-not-send="true" href="https://issues.jboss.org/browse/AS7-5376">https://issues.jboss.org/browse/AS7-5376</a></pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">cheers</pre>
<pre style="margin-left:35.4pt">--thomas</pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">-- </pre>
<pre style="margin-left:35.4pt">xxxxxxxxxxxxxxxxxxxxxxxxxxxx</pre>
<pre style="margin-left:35.4pt">Thomas Diesler</pre>
<pre style="margin-left:35.4pt">JBoss OSGi Lead</pre>
<pre style="margin-left:35.4pt">JBoss, a division of Red Hat</pre>
<pre style="margin-left:35.4pt">xxxxxxxxxxxxxxxxxxxxxxxxxxxx</pre>
<pre style="margin-left:35.4pt"> </pre>
<pre style="margin-left:35.4pt">_______________________________________________</pre>
<pre style="margin-left:35.4pt">jboss-as7-dev mailing list</pre>
<pre style="margin-left:35.4pt"><a moz-do-not-send="true" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a></pre>
<pre style="margin-left:35.4pt"><a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a></pre>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<pre style="margin-left:35.4pt">-- </pre>
<pre style="margin-left:35.4pt">xxxxxxxxxxxxxxxxxxxxxxxxxxxx</pre>
<pre style="margin-left:35.4pt">Thomas Diesler</pre>
<pre style="margin-left:35.4pt">JBoss OSGi Lead</pre>
<pre style="margin-left:35.4pt">JBoss, a division of Red Hat</pre>
<pre style="margin-left:35.4pt">xxxxxxxxxxxxxxxxxxxxxxxxxxxx </pre>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<pre style="margin-left:35.4pt">-- </pre>
<pre style="margin-left:35.4pt">xxxxxxxxxxxxxxxxxxxxxxxxxxxx</pre>
<pre style="margin-left:35.4pt">Thomas Diesler</pre>
<pre style="margin-left:35.4pt">JBoss OSGi Lead</pre>
<pre style="margin-left:35.4pt">JBoss, a division of Red Hat</pre>
<pre style="margin-left:35.4pt">xxxxxxxxxxxxxxxxxxxxxxxxxxxx </pre>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
</p>
<pre style="margin-left:35.4pt">-- </pre>
<pre style="margin-left:35.4pt">xxxxxxxxxxxxxxxxxxxxxxxxxxxx</pre>
<pre style="margin-left:35.4pt">Thomas Diesler</pre>
<pre style="margin-left:35.4pt">JBoss OSGi Lead</pre>
<pre style="margin-left:35.4pt">JBoss, a division of Red Hat</pre>
<pre style="margin-left:35.4pt">xxxxxxxxxxxxxxxxxxxxxxxxxxxx </pre>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<br>
<br>
<br>
...<br>
<br>
<table id="table1" style="border-collapse:collapse" width="100%"
border="0">
<tbody>
<tr>
<td style="border-bottom-style:double;
border-bottom-width:3px" width="272"> </td>
<td style="border-bottom-style:double;
border-bottom-width:3px" width="45"> </td>
<td style="border-bottom-style:double;
border-bottom-width:3px"> </td>
</tr>
</tbody>
</table>
<br>
<br>
<table id="table1" style="border-collapse:collapse" width="100%"
border="0">
<tbody>
<tr>
<td width="272"><font color="#808080" face="Arial" size="1"><b>SEEBURGER
AG</b></font></td>
<td width="45"> </td>
<td><font color="#808080" face="Arial" size="1">Vorstand/Seeburger
Executive Board:</font></td>
</tr>
<tr>
<td width="272"><font color="#808080" face="Arial" size="1">Sitz
der Gesellschaft/Registered Office:</font></td>
<td width="45"> </td>
<td><font color="#808080" face="Arial" size="1">Bernd
Seeburger, Axel Haas, Michael Kleeberg</font></td>
</tr>
<tr>
<td width="272"><font color="#808080" face="Arial" size="1">Edisonstr.
1</font></td>
<td width="45"> </td>
<td><br>
</td>
</tr>
<tr>
<td width="272"><font color="#808080" face="Arial" size="1">D-75015
Bretten</font></td>
<td width="45"><br>
</td>
<td><font color="#808080" face="Arial" size="1">Vorsitzender
des Aufsichtsrats/Chairperson of the Seeburger
Supervisory Board:</font></td>
</tr>
<tr>
<td width="272"><font color="#808080" face="Arial" size="1">Tel.:
07252 / 96 - 0</font></td>
<td width="45"><br>
</td>
<td><font color="#808080" face="Arial" size="1">Dr. Franz
Scherer</font></td>
</tr>
<tr>
<td width="272"><font color="#808080" face="Arial" size="1">Fax:
07252 / 96 - 2222</font></td>
<td width="45"><br>
</td>
<td><br>
</td>
</tr>
<tr>
<td width="272"><font color="#808080" face="Arial" size="1">Internet:
<a class="moz-txt-link-freetext" href="http://www.seeburger.de">http://www.seeburger.de</a></font></td>
<td width="45"><br>
</td>
<td><font color="#808080" face="Arial" size="1">Registergericht/Commercial
Register:</font></td>
</tr>
<tr>
<td width="272"><font color="#808080" face="Arial" size="1">e-mail:
<a class="moz-txt-link-abbreviated" href="mailto:info@seeburger.de">info@seeburger.de</a></font></td>
<td width="45"><br>
</td>
<td><font color="#808080" face="Arial" size="1">HRB 240708
Mannheim</font></td>
</tr>
</tbody>
</table>
<p><font face="Arial" size="2"><br>
</font></p>
<p align="justify"><font color="#808080" face="Arial" size="1">Dieses
E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet
ist und kann vertrauliches bzw. unter das Berufsgeheimnis
fallendes Material enthalten. Jegliche darin enthaltene
Ansicht oder Meinungsäußerung ist die des Autors und stellt
nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER
AG dar. Sind Sie nicht der Empfänger, so haben Sie diese
E-Mail irrtümlich erhalten und jegliche Verwendung,
Veröffentlichung, Weiterleitung, Abschrift oder jeglicher
Druck dieser E-Mail ist strengstens untersagt. Weder die
SEEBURGER AG noch der Absender ( Neubauer. Rico ) übernehmen
die Haftung für Viren; es obliegt Ihrer Verantwortung, die
E-Mail und deren Anhänge auf Viren zu prüfen.
<br>
<br>
</font></p>
<font color="#808080" face="Arial" size="1">
<p align="justify"><font color="#808080" face="Arial" size="1">The
present email addresses only the addressee which it targets
and may contain confidential material that may be protected
by the professional secret. The opinions reflected herein
are not necessarily the one of the SEEBURGER AG. If you are
not the addressee, you have accidentally got this email and
are not enabled to use, publish, forward, copy or print it
in any way. Neither SEEBURGER AG , nor the sender (Neubauer.
Rico) are liable for viruses, being your own responsibility
to check this email and its attachments for this purpose.
<br>
<br>
</font></p>
</font>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
</pre>
</body>
</html>