[Design of POJO Server] - Hot deploying deployers - deployer chains
by adrian＠jboss.org
Rather than having a single deployer chain,
what we really need is a tree like structure based on the
input/output of the metadata structures.
e.g.
| -- one-to-one
| -< one-to-many
| \- additional branch
|
| Services
| -service.xml -- ServiceDeployment.class -< ServiceMetaData.class -- MBean
| \- LoaderRepositoryConfig.class - ClassLoader
|
| Rars
| .rar -- RARMetaData.class -- ServiceMetaData -- etc.
| \- LoaderRepositoryConfig.class -- etc.
|
| Connection factories
| -ds.xml -- ServiceDeployment.class -- etc.
| \- LoaderRepositoryConfig.class -- etc.
|
With each deployer defining its inputs and outputs.
e.g.
SARDeployer
input = -service.xml
output = ServiceDeployment.class
ServiceDeploymentDeployer
input = ServiceDeployment.class, ServiceMetaData.class
output = ServiceMetaData.class
ServiceDeployer
input = ServiceMetaData.class
output = REAL
This way the chain can built up based on the input/outputs.
We still need the original relative ordering to decide
which parts of the chain of get done at what stage,
e.g. the ServiceClassloaderDeployer is done
before the ServiceDeploymentDeployer
The advantage to this, is that we know when a deployer is added
whether other deployments (really pieces of their metadata)
are affected. i.e. whether we need to unwind them to
reprocess something.
e.g. When I add the RARDeployer to the beginning of the chain
I only need to see what deployments are rars (end in .rar or have
a ra.xml) and process the output ServiceMetaData through its
particular chain.
e.g.2. If somebody interpolates a deployer
that processes ServiceMetaData.class between the
ServiceDeploymentDeployer and the ServiceMetaDataDeployer
then I need to unwind the work of the ServiceMetaDataDeployer
to do that work before winding forward again.
Such a mechanism also gives a more direct link for the front
end profile service to reprocess part of a deployment
(including just changing an attribute on an MBean if that
is all the update requires - i.e. no redeploy).
The big stumbling block, comes from things like:
-aop.xml
-security.xml
log4j.xml
where we don't want any (or maybe part) of the deployment to proceed
until these have established their context.
But if these are hotdeployed, how do we know they even exist?
One solution is to be able to define these "show stoppers"
in the main deployer or profile service metadata.
However, that still leaves the age old problem,
how do I apply a -security.xml to the security deployer?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972529#3972529
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972529
19 years, 6 months
[Design of POJO Server] - Deployers and classloading - stumbling block
by adrian＠jboss.org
We can't actually cutover head to the new deployers yet.
There is one key piece missing.
We don't have a mechanism to add deployers that are not
in the bootstrap classpath.
e.g. The rar deployer needs classes from jboss-jca.jar
so it cannot be instantiated from deployer-beans.xml
What I propose we do is we change the profile service
to be more like the old JBoss4 mechanism such that
it does something like:
Pseudo code:
| // conf/jboss-service.xml - for the classpath
| DeploymentContext ctx = main.addDeployment(profile.getBootstrapURI());
| main.process();
|
| // Run the remainder of the bootstrap under the
| // bootstrap uri's classloader
| Thread current = Thread.currentThread();
| ClassLoader cl = ctx.getClassLoader();
| ClassLoader old = current.getContextClassLoader();
| current.setContextClassLoader(cl);
| try
| {
| main.addDeployments(profile.getDeployerURIs());
| main.process();
|
| // Now do the rest of the deployments
| }
| finally
| {
| current.setContextClasLoader(old);
| }
|
Where we really want to get to is hot deployment of deployers
which is an issue that I'll deal with on a different thread.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972523#3972523
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972523
19 years, 6 months
[Design of JBoss jBPM] - Re: MessageService and JMS
by mteira
Hello again.
I've tried that, but now, the target 'package' at 'jpdl/dist' is not working any more. :-(
lang.dochtmlsingle:
| [mkdir] Created dir: C:\src\jbpm-test\jbpm.3\jpdl\userguide\target\userguide
| \en\html_single
| [copy] Copying 55 files to C:\src\jbpm-test\jbpm.3\jpdl\userguide\target\us
| erguide\en\html_single\images
| [copy] Copying 1 file to C:\src\jbpm-test\jbpm.3\jpdl\userguide\target\user
| guide\en\html_single\css
| [java] Warning: multiple "IDs" for constraint linkend: asynchronouscontinua
| tions.
| [java] Error: no ID for constraint linkend: processcompositioningop.
| [java] Error: no ID for constraint linkend: userprovidedstuff.
| [java] XRef to nonexistent id: userprovidedstuff
| [java] Warning: multiple "IDs" for constraint linkend: asynchronouscontinua
| tions.
| [java] Warning: multiple "IDs" for constraint linkend: asynchronouscontinua
| tions.
| [mkdir] Created dir: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl
| [copy] Copying 9 files to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpd
| l
| [copy] Copying 1 file to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl
|
| [copy] Copying 1 file to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl
|
| [copy] Copying 1 file to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl
|
| [mkdir] Created dir: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl\db
| [copy] Copying 16 files to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jp
| dl\db
| [copy] Copying 49 files to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jp
| dl
| [mkdir] Created dir: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl\src\
| jpdl
| [copy] Copying 487 files to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-j
| pdl\src\jpdl
| [mkdir] Created dir: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl\src\
| identity
| [copy] Copying 30 files to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jp
| dl\src\identity
| [mkdir] Created dir: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl\src\
| resources\gpd
| [copy] Copying 1 file to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl
| \src\resources\gpd
| [mkdir] Created dir: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl\conf
| ig
| [copy] Copying 5 files to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpd
| l\config
| [copy] Copying 135 files to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-j
| pdl\doc\userguide
| [copy] Copied 4 empty directories to 1 empty directory under C:\src\jbpm-te
| st\jbpm.3\jpdl\dist\target\jbpm-jpdl\doc\userguide
| [mkdir] Created dir: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl\doc\
| javadoc-jpdl
| [copy] Copying 571 files to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-j
| pdl\doc\javadoc-jpdl
| [mkdir] Created dir: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl\doc\
| javadoc-identity
| [copy] Copying 56 files to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jp
| dl\doc\javadoc-identity
| [mkdir] Created dir: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl\lib
| [copy] Copying 30 files to C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jp
| dl\lib
| [get] Getting: http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmDbCompatibilit
| y
| [get] To: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl\db\compatibil
| ity.html
| [zip] Building zip: C:\src\jbpm-test\jbpm.3\jpdl\dist\target\jbpm-jpdl.zip
|
|
| BUILD FAILED
| C:\src\jbpm-test\jbpm.3\jpdl\dist\build.xml:171: Replace: source file C:\src\jbp
| m-test\jbpm.3\jpdl\dist\target\jbpm-jpdl\readme.html doesn't exist
I wonder if perhaps the rules:
<!-- ZIPPING THE RUNTIME -->
|
| <move file="target/jbpm-jpdl" tofile="target/jbpm-jpdl-${lib.jbpm.jpdl.versi
| on}" />
| <zip destfile="target/jbpm-jpdl.zip">
| <fileset dir="target">
| <include name="jbpm-jpdl-${lib.jbpm.jpdl.version}/**" />
| </fileset>
| </zip>
|
and
<!-- UPDATING THE README -->
|
| <replace file="target/jbpm-jpdl/readme.html">
| <replacetoken><![CDATA[<!-- Suite Only]]></replacetoken>
| <replacevalue></replacevalue>
| </replace>
| <replace file="target/jbpm-jpdl/readme.html">
| <replacetoken><![CDATA[Suite Only -->]]></replacetoken>
| <replacevalue></replacevalue>
| </replace>
should be reordered?
Regards.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972505#3972505
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972505
19 years, 6 months
[Design of JBoss jBPM] - Re: does optimistic locking always work ?
by mteira
Hello.
I'm just a newbie in this jBPM world but have runned into problems trying to develop something similar (a workflow with MDB action consumers, where the tasks were modelled as JPA entitites in an EJB3 context).
I dind't find a way to perform pessimistic locking for the entities (I have the idea that it's not supported) and tests with concurrent threads led me to very odd results. About detection of conflicts in optimistic locking, I also think that table versioning is only detecting problems when committing, when the version numbers mismatch can be detected.
Another weird thing is READ_UNCOMMITED Hypersonic transaction isolation level mixed with optimistic locking. Changing to a RDBMS with a real transaction isolation leads to really different results when using optimistic locking (as chances to have obsoleted versions of the entities are bigger than with Hypersonic).
Hope it helps.
Regards.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972489#3972489
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972489
19 years, 6 months