<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/21/2012 02:35 AM, Stuart Douglas
wrote:<br>
</div>
<blockquote
cite="mid:7692410A-395A-4FB1-B7A1-69271D5C1CD4@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 18/08/2012, at 2:22 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>Just to clarify,
for non-osgi deployments on server restart we process them
in parallel. For a large set, deploymentA could race many
phases ahead of deploymentB with no particular order in
which these deployments are processed, right?<br>
</tt></div>
</blockquote>
<div><br>
</div>
<div>Yes, unless there are inter-module class loading
dependencies, in which case a deployment will wait for the
deployment it depends on to finish MODULIZE. <br>
</div>
</div>
</blockquote>
How do you guarantee that you don't run into JBAS014771: Services
with missing/unavailable dependencies?<br>
<blockquote
cite="mid:7692410A-395A-4FB1-B7A1-69271D5C1CD4@gmail.com"
type="cite">
<div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> <br>
With osgi deployments we see the resolve problem because
there is a central entity (i.e. the resolver) which works
on the complete set of metadata of the installed
deployments, which implies some sort of processing order.
The minimum requirement would be that all deployments in a
given set get processed by one phase before any deployment
moves on to the next phase.<br>
</tt></div>
</blockquote>
<div><br>
</div>
<div>I think this should be doable. When the first deployment
causes the OSGI subsystem to start, it should be possible to
read the model, and add a dependency on the PARSE phase of
every deployment. Each OSGI deployment could then a dependency
on the resolver for their PARSE phase. This should allow the
resolver to start when it know that every deployment has hit
the end of PARSE and no further. <br>
</div>
</div>
</blockquote>
In <a
href="https://community.jboss.org/wiki/OSGiSubsystemActivationProcess">this
article</a> I explain<br>
<blockquote><i>The whole Framework activation process would be easy
and straight forward if we could model the bootstrap phase
services with dependencies on their respective Bundle services.
This however cannot be done because once the Framework is active
it is perfectly valid to uninstall any Bundle - this should not
cause the Framework to go down.<br>
</i></blockquote>
The general problem is that I currently cannot have a subsystem
service with a dependency on a deployment service that may go away
at runtime. One idea to solve this is to introduce the notion of a <a
href="https://issues.jboss.org/browse/MSC-120">weak service
dependency</a> with the following semantic <br>
<ul>
<li>serviceA depends on serviceB with DependencyType.WEAK</li>
<li>serviceA starts when serviceB has started</li>
<li>serviceA stays UP when serviceB gets removed</li>
</ul>
<blockquote
cite="mid:7692410A-395A-4FB1-B7A1-69271D5C1CD4@gmail.com"
type="cite">
<div>
<div><br>
</div>
<div><br>
</div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> <br>
If the initial statement is correct it is possible that
other subsystem will also have issues with the random
ordering/parallel processing of deployment sets - not only
on server restart.<br>
</tt></div>
</blockquote>
<div><br>
</div>
<div>Other subsystems will eventually be able to use a direct
dependency between deployments in order to setup the
dependency (i.e deployments will be able to just say in a
descriptor which other deployments they depend on).</div>
</div>
</blockquote>
That's may be ok for other use cases, but does not apply to OSGi
deployments AFAICS. In particular it does not help to solve the
framework startup dilemma. <br>
<blockquote
cite="mid:7692410A-395A-4FB1-B7A1-69271D5C1CD4@gmail.com"
type="cite">
<div>
<div><br>
</div>
<div>Stuart</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> <br>
This would be our old friend: <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/AS7-378">[AS7-378]
Support notion of deployment set</a><br>
<br>
cheers<br>
--thomas<br>
<br>
</tt><br>
<div class="moz-cite-prefix">On 08/17/2012 02:13 PM, Thomas
Diesler wrote:<br>
</div>
<blockquote cite="mid:502E354D.2090705@jboss.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 08/17/2012 02:16 AM,
Stuart Douglas wrote:<br>
</div>
<blockquote
cite="mid:6780F68E-21CD-47FB-A889-5051D5B86CBE@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>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:</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>Regarding
...<br>
</tt>
<blockquote><tt><i>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?</i><br>
</tt></blockquote>
<tt>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.<br>
</tt></div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<tt>Yes, the notion of POST_MODULE phase waiting on the
Bundle.RESOLVED service (which we already have) is the
right direction I would think.</tt><br>
<blockquote
cite="mid:6780F68E-21CD-47FB-A889-5051D5B86CBE@gmail.com"
type="cite">
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> <br>
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.<br>
</tt></div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<tt>Here is how it should work IMHO<br>
<br>
#1 The user needs to have control over whether bundle
deployment should be automatically resolved or not. It
is perfectly ok for the user to want "just install"
behaviour. It is also ok, that the user wants the bundle
to resolve/start but it cannot not for one reason or
another. In which case the deployment chain would wait
on Bundle.RESOLVED. Its at the discretion of the
framework to resolve that bundle at any time - this
would normally be triggered by a class load attempt or
an explicit Bundle.start() call.<br>
<br>
#2 It must be guaranteed that on restart we get the same
wiring for the persistent bundles. This could be done in
two ways. #2.1 The order in which the bundles hit the
resolve phase must be deterministic (i.e. order of
bundle id) and the resolver must guarantee to produce
the same result for a given bundle set and order<br>
#2.2 Every successful resolver run records the wiring
result. On restart, that wiring result is restored given
that the set of persistent bundles is both present and
not modified.<br>
<br>
I have a prototype of a deployment chain that waits in a
certain stop phase depending on a user defined
StartPolicy. There are additional start/stop management
operations that make the deployment progress or reverse
DUP processing respectively. Perhaps you like to have a
look at<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/tdiesler/jboss-as/tree/as2777">https://github.com/tdiesler/jboss-as/tree/as2777</a><br>
<br>
</tt>
<blockquote
cite="mid:6780F68E-21CD-47FB-A889-5051D5B86CBE@gmail.com"
type="cite">
<div>
<div><br>
</div>
<div>Stuart</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> <br>
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.<br>
<br>
</tt></div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><tt> cheers<br>
--thomas <br>
</tt><br>
<div class="moz-cite-prefix">On 08/15/2012 01:32
PM, Thomas Diesler wrote:<br>
</div>
<blockquote cite="mid:502B88C0.9060307@jboss.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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>
<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>
<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>
<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>
<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. <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>
</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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>
<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>