[weld-issues] [JBoss JIRA] Commented: (WELD-888) Interceptors not resolvable from a WAR-module which is part of an EAR-deployment
[ https://issues.jboss.org/browse/WELD-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597035#comment-12597035 ] Pete Muir commented on WELD-888: How do you try to resolve it? Is there an exception thrown? Interceptors not resolvable from a WAR-module which is part of an EAR-deployment Key: WELD-888 URL: https://issues.jboss.org/browse/WELD-888 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.1.Final Environment: - Weld 1.1.1. Final on JBoss 6.0 GA and JBoss 6.1 nightly - tested and confirmed on Vista 32 and Linux 64 Reporter: Jan Groth Attachments: probear-jar.zip, probear.zip It seems like CDI interceptors cannot be accessed from inside a WAR-module of an EAR deployment if the interceptor is defined inside a dependent JAR which is located in the EAR/lib directory. BUT: - Managed beans and producers from the same JAR work without problems. - Moving the dependency from EAR/lib to WAR/WEB-INF/lib makes the interceptor work without problems. I consider that a serious problem, because this is a substantial restriction for enterprise applications. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-890) CDI Bean doesn't work like a webservice/soap client
[
https://issues.jboss.org/browse/WELD-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597037#comment-12597037
]
Pete Muir commented on WELD-890:
Please open an issue in the GlassFish issue tracker, this is an issue in
GF/Weld integration most likely nothing to do with Weld core.
CDI Bean doesn't work like a webservice/soap client
---
Key: WELD-890
URL: https://issues.jboss.org/browse/WELD-890
Project: Weld
Issue Type: Bug
Components: Class Beans (Managed and Session)
Affects Versions: 1.1.0.Final
Environment: NetBeans 7.0 RC2 + GlassFish 3.1 + Weld 1.1.0 + JSF2
Mojarra 2.1.0
Reporter: Edilmar Alves
Priority: Critical
Original Estimate: 4 weeks
Remaining Estimate: 4 weeks
I have a @Named/@ConversationScoped managed bean with a method to call a
webservice/SOAP1.1.
If I change the managed bean to @ManagedBean, the method works fine. And with
NetBeans 6.9.1 + GlassFish 3.0.1 + Weld 1.0.0 it works fine. But in this new
environment, Weld arises this error:
INFO: WSP5018: Loaded WSIT configuration from file:
file:/sistemas/sitesat2/build/web/WEB-INF/classes/META-INF/wsit-client.xml.
INFO: Missing required extension methods detected on
'javax.transaction.TransactionManager' implementation
'com.sun.enterprise.transaction.TransactionManagerHelper':
getTxLogLocation
INFO: WSATGatewayRM.initStore path:null/../wsat/inbound/
INFO: WSATGatewayRM.initStore path:null/../wsat/outbound/
INFO: the effective transaction attribute for operation' getCidadeCodIBGE' is
: enabled(false),required(false), version(WSAT10).
INFO: WS-AT recovery is enabled but WS-AT is not ready for runtime.
Processing WS-AT recovery log files...
INFO: recover() flag=25165824
INFO: recover() for this server flag=25165824
txlogdirOutbound:null/../wsat/outbound/,txlogdirInbound:null/../wsat/inbound/
INFO: recoverPendingBranches outbound directory:null/../wsat/outbound/
INFO: recoverPendingBranches inbound directory:null/../wsat/inbound/
INFO: WSAT recover(25165824) returning []
INFO: WS-AT activityId:[B@1bfbc471
INFO: WSAT4575: WS-AT transaction id is '4D2-313330333234363739323134372D30'
and time to live is '0' for transaction 'suspendedTransaction' on thread
Thread[http-thread-pool-8080(2),5,grizzly-kernel]
INFO: WSAT4575: WS-AT transaction id is '4D2-313330333234363739323134372D30'
and time to live is '0' for transaction 'suspendedTransaction' on thread
Thread[http-thread-pool-8080(2),5,grizzly-kernel]
INFO: WSAT4568: Client-side outbound application message after adding
transaction context for 'suspendedTransaction'
INFO: WSAT4577: About to suspend transaction 'JavaEETransactionImpl: txId=29
nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]' on thread
'Thread[http-thread-pool-8080(2),5,grizzly-kernel]'
INFO: WSAT4578: Suspended transaction 'JavaEETransactionImpl: txId=29
nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]' on thread
'Thread[http-thread-pool-8080(2),5,grizzly-kernel]'
INFO: WSAT4569: Client-side inbound message received
INFO: WSAT4570: Suspended transaction 'JavaEETransactionImpl: txId=29
nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]' will be resumed on
thread 'Thread[http-thread-pool-8080(2),5,grizzly-kernel]'
INFO: WSAT4571: Suspended transaction 'JavaEETransactionImpl: txId=29
nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]' resumed on thread
'Thread[http-thread-pool-8080(2),5,grizzly-kernel]'
AVISO: #{cidade.getCidadeCodIBGE}: javax.xml.ws.soap.SOAPFaultException:
java.lang.NullPointerException
javax.faces.FacesException: #{cidade.getCidadeCodIBGE}:
javax.xml.ws.soap.SOAPFaultException: java.lang.NullPointerException
at
com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at
com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at
org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at
util.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:42)
at
[weld-issues] [JBoss JIRA] Commented: (WELD-778) Weld must be able to support extension discovery in the modules of an multi-module application (EAR)
[ https://issues.jboss.org/browse/WELD-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597038#comment-12597038 ] Pete Muir commented on WELD-778: We can't solve this with the current SPI AFAICS. We need to completely revisit how extensions are processed. I admit that when I wrote this originally, the stuff I did with classloading/structure seemed a little bit odd, and I think I just didn't see that extensions need to be per bda and call events for any bean on extensions defined in that bda for any classes that are resolvable. The primary issue I wanted to avoid with the previous design was that events would be called multiple times for the same bean/class on the same extension, however if we only ever call events on extensions within the bda then I think this won't be a problem. I would propose we redesign the SPI so that loadExtensions is per BDA not per app. Weld must be able to support extension discovery in the modules of an multi-module application (EAR) Key: WELD-778 URL: https://issues.jboss.org/browse/WELD-778 Project: Weld Issue Type: Feature Request Components: Bootstrap and Metamodel API Affects Versions: 1.1.0.Beta2 Reporter: Marius Bogoevici Fix For: TBC Currently, only extensions which are visible to the entire application (i.e. all modules) are installed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Assigned: (CDITCK-210) org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull (Stateful session bean) 's @Remove method not part of EJB's business interface
[ https://issues.jboss.org/browse/CDITCK-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir reassigned CDITCK-210: Assignee: Jozef Hartinger org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull (Stateful session bean) 's @Remove method not part of EJB's business interface -- Key: CDITCK-210 URL: https://issues.jboss.org/browse/CDITCK-210 Project: CDI TCK Issue Type: Bug Security Level: Public(Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Environment: Generic Java Platform Reporter: Bob Nettleton Assignee: Jozef Hartinger A Stateful session bean defined in the following test suite: org.jboss.jsr299.tck.tests.implementation.enterprise.definition includes a @Remove method that is not part of the Session Bean's Business interface. The bean in question is: org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull According to the javadoc for the Remove annotation: http://download.oracle.com/javaee/6/api/javax/ejb/Remove.html This annotation must be placed on a method that is also a part of the Session Bean's business interface. This issue can cause problems with the portability of this test application and test suite, since different application servers may fail at deployment time with this type of EJB-related error. I request that either the Session Bean be modified to add this method to the business interface, or that the tests listed below be removed from the TCK: org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testStatelessMustBeDependentScoped [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanViaXmlTest.testEjbDeclaredInXmlNotSimpleBean [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testSingletonWithDependentScopeOK [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testEnterpriseBeanClassLocalView [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testObjectIsInAPITypes [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithStereotype [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testDefaultName [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithNamedAnnotation [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithQualifiers [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithScopeAnnotation [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testSingletonWithApplicationScopeOK [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanTypesAreLocalInterfacesWithoutWildcardTypesOrTypeVariablesWithSuperInterfaces [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testConstructorAnnotatedInjectCalled [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testRemoteInterfacesAreNotInAPITypes Another test suite: org.jboss.jsr299.tck.tests.context.dependent.ejb also has this problem in the following Stateful session EJB: org.jboss.jsr299.tck.tests.context.dependent.ejb.Fox In addition to the list above, the following tests also appear to be affected by this issue: org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest.testDestroyingEjbDestroysDependentSimples [testng] org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest.testDestroyingEjbDestroysDependents -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (CDITCK-210) org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull (Stateful session bean) 's @Remove method not part of EJB's business interfac
[ https://issues.jboss.org/browse/CDITCK-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597125#comment-12597125 ] Jozef Hartinger commented on CDITCK-210: Exclude list updated http://anonsvn.jboss.org/repos/weld/cdi-tck/branches/1.0/impl/src/main/resources/tck-tests-released.xml org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull (Stateful session bean) 's @Remove method not part of EJB's business interface -- Key: CDITCK-210 URL: https://issues.jboss.org/browse/CDITCK-210 Project: CDI TCK Issue Type: Bug Security Level: Public(Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Environment: Generic Java Platform Reporter: Bob Nettleton Assignee: Jozef Hartinger A Stateful session bean defined in the following test suite: org.jboss.jsr299.tck.tests.implementation.enterprise.definition includes a @Remove method that is not part of the Session Bean's Business interface. The bean in question is: org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull According to the javadoc for the Remove annotation: http://download.oracle.com/javaee/6/api/javax/ejb/Remove.html This annotation must be placed on a method that is also a part of the Session Bean's business interface. This issue can cause problems with the portability of this test application and test suite, since different application servers may fail at deployment time with this type of EJB-related error. I request that either the Session Bean be modified to add this method to the business interface, or that the tests listed below be removed from the TCK: org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testStatelessMustBeDependentScoped [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanViaXmlTest.testEjbDeclaredInXmlNotSimpleBean [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testSingletonWithDependentScopeOK [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testEnterpriseBeanClassLocalView [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testObjectIsInAPITypes [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithStereotype [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testDefaultName [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithNamedAnnotation [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithQualifiers [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithScopeAnnotation [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testSingletonWithApplicationScopeOK [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanTypesAreLocalInterfacesWithoutWildcardTypesOrTypeVariablesWithSuperInterfaces [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testConstructorAnnotatedInjectCalled [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testRemoteInterfacesAreNotInAPITypes Another test suite: org.jboss.jsr299.tck.tests.context.dependent.ejb also has this problem in the following Stateful session EJB: org.jboss.jsr299.tck.tests.context.dependent.ejb.Fox In addition to the list above, the following tests also appear to be affected by this issue: org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest.testDestroyingEjbDestroysDependentSimples [testng] org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest.testDestroyingEjbDestroysDependents -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-778) Weld must be able to support extension discovery in the modules of an multi-module application (EAR)
[ https://issues.jboss.org/browse/WELD-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597127#comment-12597127 ] Mark Struberg commented on WELD-778: ... so that loadExtensions is per BDA not per app. Pete, the main problem is that there is NO explicit definition what an 'Application' is! One interpret it as Web APP another one interpret it as EAR=APP ... I personally don't care about whether we use, but we finally need to get down on one or the other. LieGrue, strub Weld must be able to support extension discovery in the modules of an multi-module application (EAR) Key: WELD-778 URL: https://issues.jboss.org/browse/WELD-778 Project: Weld Issue Type: Feature Request Components: Bootstrap and Metamodel API Affects Versions: 1.1.0.Beta2 Reporter: Marius Bogoevici Fix For: TBC Currently, only extensions which are visible to the entire application (i.e. all modules) are installed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
