[JBoss AS7 Development] - Running AS7 embedded in Arquillian
by Thomas Diesler
Thomas Diesler [http://community.jboss.org/people/thomas.diesler%40jboss.com] created the discussion
"Running AS7 embedded in Arquillian"
To view the discussion, visit: http://community.jboss.org/message/572225#572225
--------------------------------------------------------------
This post describes what I have done and have seen when running AS7 embedded in Arquillian. There is a large overlap with what Kabir has done with embedded AS7 so lets try to converge.
The https://github.com/jbosgi/arquillian/blob/jbas7/containers/jbossas-embedd... JBossASEmbeddedContainer the https://github.com/jbosgi/jboss-as/blob/arquillian/server/src/main/java/o... StandaloneServerFactory and waits for the Arquillian MBean to become available
Properties sysprops = new Properties();
sysprops.putAll(System.getProperties());
sysprops.setProperty("jboss.home.dir", jbossHomeDir.getAbsolutePath());
sysprops.setProperty("java.util.logging.manager", "org.jboss.logmanager.LogManager");
sysprops.setProperty("logging.configuration", "file:" + jbossHomeDir + "/standalone/configuration/logging.properties");
sysprops.setProperty("org.jboss.boot.log.file", jbossHomeDir + "/standalone/log/boot.log");
server = StandaloneServerFactory.create(jbossHomeDir, sysprops);
server.start();
The StandaloneServerFactory uses the https://github.com/jbosgi/jboss-as/blob/arquillian/server/src/main/java/o... InitialModuleLoaderFactory to bootstrap modules with a controlled set of packages from the app classpath. I agree with Jason, it is impossible to put stuff on the appclasspath and somehow hope the test deployemnts will behave like they would in a running server.
For this to work in ARQ it is necessary that nothing initializes jdk logging before we have a chance to load the LoggingManager from the "org.jboss.logmanager" module. Therefore, I added a https://github.com/jbosgi/arquillian/commit/6a7e152a1416a634047cf11178c7a... looging abstraction to ARQ that allows you do disable or redirect ARQ logging to System.out
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemProperties>
<property>
<name>java.util.logging.manager</name>
<value>org.jboss.logmanager.LogManager</value>
</property>
<property>
<name>arquillian.logging</name>
<value>system</value>
</property>
</systemProperties>
</configuration>
</plugin>
The StandaloneServerFactory loads the server module and uses reflection and a proxy to bootstrap the server.
Currently, the server comes up and deployment fails with
12:46:07,295 ERROR [org.jboss.as.protocol.connection] (pool-1-thread-2) Failed to read a message: java.util.ServiceConfigurationError: org.jboss.marshalling.ProviderDescriptor: Provider org.jboss.marshalling.river.RiverProviderDescriptor could not be instantiated: java.lang.ClassCastException
at java.util.ServiceLoader.fail(ServiceLoader.java:207) [:1.6.0_21]
at java.util.ServiceLoader.access$100(ServiceLoader.java:164) [:1.6.0_21]
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) [:1.6.0_21]
at java.util.ServiceLoader$1.next(ServiceLoader.java:421) [:1.6.0_21]
at org.jboss.marshalling.Marshalling.loadMarshallerFactory(Marshalling.java:78) [jboss-marshalling-1.3.0.CR8.jar:1.3.0.CR8]
at org.jboss.marshalling.Marshalling.getMarshallerFactory(Marshalling.java:74) [jboss-marshalling-1.3.0.CR8.jar:1.3.0.CR8]
at org.jboss.as.protocol.ProtocolUtils.<clinit>(ProtocolUtils.java:50) [jboss-as-protocol-7.0.0.Alpha1.jar:7.0.0.Alpha1]
at org.jboss.as.protocol.mgmt.ManagementProtocolHeader.read(ManagementProtocolHeader.java:75) [jboss-as-protocol-7.0.0.Alpha1.jar:7.0.0.Alpha1]
at org.jboss.as.protocol.mgmt.ManagementResponseHeader.read(ManagementResponseHeader.java:60) [jboss-as-protocol-7.0.0.Alpha1.jar:7.0.0.Alpha1]
at org.jboss.as.protocol.mgmt.ManagementProtocolHeader.<init>(ManagementProtocolHeader.java:55) [jboss-as-protocol-7.0.0.Alpha1.jar:7.0.0.Alpha1]
at org.jboss.as.protocol.mgmt.ManagementResponseHeader.<init>(ManagementResponseHeader.java:45) [jboss-as-protocol-7.0.0.Alpha1.jar:7.0.0.Alpha1]
at org.jboss.as.protocol.mgmt.ManagementRequest$1.handle(ManagementRequest.java:124) [jboss-as-protocol-7.0.0.Alpha1.jar:7.0.0.Alpha1]
StandaloneServer is now an interface that also supports StandaloneServer.stop(). The idea is that the factory installs a service that can be used to bring down the server.
To try this out you need to checkout these branches
https://github.com/jbosgi/arquillian/tree/jbas7 https://github.com/jbosgi/arquillian/tree/jbas7
https://github.com/jbosgi/jboss-as/tree/arquillian https://github.com/jbosgi/jboss-as/tree/arquillian
Build AS7 and in arquillian run
mvn -Djboss.home=/home/tdiesler/git/jboss-as/build/target/jboss-7.0.0.Alpha2 -pl container/jbossas-embedded-7 -am install
I'll talk this through with Kabir. So hopefully the demos and other smoke/integration tests can be embedded ARQ tests soon.
cheers
-thomas
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572225#572225]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 5 months
[jBPM Development] - jbpm process variable - Classcastexception/ classloader issues
by Mahavir Jain
Mahavir Jain [http://community.jboss.org/people/mahavirj] created the discussion
"jbpm process variable - Classcastexception/ classloader issues"
To view the discussion, visit: http://community.jboss.org/message/572147#572147
--------------------------------------------------------------
Hi,
I am able to start a jbpm4.4 process from a servlet by passing a process variable (com.process.servicedata.Plan). However, a decision handler later in the process gets a classcast exception when accessing this variable:
java.lang.ClassCastException
: com.process.servicedata.Plan cannot be cast to com.process.servicedata.Plan
at com.process.activitymodel.HealthPlanDecisionHandler.decide(
HealthPlanDecisionHandler.java:15)
at org.jbpm.jpdl.internal.activity.DecisionHandlerActivity.execute(
DecisionHandlerActivity.java:60)
at org.jbpm.jpdl.internal.activity.DecisionHandlerActivity.execute(
DecisionHandlerActivity.java:42)
at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(
ExecuteActivity.java:60)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(
ExecutionImpl.java:672)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(
ExecutionImpl.java:632)
at org.jbpm.pvm.internal.model.op.TransitionEndActivity.perform(
TransitionEndActivity.java:56)
This appears to be a classloader problem, so here are the details on my project structure:
1. process-web.war contains the servlet that starts the process.
1. process.jpdl.xml is in process.jar
2. process.jar is in WEB-INF/lib of process-web.war.
3. all the jbpm libraries (e.g. jbpm.jar) are in the WEB-INF/lib.
4. process.jpdl.xml in process.jar is deployed using an Ant script that was taken from the examples app that comes with jbpm.
5. process-web.war is deployed to jboss 5 and uses jbpm 4.4.
Any clues on what am I missing?
Thanks,
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572147#572147]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 5 months
[JBoss AS7 Development] - Re: Thoughts on filesystem action driven hot deployment
by Max Andersen
Max Andersen [http://community.jboss.org/people/max.andersen%40jboss.com] created the discussion
"Re: Thoughts on filesystem action driven hot deployment"
To view the discussion, visit: http://community.jboss.org/message/572083#572083
--------------------------------------------------------------
Thought I would spend part of my trainride home to outline what I and Brian talked/agreed upon at Devoxx:
The intent is to have a "safer" file deployment api via the use of marker files.
In case of a deployment named foo.war the following marker files will have meaning.
*foo.war.dodeploy* - trigger deploy of archive or exploded directory.
*foo.war.donotdeploy* - Marker for server to ignore foo.war (used to ensure partial deployments does not happen while copying)
*foo.war* - in case of archive (not exploded directory) it work as foo.war.dodeploy if file hasn't changed since last scan/some grace period.
*foo.war.faileddeploy* - ACK from server that deploy failed (content should contain info about reason for failure)
*foo.war.isdeployed* - ACK from server that foo.war.isdeployed.
There will be flag in server configuration (TBD where exactly) to
enable old style scanning for/reaction on descriptors, but will not be
enabled by default. This will allow existing tooling for pre-AS7 to work sensibly.
The deployment folder will have a README or similar explaining the above to spread the word on how this folder works.
...and that's it ;)
The following show it in us from a pure command line perspective to show the simplicity (and power) of the "File Deployment API".
For exploded deployments:
1. cp -r target/foo.war/ $AS7/deployment
2. touch $AS7/deployment/foo.war.dodeploy
AS will ignore the directory at step #1 but
step #2 will make it deploy foo.war on the next
scan.
If deploy is succesfully AS7 will do the following:
1. rm $AS7/deployment/foo.war.dodeploy
2. touch $AS7/deployment/foo.war.isdeployed
Meaning that you as user (or tool) can explicitly
control when deployment occurs and you get an ACK
from the server on succesfully deployment.
In case of error during deployment AS7 will do the following:
1. echo $DEPLOY_ERROR_INFO > $AS7/deployment/foo.war.faileddeploy (name TBD)
2. rm $AS7/deployment/foo.war.dodeploy
Where $DEPLOY_ERROR_INFO is what the server knows about the reason for deploy error.
For archived deployments:
For archived deployments the behavior/semantics is the same except
AS7 will automatically start deploying an archive once the file has not changed
in some grace period (i.e. 500 ms? )
The user can trigger redeploy by either doing touch foo.war or touch foo.war.dodeploy.
"Suspend deployment"
To handle the case of possible errors occurring while copying deployments (i.e. network connection error
or sudden crash) it is possible to tell the scanner to ignore an archive or exploded directory by doing:
1. touch $AS7/deployment/foo.war.donotdeploy
When user want it to be deployed he can simple remove the .donotdeploy and then touch foo.war if its an archive or
touch $AS7/deployment/foo.war.dodeploy in case of directory and archive.
Info:
We did not use .deploy, .deployed as markers since it could cause confusion in filebrowser that can cut off the ending.
We did not use dodeploy.foo.war since then it would not show up close to the deployment - if you want sorting by "status" sort by extension.
Important that whatever the deployment does theres should be zero delay for reosurces like .html/.xhtml thus shadow copying is probably out of the question; but at the same time need to reduce chance of jar locking on windows filesystems. TBD how and if it is still a problem these days on pre-AS7 deployments.
Questions:
Will subdirectories be allowed in /deployment for separation ? (don't think so - but good to document that you have to add multiple deployment roots)
If I rm foo.war.isdeployed what does that mean ? Should AS7 create it again ? ( I guess not..they are just transient markers)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572083#572083]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 5 months
[JBoss AS7 Development] - Re: Embedded AS
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion
"Re: Embedded AS"
To view the discussion, visit: http://community.jboss.org/message/572075#572075
--------------------------------------------------------------
> One issue that occurred to me after doing this is that the the SystemLocalLoader only gets initialized once per jvm, so the first test to set this wins. Maybe this should happen at a higher level for the whole project? Maybe in a /system-classpath.properties or a package annotation for test's root package?
>
>
>
This is now initialized in a package-info in a parent package in the project containing the tests:
@ClasspathFilter(maven= {
@MavenFilter(groupId="org.jboss.shrinkwrap", artifactId="shrinkwrap-api"),
@MavenFilter(groupId="org.jboss.shrinkwrap", artifactId="shrinkwrap-impl-base")})
*package* org.jboss.test.as.modular;
*import* org.jboss.as.embedded.modular.bootstrap.ClasspathFilter;
*import* org.jboss.as.embedded.modular.bootstrap.MavenFilter;
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572075#572075]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 5 months
[JBoss AS7 Development] - Re: Embedded AS
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] created the discussion
"Re: Embedded AS"
To view the discussion, visit: http://community.jboss.org/message/571835#571835
--------------------------------------------------------------
> Kabir Khan wrote:
>
> I don't think you can change the classpath of an already running java program
No you can't. What that class was doing was an attempt to get the jboss-modules SystemLocalLoader to not load undesired classes. It reads the java.class.path property when determining what jars/directories to load from. That part actually seems to work.
The problem is the static intializer block in java.util.logging.LogManager tries to use ClassLoader.getSystemClassLoader() to load the class. And that classloader's unaffected by my change of the system property.
And that problem would affect your #2 solution as well. :( The true system classloader is not controlled by jboss-modules, so any time some code uses it, it will see the original classpath.
Do you know how the Arquillian guys are dealing with this problem?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/571835#571835]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 5 months