[JBoss JIRA] Created: (AS7-944) EJB lifecycle interceptors that are not included in the deployment are not applied
by Marius Bogoevici (JIRA)
EJB lifecycle interceptors that are not included in the deployment are not applied
----------------------------------------------------------------------------------
Key: AS7-944
URL: https://issues.jboss.org/browse/AS7-944
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.0.0.Beta3
Reporter: Marius Bogoevici
Suppose that we have a class
{code}
@Startup @Singleton @Interceptors(A.class, B.class)
public class MyEJB {
}
{code}
Where A.class is included with the deployment and B.class is included in a module that is visible to the deployment.
B will be identified correctly as an interceptor for MyEJB, but LifecycleAnnotationParsingProcessor will not process it (as it apparently handles only components found within the deployment). Therefore, B will be ignored when creating the interceptor set for MyEJB, since ComponentInstallProcessor will treat it as a class that has no lifecycle methods.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JGRP-1340) GossipRouter: view shows mix of logical address and UUID for nodes
by Bela Ban (JIRA)
GossipRouter: view shows mix of logical address and UUID for nodes
------------------------------------------------------------------
Key: JGRP-1340
URL: https://issues.jboss.org/browse/JGRP-1340
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12.2, 3.0
[Vivek Sar]
On Sat, Jun 18, 2011 at 4:56 AM, Bela Ban <belaban(a)yahoo.com> wrote:
> > #1 When does this happen (after a restart of a node, or on starting a new
> > node) ?
[vivek]: this usually happens after a node has gone out of a group
(due to some intermittent network outage or communication issues) and
comes back to merge into the group. We have also seen this if we
restart the node without much time between stop and start (this was
the example above). So, it's kind of random - it happens both for
merge views and a new views.
> > #2 Do the UUIDs disappear after some time, and the logical names are shown ?
[vivek]: No, in my experience the UUID remain if it's the same view,
but if the view changes (if any node goes in and out of a group) then
the logical name come back, otherwise the UUID remains.
> > #3 Does this cause any issues, other than a not-so-nice view with mixed
> > logical and UUID addresses ?
[vivek]: It's both - in some cases we have seen this causes node
isolation - where we are not able to get the merges (see related
https://issues.jboss.org/browse/JGRP-1326) - even after a node come
back it's not able to merge back. In some cases, the communication is
ok and it's just not-so-nice view.
> > #4 What's you config ?
We are using Tunnel with PING with two GRs (this is with JGroups 2.12.1),
(see attached config)
Thanks,
-vivek
> >
> > On 6/17/11 10:27 PM, vivek sar wrote:
>> >>
>> >> Hi,
>> >>
>> >> We are currently using JGroups 2.12.1 with Tunnel protocol (using
>> >> PING for discovery). Once in a while we see node represented using
>> >> UUID rather than their logical address. I think this issue is not
>> >> specific to this version of JGroups as we have seen similar problem
>> >> with 2.10 as well. The problem for us is not the view logging, but
>> >> different view information on different nodes - some get the logical
>> >> name and others just the UUID for the same view id. In past this kind
>> >> of view (showing UUIDs instead of logical address) also indicated
>> >> nodes and GRs out-of-sync on the node list, which in turn was causing
>> >> merge issues.
>> >>
>> >> Questions,
>> >>
>> >> 1) When does this happen - getting both logical address and UUID in
>> >> the same view?
>> >> 2) Why different nodes with same view id get different node
>> >> information (some get UUID, while others get the right logical
>> >> address)?
>> >> 3) How to fix it?
>> >>
>> >> For ex.,
>> >>
>> >> On Coordinator (collector_192.168.50.23):
>> >>
>> >> 2011-06-17 17:25:56,233 INFO
>> >> [Incoming-4,192.168.50.22_group,collector_192.168.50.23:4576]
>> >> RpcServiceManager - viewAccepted()-> New View:
>> >> [collector_192.168.50.23:4576|51] [collector_192.168.50.23:4576,
>> >> probe_192.168.50.32:4576, probe_192.168.50.24:4576,
>> >> manager_192.168.50.22:4576, probe_192.168.50.56:4576]
>> >>
>> >> Node 1 (manager_192.168.50.22):
>> >>
>> >> 2011-06-17 17:25:56,429 INFO
>> >> [Incoming-5,192.168.50.22_group,manager_192.168.50.22:4576]
>> >> RpcServiceManager - viewAccepted()-> New View:
>> >> [collector_192.168.50.23:4576|51] [collector_192.168.50.23:4576,
>> >> 110fcd0e-6f80-7cf0-d76b-0813b913daf1,
>> >> dd068d2f-ef21-1b66-1430-e8bfc862e6f9, manager_192.168.50.22:4576,
>> >> probe_192.168.50.56:4576]
>> >>
>> >> Node 2 (probe_192.168.50.56):
>> >>
>> >> 2011-06-17 12:02:01,695 INFO
>> >> [Incoming-10,192.168.50.22_group,probe_192.168.50.56:4576]
>> >> RpcServiceManager - viewAccepted()-> New View:
>> >> [collector_192.168.50.23:4576|51] [collector_192.168.50.23:4576,
>> >> probe_192.168.50.32:4576, probe_192.168.50.24:4576,
>> >> manager_192.168.50.22:4576, probe_192.168.50.56:4576]
>> >>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (AS7-942) The CXF-DOSGi distributed discovery demo doesn't work.
by David Bosschaert (JIRA)
The CXF-DOSGi distributed discovery demo doesn't work.
------------------------------------------------------
Key: AS7-942
URL: https://issues.jboss.org/browse/AS7-942
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Reporter: David Bosschaert
Priority: Minor
This demo is described here: http://cxf.apache.org/dosgi-discovery-demo-page.html
It seems that the client and the server bundles individually do work. The server bundle does register a remote endpoint and the client bundle does seem to look up the service, but something seems to go wrong with the interaction with the zookeeper server.
I did try to configure it both through standalone.xml and load/org.apache.cxf.dosgi.diovery.zookeeper.cfg file.
standalone.xml content:
{code}
<subsystem xmlns="urn:jboss:domain:osgi:1.0" activation="lazy">
<configuration pid="org.apache.cxf.dosgi.discovery.zookeeper">
<property name="zookeeper.host">
127.0.0.1
</property>
</configuration>
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (AS7-1696) Arquillian test EAR deploys on AS7 with JMX protocol, but test config not found
by Ben Kirby (JIRA)
Arquillian test EAR deploys on AS7 with JMX protocol, but test config not found
-------------------------------------------------------------------------------
Key: AS7-1696
URL: https://issues.jboss.org/browse/AS7-1696
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Affects Versions: 7.0.1.Final
Environment: Windows 7; AS 7.0.1.Final or AS 7.1.0.Alpha1-SNAPSHOT; Arquillian 1.0.0.CR4
Reporter: Ben Kirby
Assignee: Andrew Rubinger
This issue has been discussed at http://community.jboss.org/message/623963, and the suggested workaround using the Servlet protocol works. However creating this JIRA at Aslak Knutsen's request.
The attached project includes a very simple test. When run, the EAR archive is deployed to the remote instance of AS 7.0.1.Final or 7.1.0.Alpha1-SNAPSHOT, but the config for the test itself, although the code is annotated with @RunWith and @Test, cannot be found:
{code}
// from server logging
21:43:35,746 INFO [org.jboss.as.server.deployment] (pool-1-thread-7) Content added at location C:\jboss-as-7.1.0.Alpha1-SNAPSHOT\standalone\data\content\95\d3f543b1775223b963fe549546147322b07a2c\content
21:43:35,747 INFO [org.jboss.as.server.deployment] (MSC service thread 1-14) Starting deployment of "main-test.ear"
21:43:35,822 INFO [org.jboss.as.jpa] (MSC service thread 1-21) added javax.persistence.api dependency to main-test.ear
21:43:35,825 INFO [org.jboss.weld] (MSC service thread 1-18) Processing CDI deployment: main-test.ear
21:43:35,842 INFO [org.jboss.weld] (MSC service thread 1-2) Starting Services for CDI deployment: main-test.ear
21:43:35,843 INFO [org.jboss.weld] (MSC service thread 1-6) Starting weld service
21:43:35,854 INFO [org.jboss.seam.solder.Version] (MSC service thread 1-6) Seam Solder null (build id: null)
21:43:35,871 INFO [org.jboss.seam.solder.core.CoreExtension] (MSC service thread 1-6) Preventing class org.jboss.seam.transaction.UTTransaction from being installed as bean due to @Veto annotation
21:43:35,885 INFO [org.jboss.seam.solder.core.CoreExtension] (MSC service thread 1-6) Preventing class org.jboss.seam.transaction.SeSynchronizations from being installed as bean due to @Veto annotation
21:43:35,890 INFO [org.jboss.seam.solder.core.CoreExtension] (MSC service thread 1-6) Preventing class org.jboss.seam.transaction.CMTTransaction from being installed as bean due to @Veto annotation
21:43:35,891 INFO [org.jboss.seam.solder.core.CoreExtension] (MSC service thread 1-6) Preventing class org.jboss.seam.transaction.EntityTransaction from being installed as bean due to @Veto annotation
21:43:35,900 INFO [org.jboss.seam.solder.core.CoreExtension] (MSC service thread 1-6) Preventing class org.jboss.seam.persistence.hibernate.HibernateManagedSessionExtensionImpl from being installed as bean due to @Veto annotation
21:43:35,900 INFO [org.jboss.seam.solder.core.CoreExtension] (MSC service thread 1-6) Preventing class org.jboss.seam.transaction.NoTransaction from being installed as bean due to @Veto annotation
17845.326: [GC
Desired survivor size 48300032 bytes, new threshold 1 (max 15)
905911K->652820K(3094272K), 0.0104778 secs]
21:43:36,043 INFO [org.jboss.seam.solder.core.CoreExtension] (MSC service thread 1-6) Preventing class org.jboss.seam.solder.core.VersionLoggerUtil from being installed as bean due to @Veto annotation
21:43:36,095 INFO [org.jboss.seam.solder.core.CoreExtension] (MSC service thread 1-6) Preventing class org.jboss.seam.solder.resourceLoader.ResourceProvider from being installed as bean due to @Veto annotation
21:43:36,186 INFO [org.jboss.as.server.controller] (pool-1-thread-7) Deployed "main-test.ear"
21:43:36,275 DEBUG [org.jboss.as.arquillian] (RMI TCP Connection(18)-127.0.0.1) Getting Arquillian config for: temp.tests.TestNewService
21:43:36,275 DEBUG [org.jboss.as.arquillian] (RMI TCP Connection(18)-127.0.0.1) Waiting on Arquillian config for: temp.tests.TestNewService
21:44:06,277 DEBUG [org.jboss.as.arquillian] (RMI TCP Connection(18)-127.0.0.1) Getting Arquillian config for: temp.tests.TestNewService
21:44:06,326 INFO [org.jboss.weld] (MSC service thread 1-22) Stopping weld service
21:44:06,336 INFO [org.jboss.as.server.controller] (pool-1-thread-7) Undeployed "main-test.ear"
21:44:06,339 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) Stopped deployment main-test.ear in 14ms
{code}
{code}
// from mvn test run logging
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running temp.tests.TestNewService
log4j: reset attribute= "false".
log4j: Threshold ="null".
log4j: Class name: [org.apache.log4j.ConsoleAppender]
log4j: Setting property [target] to [System.out].
log4j: Setting property [threshold] to [ALL].
log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
log4j: Setting property [conversionPattern] to [%d{ABSOLUTE} %-5p [%c{1}] %m%n].
log4j: Adding appender named [CONSOLE] to category [root].
31-Aug-2011 22:43:34 org.jboss.arquillian.container.impl.client.container.ContainerRegistryCreator getActivatedConfiguration
INFO: Could not read active container configuration: null
inner-jar.jar:
/temp/
/temp/tests/
/temp/tests/TestNewService.class
/temp/tests/MyLittleService.class
/META-INF/
/META-INF/beans.xml
main-test.ear:
/lib/
/lib/seam-persistence-3.0.0.Final.jar
/lib/seam-solder-3.0.0.Final.jar
/seam-persistence-3.0.0.Final.jar
/inner-jar.jar
/seam-solder-3.0.0.Final.jar
22:43:34,817 DEBUG [JMXProtocolPackager] Generating: arquillian-service
22:43:34,825 DEBUG [JMXProtocolPackager] Merging archive: arquillian-testenricher-cdi.jar: 13 assets
22:43:34,826 DEBUG [JMXProtocolPackager] Merging archive: arquillian-testenricher-initialcontext.jar: 3 assets
22:43:34,826 DEBUG [JMXProtocolPackager] Merging archive: arquillian-testenricher-osgi.jar: 9 assets
22:43:34,827 DEBUG [JMXProtocolPackager] Merging archive: arquillian-junit.jar: 252 assets
22:43:34,833 DEBUG [JMXProtocolPackager] Merging archive: arquillian-core.jar: 375 assets
22:43:34,840 DEBUG [JMXProtocolPackager] Merging archive: arquillian-testenricher-ejb.jar: 8 assets
22:43:34,840 DEBUG [JMXProtocolPackager] Merging archive: arquillian-testenricher-msc.jar: 7 assets
22:43:34,841 DEBUG [JMXProtocolPackager] Merging archive: arquillian-testenricher-resource.jar: 8 assets
22:43:34,844 DEBUG [JMXProtocolPackager] Loadable extensions: [org.jboss.arquillian.testenricher.ejb.container.EJBEnricherRemoteExtension, org.jboss.arquillian.testenricher.cdi.container.CDIEnricherRemoteExten
.testenricher.resource.container.ResourceEnricherRemoteExtension, org.jboss.arquillian.testenricher.initialcontext.container.InitialContextRemoteExtension, org.jboss.as.arquillian.service.JMXProtocolEndpointEx
ian.container.test.impl.ContainerTestRemoteExtension, org.jboss.arquillian.testenricher.msc.MSCEnricherRemoteExtension, org.jboss.arquillian.testenricher.osgi.OSGiEnricherRemoteExtension]
22:43:34,849 DEBUG [JMXProtocolPackager] Add dependencies: org.jboss.modules,deployment.arquillian-service,org.jboss.msc
22:43:34,857 INFO [ArquillianServiceDeployer] Deploy arquillian service: arquillian-service: 699 assets
22:43:35,099 INFO [remoting] JBoss Remoting version 3.2.0.Beta2
22:43:35,106 INFO [xnio] XNIO Version 3.0.0.Beta2
22:43:35,120 INFO [nio] XNIO NIO Implementation Version 3.0.0.Beta2
22:43:35,137 DEBUG [channel-thread] Started channel thread 'XNIO NIO Read 1', selector sun.nio.ch.WindowsSelectorImpl@72e5355f
22:43:35,137 DEBUG [channel-thread] Started channel thread 'XNIO NIO Write 1', selector sun.nio.ch.WindowsSelectorImpl@802b249
22:43:35,541 DEBUG [channel-thread] Started channel thread 'XNIO NIO Read 2', selector sun.nio.ch.WindowsSelectorImpl@558041e0
22:43:35,542 DEBUG [channel-thread] Started channel thread 'XNIO NIO Write 2', selector sun.nio.ch.WindowsSelectorImpl@56278e83
22:43:35,563 ERROR [remote] JBREM00200: Remote connection failed: java.io.IOException: Message data for non-existent channel
22:43:35,565 DEBUG [channel-thread] Started channel thread 'XNIO NIO Read 3', selector sun.nio.ch.WindowsSelectorImpl@44739f3f
22:43:35,566 DEBUG [channel-thread] Started channel thread 'XNIO NIO Write 3', selector sun.nio.ch.WindowsSelectorImpl@1e670479
22:43:35,571 DEBUG [channel-thread] Started channel thread 'XNIO NIO Read 4', selector sun.nio.ch.WindowsSelectorImpl@4e1263db
22:43:35,572 DEBUG [channel-thread] Started channel thread 'XNIO NIO Write 4', selector sun.nio.ch.WindowsSelectorImpl@3a0b53e
22:43:36,187 ERROR [remote] JBREM00200: Remote connection failed: java.io.IOException: Window open for non-existent channel
22:43:36,188 DEBUG [channel-thread] Started channel thread 'XNIO NIO Read 5', selector sun.nio.ch.WindowsSelectorImpl@74bfed5a
22:43:36,189 DEBUG [channel-thread] Started channel thread 'XNIO NIO Write 5', selector sun.nio.ch.WindowsSelectorImpl@27bc4ec8
22:43:36,273 DEBUG [JMXMethodExecutor] Invoke temp.tests.TestNewService.testServiceCreation
22:44:06,293 DEBUG [JMXMethodExecutor] Result: TestResult[status=FAILED,time=0ms]
22:44:06,294 ERROR [JMXMethodExecutor] Failed: temp.tests.TestNewService.testServiceCreation
java.lang.IllegalStateException: Cannot obtain Arquillian config for: temp.tests.TestNewService
at org.jboss.as.arquillian.service.ArquillianService.getArquillianConfig(ArquillianService.java:178)
at org.jboss.as.arquillian.service.ArquillianService.getArquillianConfig(ArquillianService.java:188)
at org.jboss.as.arquillian.service.ArquillianService.access$300(ArquillianService.java:64)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:199)
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 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at org.jboss.as.jmx.tcl.TcclMBeanServer.invoke(TcclMBeanServer.java:214)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1426)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1264)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1359)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
22:44:06,315 DEBUG [channel-thread] Started channel thread 'XNIO NIO Read 6', selector sun.nio.ch.WindowsSelectorImpl@19d03a4e
22:44:06,316 DEBUG [channel-thread] Started channel thread 'XNIO NIO Write 6', selector sun.nio.ch.WindowsSelectorImpl@67cee792
22:44:06,340 ERROR [remote] JBREM00200: Remote connection failed: java.io.IOException: Message data for non-existent channel
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 31.998 sec <<< FAILURE!
Results :
Tests in error:
testServiceCreation(temp.tests.TestNewService): Cannot obtain Arquillian config for: temp.tests.TestNewService
{code}
I debugged ArquillianService on the server, when the EAR deploys, and, sure enough, the deployedTests set is empty. I'm not saying this test should pass - perhaps it's too simple, or the premise flawed - but I believe the test config should be found.
Interestingly, MyLittleService is a near-empty POJO/Managed Bean. If I make it an EJB Singleton, then the test config is found and the test runs...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months