February 2012 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-665) Servlet injection not working on EAP 5.1

by Pete Muir (JIRA)

Servlet injection not working on EAP 5.1 ---------------------------------------- Key: WELD-665 URL: https://jira.jboss.org/browse/WELD-665 Project: Weld Issue Type: Bug Components: Servlet Container Support Reporter: Pete Muir Fix For: 1.1.0.Beta2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

4
9
0 / 0

[JBoss JIRA] Created: (WELD-666) Write tests for WeldServletBeanManagerProvider

by Pete Muir (JIRA)

Write tests for WeldServletBeanManagerProvider ---------------------------------------------- Key: WELD-666 URL: https://jira.jboss.org/browse/WELD-666 Project: Weld Issue Type: Bug Components: Servlet Container Support Reporter: Pete Muir Fix For: 1.1.0.Beta2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

4
6
0 / 0

[JBoss JIRA] (WELD-1068) Weld conversation crash when used in portlet

by John Doyle (JIRA)

John Doyle created WELD-1068: -------------------------------- Summary: Weld conversation crash when used in portlet Key: WELD-1068 URL: https://issues.jboss.org/browse/WELD-1068 Project: Weld Issue Type: Bug Components: Conversations Affects Versions: 1.1.5.Final Environment: Windows XP, Tomcat 7.0.23, Liferay 6.1.0 Community Edition GA1, Mojarra 2.1.6, portletfaces-bridge 2.0.0 Reporter: John Doyle When attempting to view a JSF2/Weld based portlet in a portal the following exception is thrown: 14:11:54,917 ERROR [render_portlet_jsp:154] java.lang.IllegalStateException: Must call associate() before calling activate() at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:200) at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:108) at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:85) at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:391) at org.portletfaces.bridge.GenericFacesPortlet.doView(GenericFacesPortlet.java:181) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328) at javax.portlet.GenericPortlet.render(GenericPortlet.java:233) at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:100) at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64) at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:93) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:72) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:70) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) This happens on viewing a page which starts a conversation. I'll try and attach a little example app to aid reproducing the problem. -- 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

12 years, 10 months

3
9
0 / 0

[JBoss JIRA] Created: (WELD-883) Weird behavior of custom context in some configurations

by Fab Mars (JIRA)

Weird behavior of custom context in some configurations ------------------------------------------------------- Key: WELD-883 URL: https://issues.jboss.org/browse/WELD-883 Project: Weld Issue Type: Bug Components: Scopes & Contexts Affects Versions: 1.1.1.Final Environment: W7 x86, Glassfish 3.1 GA, Weld 1.1.1, JDK 1.6.0_24 Reporter: Fab Mars In my applciation, some configs are in external xml files. They may be updated by hand and configs reloaded on the fly. While migrating to CDI, the methods loading the confg became producers and the beans holding the config became @ApplicationScoped. I couldn't reload configs anymore, so I created a custom scope to control the lifecycle of my configs. And I faced a couple of issues. My EAR is a good old one: some api jar (TrucEJBClient), the business logic module (TrucEBJ), the tools and config stuff jar (TrucConfig) and the web module (TrucWeb). 1) At first I obviously put the new scope and context in the TrucConfig jar. Open weld_context_destroy_bean_issue (ext config, decl config).zip and deploy the ear. Test via http://localhost:8080/TrucWeb/test.jsf , the text displayed comes from 2 bean instances generated with producer methods rom xml files Click on the button [alter configs], one of the 2 beans is modified on the fly. Then click on the button [reload configs] which triggers an event to destroy the aforementioned bean (whichtherefore will be reloaded on the next get()) Problem: As you can see the bean isn't destroyed. If you have a look at com.dummy.config.ConfigContext line 106, you can see beanManager.getBeans(instance.getClass(), xmlConfigQualifier) returns an empty set. However you can also see contextualInstancesMap.size() == 2, so I'm not able to retrieve my beans correctly there. 2) Now let's move the context and its extension configuration javax.enterprise.inject.spi.Extension into the TrucEJB module. Open weld_error_001324 (ext ejb, decl ejb).zip and deploy the jar The jar won't deploy, error WELD001324 3) Now let's move back the extension configuration back into the TrucConfig jar. Open weld_working (ext ejb, decl config).zip and deploy the ear. Test via http://localhost:8080/TrucWeb/test.jsf , the text displayed comes from 2 bean instances generated with producer methods rom xml files Click on the button [alter configs], one of the 2 beans is modified on the fly. Then click on the button [reload configs] which triggers an event to destroy the aforementioned bean (whichtherefore will be reloaded on the next get()) >> Despite the fact the Context is in an EJB module whilst its Extension configuration is in another jar of the same EAR, it works !! I'm not storng enough yet with the Weld code, so it's hard for me to find the root cause(s). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
13
0 / 0

[JBoss JIRA] Created: (WELD-693) Add a way to get the active context easily

by Pete Muir (JIRA)

Add a way to get the active context easily ------------------------------------------ Key: WELD-693 URL: https://jira.jboss.org/browse/WELD-693 Project: Weld Issue Type: Feature Request Components: Scopes & Contexts Reporter: Pete Muir Fix For: 1.1.0.Beta2 For example @Inject @Active ConversationContext ctx; which would inject null if there was no active context -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (WELD-815) Add some design time readable metadata to weld-*.jars for tooling

by Max Andersen (JIRA)

Add some design time readable metadata to weld-*.jars for tooling ----------------------------------------------------------------- Key: WELD-815 URL: https://issues.jboss.org/browse/WELD-815 Project: Weld Issue Type: Feature Request Components: Tooling Reporter: Max Andersen Working on JBIDE-8017 it became obvious that it would be good if Weld (and other spec implementations) jars could say which services they implement (and optionally how) so tooling could validate and navigate based on the classpath. Opening this issue to not forget - suggested approach was to see if one could use the seam-beans.xml format (but under a different name, i.e. design-time-beans.xml) to help guide tooling. This is to include not only spec required services but also additonal ones as for example http://docs.jboss.org/weld/reference/1.1.0.CR1/en-US/html/contexts.html#d... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

7
9
0 / 0

[JBoss JIRA] Created: (WELD-398) Unable to run translator example with settings for cluster

by Martin Gencur (JIRA)

Unable to run translator example with settings for cluster ---------------------------------------------------------- Key: WELD-398 URL: https://jira.jboss.org/jira/browse/WELD-398 Project: Weld Issue Type: Bug Reporter: Martin Gencur When I try to go to http://localhost:8080/weld-translator after deploying the translator example to JBossAS 6.0.0.M1, exceptions are thrown both at server.log and web browser. The exception are attached as separated files. Steps to reproduce: 1) add <distributable/> tag to web.xml as it's first tag (at WELD/examples/jsf/translator/war/src/main/webapp/WEB-INF/web.xml) 2) add this content to jboss.xml file at WELD/examples/jsf/translator/ejb/src/main/resources/META-INF/jboss.xml : <?xml version="1.0" encoding="UTF-8"?> <jboss xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee jboss_5_0.xsd" version="5.0"> <enterprise-beans> <session>  <ejb-name>SentenceTranslator</ejb-name> <clustered>true</clustered> </session> <session>  <ejb-name>TranslatorControllerBean</ejb-name> <clustered>true</clustered> </session> </enterprise-beans> </jboss> 3) download jboss-6.0.0.M1 (for example from http://reports.qa.atl.jboss.com/release_tests/binaries/JBossAS/jboss-6.0....) 4) unzip it twice to different folders 5) now you have to update both the JBoss AS instances with current version of WELD core (from WELD/core) 6) run the first instance from its bin directory: ./run.sh -c all -g DocsPartition -u 239.255.101.101 -b localhost -Djboss.messaging.ServerPeerID=1 -Djboss.service.binding.set=ports-default 7) run the second instance from its bin directory: ./run.sh -c all -g DocsPartition -u 239.255.101.101 -b localhost -Djboss.messaging.ServerPeerID=2 -Djboss.service.binding.set=ports-01 8) clean and build the application: run mvn clean package in examples/jsf/translator 9) copy resulting ear file (weld-numberguess.war) from translator/ear/target/ directory to serve/all/farm directory at first jbossAS instance 10) go to http://localhost:8080/weld-translator 11) now you can see both exception in server.log and web browser -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

5
21
0 / 0

[JBoss JIRA] (WELD-59) Clustered WebBeans, no support for sessionscoped (and higher) replication

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/WELD-59?page=com.atlassian.jira.plugin.sy... ] Ales Justin resolved WELD-59. ----------------------------- Resolution: Out of Date > Clustered WebBeans, no support for sessionscoped (and higher) replication > ------------------------------------------------------------------------- > > Key: WELD-59 > URL: https://issues.jboss.org/browse/WELD-59 > Project: Weld > Issue Type: Bug > Components: Scopes & Contexts > Affects Versions: 1.0.0.PREVIEW1 > Environment: JBoss AS 5.1 + JDK 6 > Reporter: John Ament > Fix For: TBC > > Attachments: ClusteredWebBeansTestApp.zip, ClusteredWebBeansTestApp.zip > > > From what I can tell, this is what happens. > Assume you have a 2 node environment w/ apache httpd + mod_jk in front of the jboss servers, used to limit servers exposed + a loadbalancer (F5 ASM) in front of those. The apache servers are only configured to talk to one jboss server each (httpd + jboss are on same box, they only talk to the local client). the f5 serving the initial request is configured for pure round robin (no cookie persistence) and as a result request 1 could go to server 1 and then request 2 goes to server 2. > Now assume that the two jboss servers are clustered together, the EJBs are clustered and have a cache policy (based on the JBoss annotations). They only have local interfaces. In addition, there are some classes that are only POJOs; but they sit in the ejb module. Based on what's happening these objects should be replicated as part of the HTTP session state. > A few problems seem to occur when the request goes to the second server after the first request goes to the first server. > 1. References to the resources required by the EJBs are not injected in the second server. This includes members decorated @Resource or @PersistenceContext > 2. References to EJBs required at the view level are not restored. > In addition, concurrent modification exceptions seem to be more likely when deployed like this, resulting in having to downgrade EJBs to POJOs in order to remain stateful. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (WELD-734) Support @EJB injection in pre-Java EE 6 environments

by Dan Allen (JIRA)

Support @EJB injection in pre-Java EE 6 environments ---------------------------------------------------- Key: WELD-734 URL: https://jira.jboss.org/browse/WELD-734 Project: Weld Issue Type: Feature Request Components: Servlet Container Support Affects Versions: 1.1.0.Beta1 Reporter: Dan Allen Priority: Minor Add support for the injection of EJBs into CDI beans (via the @EJB annotation) in Weld Servlet for use in pre-Java EE 6 environments. This feature would enable more developers to immeidately switch to CDI despite having to use an older platform. The best strategy to take to implement this feature would be to leverage Weld's EjbServices SPI interface (http://docs.jboss.org/weld/reference/latest/en-US/html/ri-spi.html) on a per container basis (in the same way Weld is integrated into the Java EE 6 containers). Currently, the Weld Listener doesn't provide any hooks to register services before it starts the container. We could redesign the Listener to support providing the EjbServices implementation (and perhaps other service implementations) in a listener subclass. It's unlikely we can fully implement EJB integration in pre EE6 environments as (at least in JBoss AS and GlassFish) as some of the hooks (specifically the hooks to remove EJBs on demand) are missing. However, basic injection would cover ~80% of the cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (WELD-902) CLONE - The qualified observer section is incorrect

by Christian Bauer (JIRA)

CLONE - The qualified observer section is incorrect --------------------------------------------------- Key: WELD-902 URL: https://issues.jboss.org/browse/WELD-902 Project: Weld Issue Type: Bug Components: Documentation Affects Versions: 1.0.0.GA Reporter: Christian Bauer Assignee: Jason Porter Fix For: 1.1.0.CR1 The documentation at http://docs.jboss.org/weld/reference/1.0.0/en-US/html/events.html#d0e3980 is incorrect for the way qualified observers work. The related spec section is 10.2. The docs say all possible observers with any of the qualifiers will be called, which is incorrect. The full signature including all qualifiers must match for the observer to be invoked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues February 2012