<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<tt>The work to configure and get the module only needs to be done
ones - a module will never "unresolve" unless you undeploy it.</tt><br>
<blockquote><tt><font size="2">11:18:05 PM)</font><font size="3"> <b>tdiesler:</b>
Nihility, for osgi the behavior for a bundle deployment that
cannot resolve would be such that the deployment does not fail
but it hangs in some pre_module phase. you could deploy
additional stuff and retry to resolve/start the thing through
the console. It is metadata valid and stays in the runtime as
such. </font></tt><br>
<tt><font size="2">(11:18:54 PM)</font><font size="3"> <b>tdiesler:</b>
That would solve all ordering issues I think</font></tt><br>
<tt><font size="2">(11:19:42 PM)</font><font size="3"> <b>Nihility:</b>
yeah so like if we had a dep on another deployments MODULE</font></tt><br>
<tt><font size="2">(11:20:03 PM)</font><font size="3"> <b>tdiesler:</b>
you dont get an error</font></tt><br>
<tt><font size="2">(11:20:08 PM)</font><font size="3"> <b>Nihility:</b>
that would do what you are talking about</font></tt><br>
<tt><font size="2">(11:20:13 PM)</font><font size="3"> <b>tdiesler:</b>
yes</font></tt><br>
<tt><font size="2">(11:20:13 PM)</font><font size="3"> <b>Nihility:</b>
it just waits</font></tt><br>
<tt><font size="2">(11:20:29 PM)</font><font size="3"> <b>Nihility:</b>
of course we have a circularity problem to think about </font></tt><br>
<tt><font size="2">(11:20:37 PM)</font><font size="3"> <b>Nihility:</b>
I'm not sure if we support this today or not</font></tt><br>
<tt><font size="2">(11:20:58 PM)</font><font size="3"> <b>Nihility:</b>
but i wonder if a.jar (dependency b) b.jar (dependency a)
works for modules</font></tt><br>
<tt><font size="2">(11:21:04 PM)</font><font size="3"> <b>Nihility:</b>
we make it work for class-path</font></tt><br>
<tt><font size="2">(11:21:15 PM)</font><font size="3"> <b>Nihility:</b>
since Class-path is supposed to allow it</font></tt><br>
<tt><font size="2">(11:21:32 PM)</font><font size="3"> <b>Nihility:</b>
it works in jboss modules</font></tt><br>
<tt><font size="2">(11:21:41 PM)</font><font size="3"> <b>Nihility:</b>
but as a deployment module dep I'm not sure</font></tt><br>
<tt><font size="2">(11:21:51 PM)</font><font size="3"> <b>Nihility:</b>
stuartdouglas: would know, are you up?</font></tt><br>
<tt><font size="2">(11:22:19 PM)</font><font size="3"> <b>Nihility:</b>
tdiesler: i take it thats completely invalid with bundles
right, circularity?</font></tt><br>
<tt><font size="2">(11:22:39 PM)</font><font size="3"> <b>tdiesler:</b>
Nihility, it works in osgi. because the resolver knows the
complete set of metadata. and when triggered to resolve a set
of bundles and it finds a cosistent solution we go to the
jboss-modules PAI</font></tt><br>
<tt><font size="2">(11:23:10 PM)</font><font size="3"> <b>tdiesler:</b>
Nihility, I don't think so</font></tt><br>
<tt><font size="2">(11:23:24 PM)</font><font size="3"> <b>Nihility:</b>
ah ok</font></tt><br>
<tt><font size="2">(11:23:37 PM)</font><font size="3"> <b>tdiesler:</b>
Require-Bundle is of course discouraged anyway, but it should
work </font></tt><br>
<tt><font size="2">(11:23:58 PM)</font><font size="3"> <b>Nihility:</b>
tdiesler: you can do it with packages too right?</font></tt><br>
<tt><font size="2">(11:24:12 PM)</font><font size="3"> <b>tdiesler:</b>
yes</font></tt><br>
</blockquote>
<tt>The default behaviour for a bundle deployment would be "don't
fail on cannot resolve". For other deployment types it could be
different as it is now. An explicit start op would take the
deployment past the resolve phase and through the activate phases.
If it still cannot resolve you'd get an error.<br>
<br>
On the CLI you can do:<br>
<br>
> deploy foo.jar --no-start (which means it is ok that foo
cannot resolve)<br>
> deploy bar.jar<br>
> start foo.jar (which means that foo must resolve and start
without error)<br>
> stop foo.jar (which means that foo runs back through the
activate DUPs only - it stays resolved and keeps the module)<br>
<br>
The cleanup issue only becomes a problem if you want to do
repeated start ops.<br>
</tt>
<blockquote><br>
</blockquote>
<tt><br>
</tt>
<div class="moz-cite-prefix">On 09/21/2012 01:59 AM, Stuart Douglas
wrote:<br>
</div>
<blockquote cite="mid:505BADE3.9080503@gmail.com" type="cite">I did
no a similar thing a little while ago, that would allow a
deployment with a dependency on another deployment to basically
sit and wait for the next deployment to come up.
<br>
<br>
I think the way to implement this is to have the configure
CONFIGURE_MODULE phase be set to passive, so it only starts
<br>
when the services that it depends on become available. So in the
OSGI case this would depended on the RESOLVE services, and would
start as soon as resolution completed.
<br>
<br>
Things get more complicated if this passive service has its
dependencies go away, as deployment phases are not restartable. I
think the only way to actually handle this is to perform a full
re-deployment. The reason why this is so problematic is because
the DUP contains a lot of mutable state that is modified in each
phase. Re-running all the DUP's would result in a lot of this
information being doubled up.
<br>
<br>
It is also more complicated if we are dealing with a multi-module
deployment. If any of the sub deployments are not set to start
lazily, and are dependent on services that are present in the lazy
deployment then this will fail. This will probably not be a big
deal in practice.
<br>
<br>
Another big issue is that we have no way of reporting the success
or failure of the deployment back to the user. We also need to
make sure that if this passive deployment fails we have some way
of rolling back the deployment, to keep the behavior consistent
with normal deployments. We do not want to leave a half finished
deployment sitting around.
<br>
<br>
Basically I think this is possible for a fairly limited case
where:
<br>
<br>
- The deployment stops after configure module
<br>
- We have a mechanism in place to prevent the DU from attempting
to restart without a full re-deployment.
<br>
- We make sure that partial deployment is not allowed, and a full
rollback is attempted if start fails.
<br>
<br>
Stuart
<br>
<br>
<br>
<br>
<br>
<br>
Scott Marlow wrote:
<br>
<blockquote type="cite">On 09/20/2012 02:52 PM, Thomas Diesler
wrote:
<br>
<blockquote type="cite">On 09/20/2012 02:29 PM, Scott Marlow
wrote:
<br>
<blockquote type="cite">On 09/20/2012 09:18 AM, Thomas Diesler
wrote:
<br>
<blockquote type="cite">Folks,
<br>
<br>
I rebased the
as2777<a class="moz-txt-link-rfc2396E" href="https://github.com/tdiesler/jboss-as/tree/as2777"><https://github.com/tdiesler/jboss-as/tree/as2777></a>
<br>
branch on the current as3694
<br>
<a class="moz-txt-link-rfc2396E" href="https://github.com/tdiesler/jboss-as/tree/as3694"><https://github.com/tdiesler/jboss-as/tree/as3694></a>
approach.
<br>
<br>
This integrates with the CLI and you can do
<br>
<br>
<deployment name="simple.war"
runtime-name="simple.war">
<br>
<content
sha1="be6f7ba1ceaa2028c86d080648e1467904999f8e"/>
<br>
<properties>
<br>
<property name="start.policy"
value="deferred"/>
<br>
</properties>
<br>
</deployment>
<br>
<br>
[tdiesler@tdvaio jboss-as-7.2.0.Alpha1-SNAPSHOT]$
bin/jboss-cli.sh
<br>
--connect
<br>
[standalone@localhost:9999 /] start simple.war
<br>
[standalone@localhost:9999 /] stop simple.war
<br>
<br>
on the server you should see
<br>
<br>
08:56:30,002 INFO [org.jboss.web] (MSC service thread
1-2) JBAS018210:
<br>
Register web context: /simple
<br>
08:57:16,533 INFO [org.jboss.web] (MSC service thread
1-3) JBAS018224:
<br>
Unregister web context: /simple
<br>
<br>
The current implementation sets the initial mode of the
CONFIGURE_MODULE
<br>
to NEVER for start.policy=deferred
<br>
The start/stop operations toggle the mode of the INSTALL
phase service
<br>
between ACTIVE/NEVER.
<br>
<br>
The CLEANUP phase is currently a problem on repeated
start. You'll see
<br>
<br>
Caused by: java.lang.NullPointerException
<br>
atorg.jboss.as.ejb3.deployment.processors.merging.AbstractMergingProcessor.deploy(AbstractMergingProcessor.java:61)
<br>
<br>
at
<br>
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:124)
<br>
<br>
[jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2
<br>
<br>
because the EEModuleDescription is no longer attached.
<br>
<br>
Stopping a deployment would not need to take the Module
and associated
<br>
ClassLoader down. So any datastructures needed to
configure the Module
<br>
can safely be cleaned up IMHO. I presume the DUPs can
reasonably be
<br>
fixed by moving them to the appropriate phases (see below)
and by making
<br>
</blockquote>
Which DUPs do you propose moving and to which phase?
Currently, the
<br>
first DUP to use a deployment module classloader, is JPA
(for class
<br>
enhancing (rewriting) in the FIRST_MODULE_USE phase as part
of
<br>
creating the EntityManagerFactory). If class enhancing is
not
<br>
enabled, the JPA entity manager factory is created during
the INSTALL
<br>
phase.
<br>
</blockquote>
All DUPs currently assume that they run in a single
transaction. IOW,
<br>
the DUPs in the INSTALL phase are not designed for the
deployment to
<br>
yo-yo in that phase, which they would have to do if we are
going to
<br>
implement deployment start/stop behaviour (without
reconstruction on the
<br>
Module) properly.
<br>
<br>
I suggest the review the DUPs in the INSTALL phase to see
whether they
<br>
use data structures that are removed in the CLEANUP phase.
There are two
<br>
possibilities
<br>
<br>
#1 DUP (in INSTALL) should be moved to a phase that is only
executed
<br>
once. Then the associated data can safely be discarded in
CLEANUP
<br>
<br>
#2 DUP (in INSTALL) should only use data that stays attached
with the DU
<br>
and is not discarded in CLEANUP
<br>
<br>
I guess this has to be decided on a case-by-case basis. Each
subsystem
<br>
would have to make up its mind what it means to start/stop
their
<br>
respective deployments. For a webapp that probably means to
start/stop
<br>
the web context.
<br>
</blockquote>
<br>
JPA class enhancing/rewriting (if enabled), needs to happen
before any
<br>
application classes are loaded. The JPA class
enhancing/rewriting
<br>
occurs when the EntityManagerFactory is created.
<br>
<br>
If we were to allow non-JPA deployers to run in the same or
earlier
<br>
phase as JPA, we would need a strong guard to prevent the
non-JPA
<br>
deployers from invoking any code that could load application
classes
<br>
(while letting JPA to load application classes).
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">sure they still have the data
structures attached to do yo-yo on the
<br>
activate phases.
<br>
<br>
Using this
terminology<a class="moz-txt-link-rfc2396E" href="https://issues.jboss.org/browse/AS7-3585"><https://issues.jboss.org/browse/AS7-3585></a>
<br>
<br>
STRUCTURE => STRUCTURE
<br>
<br>
PARSE => PRE_INSTALL
<br>
REGISTER => INSTALL
<br>
=> POST_INSTALL
<br>
<br>
DEPENDENCIES => PRE_RESOLVE
<br>
CONFIGURE_MODULE => RESOLVE
<br>
FIRST_MODULE_USE => POST_RESOLVE
<br>
<br>
POST_MODULE => PRE_ACTIVATE
<br>
INSTALL => ACTIVATE
<br>
=> POST_ACTIVATE
<br>
<br>
CLEANUP => CLEANUP
<br>
<br>
We could stop at PRE_RESOLVE. Subsequent start would go up
to and
<br>
including CLEANUP. Subsequent stop would go back including
PRE_ACTIVATE.
<br>
Subsequent start as before.
<br>
<br>
cheers
<br>
--thomas
<br>
<br>
<br>
--
<br>
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
<br>
Thomas Diesler
<br>
JBoss OSGi Lead
<br>
JBoss, a division of Red Hat
<br>
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
<br>
<br>
<br>
<br>
_______________________________________________
<br>
jboss-as7-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a>
<br>
<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>
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
_______________________________________________
<br>
jboss-as7-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a>
<br>
<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>
<br>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
</pre>
</body>
</html>