[jBPM] New message: "Examples not working as expected"
by Yongtao You
User development,
A new message was posted in the thread "Examples not working as expected":
http://community.jboss.org/message/527326#527326
Author : Yongtao You
Profile : http://community.jboss.org/people/yongtao
Message:
--------------------------------------------------------------
Setup:
JBPM 4.3 running in JBoss 5.1.0 on RedHat 5.
What works:
I started the "BPMN2 Example process using task forms" process. I can see the process instance in RUNNING state.
What's NOT:
Since the process instance is running, I expect to see something in the task list. However, both group task list and personal task list are empty. I can see an entry in the JBPM4_TASK table in the database. However, I don't see it in the jBPM Console. Yes, I did hit the refresh button a few times.
Any suggestions?
Thanks!
Yongtao
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527326#527326
16 years, 2 months
[EJB 3.0] New message: "Re: EJB 3.0 tutorial build problem with Maven 2.2.1"
by jaikiran pai
User development,
A new message was posted in the thread "EJB 3.0 tutorial build problem with Maven 2.2.1":
http://community.jboss.org/message/527324#527324
Author : jaikiran pai
Profile : http://community.jboss.org/people/jaikiran
Message:
--------------------------------------------------------------
> tothc wrote:
>
>
> [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireMavenVersion failed with message:
> Detected Maven Version: 2.2.1 is not in the allowed range [2.0.9,2.1).
This error states that the Maven version which you are using (2.2.1) is not allowed for the project you are building (the tutorials). Within the tutorial pom.xml file we have set this restriction. The tutorials have been tested using Maven 2.0.9. The only reason why we added a upper limit to the Maven version is because we of our experience with Maven issues with every new Maven version. It doesn't mean the the tutorial +will+ not work against Maven 2.2.1, it just means we haven't tested it agains that version and hence don't know if it's going to run into issues.
You'll have to downgrade to Maven 2.0.9 (atleast for now) to get that running. But i think it makes sense to remove that restriction from the tutorials. I'll create a JIRA for that and fix it.
> tothc wrote:
>
>
> I want to start with the first example, the stateless bean.
> First I got FATAL errors. Googled it and turned out that I had to add this
> " <repositories>
> <repository>
> <id>jboss-repo</id>
> <url>http://repository.jboss.org/maven2/</url>
> </repository>
> </repositories>"
>
> to the pom.xml of the stateless example. Note: does this mean that I have to do this modification to every freakin' example's pom.xml???
Maven works on the concept of "repositories" where it searches for dependent published artifacts. Any project like the tutorial you are building can depend on these published artifacts. The project has to point Maven to the right repositories. This can be done in two ways:
1) Either set it in the pom.xml (hierarchy) of the project you are building
OR 2) Set in a global Maven settings.xml file (like explained here http://community.jboss.org/wiki/MavenSettings)
You don't have set it in every pom.xml. Either set it in the Maven settings.xml file or set it in TUTORIAL_HOME/build/pom.xml. Again, i think this should have been done in the tutorials by default so that users don't have to change it themselves. I'll create a JIRA for this too.
> tothc wrote:
>
>
> After adding this to the xml the build command seemed to work, it downloaded gazillions of pom (?) files to somewhere (??? I couldn't find where, I could just read the source, the webpage address it downloaded from).
>
That's expected from Maven. As i explained earlier, Maven downloads the dependencies of projects from repositories. So if project A depends on project B, then while building project A, Maven downloads project B to your local file system. Project B internally might depend on project C, so this will lead to a long chain of transitive dependency downloads. So the first time you build a prooject through Maven it usually takes time to download all those dependencies. Once they are downloaded to your local file system, they won't be downloaded the next time.
By the way, if you are running into trouble with Maven and instead are more interested in just seeing EJB3 in action, then you can alternatively use the Ant approach of building the tutorials (which is explained in the tutorial docs).
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527324#527324
16 years, 2 months
[EJB 3.0] New message: "EJB 3.0 tutorial with Maven 2.2.1"
by Csaba Toth
User development,
A new message was posted in the thread "EJB 3.0 tutorial with Maven 2.2.1":
http://community.jboss.org/message/527322#527322
Author : Csaba Toth
Profile : http://community.jboss.org/people/tothc
Message:
--------------------------------------------------------------
In advance: I'm new to Maven and JBoss also.
Windows 7 64 bit
Maven 2.2.1
EJB 3.0 tutorial
I want to start with the first example, the stateless bean.
First I got FATAL errors. Googled it and turned out that I had to add this
" <repositories>
<repository>
<id>jboss-repo</id>
<url>http://repository.jboss.org/maven2/</url>
</repository>
</repositories>"
to the pom.xml of the stateless example. Note: does this mean that I have to do this modification to every freakin' example's pom.xml???
After adding this to the xml the build command seemed to work, it downloaded gazillions of pom (?) files to somewhere (??? I couldn't find where, I could just read the source, the webpage address it downloaded from).
But unfortunately I got an ERROR from a WARNING. Searching for this warning in google gives just one result in a blog, which doesn't solve my problem. So I would appreciate some help. Thanks.
"$EJB3_TUTORIAL_HOME\source\stateless>mvn clean install -e -PRunSingleTutorial
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building EJB3.0 Stateless Bean Tutorial
[INFO] task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean {execution: default-clean}]
[INFO] [enforcer:enforce {execution: enforce-banned-dependencies}]
[WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireMavenVersion failed with message:
Detected Maven Version: 2.2.1 is not in the allowed range [2.0.9,2.1).
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed.
at org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:218)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6 seconds
[INFO] Finished at: Fri Feb 19 11:35:48 CST 2010
[INFO] Final Memory: 70M/295M
[INFO] ------------------------------------------------------------------------
"
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527322#527322
16 years, 2 months
[Beginner's Corner] New message: "How to using propertyService to substitute parameter in ejb-jar.xml file"
by Louie Liu
User development,
A new message was posted in the thread "How to using propertyService to substitute parameter in ejb-jar.xml file":
http://community.jboss.org/message/527316#527316
Author : Louie Liu
Profile : http://community.jboss.org/people/liuxiaodu
Message:
--------------------------------------------------------------
We have a MDB with some activation parameters needed to be externalized due to the security reason. We we are running application in JBOSS 4.2, we are using the org.jboss.varia.property.SystemPropertiesService service to define the properties which are used in my ejb mdb configuration file (ejb-jar.xml).
Here is the example:
In my ejb-jar.xml, we define the activation attribute place holder like the following:
* <activation-config>
<activation-config-property>
<activation-config-property-name>ConnectionURLs</activation-config-property-name>
<activation-config-property-value>${ConnectionURLs}</activation-config-property-value>
</activation-config-property>
.....
</activation-config>*
and we define the properties service:
*<mbean code="org.jboss.varia.property.SystemPropertiesService"
name="jboss:type=Service,name=SystemProperties">*
* <attribute name="Properties">** ConnectionURLs=tcp://server:3507,tcp://server:3508*
* ......**
</attribute>*
* * *</mbean>*
It works in JBOSS 4.2, meaning the value defined in properties service get substituted during the server startup.
However, when we upgrade the JBOSS to 5.1, it is not working anymore. Basically, eventhrough there is properties service available in JBOSS 5.1, but for some reason, if we have parameters defined in ejb-jar.xml, the values defined in the JBOSS 5.1 properties service mbean did not substitute the parameters in ejb-jar.xml and then MDB deploy FAILED.
I would like to get help and pointing me the right directory of how to make it work.
Thanks a lot.
Louie Liu
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527316#527316
16 years, 2 months
[JCA] New message: "How to create a XA aware connection factory"
by Kreek Fred
User development,
A new message was posted in the thread "How to create a XA aware connection factory":
http://community.jboss.org/message/527303#527303
Author : Kreek Fred
Profile : http://community.jboss.org/people/fredk
Message:
--------------------------------------------------------------
Hi,
Currently I have a connection factory that supports local transactions, but since I need to connect to another database I have to transform it to a XA aware factory.
I changed my resource adapter configuration to support XATransactions, changed my custom factory class to extend org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory
and my changed my xa-ds.xml as attached.
After deploying the code on JBoss 5.1.0.GA
This is the error message:
16:43:51 WARN [main] JBossManagedConnectionPool.warn(363) Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Ongeldige Oracle-URL opgegeven.: OracleDataSource.makeURL)
at org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:465)
at org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:409)
at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:633)
at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:267)
at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:679)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:404)
at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:381)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:496)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
at nl.xa.OracleWrapperDataSource.getConnection(OracleWrapperDataSource.java:45)
...
...
(BTW translation 'Ongeldige Oracle-URL opgegeven' is about the same as 'Passed invalid Oracle-URL')
I tried to change 'ConnectionURL' to 'URL' and to 'URLProperty' but those won't work either. What am I doing wrong.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527303#527303
16 years, 2 months
[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"
by Kabir Khan
User development,
A new message was posted in the thread "Profiling the dependency project":
http://community.jboss.org/message/527292#527292
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
> alesj wrote:
>
>
> > Since installCallbacks and uninstallCallbacks are ConcurrentHashMaps, I think the read lock is unnecessary here in AbstractController:
> Since I think callbacks are already used in some explicitly locked code (via Lock),
> what about if we leave the locks and just change the callbacks to plain HashMap?
>
> Like discussed on the call, what is faster in a really-rare-concurrent env?
> * lock + plain hash collection
> * concurrent hash collection
>
> Jason, DML?
I see we are adding them here (and similarly for removing them)
protected <T> void addCallback(Object name, boolean isInstallPhase, CallbackItem<T> callback)
{
lockWrite();
try
{
Map<Object, Set<CallbackItem<?>>> map = (isInstallPhase ? installCallbacks : uninstallCallbacks);
Set<CallbackItem<?>> callbacks = map.get(name);
if (callbacks == null)
{
callbacks = new HashSet<CallbackItem<?>>();
map.put(name, callbacks);
}
callbacks.add(callback);
}
finally
{
unlockWrite();
}
}
So this needs some rethinking. Since callbacks is a plain HashSet and the user of getCallbacks() is iterating over them this code is broken.
So we either make everything plain HashMap/Set, reintroduce the locks, and replace getContexts() with this method where we do the iteration (via addAll()) with the lock taken:
/**
* Get the matching callbacks.
*
* @param result the set to put any callbacks into
* @param name demand name
* @param isInstallPhase install or uninstall phase
* @return The passed in result parameter. If it was null and callbacks were found a new set is created
*/
protected Set<CallbackItem<?>> addCallbacks(Set<CallbackItem<?>> result, Object name, boolean isInstallPhase)
{
lockRead();
try
{
Map<Object, Set<CallbackItem<?>>> map = (isInstallPhase ? installCallbacks : uninstallCallbacks);
Set<CallbackItem<?>> callbacks = map.get(name);
if (callbacks != null)
{
if (result == null)
result = new HashSet<CallbackItem<?>>();
result.addAll(callbacks);
}
}
finally
{
unlockRead();
}
return result;
}
Or we make everything involved concurrent map set that would work too. I need to understand a bit better how this code is used.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527292#527292
16 years, 2 months
[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"
by David Lloyd
User development,
A new message was posted in the thread "Profiling the dependency project":
http://community.jboss.org/message/527291#527291
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
> alesj wrote:
>
>
> > Since installCallbacks and uninstallCallbacks are ConcurrentHashMaps, I think the read lock is unnecessary here in AbstractController:
> Since I think callbacks are already used in some explicitly locked code (via Lock),
> what about if we leave the locks and just change the callbacks to plain HashMap?
>
> Like discussed on the call, what is faster in a really-rare-concurrent env?
> * lock + plain hash collection
> * concurrent hash collection
>
> Jason, DML?
Well, if you're already locking, concurrent hash maps will generally give you general throughput in the contended case; if there's only one contender then there's only one lock acquisition so it's a wash, on paper. In reality, a CHM is actually a bit more complex, and it's also a really big structure (even if it's empty), consisting of a ReentrantLock for each lock stripe, each of which includes a bunch of stuff, so you get another kind of savings by using a simple synchronized map. In fact I'm hesitant to ever use CHM just because of its excessive size, especially if you're creating a lot of them (if you ever do a memory profile of AS, you can see that CHM and its components tend to bubble to the top of the list). So for low contention situations I'd always recommend a plain synchronized map.
The best solution would of course be to eliminate the lock - if you're already protected, you could use a plain hashmap. Otherwise consider if copy-on-write is suitable for you - Jason's FastCopyHashMap is good for that kind of thing.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527291#527291
16 years, 2 months
[EJB 3.0] New message: "Servlet 3.0 and no-interface session bean"
by Juergen Zimmermann
User development,
A new message was posted in the thread "Servlet 3.0 and no-interface session bean":
http://community.jboss.org/message/527285#527285
Author : Juergen Zimmermann
Profile : http://community.jboss.org/people/Juergen.Zimmermann
Message:
--------------------------------------------------------------
I'm not sure whether this is the right forum. Otherwise, please give me a hint where to post.
Using JBossAS 6.0.0.M2 I tried a servlet 3.0 referencing a no-interface stateless session bean and the deployment failed (see stacktrace below):
@WebServlet(name="einfachesServlet", urlPatterns={"/EinfachesServlet"})
public class EinfachesServlet extends HttpServlet {
@EJB
private Kundenverwaltung kv; // no-interface stateless session bean
...
}
Stacktrace of the deployment:
16:24:35,966 WARN [org.jboss.web.tomcat.service.injection.WebEJBRemoteHandler] EJBTHREE-1289: Using legacy EjbEncInjector, because mappedName for enc "env/de.hska.kundenverwaltung.ui.EinfachesServlet/kv", field "null" is null (container.environmentRefGroup.annotatedEjbReferences = [AnnotatedEJBReferenceMetaData{name=de.hska.kundenverwaltung.ui.EinfachesServlet/kv,ejb-ref-type=null,link=null,ignore-dependecy=false,mapped/jndi-name=null,resolved-jndi-name=null,beanInterface=class de.hska.kundenverwaltung.service.Kundenverwaltung}])
16:24:35,966 WARN [org.jboss.injection.AbstractHandler] EJBTHREE-1828: calling deprecated addDependency
16:24:35,972 ERROR [org.jboss.web.tomcat.service.deployers.TomcatDeployment] ENC setup failed:
java.lang.IllegalStateException: Resolution should not happen via injection containerat org.jboss.web.tomcat.service.TomcatInjectionContainer.getEjbJndiName(
TomcatInjectionContainer.java:664)at org.jboss.injection.EjbEncInjector.inject(
EjbEncInjector.java:80)at org.jboss.web.tomcat.service.TomcatInjectionContainer.populateEnc(
TomcatInjectionContainer.java:506)at org.jboss.web.tomcat.service.deployers.TomcatDeployment$EncListener.lifecycleEvent(
TomcatDeployment.java:441)at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(
LifecycleSupport.java:115)at org.apache.catalina.core.StandardContext.start(
StandardContext.java:4442)at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(
TomcatDeployment.java:315)at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(
TomcatDeployment.java:145)at org.jboss.web.deployers.AbstractWarDeployment.start(
AbstractWarDeployment.java:462)at org.jboss.web.deployers.WebModule.startModule(
WebModule.java:116)at org.jboss.web.deployers.WebModule.start(
WebModule.java:95)at sun.reflect.NativeMethodAccessorImpl.invoke0(
Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(
Method.java:597)at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(
ReflectedDispatcher.java:157)at org.jboss.mx.server.Invocation.dispatch(
Invocation.java:96)at org.jboss.mx.server.Invocation.invoke(
Invocation.java:88)at org.jboss.mx.server.AbstractMBeanInvoker.invoke(
AbstractMBeanInvoker.java:271)at org.jboss.mx.server.MBeanServerImpl.invoke(
MBeanServerImpl.java:670)at org.jboss.system.microcontainer.ServiceProxy.invoke(
ServiceProxy.java:206)at $Proxy41.start(Unknown Source)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(
StartStopLifecycleAction.java:53)at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(
StartStopLifecycleAction.java:41)at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(
SimpleControllerContextAction.java:62)at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(
AccessControllerContextAction.java:71)at org.jboss.dependency.plugins.AbstractControllerContextActions.install(
AbstractControllerContextActions.java:51)at org.jboss.dependency.plugins.AbstractControllerContext.install(
AbstractControllerContext.java:378)at org.jboss.system.microcontainer.ServiceControllerContext.install(
ServiceControllerContext.java:301)at org.jboss.dependency.plugins.AbstractController.install(
AbstractController.java:2029)at org.jboss.dependency.plugins.AbstractController.incrementState(
AbstractController.java:1050)at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(
AbstractController.java:1289)at org.jboss.dependency.plugins.AbstractController.resolveContexts(
AbstractController.java:1213)at org.jboss.dependency.plugins.AbstractController.resolveContexts(
AbstractController.java:1107)at org.jboss.dependency.plugins.AbstractController.change(
AbstractController.java:918)at org.jboss.dependency.plugins.AbstractController.change(
AbstractController.java:633)at org.jboss.system.ServiceController.doChange(
ServiceController.java:671)at org.jboss.system.ServiceController.start(
ServiceController.java:443)at org.jboss.system.deployers.ServiceDeployer.start(
ServiceDeployer.java:189)at org.jboss.system.deployers.ServiceDeployer.deploy(
ServiceDeployer.java:102)at org.jboss.system.deployers.ServiceDeployer.deploy(
ServiceDeployer.java:49)at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(
AbstractSimpleRealDeployer.java:62)at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(
AbstractRealDeployer.java:55)at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(
DeployerWrapper.java:179)at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(
DeployersImpl.java:1660)at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(
DeployersImpl.java:1378)at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(
DeployersImpl.java:1399)at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(
DeployersImpl.java:1431)at org.jboss.deployers.plugins.deployers.DeployersImpl.install(
DeployersImpl.java:1319)at org.jboss.dependency.plugins.AbstractControllerContext.install(
AbstractControllerContext.java:378)at org.jboss.dependency.plugins.AbstractController.install(
AbstractController.java:2029)at org.jboss.dependency.plugins.AbstractController.incrementState(
AbstractController.java:1050)at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(
AbstractController.java:1289)at org.jboss.dependency.plugins.AbstractController.resolveContexts(
AbstractController.java:1213)at org.jboss.dependency.plugins.AbstractController.resolveContexts(
AbstractController.java:1107)at org.jboss.dependency.plugins.AbstractController.change(
AbstractController.java:918)at org.jboss.dependency.plugins.AbstractController.change(
AbstractController.java:633)at org.jboss.deployers.plugins.deployers.DeployersImpl.process(
DeployersImpl.java:898)at org.jboss.deployers.plugins.main.MainDeployerImpl.process(
MainDeployerImpl.java:677)at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(
MainDeployerAdapter.java:117)at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(
HDScanner.java:409)at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(
HDScanner.java:294)at java.util.concurrent.Executors$RunnableAdapter.call(
Executors.java:441)at java.util.concurrent.FutureTask$Sync.innerRunAndReset(
FutureTask.java:317)at java.util.concurrent.FutureTask.runAndReset(
FutureTask.java:150)at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(
ScheduledThreadPoolExecutor.java:98)at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(
ScheduledThreadPoolExecutor.java:181)at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(
ScheduledThreadPoolExecutor.java:205)at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
ThreadPoolExecutor.java:886)at java.util.concurrent.ThreadPoolExecutor$Worker.run(
ThreadPoolExecutor.java:908)at java.lang.Thread.run(
Thread.java:619)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527285#527285
16 years, 2 months