[JBoss JIRA] Created: (JBAS-6400) ExecutionContext returns the trasnaction timeout in seconds, but we use that argument to schedule the thread that is in milliseconds.
by Jay Howell (JIRA)
ExecutionContext returns the trasnaction timeout in seconds, but we use that argument to schedule the thread that is in milliseconds.
-------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-6400
URL: https://jira.jboss.org/jira/browse/JBAS-6400
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-5.0.0.GA, JBossAS-4.2.2.GA
Reporter: Jay Howell
Assignee: Jesper Pedersen
Fix For: JBossAS-5.0.1.GA, JBossAS-4.2.4.GA
PLEASE NOTE: THIS ONLY AFFECTS 3RD PARTY ADAPTERS RUNNING INSIDE THE JBOSS APP SERVER. THIS DOES NOT AFFECT ANY OF THE ADAPTERS THAT JBOSS SHIPS WITH.
The implementing adapter handles scheduling work to be performed. So they usually do something like..
WorkManager wm = adapter.ctx.getWorkManager();
TestWork work = new Somework();
ExecutionContext ec = new ExecutionContext();
...
ec.TransactionTimeout(trans.getTimeout())
wm.doWork(work, 0l, ec, null);
Usually the work class schedules the work by telling the WorkManager to do some work(dowork). If you don't specify a timeout in the execution context, the thread will wait indefinilty to finish the work. In our adapters(JMS, MAIL), I don't see where we ever set a timout in the ExecutionContext. So we will never run into the but I'm getting ready to describe.
The ExecutionContext, is required to express the timeout in seconds(not milliseconds). http://java.sun.com/j2ee/1.4/docs/api/javax/resource/spi/work/ExecutionCo...
The org.jboss.resource.work.WorkWrapper(implements Task) is the task that gets passed to the thread pool. It implements getCompletionTimeout. getCompletionTimeout on the task is in milliseconds. You can see by the following method we pass the executionContext.getTransactionTimeout() as the completion time for the task. So we go from seconds to milliseconds.
public long getCompletionTimeout()
{
return executionContext.getTransactionTimeout();
}
This means that if you initially have a timeout as 6 seconds, it will be passed to the thread pool as 6 milliseconds.
to move further down the stack(skipping a few layers ), you can see that in BasicThreadPool, you can see that we pass the timeout into the runTaskWrapper method, which constructs the TimeoutInfo Object.
long completionTimeout = wrapper.getTaskCompletionTimeout();
TimeoutInfo info = null;
if( completionTimeout > 0 )
{
checkTimeoutMonitor();
// Install the task in the
info = new TimeoutInfo(wrapper, completionTimeout);
tasksWithTimeouts.insert(info);
}
then in the TimeoutInfo constructor we set the timout time in milliseconds...
TimeoutInfo(TaskWrapper wrapper, long timeout)
{
this.start = System.currentTimeMillis();
this.timeoutMS = start + timeout;
this.wrapper = wrapper;
}
What we should do to fix this is inside the org.jboss.resource.work.WorkWrapper
public long getCompletionTimeout()
{
//get completionTimout on the task is in milliseconds. We need to convert.
return executionContext.getTransactionTimeout()*1000;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Created: (JBAS-6360) Multiple redeployments of ear when many 'watched files' are touched in the ear
by DRAI (JIRA)
Multiple redeployments of ear when many 'watched files' are touched in the ear
------------------------------------------------------------------------------
Key: JBAS-6360
URL: https://jira.jboss.org/jira/browse/JBAS-6360
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployers
Affects Versions: JBossAS-5.0.0.GA
Environment: Windows, JBoss Tools 3.0.0 CR 1
Reporter: DRAI
Assignee: Ales Justin
When many 'watched files' are touched simultaneously in an ear (for example web.xml, ejb-jar.xml and persistence.xml), the redeploy process is triggered independently for each file and the ear is redeployed as many times as there are modified files. It looks that the deploy process does not correctly clear the list of units to deploy after a deployment is finished.
This is particularly visible when using 'Project archives' of JBoss Tools because almost all files are touched at every build of the archives.
I'm pretty sure this has nothing to do with the archive not being completely built at the time of deployment because the number of redeployments is not just 2 but more than 5 and after debugging the deployer, it is exactly the same number of times than there are watched files.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Created: (JBAS-6343) JCA adapter inflow does not Roll back messages if using a non-xa connection factory in the JNDIProviderAdapter
by Jay Howell (JIRA)
JCA adapter inflow does not Roll back messages if using a non-xa connection factory in the JNDIProviderAdapter
--------------------------------------------------------------------------------------------------------------
Key: JBAS-6343
URL: https://jira.jboss.org/jira/browse/JBAS-6343
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.2.3.GA
Reporter: Jay Howell
Assignee: Jesper Pedersen
This customer is using a non-xa connection factory(IBMMQ) and is having problems with 4.2.3 rolling messages back.
In 4.0.5, it looks like we set up an XATransactionDemarcationStrategy if the pool activation was set up for isDeliveryTransacted, but we didn't look to make sure that the resource gave us an XASession.
if(pool.getActivation().isDeliveryTransacted())
{
try
{
return new XATransactionDemarcationStrategy();
in 4.2.3, we fixed this and now its
if (activation.isDeliveryTransacted() && xaSession != null)
{
try
{
current = new XATransactionDemarcationStrategy();
This means that the customer was getting an XATransactionDemarcationStrategy, but now they are getting the LocalDemarcationStrategy. I thought to myself, wow, the XATransactionDemarcationStrategy should not work, but I see there is code in the bottom to handle it in the XATransactionDemarcationStrategy.
// NO XASession? then manually rollback.
// This is not so good but
// it's the best we can do if we have no XASession.
if (xaSession == null && pool.getActivation().isDeliveryTransacted())
{
session.rollback();
}
Looking at the jms inflow adapter, it doesn't look like we've ever supported transaction rollbacks for non-xa connection factories, but because of a bug in 4.0.5, we were allowing nonXA connection factories to get the XATransactionDemarcationStrategy. Inside of the 4.0.5 XATransactionDemarcationStrategy, when the tx is rolled back, we look to see if we have an XA session to rollback. if we don't, then we roll back the transacted session. So returning the wrong factory actaully gave us the correct behavior. Once we fixed the bug in 4.0.5, it seems that we broke what was once working.
What I would expect to see in the LocalDemarcationStrategy is something that would check current transaction to see if it's rolled back before calling the commit on the transacted session(similar to whats in the old StdServerSession). Here's what I see in the end for the LocalDemarcationStrategy in the inflow adapter.
private class LocalDemarcationStrategy implements TransactionDemarcationStrategy
{
public void end()
{
final JmsActivationSpec spec = pool.getActivation().getActivationSpec();
if (spec.isSessionTransacted())
{
if (session != null)
{
try
{
session.commit();
}
catch (JMSException e)
{
log.error("Failed to commit session transaction", e);
}
}
}
}
The code above just calls commit on the session, even if the tx has had setRollbackOnly on it inside the onMessage in an MDB. We tell customers not to throw runtime exceptions out of the onMessage because it causes the instance of the MDB to be thrown away.(which slows down performance and is discouraged by all the specs). But it looks like throwing a Runtime exception(which calls error, which calls session.rollback) is the only way to roll back a message for a non-xa ConnectionFactory(transacted session).
Should we support a non-xa connection factory by adding the logic to look at the transaction and roll the transacted session back if the current transaction is in a rolled back state? The fix, I would imagine would be something like this in the End of the LocalDemarcationStrategy. The fix would check the current tx to see if it's rolled back and if it is, it would roll the transacted session back.
This is somewhat of what I would expect.
private class LocalDemarcationStrategy implements TransactionDemarcationStrategy
{
public void end()
{
final JmsActivationSpec spec = pool.getActivation().getActivationSpec();
if (spec.isSessionTransacted())
{
if (session != null)
{
try
{
.....
// Marked rollback
if (trans.getStatus() == Status.STATUS_MARKED_ROLLBACK)
{
if (trace)
log.trace("Rolling back JMS transacted session");
// actually roll it back
session.rollback();
...
}
else
session.commit();
}
catch (JMSException e)
{
log.error("Failed to commit session transaction", e);
}
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Created: (JBAS-6336) CleanShutdownInterceptor Can Log Container State Incorrectly
by Jimmy Wilson (JIRA)
CleanShutdownInterceptor Can Log Container State Incorrectly
------------------------------------------------------------
Key: JBAS-6336
URL: https://jira.jboss.org/jira/browse/JBAS-6336
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.2.3.GA
Reporter: Jimmy Wilson
Assignee: Jimmy Wilson
Fix For: JBossAS-4.2.4.GA
CleanShutdownInterceptor will report this exception
Caused by: org.jboss.ha.framework.interfaces.GenericClusteringException: Container is shuting down on this node at org.jboss.ejb.plugins.CleanShutdownInterceptor.invokeHome(CleanShutdownInterceptor.java:234)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107) at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:637)
at org.jboss.ejb.Container.invoke(Container.java:975) at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:359)
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133)
even when the container in question failed to start as opposed to shutting down.
The error message needs to be updated to indicate that the container may not have started as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Created: (JBAS-4451) SNMP Adaptor of JBOSS does not handle the read community properly, it responds with "public" community instead of custom one.
by Pascal Heraud (JIRA)
SNMP Adaptor of JBOSS does not handle the read community properly, it responds with "public" community instead of custom one.
-----------------------------------------------------------------------------------------------------------------------------
Key: JBAS-4451
URL: http://jira.jboss.com/jira/browse/JBAS-4451
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Management services
Affects Versions: JBossAS-4.0.5.GA
Environment: Tested on REDHAT enterprise, JDK 1.5.0
Reporter: Pascal Heraud
Assigned To: Dimitris Andreadis
I'm using JBOSS SnmpAdaptor to monitor jboss and my web application.
Ive modified the read community of the snmp adaptor into the META-INF/jboss-service.xml configuration file :
<attribute name="ReadCommunity">myCommunity</attribute>
The software we're using for monitoring is using the PERL implementation NET-SNMP and is issuing errors because JBOSS does not reply using the good ReadCommunity (it responds using "public").
We tried with snmpwalk and you can find the logs.
Pascal.
Here is the details of the snmpwalk to the server, the -d options outputs the buffzer
=======================================================
>snmpwalk -d -v1 -c myCommunity localhost:1161 1.2.3.4.1.2
Sending 43 bytes to UDP: [127.0.0.1]:1161
0000: 30 29 02 01 00 04 0B 6D 79 43 6F 6D 6D 75 6E 69 0).....myCommuni
0016: 74 79 A1 17 02 02 38 B6 02 01 00 02 01 00 30 0B tyí...8Â......0.
0032: 30 09 06 05 2A 03 04 01 02 05 00 0 ..*......
Received 42 bytes from UDP: [127.0.0.1]:1161
0000: 30 28 02 01 00 04 06 70 75 62 6C 69 63 A2 1B 02 0(.....publicó..
0016: 02 38 B6 02 01 00 02 01 00 30 0F 30 0D 06 05 2A .8Â......0.0...*
0032: 03 04 01 03 42 04 1F A5 00 00 ....B..Ñ..
Sending 43 bytes to UDP: [127.0.0.1]:1161
0000: 30 29 02 01 00 04 0B 6D 79 43 6F 6D 6D 75 6E 69 0).....myCommuni
0016: 74 79 A0 17 02 02 38 B7 02 01 00 02 01 00 30 0B tyá...8À......0.
0032: 30 09 06 05 2A 03 04 01 02 05 00 0 ..*......
Received 42 bytes from UDP: [127.0.0.1]:1161
0000: 30 28 02 01 00 04 06 70 75 62 6C 69 63 A2 1B 02 0(.....publicó..
0016: 02 38 B7 02 01 00 02 01 00 30 0F 30 0D 06 05 2A .8À......0.0...*
0032: 03 04 01 02 42 04 05 55 4A D8 ....B..UJÏ
iso.2.3.4.1.2 = Gauge32: 89475800
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Created: (JBAS-6506) JBossAS-5.0.0.GA fails to start with 64bit IBM SDK 6 on AIX 5.3 (error in java.util.HashSet)
by Mihai Criveti (JIRA)
JBossAS-5.0.0.GA fails to start with 64bit IBM SDK 6 on AIX 5.3 (error in java.util.HashSet)
--------------------------------------------------------------------------------------------
Key: JBAS-6506
URL: https://jira.jboss.org/jira/browse/JBAS-6506
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.GA
Environment: AIX 5300-09-02-0849, 64 bit
java version "1.6.0" Java(TM) SE Runtime Environment (build pap6460sr3-20081106_07(SR3))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 AIX ppc64-64 jvmap6460-20081105_25433 (JIT enabled, AOT enabled)
Reporter: Mihai Criveti
Note: jboss-4.2.3.GA works fine with this version of Java (as well as various other Java apps), so the Java version is functional.
jboss-5.0.0.GA works with IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20080315 (JIT enabled) though.
It does not work with Java6 64:
cmihai@phobos:/home/cmihai/binary/jboss-5.0.0.GA-JDK6/bin$ ./run.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /home/cmihai/binary/jboss-5.0.0.GA-JDK6
JAVA: /usr/java6_64/bin/java
JAVA_OPTS: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
CLASSPATH: /home/cmihai/binary/jboss-5.0.0.GA-JDK6/bin/run.jar:/usr/java6_64/lib/tools.jar
=========================================================================
18:06:46,285 INFO [ServerImpl] Starting JBoss (Microcontainer)...
18:06:46,299 INFO [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812042120)
18:06:46,305 INFO [ServerImpl] Bootstrap URL: null
18:06:46,307 INFO [ServerImpl] Home Dir: /home/cmihai/binary/jboss-5.0.0.GA-JDK6
18:06:46,309 INFO [ServerImpl] Home URL: file:/home/cmihai/binary/jboss-5.0.0.GA-JDK6/
18:06:46,311 INFO [ServerImpl] Library URL: file:/home/cmihai/binary/jboss-5.0.0.GA-JDK6/lib/
18:06:46,317 INFO [ServerImpl] Patch URL: null
18:06:46,323 INFO [ServerImpl] Common Base URL: file:/home/cmihai/binary/jboss-5.0.0.GA-JDK6/common/
18:06:46,325 INFO [ServerImpl] Common Library URL: file:/home/cmihai/binary/jboss-5.0.0.GA-JDK6/common/lib/
18:06:46,327 INFO [ServerImpl] Server Name: default
18:06:46,329 INFO [ServerImpl] Server Base Dir: /home/cmihai/binary/jboss-5.0.0.GA-JDK6/server
18:06:46,332 INFO [ServerImpl] Server Base URL: file:/home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/
18:06:46,335 INFO [ServerImpl] Server Config URL: file:/home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default/conf/
18:06:46,337 INFO [ServerImpl] Server Home Dir: /home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default
18:06:46,339 INFO [ServerImpl] Server Home URL: file:/home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default/
18:06:46,341 INFO [ServerImpl] Server Data Dir: /home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default/data
18:06:46,344 INFO [ServerImpl] Server Library URL: file:/home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default/lib/
18:06:46,346 INFO [ServerImpl] Server Log Dir: /home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default/log
18:06:46,348 INFO [ServerImpl] Server Native Dir: /home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default/tmp/native
18:06:46,365 INFO [ServerImpl] Server Temp Dir: /home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default/tmp
18:06:46,367 INFO [ServerImpl] Server Temp Deploy Dir: /home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default/tmp/deploy
18:06:56,337 INFO [ServerImpl] Starting Microcontainer, bootstrapURL=file:/home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default/conf/bootstrap.xml
18:07:03,534 INFO [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.IterableTimedVFSCache]
18:07:03,645 INFO [VFSCacheFactory] Using VFSCache [IterableTimedVFSCache{lifetime=1800, resolution=60}]
18:07:11,591 INFO [CopyMechanism] VFS temp dir: /home/cmihai/binary/jboss-5.0.0.GA-JDK6/server/default/tmp
18:07:11,607 INFO [ZipEntryContext] VFS force nested jars copy-mode is enabled.
18:07:36,399 INFO [ServerInfo] Java version: 1.6.0,IBM Corporation
18:07:36,413 INFO [ServerInfo] Java VM: IBM J9 VM 2.4,IBM Corporation
18:07:36,414 INFO [ServerInfo] OS-System: AIX 5.3,ppc64
18:07:37,337 INFO [JMXKernel] Legacy JMX core initialized
18:08:05,390 ERROR [AbstractKernelController] Error installing to Instantiated: name=StandardBindings state=Described
java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[int] actual=[java.util.HashSet]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:395)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:153)
at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:106)
at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.createTarget(AOPConstructorJoinpoint.java:276)
at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:97)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:66)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
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:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1595)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:331)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:309)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
at org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:91)
at org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:161)
at org.jboss.bootstrap.microcontainer.ServerImpl.doStart(ServerImpl.java:144)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:394)
at org.jboss.Main.boot(Main.java:209)
at org.jboss.Main$1.run(Main.java:547)
at java.lang.Thread.run(Thread.java:735)
18:08:09,856 INFO [ProfileServiceImpl] Loading profile: default from: org.jboss.system.server.profileservice.repository.SerializableDeploymentRepository(a)65716571(root=/home/cmihai/binary/jboss-5.0.0.GA-JDK6/server, key=org.jboss.profileservice.spi.ProfileKey@143b82c3[domain=default,server=default,name=default])
18:08:09,887 INFO [ProfileImpl] Using repository:org.jboss.system.server.profileservice.repository.SerializableDeploymentRepository@65716571(root=/home/cmihai/binary/jboss-5.0.0.GA-JDK6/server, key=org.jboss.profileservice.spi.ProfileKey@143b82c3[domain=default,server=default,name=default])
18:08:09,889 INFO [ProfileServiceImpl] Loaded profile: ProfileImpl@4af64af6{key=org.jboss.profileservice.spi.ProfileKey(a)143b82c3[domain=default,server=default,name=default]}
Failed to boot JBoss:
java.lang.IllegalStateException: Incompletely deployed:
*** DEPLOYMENTS IN ERROR: Name -> Error
StandardBindings -> java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[int] actual=[java.util.HashSet]
*** DEPLOYMENTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
SystemPropertyBinder -> SystemPropertyBinder#1{Installed:Described}
SystemPropertyBinder#1 -> ServiceBindingManager{Installed:Described}
ServiceBindingStore -> StandardBindings{Installed:**ERROR**}
ServiceBindingManager -> ServiceBindingStore{Installed:Instantiated}
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:290)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:174)
at org.jboss.bootstrap.microcontainer.ServerImpl.doStart(ServerImpl.java:148)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:394)
at org.jboss.Main.boot(Main.java:209)
at org.jboss.Main$1.run(Main.java:547)
at java.lang.Thread.run(Thread.java:735)
18:08:18,701 INFO [ServerImpl] Runtime shutdown hook called, forceHalt: true
18:08:18,741 INFO [ServerImpl] Shutdown complete
Shutdown complete
Halting VM
cmihai@phobos:/home/cmihai$ oslevel -s
5300-09-02-0849
cmihai@phobos:/home/cmihai$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap6460sr3-20081106_07(SR3))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 AIX ppc64-64 jvmap6460-20081105_25433 (JIT enabled, AOT enabled)
J9VM - 20081105_025433_BHdSMr
JIT - r9_20081031_1330
GC - 20081027_AB)
JCL - 20081106_01
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months