[JBoss JIRA] (AS7-4674) Child resources displayed out of order
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-4674:
-----------------------------------
Summary: Child resources displayed out of order
Key: AS7-4674
URL: https://issues.jboss.org/browse/AS7-4674
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.1.Final
Reporter: Thomas Diesler
Assignee: Jason Greene
Fix For: 7.2.0.Alpha1
A runtime resource may have child resource entries that have a natural ordering. Ordering should not be ignored
{code}
[standalone@localhost:9999 /] /subsystem=osgi:read-resource(include-runtime=true,recursive=true)
{
"outcome" => "success",
"result" => {
"activation" => "eager",
"startlevel" => 1,
"bundle" => {
"1" => {
"id" => 1L,
"location" => "org.osgi.enterprise",
"startlevel" => 1,
"state" => "RESOLVED",
"symbolic-name" => "osgi.enterprise",
"type" => "bundle",
"version" => "4.2.0.201003190513"
},
"0" => {
"id" => 0L,
"location" => "System Bundle",
"startlevel" => 0,
"state" => "ACTIVE",
"symbolic-name" => "system.bundle",
"type" => "bundle",
"version" => "0.0.0"
},
"6" => {
"id" => 6L,
"location" => "org.jboss.as.osgi.configadmin",
"startlevel" => 1,
"state" => "ACTIVE",
"symbolic-name" => "jboss-as-osgi-configadmin",
"type" => "bundle",
"version" => "7.1.2.Final-SNAPSHOT"
},
"5" => {
"id" => 5L,
"location" => "org.apache.felix.configadmin",
"startlevel" => 1,
"state" => "ACTIVE",
"symbolic-name" => "org.apache.felix.configadmin",
"type" => "bundle",
"version" => "1.2.8"
},
"4" => {
"id" => 4L,
"location" => "org.jboss.osgi.logging",
"startlevel" => 1,
"state" => "ACTIVE",
"symbolic-name" => "jboss-osgi-logging",
"type" => "bundle",
"version" => "1.0.0"
},
"3" => {
"id" => 3L,
"location" => "org.apache.felix.log",
"startlevel" => 1,
"state" => "ACTIVE",
"symbolic-name" => "org.apache.felix.log",
"type" => "bundle",
"version" => "1.0.0"
},
"2" => {
"id" => 2L,
"location" => "javax.servlet.api:v25",
"startlevel" => 1,
"state" => "RESOLVED",
"symbolic-name" => "javax.servlet.api",
"type" => "bundle",
"version" => "2.5.0.Final"
}
},
"capability" => {
"javax.transaction.api" => {},
"org.jboss.osgi.logging" => {"startlevel" => "1"},
"javax.servlet.api:v25" => {},
"org.jboss.as.osgi.configadmin" => {"startlevel" => "1"},
"org.apache.felix.log" => {"startlevel" => "1"},
"org.apache.felix.configadmin" => {"startlevel" => "1"}
},
"property" => {"org.osgi.framework.startlevel.beginning" => {"value" => "1"}}
}
}
{code}
In the case of OSGi, the runtime bundles should be sorted by id.
For natural ordering, the ResourceEntry could implement Comparable<ResourceEntry>
{code}
Set<ResourceEntry> getChildren(String childType)
{code}
alternatively, the controller could preserve the implicit order of the returned set (i.e. internally using a List).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (JBRULES-3275) MVEL Dialect: BigDecimal does not show the correct value
by Alessandro Lazarotti (Created) (JIRA)
MVEL Dialect: BigDecimal does not show the correct value
--------------------------------------------------------
Key: JBRULES-3275
URL: https://issues.jboss.org/browse/JBRULES-3275
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.3.0.Final, 5.2.0.Final
Environment: Fedora 15, JDK Oracle 1.6
Reporter: Alessandro Lazarotti
Assignee: Mario Fusco
MVEL does not show the correct value for BigDecimal instances, like:
BigDecimal ale = 500.01B;
System.out.println(ale);
The result is: 500
BigDecimal should invoke toString, like any Java instance to show values of variables instead of .intValue().
The same happens to show result of arithmetic operations btw BigDecimals:
BigDecimal test = new BigDecimal("50000");
System.out.println(test / new BigDecimal("1.13"));
The result is:
44247
... instead of 44247.78761061946902654867256637168.
Anyway, the internal representation is correct, only the method invoked to show the values is wrong.
The result for:
System.out.println( (test / new BigDecimal("1.13")) == 44247.78761061946902654867256637168B)
is true.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] Created: (AS7-1296) JBREM00200: Remote connection failed
by Gary Quinn (JIRA)
JBREM00200: Remote connection failed
------------------------------------
Key: AS7-1296
URL: https://issues.jboss.org/browse/AS7-1296
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.0.0.Final
Reporter: Gary Quinn
Downloaded JBoss and followed the "Installing and starting JBoss AS on Linux, Unix or Mac OS X". started the standalone server (jboss-as-7.0.0.Final/bin/standalone.sh)
Server starts but keep logging the following error: 13:57:52,026 ERROR [org.jboss.remoting.remote] (XNIO NIO Read 1) JBREM00200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4580) Hornetq 2.2.14 Discovery Binding Failing
by James Scollard (JIRA)
James Scollard created AS7-4580:
-----------------------------------
Summary: Hornetq 2.2.14 Discovery Binding Failing
Key: AS7-4580
URL: https://issues.jboss.org/browse/AS7-4580
Project: Application Server 7
Issue Type: Clarification
Components: Clustering
Affects Versions: 7.1.0.Final
Environment: RHEL 6, jdk 1.6.0_32, hornetq 2.2.14
Reporter: James Scollard
Assignee: Paul Ferraro
Priority: Minor
We have downloaded the new (published yesterday) hornetq 2.2.14 from https://repository.jboss.org/nexus/content/repositories/releases/org/horn... and added our config from 2.2.5 which ran without issues. Only submitting this since this was released yesterday. We are trying to upgrade from 2.2.5 due to the bug that affects our topic/subscriber configuration preventing clustering. Also the Maven 2.2.14 client does not seem to be available anywhere in the jboss maven repo.
JBoss's maven repository: https://repository.jboss.org/nexus/content/repositories/releases/org/horn...
Only 2.2.13 and 2.2.15 are available.
Hornetq 2.2.14 Cluster Settings:
<broadcast-groups>
<broadcast-group name="Corp-UAT">
<group-address>225.3.2.3</group-address>
<group-port>7777</group-port>
<broadcast-period>5000</broadcast-period>
<connector-ref>netty</connector-ref>
</broadcast-group>
</broadcast-groups>
<discovery-groups>
<discovery-group name="Discovery">
<group-address>225.3.2.3</group-address>
<group-port>7777</group-port>
<refresh-timeout>10000</refresh-timeout>
</discovery-group>
</discovery-groups>
<cluster-connections>
<cluster-connection name="UAT-Cluster">
<address>jms</address>
<connector-ref>netty</connector-ref>
<discovery-group-ref discovery-group-name="Discovery"/>
</cluster-connection>
</cluster-connections>
Error on Startup:
* [main] 20-Apr 13:7:23,775 WARNING [DiscoveryGroupImpl] Could not bind to 225.3.2.3 (IPv4 address); make sure your discovery group-address is of the same type as the IP stack (IPv4 or IPv6).
Ignoring discovery group-address, but this may lead to cross talking.
java.net.BindException: Cannot assign requested address
at java.net.PlainDatagramSocketImpl.bind0(Native Method)
at java.net.PlainDatagramSocketImpl.bind(PlainDatagramSocketImpl.java:91)
at java.net.DatagramSocket.bind(DatagramSocket.java:372)
at java.net.MulticastSocket.<init>(MulticastSocket.java:147)
at org.hornetq.core.cluster.impl.DiscoveryGroupImpl.start(DiscoveryGroupImpl.java:129)
at org.hornetq.core.client.impl.ServerLocatorImpl.initialise(ServerLocatorImpl.java:370)
at org.hornetq.core.client.impl.ServerLocatorImpl.start(ServerLocatorImpl.java:544)
at org.hornetq.core.server.cluster.impl.ClusterConnectionImpl.activate(ClusterConnectionImpl.java:707)
at org.hornetq.core.server.cluster.impl.ClusterConnectionImpl.start(ClusterConnectionImpl.java:385)
at org.hornetq.core.server.cluster.impl.ClusterManagerImpl.start(ClusterManagerImpl.java:205)
at org.hornetq.core.server.impl.HornetQServerImpl.initialisePart2(HornetQServerImpl.java:1493)
at org.hornetq.core.server.impl.HornetQServerImpl.access$1200(HornetQServerImpl.java:138)
at org.hornetq.core.server.impl.HornetQServerImpl$SharedStoreLiveActivation.run(HornetQServerImpl.java:1919)
at org.hornetq.core.server.impl.HornetQServerImpl.start(HornetQServerImpl.java:366)
at org.hornetq.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:269)
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.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
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.LifecycleAction.installActionInternal(LifecycleAction.java:221)
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:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
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:319)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
at org.jboss.kernel.plugins.deployment.xml.BeanXMLDeployer.deploy(BeanXMLDeployer.java:96)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.deploy(HornetQBootstrapServer.java:236)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.deploy(HornetQBootstrapServer.java:206)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.bootstrap(HornetQBootstrapServer.java:155)
at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:83)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.run(HornetQBootstrapServer.java:116)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.main(HornetQBootstrapServer.java:73)
* [main] 20-Apr 13:7:23,820 INFO [NettyAcceptor] Started Netty Acceptor version 3.2.5.Final-a96d88c 10.60.2.38:7777 for CORE protocol
* [main] 20-Apr 13:7:23,821 INFO [HornetQServerImpl] Server is now live
* [main] 20-Apr 13:7:23,821 INFO [HornetQServerImpl] HornetQ Server version 2.2.14.Final (HQ_2_2_14_FINAL, 122) [4aab31e6-8b0b-11e1-b160-4db571fc46b1]) started
Then once the second server is started with the same settings:
* [Thread-4 (HornetQ-server-HornetQServerImpl::serverUUID=4aab31e6-8b0b-11e1-b160-4db571fc46b1-1332226643)] 20-Apr 13:14:10,689 INFO [BridgeImpl] Bridge ClusterConnectionBridge@4e842e74 [name=sf.UAT-Cluster.3ba6a1f7-8b0c-11e1-a397-b19663cedaac, queue=QueueImpl[name=sf.UAT-Cluster.3ba6a1f7-8b0c-11e1-a397-b19663cedaac, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=4aab31e6-8b0b-11e1-b160-4db571fc46b1]]@4805e9f1 targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@4e842e74 [name=sf.UAT-Cluster.3ba6a1f7-8b0c-11e1-a397-b19663cedaac, queue=QueueImpl[name=sf.UAT-Cluster.3ba6a1f7-8b0c-11e1-a397-b19663cedaac, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=4aab31e6-8b0b-11e1-b160-4db571fc46b1]]@4805e9f1 targetConnector=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=7777&host=10-60-2-39], discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1224217602[nodeUUID=4aab31e6-8b0b-11e1-b160-4db571fc46b1, connector=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=7777&host=10-60-2-38, address=jms, server=HornetQServerImpl::serverUUID=4aab31e6-8b0b-11e1-b160-4db571fc46b1])) [initialConnectors=[org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=7777&host=10-60-2-39], discoveryGroupConfiguration=null]] is connected
Is there a setting that I may have excluded when adding my configuration to the newer container? I just copied over the configs that came with the archive but when I look at the configs that were included in the new version they are the same as the defaults from 2.2.5.
Apologies. We are new to adopting this product so it is very likely that we have missed something.
Thanks in advance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (JGRP-1453) Exception thrown when diagnostics address /port not equal to udp address /port
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created JGRP-1453:
-----------------------------------------
Summary: Exception thrown when diagnostics address /port not equal to udp address /port
Key: JGRP-1453
URL: https://issues.jboss.org/browse/JGRP-1453
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.9
Environment: Fedora 16, x86_64
AS7 4.1.1.Final
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Fix For: 3.0.10
When using JGroups as part of AS7 in the server configuration standalone-ha.xml, upon start up, we receive the exception:
{noformat}
09:52:36,831 ERROR [org.jboss.msc.service.fail] (pool-14-thread-1) MSC00001: Failed to start service jboss.jgroups.channel.web: org.jboss.msc.service.StartException in service jboss.jgroups.channel.web: java.lang.IllegalArgumentException: diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:62) [jboss-as-clustering-common-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
Caused by: java.lang.IllegalArgumentException: diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different
at org.jgroups.protocols.UDP.createSockets(UDP.java:359) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.UDP.start(UDP.java:224) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:938) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.startStack(JChannel.java:841) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.connect(JChannel.java:277) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.connect(JChannel.java:261) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:44) [jboss-as-clustering-jgroups-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:59) [jboss-as-clustering-common-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
{noformat}
even when the address / port combination for udp and the address / port combination for diagnostics are distinct:
{noformat}
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
...
<socket-binding name="jgroups-diagnostics" port="0" multicast-address="ff0e::1" multicast-port="7500"/>
<socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:ff0e::1}" multicast-port="45700"/>
<socket-binding name="jgroups-tcp" port="7600"/>
<socket-binding name="jgroups-tcp-fd" port="57600"/>
<socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:ff0e::1}" multicast-port="45688"/>
<socket-binding name="jgroups-udp-fd" port="54200"/>
<socket-binding name="modcluster" port="0" multicast-address="ff0e::1" multicast-port="23364"/>
...
</socket-binding-group>
{noformat}
The expected behaviour is that as long as the ports are distinct, we should be able to use the same mcast address for both udp and diagnostics.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] Created: (EJBTHREE-2248) singleton time bean starts with uninitialized EJBs
by Chris Wesdorp (JIRA)
singleton time bean starts with uninitialized EJBs
--------------------------------------------------
Key: EJBTHREE-2248
URL: https://issues.jboss.org/browse/EJBTHREE-2248
Project: EJB 3.0
Issue Type: Bug
Components: ejb3_1
Environment: jboss 6.0.0 final
Reporter: Chris Wesdorp
Attachments: jboss-timer-singleton.zip
During the deployment of a (large) EAR the following problem occurs. In one of the JARs a singleton EJB is included which has a method annotated with @Schedule. The time out for this schedule is every minute. This singleton has references to other EJBS in the project. But at deployment the singleton is loaded before the referenced EJBs are added registered in JNDI. When the time out of the singleton occurs a NullPointerException is thrown because the container isn't able to inject the other EJBs.
{noformat}2011-05-12 13:21:01,201 ERROR [org.jboss.ejb3.timerservice.mk2.task.TimerTask] (pool-99-thread-3) Error during retyring timeout for timer: [id=2d8011ca-66e3-4746-a035-3fa2b5a68263 timedObjectId=jboss.j2ee:ear=ht-ear-1.8.0-SNAPSHOT.ear,jar=ht-system.jar,name=BatchExecutor,service=EJB3 auto-timer?:true persistent?:true timerService=org.jboss.ejb3.timerservice.mk2.TimerServiceImpl@1d261c7e initialExpiration=2011-05-10 00:00:00.0 intervalDuration(in milli sec)=0 nextExpiration=Tue May 10 16:03:00 CEST 2011 timerState=RETRY_TIMEOUT: javax.ejb.EJBException: java.lang.NullPointerException
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:137) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.get(SingletonEJBInstanceManagerImpl.java:152) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.impl.container.SingletonContainer.invoke(SingletonContainer.java:201) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.callTimeout(AOPBasedSingletonContainer.java:886) [:1.0.0-alpha-28]
at org.jboss.ejb3.timerservice.mk2.task.CalendarTimerTask.callTimeout(CalendarTimerTask.java:80) [:1.0.0-alpha-13]
at org.jboss.ejb3.timerservice.mk2.task.TimerTask.run(TimerTask.java:127) [:1.0.0-alpha-13]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_24]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_24]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_24]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) [:1.6.0_24]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: org.jboss.injection.manager.spi.InjectionException: javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NameNotFoundException: ConfigDAO not bound]]
at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:87) [:1.0.0-alpha-6]
at org.jboss.injection.manager.core.DefaultInjectionContext.proceed(DefaultInjectionContext.java:58) [:1.0.0-alpha-6]
at org.jboss.injection.manager.core.DefaultInjectionManager.inject(DefaultInjectionManager.java:58) [:1.0.0-alpha-6]
at org.jboss.injection.manager.core.DefaultInjectionManager.inject(DefaultInjectionManager.java:64) [:1.0.0-alpha-6]
at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:140) [:1.7.17]
at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:125) [:1.7.17]
at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.7.17]
at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:116) [:1.7.17]
at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1]
at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:116) [:1.7.17]
at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1363) [:1.7.17]
at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.postConstruct(AOPBasedSingletonContainer.java:759) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:133) [:1.0.0-alpha-28]
... 13 more{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months