[weld-issues] [JBoss JIRA] Assigned: (WELD-854) Injecting SessionContext and WebServiceContext failing with Weld1.1 Final in JBoss 6
[ https://issues.jboss.org/browse/WELD-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ales Justin reassigned WELD-854: Assignee: Marius Bogoevici Injecting SessionContext and WebServiceContext failing with Weld1.1 Final in JBoss 6 Key: WELD-854 URL: https://issues.jboss.org/browse/WELD-854 Project: Weld Issue Type: Bug Components: Weld SPI Affects Versions: 1.1.0.Final Environment: JBoss AS6 Reporter: Joel Tosi Assignee: Marius Bogoevici A customer development team at is using Weld 1.1 on JBoss 6 and is encountering the following issue. hey are looking to apply an interceptor to their EJB's to do special exception handling based upon on how the EJB was invoked (RMI or SOAP). Other than the interceptor, they want no reference to exception handling code in the EJB. They are an EAP customer and using EAP5.1 with @Interceptors(class), they could create an interceptor where they could inject the SessionContext and WebServiceContext simply using @Resource without additional parameters. Trying to do the same thing in JBoss 6 using interceptor bindings, it appears that this does not function the same way. From the stack trace and the code available on line, it appears it is trying to inject the resource as if the interceptor is completely independent of the EJB. Is that as expected or is it an issue? They are seeing an error on the jndi lookup that is caused from the interceptor implementation not being bound. Ideally they would like to reuse this interceptor on all of their services, regardless of whether the EJB's are invoked via RMI or SOAP, POJO JAX-WS services, or POJO JAX-RS services. The expectation is for the injection to fail gracefully (just return null or some façade / proxy) if the SessionContext or WebServiceContext is not relevant for the given invocation. In the short term, in the context of EJB's shouldn't this function the same as @Interceptors? Sample code from the customer is in steps to reproduce along with the stack trace. This looks like a bug - if its not please help me understand the design choices here. Best, Joel -- 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-855) Error while catching NonexistentConversationException with Seam Faces/Catch
[
https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581991#comment-12581991
]
Pete Muir commented on WELD-855:
Brian, this looks like the age old problem of the contexts not being properly
set up inside servlet forwards, which I thought we were past. It's look like
you are using form auth below? Can you debug and see if the
WeldListener.beginRequest is properly invoked for this request?
Error while catching NonexistentConversationException with Seam Faces/Catch
---
Key: WELD-855
URL: https://issues.jboss.org/browse/WELD-855
Project: Weld
Issue Type: Bug
Environment: Glassfish 3.1 M2 (b41), weld 1.1 patched with Stuart's
WELD-846 patch.
Reporter: Brian Leathem
I have a Faces app, with the exception handler:
void conversationExpired(@Handles
CaughtExceptionNonexistentConversationException t) {...}
When I pull up a URL with an invalid cid, I get the stacktrace below.
(copied from SEAMCATCH-46)
Stacktrace:
---
java.lang.RuntimeException: Exception invoking method [conversationExpired]
on object
[ca.triumf.mis.qms.workrequest.jsf.exception.ExceptionCatchHandler@264d6a2c],
using arguments [org.jboss.seam.exception.control.CaughtException@24758259]
at
org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:547)
at
org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:458)
at
org.jboss.seam.solder.reflection.annotated.InjectableMethod.invoke(InjectableMethod.java:189)
at
org.jboss.seam.exception.control.HandlerMethodImpl.notify(HandlerMethodImpl.java:189)
at
org.jboss.seam.exception.control.ExceptionHandlerDispatch.executeHandlers(ExceptionHandlerDispatch.java:129)
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.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at
org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at
org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at
org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at
org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:270)
at
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:222)
at
org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:613)
at
org.jboss.seam.faces.exception.CatchExceptionHandler.handle(CatchExceptionHandler.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
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.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at
org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at
org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:465)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:253)
at
com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1192)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at
[weld-issues] [JBoss JIRA] Assigned: (WELD-617) Can not find beans when deploying compressed Archive to Tomcat
[
https://issues.jboss.org/browse/WELD-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ales Justin reassigned WELD-617:
Assignee: Ales Justin
Can not find beans when deploying compressed Archive to Tomcat
--
Key: WELD-617
URL: https://issues.jboss.org/browse/WELD-617
Project: Weld
Issue Type: Bug
Components: Servlet Container Support
Affects Versions: 1.0.1.Final
Reporter: Aslak Knutsen
Assignee: Ales Justin
Priority: Minor
Fix For: 1.2.0.Beta1
When deploying a compressed Archive on Tomcat,
WebAppBeanDeploymentArchive.scan fails to find and classes.
In WebAppBeanDeploymentArchive.scan we try to get the File object
representation of the WEB-INF/classes directory so we can recursively scan
for classes, but in Tomcat this is a URL to jndi backed by a DirContext.
WebAppBeanDeploymentArchive.scan
{ // inside scan
File webInfClasses = Servlets.getRealFile(servletContext, WEB_INF_CLASSES);
{ // inside getRealFile
String realPath = servletContext.getRealPath(path);
realPath == null
URL resourcePath = servletContext.getResource(path);
resourcePath == jndi:/localhost/test/WEB-INF/classes
}
webInfClasses == null
}
End result is no classes are found.
--
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-855) Error while catching NonexistentConversationException with Seam Faces/Catch
[
https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582128#comment-12582128
]
Brian Leathem commented on WELD-855:
I can confirm that WeldListener.requestInitialized is invoked when I request a
URL with an non-existent cid. I don't see a beginRequest method in Weld
Listener.
Note: I am using the latest Weld 1.1 SNAPSHOT.
Error while catching NonexistentConversationException with Seam Faces/Catch
---
Key: WELD-855
URL: https://issues.jboss.org/browse/WELD-855
Project: Weld
Issue Type: Bug
Environment: Glassfish 3.1 M2 (b41), weld 1.1 patched with Stuart's
WELD-846 patch.
Reporter: Brian Leathem
I have a Faces app, with the exception handler:
void conversationExpired(@Handles
CaughtExceptionNonexistentConversationException t) {...}
When I pull up a URL with an invalid cid, I get the stacktrace below.
(copied from SEAMCATCH-46)
Stacktrace:
---
java.lang.RuntimeException: Exception invoking method [conversationExpired]
on object
[ca.triumf.mis.qms.workrequest.jsf.exception.ExceptionCatchHandler@264d6a2c],
using arguments [org.jboss.seam.exception.control.CaughtException@24758259]
at
org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:547)
at
org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:458)
at
org.jboss.seam.solder.reflection.annotated.InjectableMethod.invoke(InjectableMethod.java:189)
at
org.jboss.seam.exception.control.HandlerMethodImpl.notify(HandlerMethodImpl.java:189)
at
org.jboss.seam.exception.control.ExceptionHandlerDispatch.executeHandlers(ExceptionHandlerDispatch.java:129)
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.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at
org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at
org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at
org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at
org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:270)
at
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:222)
at
org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:613)
at
org.jboss.seam.faces.exception.CatchExceptionHandler.handle(CatchExceptionHandler.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
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.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at
org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at
org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:465)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:253)
at
com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1192)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at
[weld-issues] [JBoss JIRA] Commented: (WELD-510) Support for Portlet 2.0
[ https://issues.jboss.org/browse/WELD-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582203#comment-12582203 ] Kito Mann commented on WELD-510: Is there any activity on this issue? How did the GateIn folks solve this with the JBoss Portlet Bridge? Support for Portlet 2.0 --- Key: WELD-510 URL: https://issues.jboss.org/browse/WELD-510 Project: Weld Issue Type: Feature Request Affects Versions: 1.0.1.Final Reporter: Neil Griffin Priority: Blocker Fix For: 1.2.0.Beta1 There are some folks trying to use the PortletFaces Bridge for JSF 2.0 + Portlet 2.0 in Glassfish V3, but Weld is causing an issue. Original Post: http://www.portletfaces.org/community/forums/-/message_boards/message/43041#_19_message_43038 Here is a simple stacktrace of the problem: Caused by: java.lang.IllegalStateException: Weld doesn not support using JSF in an non-servlet environment at org.jboss.weld.jsf.JsfHelper.getModuleBeanManager(JsfHelper.java:119) at org.jboss.weld.jsf.WeldPhaseListener.initiateSessionAndConversation(WeldPhaseListener The code for the bridge API is here: http://svn.portletfaces.org/svn/portletfaces/bridge/org.portletfaces.bridge.api/ The code for the bridge IMPL is here: http://svn.portletfaces.org/svn/portletfaces/bridge/org.portletfaces.bridge.impl/ And the code for a sample portlet is here: http://svn.portletfaces.org/svn/portletfaces/portlets/sample/jsf-2.0-job-application-portlet/ -- 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-510) Support for Portlet 2.0
[ https://issues.jboss.org/browse/WELD-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582238#comment-12582238 ] Nicklas Karlsson commented on WELD-510: --- The fix should be pretty straightforward but what could be used for writing the tests for the portal env? I don't think JSFUnit supports it? There is some portletUnit (http://sourceforge.net/projects/portletunit/) but I've never tried it... Support for Portlet 2.0 --- Key: WELD-510 URL: https://issues.jboss.org/browse/WELD-510 Project: Weld Issue Type: Feature Request Affects Versions: 1.0.1.Final Reporter: Neil Griffin Priority: Blocker Fix For: 1.2.0.Beta1 There are some folks trying to use the PortletFaces Bridge for JSF 2.0 + Portlet 2.0 in Glassfish V3, but Weld is causing an issue. Original Post: http://www.portletfaces.org/community/forums/-/message_boards/message/43041#_19_message_43038 Here is a simple stacktrace of the problem: Caused by: java.lang.IllegalStateException: Weld doesn not support using JSF in an non-servlet environment at org.jboss.weld.jsf.JsfHelper.getModuleBeanManager(JsfHelper.java:119) at org.jboss.weld.jsf.WeldPhaseListener.initiateSessionAndConversation(WeldPhaseListener The code for the bridge API is here: http://svn.portletfaces.org/svn/portletfaces/bridge/org.portletfaces.bridge.api/ The code for the bridge IMPL is here: http://svn.portletfaces.org/svn/portletfaces/bridge/org.portletfaces.bridge.impl/ And the code for a sample portlet is here: http://svn.portletfaces.org/svn/portletfaces/portlets/sample/jsf-2.0-job-application-portlet/ -- 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
