jax-rs deployments have incomplete module imports
by Bill Burke
I'm sending this here before I submit a JIRA.
JAX-RS deployments need to import more dependencies, specifically:
* the jackson libraries
* Apache Http Client 4 libraries
Jackson and HC4 are often used within jax-rs deployments because users
need to add additional configuration and initialization that can only be
done programmatically.
Another thing:
Can modules be declared with empty <resources>? It would be cool if we
could have a resteasy module with which all it did was define what
modules it would export to a deployment. Right now this metadata is
hardcoded, correct? This sucks for multiple reasons. One: users will
have to manually define a lot of module dependencies, or they will end
up including resteasy and thirdparty libraries that may conflict and
cause CCEs. Two: Its very hard for me to provide a patch to AS7 if I
want to provide *ALL* features that come with the resteasy distribution.
Sure I could include and export everything within the current resteasy
default module, but I would rather have separate modules for these features.
Another alternative could be to only distribute and export the core
resteasy modules with AS7. Then, users would just include other
resteasy features/components/jars directly within their deployments.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 7 months
Coping with cyclic test dependencies
by Paul Robinson
All,
JBoss transactions uses Arquillian for some of the project tests. Therefore JBossTS has a dependency on AS7 (for the Arquillian container dependency), but as AS7 consumes JBossTS, the target AS7 version is not available when we do the release of JBossTS. We get around this at the moment by referencing a SNAPSHOT version of AS7 in the Arquillian container dependency. However, this does mean that our release will reference the SNAPSHOT dependency.
This must be a common issue that other projects have. I was wondering what the accepted pattern was to solve this issue?
Paul.
--
Paul Robinson
Web service transactions lead
paul.robinson(a)redhat.com
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
(USA), Charlie Peters (USA)
11 years, 7 months
as7-master-testsuite-ip6 - Build # 4178 - Failure!
by ci-builds＠redhat.com
as7-master-testsuite-ip6 - Build # 4178 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/4178
Internal: http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...
Test summary:
1 tests failed.
REGRESSION: org.jboss.as.test.integration.osgi.webapp.WebAppTestCase.testServletContextService
Error Message:
java.util.concurrent.ExecutionException: java.io.IOException: <html><head><title>JBoss Web/7.0.17.Final - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>java.lang.RuntimeException: Error: BundleContext attribute not set on: org.apache.catalina.core.ApplicationContextFacade@71846ce0 org.jboss.as.test.integration.osgi.webapp.bundle.TestServletContext.doGet(TestServletContext.java:57) javax.servlet.http.HttpServlet.service(HttpServlet.java:734) javax.servlet.http.HttpServlet.service(HttpServlet.java:847) </pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the JBoss Web/7.0.17.Final logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.0.17.Final</h3></body></html>
11 years, 7 months
How to access a AS7 service from a deployed archive?
by Jeff Mesnil
Hi,
I'm working on making the HornetQ RA deployable in AS7 standalone (ie without a running HornetQ server) to be able to consume
messages from a remote JMS server[1].
The HornetQ RA requires access to the app server transaction manager to be fully functional[2].
I deploy the RA in standalone/deployments/ directory, the RA is started and it calls a class in the AS7 module
org.jboss.as.messaging which is in charge to locate the TM[3].
However this class code has a reference on the service container to be able to get the TxnService.
This was working when the RA is instantiated by the messaging subsystem. But when the RA is deployed, the container reference is
null.
My question is: in my case (a deployed archive that calls a AS7 module), is there a way to get a reference to the
ServiceContainer deploying the archive? Does it even make sense to do that this way?
Once I got it, I should be able to get the transaction manager service.
thanks,
jeff
[1] https://issues.jboss.org/browse/AS7-5483
[2] https://community.jboss.org/message/760644
[3]
https://github.com/jbossas/jboss-as/blob/master/messaging/src/main/java/o...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
11 years, 7 months
Update to deferred resolve and start/stop
by Thomas Diesler
Folks,
I rebased the as2777 <https://github.com/tdiesler/jboss-as/tree/as2777>
branch on the current as3694
<https://github.com/tdiesler/jboss-as/tree/as3694> approach.
This integrates with the CLI and you can do
<deployment name="simple.war" runtime-name="simple.war">
<content sha1="be6f7ba1ceaa2028c86d080648e1467904999f8e"/>
<properties>
<property name="start.policy" value="deferred"/>
</properties>
</deployment>
[tdiesler@tdvaio jboss-as-7.2.0.Alpha1-SNAPSHOT]$ bin/jboss-cli.sh --connect
[standalone@localhost:9999 /] start simple.war
[standalone@localhost:9999 /] stop simple.war
on the server you should see
08:56:30,002 INFO [org.jboss.web] (MSC service thread 1-2) JBAS018210:
Register web context: /simple
08:57:16,533 INFO [org.jboss.web] (MSC service thread 1-3) JBAS018224:
Unregister web context: /simple
The current implementation sets the initial mode of the CONFIGURE_MODULE
to NEVER for start.policy=deferred
The start/stop operations toggle the mode of the INSTALL phase service
between ACTIVE/NEVER.
The CLEANUP phase is currently a problem on repeated start. You'll see
Caused by: java.lang.NullPointerException
atorg.jboss.as.ejb3.deployment.processors.merging.AbstractMergingProcessor.deploy(AbstractMergingProcessor.java:61)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:124)
[jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2
because the EEModuleDescription is no longer attached.
Stopping a deployment would not need to take the Module and associated
ClassLoader down. So any datastructures needed to configure the Module
can safely be cleaned up IMHO. I presume the DUPs can reasonably be
fixed by moving them to the appropriate phases (see below) and by making
sure they still have the data structures attached to do yo-yo on the
activate phases.
Using this terminology <https://issues.jboss.org/browse/AS7-3585>
STRUCTURE => STRUCTURE
PARSE => PRE_INSTALL
REGISTER => INSTALL
=> POST_INSTALL
DEPENDENCIES => PRE_RESOLVE
CONFIGURE_MODULE => RESOLVE
FIRST_MODULE_USE => POST_RESOLVE
POST_MODULE => PRE_ACTIVATE
INSTALL => ACTIVATE
=> POST_ACTIVATE
CLEANUP => CLEANUP
We could stop at PRE_RESOLVE. Subsequent start would go up to and
including CLEANUP. Subsequent stop would go back including PRE_ACTIVATE.
Subsequent start as before.
cheers
--thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11 years, 7 months
cl.getResources() doesn't work from module-based code
by Bill Burke
I'm creating a custom login-module that is declared within
standalone.xml. This module references a new module that I have
deployed (see below). The login-module class uses Resteasy to make
invocations. The problem is that Resteasy is not able to find and
register built-in providers. Resteasy does this by doing:
Enumeration<URL> en =
Thread.currentThread().getContextClassLoader().getResources("META-INF/services/"
+ Providers.class.getName());
while (en.hasMoreElements())
{
URL url = en.nextElement();
No URLs are turning up when calling cl. getResources(). Is there some
configuration switch I don't know about? Here is my module:
<module xmlns="urn:jboss:module:1.1"
name="org.jboss.resteasy.resteasy-skeleton-key">
<properties>
<property name="jboss.api" value="private"/>
</properties>
<resources>
<resource-root
path="resteasy-skeleton-key-core-3.0-alpha-1-SNAPSHOT.jar"/>
<resource-root
path="resteasy-skeleton-key-as7-3.0-alpha-1-SNAPSHOT.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.servlet.api"/>
<module name="javax.security.auth.message.api"/>
<module name="javax.security.jacc.api"/>
<module name="org.jboss.as.web"/>
<module name="javax.ws.rs.api"/>
<module name="org.picketbox"/>
<module name="org.apache.httpcomponents"/>
<module name="org.jboss.resteasy.resteasy-jackson-provider"/>
<module name="org.jboss.resteasy.resteasy-jaxrs"/>
<module name="org.jboss.resteasy.resteasy-crypto"/>
<module name="org.jboss.security.web.login-module-authenticator"/>
</dependencies>
</module>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 7 months
