[weld-issues] [JBoss JIRA] Created: (WELD-942) Analyze FindBugs report
Analyze FindBugs report --- Key: WELD-942 URL: https://issues.jboss.org/browse/WELD-942 Project: Weld Issue Type: Task Affects Versions: 1.1.1.Final Reporter: Jozef Hartinger Since WELD-851 has been resolved, the FindBugs analysis is working again. It currently reports ~100 reports. Please review these warnings and either implement code changes or use FindBugs annotations to suppress these warnings. The latest report is available at http://ci.jboss.org/jenkins/job/Weld-trunk-findbugs/lastSuccessfulBuild/findbugsResult/ -- 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] Updated: (WELD-942) Analyze FindBugs report
[ https://issues.jboss.org/browse/WELD-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger updated WELD-942: - Description: Since WELD-851 has been resolved, the FindBugs analysis is working again. It currently reports ~100 warnings. Please review these warnings and either implement code changes or use FindBugs annotations to suppress these warnings. The latest report is available at http://ci.jboss.org/jenkins/job/Weld-trunk-findbugs/lastSuccessfulBuild/findbugsResult/ was: Since WELD-851 has been resolved, the FindBugs analysis is working again. It currently reports ~100 reports. Please review these warnings and either implement code changes or use FindBugs annotations to suppress these warnings. The latest report is available at http://ci.jboss.org/jenkins/job/Weld-trunk-findbugs/lastSuccessfulBuild/findbugsResult/ Analyze FindBugs report --- Key: WELD-942 URL: https://issues.jboss.org/browse/WELD-942 Project: Weld Issue Type: Task Affects Versions: 1.1.1.Final Reporter: Jozef Hartinger Since WELD-851 has been resolved, the FindBugs analysis is working again. It currently reports ~100 warnings. Please review these warnings and either implement code changes or use FindBugs annotations to suppress these warnings. The latest report is available at http://ci.jboss.org/jenkins/job/Weld-trunk-findbugs/lastSuccessfulBuild/findbugsResult/ -- 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] Resolved: (WELD-934) Weld servlet should not crash when booting in GWT dev hosted mode
[ https://issues.jboss.org/browse/WELD-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved WELD-934. - Fix Version/s: 1.1.2.Final Resolution: Done Weld servlet should not crash when booting in GWT dev hosted mode - Key: WELD-934 URL: https://issues.jboss.org/browse/WELD-934 Project: Weld Issue Type: Bug Components: Servlet Container Support Affects Versions: 1.1.1.Final Reporter: Geoffrey De Smet Priority: Critical Fix For: 1.1.2.Final I 've got a working pull request ready. When running in GWT dev hosted mode, there are some tomcat classes on the classpath, which confuse weld into using the wrong container. In fact, GWT dev hosted modes is in fact a separate container (a customized variant of the Jetty 6 container). -- 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-927) ViewScoped does not work because org.jboss.weld.bean.Managedbean is not serializable
[ https://issues.jboss.org/browse/WELD-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614140#comment-12614140 ] Pete Muir commented on WELD-927: I think this a bug in Seam Faces, it can't assume it can serialize a Bean object. ViewScoped does not work because org.jboss.weld.bean.Managedbean is not serializable Key: WELD-927 URL: https://issues.jboss.org/browse/WELD-927 Project: Weld Issue Type: Bug Components: CDI API, Class Beans (Managed and Session), Scopes Contexts, Web Tier integration (JSF, JSP, EL and Servlet) Affects Versions: 1.1.1.Final Environment: Tomcat/Jetty, Weld Servlet 1.1.2-SNAPSHOT or 1.1.1-Final, MyFaces 2.x or 2.1.x, Seam Faces 3.0.1-Final, Seam Persistence 3.0.0 Reporter: Thomas Andraschko Priority: Blocker If you use @ViewScoped, a will exception occur that org.jboss.weld.bean.Managedbean is not serializable. This a blocker because we can't use @ViewScoped with Weld (and this envorionment) and Seam does not work with OWB. This should be the same issue as: https://issues.apache.org/jira/browse/EXTCDI-118 -- 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: (WELD-936) Unsatisfied resolution for @Observes(during=TransactionPhase.AFTER_COMPLETION)
[ https://issues.jboss.org/browse/WELD-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas reassigned WELD-936: --- Assignee: Stuart Douglas Unsatisfied resolution for @Observes(during=TransactionPhase.AFTER_COMPLETION) --- Key: WELD-936 URL: https://issues.jboss.org/browse/WELD-936 Project: Weld Issue Type: Bug Reporter: Sivakumar Thyagarajan Assignee: Stuart Douglas While investigating GLASSFISH-16513 (http://java.net/jira/browse/GLASSFISH-16513 ), I see that we run into the following root cause: [#|2011-06-26T22:15:38.271+0530|SEVERE|glassfish3.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=12;_ThreadName=Thread-2;|org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [interface org.jboss.weld.context.ejb.EjbRequestContext]; Bindings: [@javax.enterprise.inject.Any(), @javax.enterprise.inject.Default(), @org.jboss.weld.context.unbound.Unbound()] at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:809) at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:108) at org.jboss.weld.event.DeferredEventNotification$RunInRequest.run(DeferredEventNotification.java:103) at org.jboss.weld.event.DeferredEventNotification.run(DeferredEventNotification.java:64) at org.jboss.weld.event.TransactionSynchronizedRunnable.afterCompletion(TransactionSynchronizedRunnable.java:62) at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:537) at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:852) at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5138) at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4903) at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044) at com.sun.ejb.containers.EjbAsyncTask.call(EjbAsyncTask.java:114) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) |#] I am able to confirm the following BDA hierarchy being sent during deployment, that GF adds EJBServices to the DeploymentImpl, and that the AsyncSessionBean is being identified as a EJB in the root BeanManager. An unsatisfied resolution exception still occurs for org.jboss.weld.context.ejb.EjbRequestContext. [#|2011-06-26T22:40:09.337+0530|FINE|glassfish3.2|org.glassfish.weld.DeploymentImpl|_ThreadID=12;_ThreadName=Thread-2;ClassName=org.glassfish.weld.DeploymentImpl;MethodName=getBeanDeploymentArchives;|DeploymentImpl::getBDAs. Returning [|ID: AsyncWebApp, bdaType= WAR, accessibleBDAs #:11, [WEB-INF/lib/jersey-server-1.3,,,], Bean Classes #: 4,[test.async.MyAsyncSessionBean, test.async.GenericResource, test.async.MyActor, test.async.MyEvent], ejbs=[test.async.MyActor, test.async.MyAsyncSessionBean, test.async.GenericResource] |ID: WEB-INF/lib/jersey-server-1.3, bdaType= UNKNOWN, accessibleBDAs #:1, [AsyncWebApp,], Bean Classes #: 0,, ejbs=[] |ID: com.sun.jersey.server.impl.cdi.CDIExtension, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[com.sun.jersey.server.impl.cdi.CDIExtension], ejbs=[] |ID: org.glassfish.osgicdi.impl.OSGiServiceExtension, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[org.glassfish.osgicdi.impl.OSGiServiceExtension], ejbs=[] |ID: javax.ws.rs.core.Application, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.Application], ejbs=[] |ID: javax.ws.rs.core.HttpHeaders, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.HttpHeaders], ejbs=[] |ID: javax.ws.rs.ext.Providers, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.ext.Providers], ejbs=[] |ID: javax.ws.rs.core.Request, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.Request], ejbs=[] |ID: javax.ws.rs.core.SecurityContext, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.SecurityContext], ejbs=[] |ID: javax.ws.rs.core.UriInfo, bdaType= UNKNOWN, accessibleBDAs #:0, [], Bean Classes #: 1,[javax.ws.rs.core.UriInfo], ejbs=[] |ID: com.sun.jersey.core.util.FeaturesAndProperties,
[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=12614201#comment-12614201 ] Marko Strukelj commented on WELD-510: - I think we can move forward. While the idea was to set up testing infrastructure first, the real challenge was reproducing the issue in the first place, so it got stuck on hold a bit. But I managed to reproduce it. The exception in the description is only the first issue - it looks like Weld-1.1.2.AS7 does not suffer from it any more. The real issue is that Weld at the moment can't handle cross-context includes, and the reason is that cross-context includes don't trigger request initialization events - meaning RequestContexts don't get activated. One solution for that would be to install an optional filter that gets triggered on INCLUDE only, and also check that current request context is not yet activated (to avoid double init on in-context includes). Ideally the solution would not require additional web.xml configuration ... 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 Assignee: Marko Strukelj Priority: Blocker Fix For: 1.1.2.Final 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=12614238#comment-12614238 ] Kito Mann commented on WELD-510: I'm very glad to see some movement on this issue. I think the filter solution would be reasonable if it solves the problem. I would expect Weld to use Servlet 3 web.xml fragments so at least Servlet 3 containers wouldn't require extra configuration. 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 Assignee: Marko Strukelj Priority: Blocker Fix For: 1.1.2.Final 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-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614242#comment-12614242
]
Joshua Davis commented on WELD-920:
---
Now that I understand this a little better, I like the idea of analyzing the
dependent instance graph and not tracking (managing) any instances that don't
have @PreDestroy/@Disposer methods. It _should_ be a fully transparent
optimization.
+1 on putting a *big warning* in the docs about Instance, as this has tripped
up a bunch of people so far.
Memory leak through the creational context of an @AppScoped bean when
injecting Instance
--
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the
dependent-scoped bean is injected, each time the get() method is called on
the instance, even though it's not used, a reference to it stays in the
creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where
each one calls the method, more and more memory is leaked
(http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy
to AS6, click the leak button several times, and analyze the heap dump e.g.
in JProfiler.
@ApplicationScoped
@Named(test)
public class AppScopedBean {
private InstanceInstanceBean instanceBeanInstance;
@Inject
public AppScopedBean(InstanceInstanceBean instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println(Leaked!);
instanceBeanInstance.get();
}
}
--
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] Created: (CDITCK-225) TCK needs a sig file recorded with Java SE 7
TCK needs a sig file recorded with Java SE 7 Key: CDITCK-225 URL: https://issues.jboss.org/browse/CDITCK-225 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Signature Tests Affects Versions: 1.0.4.Final Environment: All Reporter: Kyle Grucci The TCK needs to be updated to also include a signature file which was recorded using Java SE 7 - http://www.java.net/download/openjdk/jdk7/promoted/b147/openjdk-7-fcs-src-b147-27_jun_2011.zip http://download.java.net/openjdk/jdk7/ -- 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
