July 2009 - weld-issues - Jboss List Archives

[webbeans-issues] [JBoss JIRA] Created: (WBRI-312) Support reporting wrapping exception to TCK

by Pete Muir (JIRA)

Support reporting wrapping exception to TCK ------------------------------------------- Key: WBRI-312 URL: https://jira.jboss.org/jira/browse/WBRI-312 Project: Web Beans Issue Type: Bug Components: Bootstrap Reporter: Pete Muir Fix For: 1.0.0.CR1 org.jboss.jsr299.tck.tests.deployment.lifecycle.broken.addDefinitionError.AddDefinitionErrorTest.testObserverDefinitionErrorTreatedAsDefinitionError() -- 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

15 years, 2 months

1
4
0 / 0

[webbeans-issues] [JBoss JIRA] Created: (WBRI-283) Clustered WebBeans, no support for sessionscoped (and higher) replication

by John Ament (JIRA)

Clustered WebBeans, no support for sessionscoped (and higher) replication ------------------------------------------------------------------------- Key: WBRI-283 URL: https://jira.jboss.org/jira/browse/WBRI-283 Project: Web Beans Issue Type: Bug Components: Contexts Affects Versions: 1.0.0.PREVIEW1 Environment: JBoss AS 5.1 + JDK 6 Reporter: John Ament Assignee: Nicklas Karlsson >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 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

15 years, 2 months

2
6
0 / 0

[webbeans-issues] [JBoss JIRA] Created: (WBRI-191) Redesign communication between SessionBeanInterceptor and the Web Beans Manager to not rely on thread-local/timing trickery

by Pete Muir (JIRA)

Redesign communication between SessionBeanInterceptor and the Web Beans Manager to not rely on thread-local/timing trickery --------------------------------------------------------------------------------------------------------------------------- Key: WBRI-191 URL: https://jira.jboss.org/jira/browse/WBRI-191 Project: Web Beans Issue Type: Feature Request Components: Enterprise Beans Reporter: Pete Muir Priority: Blocker Fix For: 1.1.0.BETA1 Currently the SessionBeanInterceptor (an EJB interceptor responsible for doing all interception work on session objects) is using a ThreadLocal to obtain info on which Bean it is for. Redesign this to be less brittle. -- 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

15 years, 3 months

1
1
0 / 0

[webbeans-issues] [JBoss JIRA] Created: (WBINT-18) Add faces-config using web.xml, not to classpath

by Pete Muir (JIRA)

Add faces-config using web.xml, not to classpath ------------------------------------------------ Key: WBINT-18 URL: https://jira.jboss.org/jira/browse/WBINT-18 Project: Web Beans Integration Issue Type: Bug Reporter: Pete Muir Assignee: Pete Muir Fix For: 5.2.0.Beta4 On 16 Jul 2009, at 18:36, Stan Silvert wrote: But there is another way to tell JSF where to find a faces-config.xml. You can also add it to the javax.faces.CONFIG_FILES context param in web.xml. So the deployer can grab the web.xml metadata and add the faces-config.xml on the fly. -- 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

15 years, 3 months

1
3
0 / 0

[webbeans-issues] [JBoss JIRA] Created: (WBRI-300) Web Beans should block requests until after container has started

by Pete Muir (JIRA)

Web Beans should block requests until after container has started ----------------------------------------------------------------- Key: WBRI-300 URL: https://jira.jboss.org/jira/browse/WBRI-300 Project: Web Beans Issue Type: Feature Request Reporter: Pete Muir Fix For: 1.0.0.CR1 -- 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

15 years, 3 months

1
6
0 / 0

[webbeans-issues] [JBoss JIRA] Created: (WBRI-324) ELResolver releases dependents immediately, not at end of EL evaluation

by Pete Muir (JIRA)

ELResolver releases dependents immediately, not at end of EL evaluation ----------------------------------------------------------------------- Key: WBRI-324 URL: https://jira.jboss.org/jira/browse/WBRI-324 Project: Web Beans Issue Type: Bug Reporter: Pete Muir Fix For: 1.0.0.CR1 We need to wrap the ExpressionFactory and have a post-evaluation call there to release dependents -- 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

15 years, 3 months

1
6
0 / 0

[webbeans-issues] [JBoss JIRA] Created: (WBRI-329) NPE in org.jboss.webbeans.ejb.SessionBeanInterceptor @PostConstruct

by Ken Saks (JIRA)

NPE in org.jboss.webbeans.ejb.SessionBeanInterceptor @PostConstruct ------------------------------------------------------------------- Key: WBRI-329 URL: https://jira.jboss.org/jira/browse/WBRI-329 Project: Web Beans Issue Type: Bug Components: Enterprise Beans, Glassfish integration Environment: 1.0.0.PREVIEW2.SP2 in 7/30/09 GlassFish V3 workspace Reporter: Ken Saks SessionBeanInterceptor @PostConstruct is throwing an NPE when the ejb container creates an instance of any session bean component type. The trace below is for a Singleton. These are all cases where there is no 299-specific interaction that causes the bean instance creation. It's just the ejb container creating the instance through some other path , e.g. to eagerly instantiate the Singleton during application startup or to resolve a direct JNDI lookup() from some application code. I haven't tried a stateful session bean creation via 299-apis or injection yet. SessionBeanInterceptor.initBean() first calls (EnterpriseBean<Object>) EnterpriseBeanProxyMethodHandler.getEnterpriseBean(), which returns null. It then calls (EnterpriseBean<Object>) CurrentManager.rootManager().getNewEnterpriseBeanMap().get(beanClass), which also returns null. That leads to the NPE on the line "this.beanId = this.bean.getId();" SEVERE: Exception while invoking class org.glassfish.ejb.startup.EjbApplication start method javax.ejb.EJBException: javax.ejb.CreateException: Initialization failed for Singleton SimpleSingleton at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:689) at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:432) at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:93) at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:62) at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:138) at org.glassfish.internal.data.EngineRef.start(EngineRef.java:126) at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:223) at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:193) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:290) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:174) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:270) at com.sun.enterprise.v3.admin.CommandRunnerImpl$4.execute(CommandRunnerImpl.java:422) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:437) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:524) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:140) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:313) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:180) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:208) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:752) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:660) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:911) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:164) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57) at com.sun.grizzly.NIOContext.execute(NIOContext.java:510) at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKey(SelectorHandlerRunner.java:357) at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKeys(SelectorHandlerRunner.java:257) at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:194) at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:129) at com.sun.grizzly.util.FixedThreadPool$BasicWorker.dowork(FixedThreadPool.java:379) at com.sun.grizzly.util.FixedThreadPool$BasicWorker.run(FixedThreadPool.java:360) at java.lang.Thread.run(Thread.java:637) Caused by: javax.ejb.CreateException: Initialization failed for Singleton SimpleSingleton at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:521) at com.sun.ejb.containers.AbstractSingletonContainer.access$100(AbstractSingletonContainer.java:70) at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:687) ... 37 more Caused by: java.lang.NullPointerException at org.jboss.webbeans.ejb.SessionBeanInterceptor.initBean(SessionBeanInterceptor.java:110) at org.jboss.webbeans.ejb.SessionBeanInterceptor.postConstruct(SessionBeanInterceptor.java:62) 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.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:939) at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:61) at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:372) at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:355) at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:514) ... 39 more -- 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

15 years, 4 months

2
13
0 / 0

[webbeans-issues] [JBoss JIRA] Created: (WBRI-59) @Interceptors

by Gavin King (JIRA)

@Interceptors ------------- Key: WBRI-59 URL: https://jira.jboss.org/jira/browse/WBRI-59 Project: Web Beans RI Issue Type: Sub-task Reporter: Gavin King At both class and method level! -- 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

15 years, 4 months

3
15
0 / 0

[webbeans-issues] [JBoss JIRA] Created: (WBRI-56) interceptors/decorators for EJBs which are not web beans

by Gavin King (JIRA)

interceptors/decorators for EJBs which are not web beans -------------------------------------------------------- Key: WBRI-56 URL: https://jira.jboss.org/jira/browse/WBRI-56 Project: Web Beans RI Issue Type: Sub-task Reporter: Gavin King -- 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

15 years, 4 months

2
8
0 / 0

[webbeans-issues] [JBoss JIRA] Created: (WBRI-231) Verify Web Beans on EJB 3.1 container

by Pete Muir (JIRA)

Verify Web Beans on EJB 3.1 container ------------------------------------- Key: WBRI-231 URL: https://jira.jboss.org/jira/browse/WBRI-231 Project: Web Beans Issue Type: Task Components: Enterprise Beans Affects Versions: 1.0.0.CR1 Reporter: Pete Muir org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testEnterpriseBeanWithLocalViewAndNotParameterizedTypeHasClassAndSuperclassesAsBeanTypes() -- 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

15 years, 4 months

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues July 2009