While integrating EJB3 service into current AS trunk, I noticed that if
a Component's service (or any service in general) has unresolved
dependencies, although the service stays in DOWN state (as expected), no
error is reported and the deployment does *not* fail. As a side effect
of this, a runtime invocation on the service (a InitialContext.lookup()
leading to the ServiceReferenceObjectFactory.getObjectInstance() in this
case) ended up hanging indefinitely http://pastebin.com/jK0i1aCi
To debug this, I had to use jconsole and then get a list of all the
services, their dependencies and the state and then figure out what's
(class org.jboss.as.ee.component.service.ComponentService) mode ACTIVE
state DOWN (dependencies:
(has missing dependency)
Shouldn't a unresolved dependency on a service result in deployment failure?
Is there currently a way to derive the DeploymentUnit for the object
that is being injected into?
This will help me to identify which PersistenceUnit service to access.
The service name is derived from the persistence unit name and the fully
qualified path to it (e.g. myapp.ear/lib/myejb3stuff.jar#MY-PU-DEF).
If someone is seeing issues with using maven 3.0.3 to run the smoke tests and that is a problem for you let me know and I'll do anther release
Begin forwarded message:
> From: Paul Gier <pgier(a)redhat.com>
> Date: 28 February 2011 15:46:51 GMT
> To: Kabir Khan <kabir.khan(a)jboss.com>
> Subject: patch for jboss modules surefire plugin
> Hey Kabir,
> I ran into a problem in the jboss modules surefire plugin when testing
> Maven 3.0.3 with the current AS build . The way Maven handles
> generics in parameters has changed slightly and it exposed an issue in
> the plugin. I attached a patch that allows the plugin to work with both
> Maven 3.0.2 and 3.0.3. You should be able to apply it to your github
Updated my local workspace with the latest from AS7 upstream a few
minutes back. The build hangs on my system in the "controller" module
with the following error:
[INFO] --- maven-surefire-plugin:2.5:test (default-test) @
[INFO] Surefire report directory:
T E S T S
25 Feb, 2011 8:35:51 PM org.jboss.as.protocol.ConnectionImpl
ERROR: Failed to read a message
java.io.EOFException: Read past end of file
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode)
I've attached a thread dump which I took when the build was hung. Anyone
else seeing the same issue?
The intent is to read children names of the current node/address. With
child-type required it complicates things (the most difficult would be
to get a list of root node names since there is no common type for them).
So, can we make child-type optional? In the mean time, I've made it in
the cli branch
I am starting to look into the options we have for a mechanism for the
authentication / trust mechanism we will need between the individual
hosts and the domain controller.
Before going too far I just want to check if there have been any
previous discussion on this that I may have missed.
I'd like to change the following AS7 modules
to include the following dependencies
<!-- JSR 181 WS MD -->
<!-- JSR 224 JAXWS API -->
<!-- JBossWS SPI -->
<module name="org.jboss.ws.spi" />
<!-- CXF META-INF servicies -->
<module name="org.jboss.ws.cxf.jbossws-cxf-factories" services="import"/>
<!-- CXF JAXWS API impl -->
<module name="org.jboss.ws.cxf.jbossws-cxf-client" services="import"/>
It's required by JAX-WS 22 & EE6 specs and TCK to have
JAX-WS client runtime available in Servlets and EJBs automatically.
I'm also attaching some usecases to demonstrate usecases.
Objections / comments ?
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942
Here are some details about a failure to shutdown the standalone as7
server. I'm using a private JPA branch, which was merged with
master/trunk on Sunday.
Deployment (NPE) error that preceded the failure to shutdown:
thread dump: http://pastebin.com/bmREwigy
as7 service dump: http://pastebin.com/wRhx4deW
pastebin links expire in 30 days.
I fixed the NPE in my DUP but I'm wondering if we should protect against
this at a higher level?
I'd like to give a status update on what I've done so far, collect some
feedback and get a sense of direction for the roadmap.
So, so far it's a primitive thing. There is a script jboss-admin.sh(bat)
under the JBOSS_HOME/bin. It starts a cli as a module (I found it easier
First thing to do is to connect to the server. It's done with
Default host is localhost, default port is 9999.
BTW, for the list of supported commands type /help. Besides /connection
and /help there are /quit and /prefix.
Anything that doesn't start with '/' is considered an operation request.
Operation requests are currently following the format:
[node-type=node-name [, node-type=node-name]*] : operation-name
([name=value [, name=value]*])
Whitespaces between separators are insignificant.
If the address part is not specified then the ':' before the operation
name is optional.
If the operation has no arguments then the brackets '()' are optional.
So, if we are at the root, just 'read-resource' will work.
The result of the operation for now is logged by invoking toString() on
it, so it's formatted as on the wiki.
About the /prefix command (it has an alias '/to'). It's an analogue of
the 'cd'. I.e. It specifies a node path prefix for an operation request
before it gets executed. E.g.
will be equivalent to subsystem=logging:read-resource executed from the
It's also possible to end the prefix on the node type, e.g.
will be equivalent to the above.
/to ~ - means go to the root.
'..' - go to the parent node.
.type - go to the node type of the current node.
/prefix (or /to) w/o arguments will print the current prefix value. BTW,
the prefix is not verified to be a valid one (except from the syntax
point of view). If the prefix is wrong the operations will fail, of course.
That's about it for now. So, we talked a bit today with Emanuel and Max
about it. To improve usability we thought of adding:
- some sort of autocompletion (for the commands, node types/names,
- having higher level management commands on top of the operation
requests, to avoid the verbose syntax of the operation requests for some
common things like deploy/undeploy, add a datasource, etc.
- use the jline for the input (currently it's BufferedReader.readLine()).
Any other ideas, suggestions?
BTW, it's currently in my detyped2 branch.