[GLASSFISH-20247] WELD-001527 Managed bean declaring a passivating scope has a non-serializable interceptor for DefaultInterceptorMetadata Created: 09/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Blocker
Reporter: arungupta Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For a bean defined as:

@Named
@SessionScoped
public class MovieClientBean implements Serializable {
...
}

b83 is throwing the following error:

SEVERE: Exception while loading the app : CDI deployment failure:WELD-001527 Managed bean declaring a passivating scope has a non-serializable interceptor. Bean: Managed Bean [class org.glassfish.movieplex7.client.MovieClientBean] with qualifiers [@Default @Any @Named] Interceptor: org.jboss.weld.interceptor.reader.DefaultInterceptorMetadata@573da625
org.jboss.weld.exceptions.DeploymentException: WELD-001527 Managed bean declaring a passivating scope has a non-serializable interceptor. Bean: Managed Bean [class org.glassfish.movieplex7.client.MovieClientBean] with qualifiers [@Default @Any @Named] Interceptor: org.jboss.weld.interceptor.reader.DefaultInterceptorMetadata@573da625

Deployment fails. This is blocking to run Java EE 7 hands-on lab using b83.

The complete application is described at http://glassfish.org/hol.



 Comments   
Comment by TangYong [ 10/Apr/13 ]

arungupta, jjsnyder83

My analyze is as following:

1 about passivating scope
Here, needing to notice that in [1], the following from 6.6.3. Passivating scopes,

"For example, the built-in session and conversation scopes defined in Section 6.7, “Context management for built-in scopes” are passivating scopes. No other built-in scopes are passivating scopes."

For @SessionScoped, it belongs to "Context management for built-in scopes", so once defining any interceptor or injecting any bean, these interceptors and dependency beans all should be serializable. Although this is from cdi 1.0, in 1.1, this can not be changed.

[1]:http://docs.jboss.org/cdi/spec/1.0/html_single/#passivatingscope

2 about @Transactional
This is an interceptor defining @InterceptorBinding.

Combining with 1 and 2, the exception happened.

In reality, previously a similar issue has been discussed in JBOSS community[2],

[2]: https://community.jboss.org/thread/179828

[About Fixing]
Because @Transactional is a part of javax.transaction api, fixing should be limited in the Movie sample, and I am still considering...

Thanks
--Tang

Comment by TangYong [ 10/Apr/13 ]

JavaEE 7 Spec group seemed missing such a scene (combining Transactional Interceptors with CDI beans with Context management for built-in scopes.

Comment by jjsnyder83 [ 10/Apr/13 ]

Made the transactional interceptors implement Serializable.
Committed revision 61342.





[GLASSFISH-20236] Exception on deployment - WELD-001408 Unsatisfied dependencies for type [IterableProvider<ComponentInvocationHandler>] Created: 09/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: adriaaaaan Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu 12.04, java version "1.7.0_13", trunk revision 61246



 Description   

When trying to deploy our compilcated application on gf4 I'm getting a weld exception in an internal glassfish class. This application deploys on gf 3.1.2 with no changes other than I have updated to the latest hibernate for compatability reasons.

SEVERE: Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [IterableProvider<ComponentInvocationHandler>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject private org.glassfish.api.invocation.InvocationManagerImpl(@Optional IterableProvider<ComponentInvocationHandler>)]
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:222)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [IterableProvider<ComponentInvocationHandler>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject private org.glassfish.api.invocation.InvocationManagerImpl(@Optional IterableProvider<ComponentInvocationHandler>)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:396)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:318)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:512)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:498)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:473)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:213)
... 36 more

SEVERE: Exception while loading the app
SEVERE: Undeployment failed for context /DiscoveryEngine2
INFO: No timers to be deleted for id: 89490257568923648
INFO: No timers to be deleted for id: 89490257568923648
INFO: No timers to be deleted for id: 89490257568923648
INFO: No timers to be deleted for id: 89490257568923648
INFO: No timers to be deleted for id: 89490257568923648
INFO: No timers to be deleted for id: 89490257568923648
SEVERE: Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [IterableProvider<ComponentInvocationHandler>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject private org.glassfish.api.invocation.InvocationManagerImpl(@Optional IterableProvider<ComponentInvocationHandler>)]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [IterableProvider<ComponentInvocationHandler>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject private org.glassfish.api.invocation.InvocationManagerImpl(@Optional IterableProvider<ComponentInvocationHandler>)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:396)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:318)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:512)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:498)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:473)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:213)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

I might need some help giving you more information as I can't obviously upload our application on here.



 Comments   
Comment by adriaaaaan [ 10/Apr/13 ]

Considering this injection point is annotated with @Optional, shouldn't it just ignore it?

Comment by Jeremy_Lv [ 10/Apr/13 ]

As the issue is occurred by weld side, change the component to the cdi to have a look.

Comment by adriaaaaan [ 10/Apr/13 ]

Updated to latest trunk build and this issue has been resolved so It seems the weld guys have fixed it. Thanks to whoever was involved you can close.





[GLASSFISH-20231] Tracking bug for cdi tck failure for org.jboss.cdi.tck.interceptors.tests.aroundConstruct.interceptorsAnnotation.AroundConstructTest Created: 08/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Bad test: https://issues.jboss.org/browse/WELD-1399



 Comments   
Comment by jjsnyder83 [ 10/Apr/13 ]

Fixed with Weld 2.0.0.CR2





[GLASSFISH-20226] Uptake Weld 2.0.0.CR1 Created: 08/Apr/13  Updated: 08/Apr/13  Resolved: 08/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by jjsnyder83 [ 08/Apr/13 ]

Committed revision 61226.





[GLASSFISH-20222] cdi tck test failing org.jboss.cdi.tck.tests.lookup.manager.jndi.ManagerTestEar Created: 08/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Failing on Weld 2.0.0.CR1



 Comments   
Comment by jjsnyder83 [ 10/Apr/13 ]

Fixed by JBoss





[GLASSFISH-20218] cdi tck test failing org.jboss.cdi.tck.tests.context.request.ws.RequestContextTest Created: 08/Apr/13  Updated: 08/Apr/13  Resolved: 08/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Failing on Weld 2.0.0.CR1



 Comments   
Comment by jjsnyder83 [ 08/Apr/13 ]

Committed revision 61235.





[GLASSFISH-20172] Usage of any EL3.0 operator leads to Method stream not found ELException Created: 27/Mar/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Critical
Reporter: marfous Assignee: jjsnyder83
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF 4.0 promoted build 81



 Description   

Sorry I can find category not for the EL implementation, please reassign it if this is not correct one.

Any simple facelet with the usage of the EL3 operators leads to following exception on GF4.0:
javax.el.ELException: /index.xhtml: Method stream not found
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:88)
at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)
at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1852)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1852)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:443)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:201)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:175)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

The expression was simple, used from the EL repository tests, see the facelet I used:
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html">
<h:head>
<title>Facelet Title</title>
</h:head>
<h:body>
#

{[1,2,3,4].stream().filter(i->i > 1).toList()}

</h:body>
</html>



 Comments   
Comment by Manfred Riem [ 27/Mar/13 ]

Cannot reproduce this with a GF4.0 build from 3/26

Comment by marfous [ 28/Mar/13 ]

Please could you give it try with my application:
https://dl.dropbox.com/u/1418580/jsf/WebApplication338.zip
https://dl.dropbox.com/u/1418580/jsf/WebApplication338.war

It doesn't work to me with GF4.0 build from 3/27. I tried also deployment from the NetBeans IDE as well from the GF Admin Console.
We would need to detect any issues in the project since this is standard/base NetBeans Web project.

Thanks a lot...

Comment by Manfred Riem [ 04/Apr/13 ]

This appears to be a Weld EL integration issue. Remove the beans.xml file and you'll see it works.

Comment by kchung [ 04/Apr/13 ]

Looks like weld's EL reolsvers do not support EL 3.0 yet. The following is what it takes to support EL 3.0, for JSP (taken from http://jcp.org/aboutJava/communityprocess/maintenance/jsr245/245-MR3.html). Weld need to do something similar.

3. Support EL 3.0 (JSR 341).

In JSP.2.9, add the following two ELResovers, after item 2, and renumber
the other ELResolvers on the list. That is, place these ELResolvers between
the custom ELResolvers and the MapELResolver.

3. The ELResolver returned by ExpressionFactory.getStreamELResolver().
4. javax.el.StaticFieldELResolver.

Comment by jjsnyder83 [ 04/Apr/13 ]

https://issues.jboss.org/browse/WELD-1394

Comment by Jozef Hartinger [ 04/Apr/13 ]

Fixed in Weld. The fix will be available in Weld 2.0.0.Beta9.

Comment by jjsnyder83 [ 10/Apr/13 ]

Fixed by Weld in 2.0.0.CR1





[GLASSFISH-20171] Tracking bug for cdi tck failure for Alternative tests Created: 04/Apr/13  Updated: 07/Apr/13  Resolved: 07/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

These tests are failing with Beta 8:
testAlternativeProducerSelected(org.jboss.cdi.tck.tests.alternative.selection.SelectedAlternative01Test): expected object to not be null
testAlternativeStereotypeSelected(org.jboss.cdi.tck.tests.alternative.selection.SelectedAlternative01Test): expected object to not be null
testDependencyResolvable(org.jboss.cdi.tck.tests.alternative.selection.SelectedAlternative02Test): expected:<false> but was:<true>
testAlternativeResourceSelected(org.jboss.cdi.tck.tests.alternative.selection.resource.ResourceAlternative04Test): expected:<false> but was:<true>

I sent email to JBoss.



 Comments   
Comment by jjsnyder83 [ 07/Apr/13 ]

Fixed in Weld 2.0.0.CR1





[GLASSFISH-20169] Fix producer field validation for @WebServiceRef Created: 04/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by jjsnyder83 [ 04/Apr/13 ]

Committed revision 61161.





[GLASSFISH-20148] Uptake Weld 2.0 Beta 8 Created: 03/Apr/13  Updated: 04/Apr/13  Resolved: 03/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[GLASSFISH-20116] Tracking bug for cdi tck failure for org.jboss.cdi.tck.tests.deployment.packaging.ear.MultiWebModuleWithExtensionTest Created: 31/Mar/13  Updated: 07/Apr/13  Resolved: 07/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by jjsnyder83 [ 01/Apr/13 ]

Sent info to JBoss. GF appears to have the information setup correctly. If I remove foo.war from the ear then it deploys successfully.

Comment by jjsnyder83 [ 07/Apr/13 ]

Fixed in Weld 2.0.0.CR1





[GLASSFISH-20045] Tracking bug for cdi tck failure org.jboss.cdi.tck.tests.extensions.lifecycle.processInjectionPoint.ProcessInjectionPointFiredTest Created: 26/Mar/13  Updated: 07/Apr/13  Resolved: 07/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

3/25 sent email to Martin Kouba with a question on who is supposed to process a @ManagedBean



 Comments   
Comment by jjsnyder83 [ 26/Mar/13 ]

This test is failing also most likely for the same reason:
org.jboss.cdi.tck.tests.extensions.lifecycle.processInjectionTarget.ContainerEventTest

testProcessInjectionTargetEventFiredForJsfManagedBean

Comment by jjsnyder83 [ 07/Apr/13 ]

The test has been removed from the tck suite.





[GLASSFISH-20042] org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest Created: 25/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

On suggestion from Lukas Jungmann I changed the test class SheepWSProduce's WebServiceRef to
@WebServiceRef(value = SheepWSEndPointService.class) public SheepWS sheepWS;

The test now deploys but I get one failure. I have email to Lukas asking for the correct location in JNDI for where the WebServiceRef should be.

Failed tests: testResourceInvocation(org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest): Exception attempting to inject Env-Prop: org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSProducer/sheepWS@Field-Injectable Resource. Class name = org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSProducer Field name=sheepWS@javax.jws.WebServiceRef@@@ into class org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSProducer: Lookup failed for 'java:comp/env/org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSProducer/sheepWS' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

 Comments   
Comment by jjsnyder83 [ 25/Mar/13 ]

After verifying JNDI location give back the test change to JBoss so they can update the test.

Comment by jjsnyder83 [ 08/Apr/13 ]

Fixed in Weld 2.0.0.CR1

Comment by jjsnyder83 [ 08/Apr/13 ]

Verify this still works on Weld 2.0.0.CR1





[GLASSFISH-19944] Add root bdas for wars and ear/libs. Created: 19/Mar/13  Updated: 07/Apr/13  Resolved: 07/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by jjsnyder83 [ 19/Mar/13 ]

We must add a root bda for a war that does not contain any cdi-enabled classes (i.e. no beans.xml or for WEB-INF/classes). We must also add a root bda for The ear libraries. A root bda contains no bean classes so rootBda.getBeanClasses will return an empty collection and rootBda.getBeanDeploymentArchives will return:

  • for war rootBda a collection of the bdas created for WEB-INF/lib and the bda for WEB-INF/classes (if there is one). Each of these bda's getBeanDeploymentArchives will include the root as well as the other bdas they already contain.
  • for ear/lib rootBda a collection of the bdas for each ear/lib that was created. Each of these bda's getBeanDeploymentArchives will include the root too.

These root bdas are used when a class that is not in a bda needs to get the bean manager from java:comp/env or from CDI.current().

No special marker is needed for weld. The integrator code creates the "root BDAs". CDI.current() or the lookup from JNDI is responsible for returning the "root BDA" appropriately.

Comment by jjsnyder83 [ 21/Mar/13 ]

These root bdas will allow for a bean manager to be obtained from classes within archives that are not cdi-enabled.

Comment by jjsnyder83 [ 07/Apr/13 ]

Committed revision 61218.





[GLASSFISH-19317] Injection of @PersistenceContext and @Resource in EAR's lib CDI beans does not work Created: 10/Nov/12  Updated: 08/Apr/13  Resolved: 08/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: titmus Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64bit, JDK 1.6.0_29 32bit


Attachments: Zip Archive jee-resources.zip    

 Description   

When a CDI bean is defined in a bean archive located in lib directory of an EAR archive GF does not properly inject values into fields annotated with @PersistenceContext or @Resource annotation.
The field is initalized with weld proxy but when a method is invoked on such field the NullInstanceException is raised: org.jboss.weld.exceptions.NullInstanceException: WELD-000044 Unable to obtain instance from null.

I found this discussion which seems to describe exactly the same problem:
http://www.java.net/forum/topic/glassfish/glassfish/persistencecontext-ignored-library-jar-classes?force=606

I attached a test case which demonstrates this bahaviour.



 Comments   
Comment by jjsnyder83 [ 08/Apr/13 ]

Committed revision 61234.





[GLASSFISH-18409] cdi interterceptors stop working in ear if there is a lib/jar with a beans.xml Created: 25/Feb/12  Updated: 07/Apr/13  Resolved: 07/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1, 3.1.1, 3.1.2_b01, 3.1.2_b02, 3.1.2_b03, 3.1.2_b04, 3.1.2_b05, 3.1.2_b06, 3.1.2_b07, 3.1.2_b09, 3.1.2_b10, 3.1.2_b11, 3.1.2_b12, 3.1.2_b13, 3.1.2_b14, 3.1.2_b15, 3.1.2_b16, 3.1.2_b17, 3.1.2_b18, 3.1.2_b19, 3.1.2_b20, 3.1.2_b21, 3.1.2_b22, 3.1.2_b23
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Critical
Reporter: gcruscoe Assignee: jjsnyder83
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all



 Description   

We have an ear project with war and ejb modules. It has a lib directory with all the dependency pojo jars. All in all a very standard setup I think.

We use CDI Interceptors in our ejb project and everything is fine.

We have the beans.xml working in our war as well as the ejb project, but as soon as we put a beans.xml in one of our pojo projects (that gets deployed as a jar to the ear's lib directory) the interceptors in the ejb stop working. This should be very easy to reproduce. The beans.xml file in the lib jar does not list any intercptors listed (not even an empty node).

This is part of the spec right? I should be able to use CDI in the jars in the lib directory, right?

I tried this on 3.1, 3.1.1, and the latest version of 3.1.2 I have and all have the same behavior.

I sure hope this can get fixed in time for 3.1.2 – it seems to be a critical issue.



 Comments   
Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by tlcksnyder [ 28/Mar/13 ]

Please provide a test case, or this will get deferred to a future release.

Comment by TangYong [ 07/Apr/13 ]

Although the issue can be re-produced on glassfish 3.1.2.2, on current v4, the issue does not happen.

-Tang

Comment by jjsnyder83 [ 07/Apr/13 ]

This has been fixed by recent updates of Weld and/or GlassFish.





Generated at Tue Sep 27 17:07:52 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.