<< Back to previous view

[GLASSFISH-20551] BLANK PAGE SHOWS UP AFTER SAVE A NEW JMS PHYSICAL DESTINATIONS OR CANCEL IT. Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b85

Type: Bug Priority: Minor
Reporter: li.wu Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

[ENV]
Windows2008 zh_TW 64bit
Firefox 11

[SHIPHOME]
http://javaweb.us.oracle.com/java/re/javaeesdk/7.0/promoted/b81/archive/bundles/java_ee_sdk-7-b81-jdk7-windows-x64-ml.exe


Tags:
Participants: Anissa Lam and li.wu

 Description   

1. Install java_ee bundle and login admin console;
2. Click server(Admin Server) link and click JMS Physical Destinations tab;
3. Click New button to create a new Destination;
4. Enter name "test" and click Save button, then blank page shows up;
5. repeat step2, and you can see the new Destination is created;
6. Click "test" or the default "mq.sys.dmq" to show its details;
7. Click Cancel button, then blank page shows again.

This bug is migrated from bugdb 16566060.



 Comments   
Comment by li.wu [ 17/May/13 03:33 AM ]

Fixed in b85.





[GLASSFISH-20550] VERSION FOR JAVA EE SDK AND GLASSFISH ARE WRONG DURING INSTALLATION Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b85

Type: Bug Priority: Minor
Reporter: li.wu Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

[ENV]
Windows2008 zh_CN 64bit

[SHIPHOME]
http://javaweb.us.oracle.com/java/re/javaeesdk/7.0/promoted/b80/archive/bundles/latest-sdk-jdk7-windows-x64-ml.exe


Tags:
Participants: li.wu and Tom Mueller

 Description   

1.Download shiphome and click it to install;
2."Java EE 6 SDK" shows up for several times during installation;
3."Glassfish Server v3.1" shows up for several times during installation. Pls
check the pictures attached.

This bug is migrated from bugdb 16517819.



 Comments   
Comment by li.wu [ 17/May/13 03:30 AM ]

Fixed in b85.





[GLASSFISH-20549] "JDK SELECTION" STEP SHOWS UP WITHOUT CONTENT IN INSTALLATION Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b85

Type: Bug Priority: Minor
Reporter: li.wu Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

[ENV]
OEL5 64bit

[SHIPHOME]
http://javaweb.us.oracle.com/java/re/javaeesdk/7.0/promoted/b80/archive/bundles/java_ee_sdk-7-b80-unix-ml.sh


Tags:
Participants: li.wu and Tom Mueller

 Description   

1.Download shiphome and click it to install;
2."JDK Selection" step shows up during Introduction and Installation Type;
3.Go to Install Directory page and "JDK Selection" disappears.

This bug is migrated from bugdb 16527137.



 Comments   
Comment by li.wu [ 17/May/13 03:29 AM ]

Fixed in b85.





[GLASSFISH-20324] EJB devtest ejb30/clientview/core failing with Weld 2.0.0.CR2 Created: 16/Apr/13  Updated: 17/Apr/13  Resolved: 17/Apr/13

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

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

Tags: 4_0-approved
Participants: jjsnyder83 and Tom Mueller

 Comments   
Comment by jjsnyder83 [ 16/Apr/13 08:40 PM ]

Dev test failure

Comment by jjsnyder83 [ 16/Apr/13 10:28 PM ]

What is the impact on the customer of the bug?

  • It's not released to the customer yet.

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?
It is a regression in the ejb dev tests

  • What is the cost/risk of fixing the bug?
  • low

How risky is the fix? How much work is the fix? Is the fix complicated?

  • low
  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    EJB Dev tests
  • Which is the targeted build of 4.0 for this fix?
  • The next build.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
Comment by Tom Mueller [ 16/Apr/13 10:32 PM ]

Approved for 4.0





[GLASSFISH-20318] SFSB passivation fails with CDI enabled Created: 16/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Blocker
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-20325 SFSB passivation fails with NotSerial... Resolved
Tags: 4_0-approved
Participants: marina vatkina and Tom Mueller

 Description   

with CDI enabled, SFSB passivation fails for beans that do not implement Serializable interface because our generated subclass is not being used when instance is created.



 Comments   
Comment by marina vatkina [ 16/Apr/13 02:03 AM ]
  • What is the impact on the customer of the bug?
    Regression: SFSB instance will be destroyed at passivation for beans that are not explicitly serializable
  • How likely is it that a customer will see the bug and how serious is the bug?
    It will break existing applications with SFSBs that are not explicitly serializable
  • What CTS failures are caused by this bug?
    CTS doesn't test passivation because its setup is appserver specific
  • What is the cost/risk of fixing the bug?
    Either class modification or implementing delegates in the ejb-container code.
  • Is there an impact on documentation or message strings?
    no
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    QA regression tests
  • Which is the targeted build of 4.0 for this fix?
    the next
  • Is this an integration of a new version of a component from another project?
    no
Comment by Tom Mueller [ 16/Apr/13 01:58 PM ]

Approved for 4.0

Comment by marina vatkina [ 23/Apr/13 12:15 AM ]

Do manual field serialization/deserialization when an EJB instance is created by CDI, and is not subclassed by our _Serializable code-gen.
Note that EJB devtets that fail because of the Weld bug need CR3 build of Weld or later to be restored.

Sending ejb-container/src/main/java/com/sun/ejb/EJBUtils.java
Sending ejb-container/src/main/java/com/sun/ejb/containers/StatefulSessionContainer.java
Sending ejb-container/src/main/java/com/sun/ejb/containers/util/cache/LruSessionCache.java
Sending ejb-container/src/main/java/com/sun/ejb/spi/container/SFSBContainerCallback.java
Transmitting file data ....
Committed revision 61586.





[GLASSFISH-20316] Findbugs: IS2_INCONSISTENT_SYNC: Inconsistent synchronization Created: 15/Apr/13  Updated: 15/Apr/13  Resolved: 15/Apr/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: None
Fix Version/s: 4.0_b85

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

Tags: 4_0-approved findbugs
Participants: mtaube and Tom Mueller

 Description   

This is a fix of a Low Priority findbugs issue:

Errors:
================================================================================
mtaube: appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java:105: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.weld.ValidationNamingProxy.beanManagerNamingProxy; locked 66% of time
mtaube: appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java:150: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.weld.ValidationNamingProxy.beanManagerNamingProxy; locked 66% of time
mtaube: appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java:181: IS2_INCONSISTENT_SYNC: Inconsistent synchronization of org.glassfish.weld.ValidationNamingPro

  • What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?

  • What is the cost/risk of fixing the bug?

very low risk, adds synchronization to a critical section

  • Is there an impact on documentation or message strings?

no

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

jsr-349 cts

  • Which is the targeted build of 4.0 for this fix?
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.


 Comments   
Comment by Tom Mueller [ 15/Apr/13 09:04 PM ]

Approved for 4.0.





[GLASSFISH-20313] NPE in buildLogFileIndex after rotated log file Created: 15/Apr/13  Updated: 18/Apr/13  Resolved: 18/Apr/13

Status: Resolved
Project: glassfish
Component/s: logging
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: sandeep.shrivastava
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved console
Participants: Anissa Lam, rajendra_inamdar, sandeep.shrivastava and Tom Mueller

 Description   

This can be reproduced consistently. Steps to reproduce:

1. go to Server (Admin Server) and click "Rotate Log File" button. Log file is rotated, works fine.
2. click the "View Log File" button, the logViewer will show up, but because of the NPE, there is the message "An error has occured", and there is no log shown.
3. click the search button again, and it now works fine.

Here is the stack trace;

[#|2013-04-15T11:51:17.577-0700|INFO|glassfish 4.0|javax.enterprise.admin.rest|_ThreadID=34;_ThreadName=admin-listener(2);_TimeMillis=1366051877577;_LevelValue=800;_MessageID=NCLS-REST-00003;|
An error occurred while processing the request. Please see the server logs for details.
java.lang.RuntimeException: java.lang.NullPointerException
at com.sun.enterprise.server.logging.logviewer.backend.LogFile.buildLogFileIndex(LogFile.java:209)
at com.sun.enterprise.server.logging.logviewer.backend.LogFile.getLastIndexNumber(LogFile.java:284)
at com.sun.enterprise.server.logging.logviewer.backend.LogFilter.getLogRecordsUsingQuery(LogFilter.java:202)
at com.sun.enterprise.server.logging.logviewer.backend.LogFilter.getLogRecordsUsingQuery(LogFilter.java:349)
at org.glassfish.admin.rest.resources.custom.StructuredLogViewerResource.getWithType(StructuredLogViewerResource.java:176)
at org.glassfish.admin.rest.resources.custom.StructuredLogViewerResource.getJson(StructuredLogViewerResource.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:195)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:318)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
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: java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1234)
at java.util.regex.Matcher.reset(Matcher.java:308)
at java.util.regex.Matcher.<init>(Matcher.java:228)
at java.util.regex.Pattern.matcher(Pattern.java:1088)
at com.sun.enterprise.server.logging.parser.LogParserFactory.detectLogFormat(LogParserFactory.java:115)
at com.sun.enterprise.server.logging.parser.LogParserFactory.createLogParser(LogParserFactory.java:90)
at com.sun.enterprise.server.logging.logviewer.backend.LogFile.buildLogFileIndex(LogFile.java:185)
... 46 more

#]


 Comments   
Comment by rajendra_inamdar [ 15/Apr/13 08:46 PM ]

Looks like it is trying to index the empty file after it is rotated.

Comment by sandeep.shrivastava [ 17/Apr/13 04:17 PM ]
  • What is the impact on the customer of the bug?

Customer will run into this issue if he/she opens the log viewer for a log file immediately after it has been rotated and the current log file is still empty.

How likely is it that a customer will see the bug and how serious is the bug?

There is a medium probability that the customer will run into this issue, if they are actively viewing the log files and the rotation happens.

Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?

The exception did not happen in GF 3.1.2.2, it is happening in new code added to support both ODL and Uniform log format. There was no exception in the prior release, the log viewer did not show any records for the empty log file.

What CTS failures are caused by this bug?

There are no CTS failures due to this issue.

  • What is the cost/risk of fixing the bug?

How risky is the fix? How much work is the fix? Is the fix complicated?

The fix is straight forward to handle the empty log file. Low risk.

  • Is there an impact on documentation or message strings?

No

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

This only affects the UI. Anissa has verified the fix offline.

  • Which is the targeted build of 4.0 for this fix?

4.0_b85

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

N/A

Comment by Tom Mueller [ 17/Apr/13 04:40 PM ]

Approved for 4.0.

Comment by sandeep.shrivastava [ 18/Apr/13 12:01 PM ]

This is fixed with revision 61489.





[GLASSFISH-20307] Mismatch between CDI system interceptors and interceptor chain for EntityBeans Created: 13/Apr/13  Updated: 17/Apr/13  Resolved: 17/Apr/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: marina vatkina

 Description   

System interceptors are registered for EntityBeans, but the interceptor chain is not created for them, which ends up in an NPE when an entity bean is injected



 Comments   
Comment by marina vatkina [ 17/Apr/13 06:45 PM ]

Fixed in weld-integration by GLASSFISH-20324





[GLASSFISH-20306] Server monitoring module throws "java.lang.NullPointerException" in the log. Created: 13/Apr/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

Status: Resolved
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Mohamed Taman Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 SP1 x64 bit
Mac OS X 10.8.3
Glassfish v4_b84


Tags: fishcat monitoring 4_0-approved
Participants: Mohamed Taman and Tom Mueller

 Description   

Reproduce Scenario:

  1. From admin console --> common tasks --> choose server (Admin Server) node.
  2. From right pan --> choose Monitor.
  3. Choose any other child buttons as (Application, Server, or resources).
  4. Check server.log and you will see the following errors:

    [2013-04-13T03:00:11.945+0200] [glassfish 4.0] [INFO] [NCLS-REST-00003] [javax.enterprise.admin.rest] 
    [tid: _ThreadID=34 _ThreadName=admin-listener(1)] [timeMillis: 1365814811945] [levelValue: 800] 
    [[
      An error occurred while processing the request. Please see the server logs for details.
    java.lang.NullPointerException
    	at org.glassfish.admin.rest.resources.MonitoringResource.getChildNodes(MonitoringResource.java:131)
    	at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.lang.reflect.Method.invoke(Method.java:601)
    	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
    	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
    	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
    	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
    	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
    	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
    	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
    	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
    	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
    	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
    	at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
    	at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
    	at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
    	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
    	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
    	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
    	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
    	at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:318)
    	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
    	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)
    ]]
    
    [2013-04-13T03:00:11.967+0200] [glassfish 4.0] [INFO] [NCLS-REST-00003] [javax.enterprise.admin.rest] 
    [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1365814811967] [levelValue: 800] 
    [[
      An error occurred while processing the request. Please see the server logs for details.
    java.lang.NullPointerException
    	at org.glassfish.admin.rest.resources.MonitoringResource.getChildNodes(MonitoringResource.java:131)
    	at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.lang.reflect.Method.invoke(Method.java:601)
    	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
    	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
    	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
    	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
    	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
    	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
    	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
    	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
    	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
    	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
    	at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
    	at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
    	at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
    	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
    	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
    	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
    	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
    	at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:318)
    	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
    	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)
    ]]
    ..................


 Comments   
Comment by Tom Mueller [ 14/Apr/13 07:12 PM ]
  • What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?

This is a regression caused by a previous performance fix to the MonitoringBootstrap service.

  • What is the cost/risk of fixing the bug?

How risky is the fix? How much work is the fix? Is the fix complicated?

Low cost, low risk. Just adding a null check in one place.

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Tests that access the monitoring feature of the console.
  • Which is the targeted build of 4.0 for this fix?
    b85.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A
Comment by Tom Mueller [ 14/Apr/13 07:12 PM ]

Approved for 4.0.

Comment by Tom Mueller [ 14/Apr/13 07:14 PM ]

Fixed in revision 61421.





[GLASSFISH-20304] BATCH RI: Can't inject an EntityManager in an ItemWriter implementation Created: 12/Apr/13  Updated: 22/Jun/13  Resolved: 18/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: rcervera Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish promoted b84.


Tags: batch cdi
Participants: jimnicolson, jjsnyder83, Mahesh Kannan, rcervera and ScottKurz

 Description   

Injecting an EntityManager using @PersistenceContext in an ItemWriter implementation results in a null pointer. For example:

...
public class MyWriter implements ItemWriter {
@PersistenceContext
EntityManager em;

@Override
public void open(Serializable s) throws Exception { System.out.println(em.toString); // em is a null pointer }
...
}



 Comments   
Comment by ScottKurz [ 16/Apr/13 05:20 PM ]

Would you be able to post a version of this application to help recreate?

Comment by rcervera [ 16/Apr/13 06:21 PM ]

Hi Scott,

I can't add an attachment to this issue on JIRA. I've sent you a very simple application that recreates this issue. This is on Glassfish b84, the last promoted build.

Thanks,

Comment by ScottKurz [ 17/Apr/13 12:20 AM ]

I'm wondering if the key element of this situation is the fact that the batch ItemReader runs on the relatively new managed thread pool (JSR-236) thread rather than the main thread of the servlet.

Could we ask JPA to take a look?

Comment by Mahesh Kannan [ 17/Apr/13 02:07 AM ]

I have the following working:

@Named("SimpleItemReader")
public class SimpleItemReader
extends AbstractItemReader { @EJB private SampleDataHolderBean dataBean; ..... }

So, I assume that the JSR 236 implementation is at least setting up the component env and class loader properly. Obviously, injection of PersistenceContext into an EJB is working (we have a lots of devtests, CTS tests for this).

I will try adding a @PostConstruct to my sample to see if it gives any clue.

Maybe, the CDI folks should look into this.

Comment by jjsnyder83 [ 17/Apr/13 10:36 AM ]

How is the instance of MyWriter created? Is it injected into a servlet or some other object?

Comment by ScottKurz [ 17/Apr/13 02:18 PM ]

If we assume the batch artifacts must be instantiated via CDI in order for the JPA injection to work, then the answer is simply that this isn't setup correctly from the batch+CDI perspective.

You're not in fact using CDI here but are falling back to META-INF/batch.xml-based artifact loading.

To fix this:

1) The batch artifacts must be annotated with @Named

2) The JSL @ref value must match the "bean name" (I put this in quotes since I'm not 100% sure this is the correct term).

E.g. you should have:

@Named
public class ExampleReader implements ItemReader {

aligning with JSL:

<step id="mobilefilter">
<chunk checkpoint-policy="item" item-count="10">
<reader ref="exampleReader"></reader> <!-- DEFAULT bean name per CDI -->

Or could have:

@Named("MyReaderBean")
public class ExampleReader implements ItemReader {

aligning with:

<step id="mobilefilter">
<chunk checkpoint-policy="item" item-count="10">
<reader ref="MyReaderBean"></reader>

------------------------------------------------------------------------------

Strictly from the batch perspective, we do support the batch.xml loading. If there is an expectation that this should also "work" in allowing JPA injection then this whole issue needs to be pursued further.

Comment by rcervera [ 17/Apr/13 07:28 PM ]

We will cover this use case in the documentation and examples, unless something changes.

Comment by Mahesh Kannan [ 18/Apr/13 03:11 AM ]

Based on Scott's comment, marking this as resolved

Comment by jimnicolson [ 21/Jun/13 01:58 PM ]

Although this is closed, I have just hit this problem for GF 4 Build 89 (Final release).

I've tried an EJB and a WAR project, with and without a valid persistence.xml and injecting EntityManager using @PersistenceContext and custom CDI Producer annotation.

The Batch processing actions are functional, EcliseLink/JPA initialization seems to be behaving normally, but no EntityManager.

Injection returns null on all three Batch classes Reader, Processor, Writer.

I'm happy to be wrong but at this point there still seems to be a problem.

I have a test WAR (with source included) (17K) but first just making an inquiry sine I'm a newbee to this site.

Comment by rcervera [ 21/Jun/13 05:46 PM ]

jimnicolson, this is no longer an issue; injecting an EntityManager should work. Please see the phonebilling example in the EE 7 tutorial for an example of a batch job that injects an EntityManager:

http://docs.oracle.com/javaee/7/tutorial/doc/batch-processing009.htm

The code for the example is included with the EE 7 SDK.

Comment by jimnicolson [ 22/Jun/13 04:28 AM ]

Thanks it's working but just for future reference:

From @Named to @Named("SimpleBatchReader") resolved the problem.

(I didn't need to add a no-arg constructor to have this work but will do so.)

@Dependent
@Named("SimpleBatchReader")
public class SimpleBatchReader extends AbstractItemReader {

@PersistenceContext
EntityManager em;

@Override
public void open(Serializable checkpoint) throws Exception { System.out.println("SimpleBatchReader.open em=" + em); }
....

Looking at the Java EE 7 Tutorial docs (http://docs.oracle.com/javaee/7/tutorial/doc/batch-processing005.htm#BCGIFJBB).

I suggest that it might be a useful addition to add an explicit note/clarification of this 'side-effect'.

Especially as the Batch Job 'works' and there are examples from credible sources (e.g. https://glassfish.java.net/hol/javaee7-hol.pdf See p40) whihc don't clarify this.

i.e. it is not clear that @Named without the string and using a batch.xml in META-INF has this side-effect (when in fact they are alternatives ?)

I had both - seems obvious now of course





[GLASSFISH-20301] OLH: All help pages return 404 error Created: 12/Apr/13  Updated: 16/Apr/13  Resolved: 16/Apr/13

Status: Resolved
Project: glassfish
Component/s: bean-validator
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Blocker
Reporter: Anissa Lam Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: console 4_0-approved
Participants: Anissa Lam, Mike Fitch, Romain Grécourt and Tom Mueller

 Description   

In build 83, online help works fine.
In build 84, none of the help pages *.html is included in the console jars. eg console-common.jar, console-ejb-plugin.jar ...

This means OLH is completely broken.
Not sure if this is a build issue or not. Assign to doc now, if nothing is changed by the doc team, he can reassign to Romain for a look.



 Comments   
Comment by Mike Fitch [ 12/Apr/13 06:53 PM ]

The last change to main-docs was svn revision 61142. It was used to build version 4.0-b27 of main-docs.

There have been no changes to main-docs since.

GlassFish was updated to start picking up version 4.0-b27 of main-docs in svn revision 61152. The April 5, 2013 nightly build demonstrates successful incorporation and display of main-docs 4.0-b27 in GlassFish. You can pick up this build here: http://dlc.sun.com.edgesuite.net/glassfish/4.0/nightly/glassfish-4.0-b84-04_05_2013.zip.

Since this past build was working and there have been no changes to main-docs since, this issue must in some way related to GlassFish product build. Therefore, I am setting the Component to build_system and assigning the issue to Romain.

Comment by Romain Grécourt [ 16/Apr/13 11:17 AM ]

This is actually because claire duplicated the plugin element for maven-dependency-plugin, which resulted into no unpacking of OLH zip artifacts.
See: Index: ../pom.xml
===================================================================
— ../pom.xml (revision 61196)
+++ ../pom.xml (revision 61197)
@@ -156,6 +156,23 @@
</execution>
</executions>
</plugin>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-dependency-plugin</artifactId>
+ <executions>
+ <execution>
+ <id>unpack-dependencies</id>
+ <goals>
+ <goal>unpack-dependencies</goal>
+ </goals>
+ <configuration>
+ <includeGroupIds>org.glassfish.docs-l10n.help-l10n</includeGroupIds>
+ <excludeTransitive>true</excludeTransitive>
+ <outputDirectory>${project.build.outputDirectory}</outputDirectory>
+ </configuration>
+ </execution>
+ </executions>
+ </plugin>
</plugins>
</build>

Log message:

Log Message:
------------
GLASSFISH-18266 - incorporate the localized version of on-line help and man pages into Glassfish workspace

Comment by Romain Grécourt [ 16/Apr/13 11:19 AM ]
  • What is the impact on the customer of the bug?
    No online hep available

How likely is it that a customer will see the bug and how serious is the bug?
Very serious, customer will see it every time.

Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
Yes, regression.

What CTS failures are caused by this bug?
None. this is OLH / l10n issue

  • What is the cost/risk of fixing the bug?
    low.

How risky is the fix? How much work is the fix? Is the fix complicated?
a few lines in a parent pom, very easy.

  • Is there an impact on documentation or message strings?
    Yes, no OLH
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    None.
  • Which is the targeted build of 4.0 for this fix?
    b85
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
Comment by Romain Grécourt [ 16/Apr/13 11:20 AM ]

changes:

Index: appserver/admingui/pom.xml
===================================================================
--- appserver/admingui/pom.xml	(revision 61436)
+++ appserver/admingui/pom.xml	(working copy)
@@ -149,52 +149,15 @@
                   <goal>unpack-dependencies</goal>
                 </goals>
                 <configuration>
-                  <includeGroupIds>org.glassfish.docs.help</includeGroupIds>
+                  <includeGroupIds>org.glassfish.docs.help,org.glassfish.docs-l10n.help-l10n</includeGroupIds>
                   <excludeTransitive>true</excludeTransitive>
                   <outputDirectory>${project.build.outputDirectory}</outputDirectory>
                 </configuration>
               </execution>
             </executions>
           </plugin>
-          <plugin>
-            <groupId>org.apache.maven.plugins</groupId>
-            <artifactId>maven-dependency-plugin</artifactId>
-            <executions>
-              <execution>
-                <id>unpack-dependencies</id>
-                <goals>
-                  <goal>unpack-dependencies</goal>
-                </goals>
-                <configuration>
-                  <includeGroupIds>org.glassfish.docs-l10n.help-l10n</includeGroupIds>
-                  <excludeTransitive>true</excludeTransitive>
-                  <outputDirectory>${project.build.outputDirectory}</outputDirectory>
-                </configuration>
-              </execution>
-            </executions>
-          </plugin>
         </plugins>
       </build>
-<!--
-    <build>
-        <plugins>
-            <plugin>
-                <groupId>org.glassfish.hk2</groupId>
-                <artifactId>hk2-maven-plugin</artifactId>
-                <configuration>
-                    <processors>
-                        <processor>
-                            <groupId>com.sun.jsftemplating</groupId>
-                            <artifactId>jsftemplating-dt</artifactId>
-                            <version>${jsftemplating.version}</version>
-                        </processor>
-                    </processors>
-                </configuration>
-                <extensions>true</extensions>
-            </plugin>
-        </plugins>
-    </build>
- -->
 
     <dependencies>
         <dependency>
Comment by Tom Mueller [ 16/Apr/13 01:39 PM ]

Approved for 4.0.

Comment by Romain Grécourt [ 16/Apr/13 04:39 PM ]

fix with svn rev #61438





[GLASSFISH-20300] config modularity write transactions are not single threaded Created: 12/Apr/13  Updated: 15/Apr/13  Resolved: 15/Apr/13

Status: Resolved
Project: glassfish
Component/s: configuration
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-20206 Boot GlassFish startup services in pa... Closed
Tags: 4_0-approved devx_web
Participants: Tom Mueller

 Description   

The config modularity feature performs write transactions on the configuration without participating in any locking protocol to prevent those transactions from proceeding at the same time as other config modularity transactions or at the same time as write transactions from commands. Before config modularity, the system made sure that the only place where write transactions occur is from within commands that hold the exclusive lock (AdminCommandLock).

This issue is for making the config modularity transactions get the AdminCommandLock in exclusive mode.



 Comments   
Comment by Tom Mueller [ 12/Apr/13 06:03 PM ]

This bug prevents activating the fix for 20206 with multiple threads.

Comment by Tom Mueller [ 12/Apr/13 08:18 PM ]
  • What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?

  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    What CTS failures are caused by this bug?

This bug is preventing the usage of the multi-threading service initialization implementation that is available with the fix for GLASSFISH-20206. It is also possible to get strange errors with committing config change transactions at the same time, for example, if a new module would be making a config modularity change at the same time as some other command that is changing the configuration runs.

  • What is the cost/risk of fixing the bug?

How risky is the fix? How much work is the fix? Is the fix complicated?

The fix consists of using an existing lock mechanism (AdminCommandLock) around calls that the config modularity feature makes to ConfigSupport.apply (the method used to make config changes). The fix is fairly simple and straightforward.

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Any test that starts the server tests this fix.
  • Which is the targeted build of 4.0 for this fix?
    The next build.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A
Comment by Tom Mueller [ 12/Apr/13 08:19 PM ]

Approved for 4.0.

Comment by Tom Mueller [ 15/Apr/13 12:12 AM ]

Fixed in revision 61422.





[GLASSFISH-20294] Timer service application is not stopped properly during server shutdown Created: 12/Apr/13  Updated: 12/Apr/13  Resolved: 12/Apr/13

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Hong Zhang Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: Hong Zhang

 Description   

Marina reported the timer service system application is not stopped properly during server shutdown. There is warning message about timer service application is not registered in the server.log.



 Comments   
Comment by Hong Zhang [ 12/Apr/13 01:03 AM ]

1. What is the impact on the customer of the bug? How likely is it that a customer will see the bug and how serious is the bug? Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)? What CTS failures are caused by this bug?

The timer service application (and other system applications which are only loaded in memory on demand but not registered in domain.xml) will not be stopped/shutdown properly during server shutdown which prevents proper clean up of the system applications.

It does not cause CTS failures.

2. What is the cost/risk of fixing the bug? How risky is the fix? How much work is the fix? Is the fix complicated?

The fix is straightforward and small, there is some change made in stop/unload application code path to accommodate such use case when the application is only loaded in the memory and not registered in domain.xml. I have a fix in my workspace already and the risk of the fix is small.

3. Is there an impact on documentation or message strings?

No impact.

4. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Tests to execute disable and undeploy commands.

5. Which is the targeted build of 4.0 for this fix?

b85

6. If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages.

N/A





[GLASSFISH-20292] html_basic.taglib.xml and facelets_jsf_core.taglib.xml are not complete in JSF2.2 Created: 10/Apr/13  Updated: 16/Apr/13  Resolved: 16/Apr/13

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: None
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: marfous Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 39 minutes
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: Ed Burns, marfous and Tom Mueller

 Description   

The issue from http://java.net/jira/browse/JAVASERVERFACES-2756 still remains and we had reported also additional missing tags from users. Please can I ask you for completion of following attributes and tags into html_basic.taglib.xml and facelets_jsf_core.taglib.xml files:

facelets_jsf_core.taglib.xml:
f:attributes - MISSING WHOLE TAG
f:passThroughAttribute - MISSING WHOLE TAG
f:passThroughAttributes - MISSING WHOLE TAG
f:ajax - MISSING delay, resetValues ATTR
f:view - MISSING transient, contracts ATTR
f:selectItems - MISSING rendered, actionListener ATTR

html_basic.taglib.xml:
h:inputFile - MISSING WHOLE TAG
h:button - MISSING role, disableClientWindow ATTR
h:commandButton - MISSING role ATTR
h:commandLink - MISSING role ATTR
h:link - MISSING role, disableClientWindow ATTR

Sorry for annoyances but we need to have these files completed for purposes of JSF editor since it's only way how to get list of tags, their attributes and their documentation. Thanks a lot!

Links to corresponding NetBeans issues:
https://netbeans.org/bugzilla/show_bug.cgi?id=228288
https://netbeans.org/bugzilla/show_bug.cgi?id=228287



 Comments   
Comment by marfous [ 10/Apr/13 06:25 AM ]

Also these two fixes would be appreciated and the #2637 is also already fixed now without fixing in the taglib metadata:

http://java.net/jira/browse/JAVASERVERFACES-2637
h:doctype - MISSING WHOLE TAG

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1131
h:outputScript - name ATTR is not required
h:outputStylesheet - name ATTR is not required

Thanks...

Comment by Ed Burns [ 11/Apr/13 09:28 PM ]

I'm sorry, but I didn't get to JAVASERVERFACES_SPEC_PUBLIC-1131, and it's too late to get it for 2.2, since we handed off the final spec. I can fix it in the html_basic.taglib.xml file though because that is an impl detail.

Comment by Ed Burns [ 11/Apr/13 09:54 PM ]

What is the impact on the customer of the bug?

NetBeans IDE displays incorrect and incomplete documentation for JSF taglibs.

How likely is it that a customer will see the bug and how serious is the bug?

100%

Is it a regression?

No

Does it meet other bug fix criteria (security, performance, etc.)?

Yes

What CTS failures are caused by this bug?

None known.

What is the cost/risk of fixing the bug

How risky is the fix? How much work is the fix? Is the fix complicated?

These files are only used for documentation purposes and not by the runtime. Therefore, there is no risk to the runtime.

Is there an impact on documentation or message strings?

No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

None, dev tests are sufficient.

Which is the targeted build of 4.0 for this fix?

TBD

Comment by Tom Mueller [ 11/Apr/13 10:05 PM ]

Approved for 4.0.

Comment by Ed Burns [ 12/Apr/13 02:08 AM ]

M jsf-ri/conf/share/facelets_jsf_core.taglib.xml
M jsf-ri/conf/share/html_basic.taglib.xml

  • Had to revert this because it was causing quicklook tests to fail.
    Sending jsf-ri/conf/share/facelets_jsf_core.taglib.xml
    Sending jsf-ri/conf/share/html_basic.taglib.xml
    Transmitting file data ..
    Committed revision 11867.
Comment by Ed Burns [ 12/Apr/13 02:09 AM ]

Your recent checkin of the taglib files for JAVASERVERFACES-2836 /
GLASSFISH-20294
breaks some of the JSF quicklook tests. Namely it is the *
Glassfish* *Profile with Security Manager Turned On
*test.
*
*Here is the test output:

1.
[testng] FAILED: jsfIndexPageBasicTest
2.
[testng] java.lang.Exception: java.io.FileNotFoundException:
http://localhost:8080/jsfastrologer/index.jsp
3.
[testng] at
test.jsf.astrologer.JSFWebTestNG.jsfIndexPageBasicTest(JSFWebTestNG.java:166)
4.
[testng] Caused by: java.io.FileNotFoundException:
http://localhost:8080/jsfastrologer/index.jsp
5.
[testng] at
sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1664)
6.
[testng] at
sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1662)
7.
[testng] at java.security.AccessController.doPrivileged(Native
Method)
8.
[testng] at
sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1660)
9.
[testng] at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1243)
10.
[testng] at
test.jsf.astrologer.JSFWebTestNG.jsfIndexPageBasicTest(JSFWebTestNG.java:147)
11.
[testng] ... 22 more
12.
[testng] Caused by: java.io.FileNotFoundException:
http://localhost:8080/jsfastrologer/index.jsp
13.
[testng] at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1613)
14.
[testng] at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
15.
[testng] at
test.jsf.astrologer.JSFWebTestNG.jsfIndexPageBasicTest(JSFWebTestNG.java:144)
16.
[testng] ... 22 more
17.
[testng] ... Removed 26 stack frames
18.
[testng] FAILED: jsfAppDeployedFirstPagetest
19.
[testng] java.lang.Exception: java.io.FileNotFoundException:
http://localhost:8080/jsfastrologer/faces/greetings.jsp
20.
[testng] at
test.jsf.astrologer.JSFWebTestNG.jsfAppDeployedFirstPagetest(JSFWebTestNG.java:125)
21.
[testng] Caused by: java.io.FileNotFoundException:
http://localhost:8080/jsfastrologer/faces/greetings.jsp
22.
[testng] at
sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1664)
23.
[testng] at
sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1662)
24.
[testng] at java.security.AccessController.doPrivileged(Native
Method)
25.
[testng] at
sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1660)
26.
[testng] at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1243)
27.
[testng] at
test.jsf.astrologer.JSFWebTestNG.jsfAppDeployedFirstPagetest(JSFWebTestNG.java:105)
28.
[testng] ... 22 more
29.
[testng] Caused by: java.io.FileNotFoundException:
http://localhost:8080/jsfastrologer/faces/greetings.jsp
30.
[testng] at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1613)
31.
[testng] at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
32.
[testng] at
test.jsf.astrologer.JSFWebTestNG.jsfAppDeployedFirstPagetest(JSFWebTestNG.java:102)
33.
[testng] ... 22 more
34.
[testng] ... Removed 26 stack frames
35.
[testng]
36.
[testng] ===============================================
37.
[testng] jsf_hello_world
38.
[testng] Tests run: 2, Failures: 2, Skips: 0
39.
[testng] ===============================================

When I replace the taglib files with 2.2.0-m13 versions (before your
change) all tests pass.
One option is to go ahead with 2.2.0-m14 without this change, then do
2.2.0-m15 when this is ready.

-roger

Comment by marfous [ 12/Apr/13 06:33 AM ]

No worries about JAVASERVERFACES_SPEC_PUBLIC-1131, the implementation change in the doc without the spec definition sounds well to us.
And when it would not be possible I think that the most important are the JSF2.2 related changes, thanks!

Comment by Ed Burns [ 16/Apr/13 02:37 PM ]

This will be in GlassFish 4.0 promoted build 85.

Ed

Comment by Ed Burns [ 16/Apr/13 02:45 PM ]

Integrated with 2.2.0-m14, committed as

r61425 | rogerk | 2013-04-15 09:06:17 -0400 (Mon, 15 Apr 2013) | 213 lines

http://java.net/jira/browse/GLASSFISH-20292 http://java.net/jira/browse/GLASSFISH-20232 http://java.net/jira/browse/GLASSFISH-20123 http://java.net/jira/browse/GLASSFISH-20122

http://java.net/jira/browse/GLASSFISH-20292

M jsf-ri/conf/share/facelets_jsf_core.taglib.xml

f:attributes - MISSING WHOLE TAG
f:passThroughAttribute - MISSING WHOLE TAG
f:passThroughAttributes - MISSING WHOLE TAG
f:ajax - MISSING delay, resetValues ATTR
f:view - MISSING transient, contracts ATTR
f:selectItems - MISSING rendered, actionListener ATTR

M jsf-ri/conf/share/html_basic.taglib.xml

h:inputFile - MISSING WHOLE TAG
h:button - MISSING role, disableClientWindow ATTR
h:commandButton - MISSING role ATTR
h:commandLink - MISSING role ATTR
h:link - MISSING role, disableClientWindow ATTR
h:doctype - MISSING WHOLE TAG

Sending jsf-ri/conf/share/facelets_jsf_core.taglib.xml
Sending jsf-ri/conf/share/html_basic.taglib.xml
Transmitting file data ..
Committed revision 11873.

http://java.net/jira/browse/GLASSFISH-20232

M jsf-ri/src/main/java/com/sun/faces/flow/FlowHandlerImpl.java

  • Instead of polling the config manager to see if there are flows, use
    the addFlow() method.
    Sending jsf-ri/src/main/java/com/sun/faces/flow/FlowHandlerImpl.java
    Transmitting file data .
    Committed revision 11852.

http://java.net/jira/browse/GLASSFISH-20123

M jsf-ri/build-pre-maven-rename.xml
M jsf-api/build-pre-maven-rename.xml

  • Apply the changes from "svn diff -r 11859:11860" to the
    "pre-maven-rename" variant.

Sending jsf-api/build-pre-maven-rename.xml
Sending jsf-ri/build-pre-maven-rename.xml
Transmitting file data ..
Committed revision 11872.

M jsf-ri/build.xml

  • change mvn.deploy.release.local and mvn.deploy.release to depend on m14.

M jsf-ri/mojarra-jsf-impl.bnd

  • change OSGi Implementation-Version to be 2.2.0-m14.
  • change OSGi Bundle-Version to be 2.1.99.b14

M common/ant/maven.xml

  • If the build.type is not -SNAPSHOT, activate the check-module property
    when invoking maven. This causes the

<groupId>org.glassfish.build</groupId>
<artifactId>spec-version-maven-plugin</artifactId>
<version>1.1</version>

plugin to be invoked, as shown in this output

[INFO] Building jar: /Users/ejburns/Documents/JavaEE/workareas/mojarra-MOJARRA_2_2_0_GLASSFISH_4_0/jsf-api/build/mvn/target/javax.faces-api-2.2-m14.jar
[INFO] [build-helper:attach-artifact {execution: attach-artifacts}]
[INFO] [spec-version:check-module {execution: default}]
[INFO] [source:jar-no-fork {execution: attach-sources}]
[INFO] Building jar: /Users/ejburns/Documents/JavaEE/workareas/mojarra-MOJARRA_2_2_0_GLASSFISH_4_0/jsf-ri/build/mvn/target/javax.faces-2.2.0-m14.jar
[INFO] [build-helper:attach-artifact {execution: attach-artifacts}]
[INFO] [spec-version:check-module {execution: default}]
[INFO] [source:jar-no-fork {execution: attach-sources}]

M common/ant/template/jsf-impl-pom-template.xml
M common/ant/template/jsf-api-pom-template.xml

  • invoke the spec-version-maven-plugin if the check-module property is
    activated.

M jsf-api/mojarra-jsf-api.bnd

  • Change OSGi Implementation-Version to be 2.2.0-m14
  • Change OSGi Bundle-Version to be 2.1.99.b14

M jsf-api/build.xml

  • change mvn.deploy.release.local and mvn.deploy.release to depend on m14
    Sending common/ant/maven.xml
    Sending common/ant/template/jsf-api-pom-template.xml
    Sending common/ant/template/jsf-impl-pom-template.xml
    Sending jsf-api/build.xml
    Sending jsf-api/mojarra-jsf-api.bnd
    Sending jsf-ri/build.xml
    Sending jsf-ri/mojarra-jsf-impl.bnd
    Transmitting file data .......
    Committed revision 11860.

To preverve backward compatibility with the now deprecated Facelets
ResourceResolver, ensure it gets consulted on ViewHandler0.viewExists().

r=mriem

SECTION: Modified Files
----------------------------
M jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFaceletFactory.java
M jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
M jsf-demo/sandbox/flow_and_contract/app/pom.xml
M jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/OutcomeTargetRenderer.java

  • Unrelated change. Don't renderd the flow attributes on outcomeTarget
    components unless there are flows.

D jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts
D jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts/leftNav
D jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts/topNav

  • Unrelated change, the focus of this demo changed so that now the flows
    and contracts are bundled in jars, not with the app.

A test/agnostic/vdl/facelets/resource-resolver
A test/agnostic/vdl/facelets/resource-resolver/nbactions.xml
A test/agnostic/vdl/facelets/resource-resolver/src
A test/agnostic/vdl/facelets/resource-resolver/src/test
A test/agnostic/vdl/facelets/resource-resolver/src/test/java
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/VerifyResourceResolverUsageIT.java
A test/agnostic/vdl/facelets/resource-resolver/src/main
A test/agnostic/vdl/facelets/resource-resolver/src/main/java
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/TestResolver.java
A test/agnostic/vdl/facelets/resource-resolver/src/main/resources
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/web.xml
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/glassfish-web.xml
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/a.xhtml
A test/agnostic/vdl/facelets/resource-resolver/pom.xml

  • New test
    Sending jsf-demo/sandbox/flow_and_contract/app/pom.xml
    Deleting jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts
    Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
    Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFaceletFactory.java
    Sending jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/OutcomeTargetRenderer.java
    Adding test/agnostic/vdl/facelets/resource-resolver
    Adding test/agnostic/vdl/facelets/resource-resolver/nbactions.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/pom.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/src
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/TestResolver.java
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/resources
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/glassfish-web.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/web.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/a.xhtml
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/VerifyResourceResolverUsageIT.java
    Transmitting file data ...........
    Committed revision 11850.

SECTION: Modified Files
----------------------------
M jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java

  • Found by jsp-flash systest-per-webapp.

Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
Transmitting file data .
Committed revision 11851.





[GLASSFISH-20291] Embedded GlassFish copies domain.xml to default-web.xml Created: 11/Apr/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Harald Wellmann Assignee: Bhavanishankar
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Bhavanishankar and Harald Wellmann

 Description   

The root cause of the problem described in http://java.net/jira/browse/GLASSFISH-20270 seems to be that Embedded GlassFish tries to parse my domain.xml as default-web.xml and then obviously fails.

This is how I start Embedded GlassFish:

File domainConfig = new File(configDirName, "domain.xml");
        GlassFishProperties gfProps = new GlassFishProperties();
        if (domainConfig.exists()) {
            gfProps.setConfigFileURI(domainConfig.toURI().toString());
        }

        try {
            glassFish = GlassFishRuntime.bootstrap().newGlassFish(gfProps);
            glassFish.start();
            // ...

In the config directory

/tmp/gfembed6394395759171343973tmp/config

I can see two files domain.xml and default-web.xml with identical content.



 Comments   
Comment by Bhavanishankar [ 19/Apr/13 05:47 AM ]

This issue is caused due to the following check-in 56069. I am working on a fix for this.

Comment by Bhavanishankar [ 19/Apr/13 07:56 AM ]

This has been fixed with check-in rev 61551. Refer the following link for fix details:

http://java.net/projects/glassfish/lists/commits/archive/2013-04/message/460





[GLASSFISH-20290] ConcurrentModificationException transactional delisting resources used by a singleton session bean Created: 11/Apr/13  Updated: 12/Apr/13  Resolved: 12/Apr/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: marina vatkina and Tom Mueller

 Description   

[2013-04-08T12:20:53.494+0100] [glassfish 4.0] [SEVERE] [enterprise_distributedtx.excep_in_delist] [javax.enterprise.resource.jta.com.sun.enterprise.transaction] [tid: _ThreadID=56 _ThreadName=p: thread-pool-1; w: 1] [timeMillis: 1365420053494] [levelValue: 1000] [[
DTX5002:Exception in delistComponentResources.
java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819)
at java.util.ArrayList$Itr.next(ArrayList.java:791)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.delistComponentResources(JavaEETransactionManagerSimplified.java:1276)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.postInvoke(JavaEETransactionManagerSimplified.java:635)
at com.sun.enterprise.transaction.TransactionInvocationHandler.beforePostInvoke(TransactionInvocationHandler.java:95)
at org.glassfish.api.invocation.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:225)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2001)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy269.doSomething(Unknown Source)
at beans._EJB31_GeneratedSingletonSessionBeanIntf__Bean_.doSomething(Unknown Source)
at beans.MyMDB.onMessage(MyMDB.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1057)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1129)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4695)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4667)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at org.glassfish.ejb.mdb.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1197)
at org.glassfish.ejb.mdb.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
at com.sun.proxy.$Proxy275.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:283)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:107)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)



 Comments   
Comment by marina vatkina [ 11/Apr/13 05:33 PM ]

See the following comment in AbstractSingletonContainer:

// Singletons can not store the underlying resource list
// in the context impl since that is shared across many
// concurrent invocations. Instead, set the resource
// handler on the invocation to provide a different
// resource List for each Singleton invocation.
inv.setResourceHandler(new ResourceHandlerImpl());

But (a) it's not called by any invocation after the singleton is created; and (b) will not handle transactions that span multiple invocations

Comment by marina vatkina [ 11/Apr/13 05:37 PM ]
  • What is the impact on the customer of the bug?
    Will see the correct behavior. It's a plain coincidence that this bug is there for so long.
  • How likely is it that a customer will see the bug and how serious is the bug?
    Request scoped JMSContext can't be used with singleton session beans
  • What CTS failures are caused by this bug?
    none
  • What is the cost/risk of fixing the bug?
    the fix is available
  • Is there an impact on documentation or message strings?
    no
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    EJB tests in CTS, QA regression tests
  • Which is the targeted build of 4.0 for this fix?
    the next
  • Is this an integration of a new version of a component from another project?
    no
Comment by Tom Mueller [ 11/Apr/13 05:49 PM ]

Approved for 4.0.

Comment by marina vatkina [ 12/Apr/13 07:38 PM ]

Fixed:

Sending ejb-container/src/main/java/com/sun/ejb/containers/AbstractSingletonContainer.java
Sending ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java
Transmitting file data ..
Committed revision 61399.





[GLASSFISH-20277] GF4 installer: Using older Update Center bootstrap / java client (regression) Created: 10/Apr/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: Joe Di Pol Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: Joe Di Pol, Snjezana Sevo-Zenzerovic and Tom Mueller

 Description   

When running the B84 GF installer I bootstrapped UC from the command line by running the "pkg" wrapper script. It looks old, because it refers to wikis.sun.com:

http://wikis.sun.com/display/updatecenter/UsageMetricsUC2

Also, the Java client appears to be pretty old too because:

1) It is slower than the B56 client. The GF4.0 bootstrap of pkg took over a minute for me, but with UC B56 it took less than 40s.

2) B56 has much improved progress feedback.

So it looks like we are using an old wrapper script for "pkg" (and I assume "updatetool") and the Java client is old too.

FYI, I checked the GF 3.1.2 GF installer, and it appears to be using the B56 version (it has the correct URL and download is fast) – so this looks like a regression.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 11/Apr/13 01:32 PM ]

It looks like this slipped through the cracks during 3.1.2 changes merge, probably because of whole nucleus/appserver pom split going on...

Yes, trunk contains B54 client and bootstrap and should be upgraded to b56.

Comment by Snjezana Sevo-Zenzerovic [ 11/Apr/13 02:18 PM ]
  • What is the impact on the customer of the bug?

This is a regression compared to 3.1.2 release. Performance and user experience for UC client bootstrap is affected due to old bootstrap/Java client version. Also, branding issues since integrated release is not Oracle branded.

  • What is the cost/risk of fixing the bug?

Low risk. Two line fix to update pkg and bootstrap jar versions in top level pom.xml. New versions have been tested in the field in 3.1.2 and 3.1.2.2 releases so low regression risk.

  • Is there an impact on documentation or message strings?

No.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Regular installer and UC integration testing will be sufficient.

  • Which is the targeted build of 4.0 for this fix?

b85

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

Not exactly new integration, but delayed merge of the 3.1.2 branch integration.

Comment by Tom Mueller [ 11/Apr/13 05:17 PM ]

Approved for 4.0.

Comment by Snjezana Sevo-Zenzerovic [ 11/Apr/13 06:37 PM ]

Integrated updated client jars.





[GLASSFISH-20274] SDK installer: Add verbage as to why "Custom Installation" is not available Created: 10/Apr/13  Updated: 11/Apr/13  Resolved: 10/Apr/13

Status: Closed
Project: glassfish
Component/s: installation
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Joe Di Pol Assignee: Snjezana Sevo-Zenzerovic
Resolution: Invalid Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Joe Di Pol and Snjezana Sevo-Zenzerovic

 Description   

When running the SDK installer you get to the "Installation Type" screen and it gives a choice for "Typical Installation" and "Custom Installation". But "Custom Installation" is inactive (due to the decision to not support cluster creation from the installaer). There is no text explaining why. If we can't hide "Custom Installation" then at least we need to modify the text. Maybe instead of saying:

"This option is ideal for production deployments."

we say

"This option is not available in this release."



 Comments   
Comment by Joe Di Pol [ 10/Apr/13 09:50 PM ]

Based on the B84 GF4 installer, this has been addressed.

Comment by Snjezana Sevo-Zenzerovic [ 11/Apr/13 01:23 PM ]

Just to confirm that this will trickle into SDK installer distributions in SDK b84 (so either today or tomorrow).





[GLASSFISH-20269] [SDK]Java EE 7 sample-concurrency documentation issue Created: 10/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Daniel Assignee: anthony.lai
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ee7 sdk build82


Tags:
Participants: anthony.lai and Daniel

 Description   

Concurrency Schedule Application documentation has incorrect samples_install_dir(which is point to concurrency/executor not concurrency/schedule), showling below:

Perform the following steps to build, deploy, and run the application:

Set up your build environment and configure the application server with which the build system has to work by following the common build instructions.
samples_install_dir is the sample application base directory. Go to: samples_install_dir/javaee7/concurrency/executor.
Build, deploy, and run the sample application using the run outcome.

mvn clean verify cargo:run
Front page of this sample is at http://localhost:8080/schedule (the port number might vary).
Use the clean outcome to undeploy the sample application and to remove the temporary directories such as build and dist.

mvn clean



 Comments   
Comment by anthony.lai [ 10/Apr/13 08:17 PM ]

Project: glassfish-samples
Repository: svn
Revision: 1117
Author: anthony.lai
Date: 2013-04-10 20:15:11 UTC
Link:

Log Message:
------------
GLASSFISH-20269 Minor fix to doc for javaee7/concurrency/schedule sample

Revisions:
----------
1117

Modified Paths:
---------------
trunk/ws/javaee7/concurrency/schedule/docs/index.html





[GLASSFISH-20268] org.jboss.cdi.tck.tests.deployment.packaging.rar.ResourceAdapterArchiveTest regression Created: 10/Apr/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_b85

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

Tags:
Participants: jjsnyder83




[GLASSFISH-20266] Maven artifacts not in sync with 4.0 releases Created: 10/Apr/13  Updated: 12/Apr/13  Resolved: 12/Apr/13

Status: Resolved
Project: glassfish
Component/s: docs, embedded
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Bruno Borges Assignee: Bhavanishankar
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Bhavanishankar, Bruno Borges and Romain Grécourt

 Description   

The Maven Embedded Plugin is not in sync with the current release process of GlassFish 4.0 beta, but some other Embedded artifacts are. As described in my blog [1], it is already possible to use the plugin 3.1.2.2 to run GF 4.0 if the correct dependencies are overridden in the POM file.

Artifacts missing sync:

  • simple-glassfish-api
  • maven-embedded-glassfish-plugin

Other issues I encountered during this investigation:

  • some artifacts are published in different groupIds, for different versions
  • there isn't a clear documentation of what Maven plugins GlassFish offers
  • developers may find themselves confused about what are the differences between GlassFish plugin [4], Embedded Plugin [3], and AsAdmin Plugin [2]

Some artifacts published are not documented on what exactly is their objective and functionality, for example:
1) groupId: org.glassfish.main.extras
artifactId: embedded
2) groupId: org.glassfish.main.extras
artifactId: javaee

    • and so many others

StackOverflow has a reference for this confusion [5]

[1] https://blogs.oracle.com/brunoborges/entry/glassfish_4_beta_and_maven
[2] https://github.com/Codeartisans/asadmin
[3] http://embedded-glassfish.java.net/nonav/plugindocs/3.1/plugin-info.html
[4] http://maven-glassfish-plugin.java.net/
[5] http://stackoverflow.com/questions/1836317/which-maven-glassfish-plugin-to-use/1836691#1836691



 Comments   
Comment by Romain Grécourt [ 10/Apr/13 06:23 PM ]

#2 is not official.
#3 has moved to https://svn.java.net/svn/glassfish~svn/trunk/maven-plugin/ which is even more confusing.
#4 needs a refresh for 4.0
org.glassfish.main.extras.javaee is a manifest jar intended for classpath within a GlassFish installation, it should actually not endup in any maven repository.

Regarding the groupIds, I agree that embedded artifacts should not use .extras but something more relevant.
Why don't you start a thread on dev@glassfish.java.net ?

Comment by Bruno Borges [ 10/Apr/13 07:15 PM ]

#2 I know, but without a clear documentation on all Maven-related artifacts and plugins, it's becoming a mess where nobody knows which plugin they should use to what.
#3 Agreed.

Several artifacts that are not for dependency nor plugins are on public repos, and this doesn't help but makes the situation even worse.

A discussion on dev@glassfish would lead to someone asking me to submit a bug. Guess this is the right way.

Comment by Romain Grécourt [ 10/Apr/13 07:54 PM ]

The discussion would help gathering more opinions around the groupIds for embedded artifacts.

Comment by Bhavanishankar [ 12/Apr/13 09:56 AM ]

Fixed with check-in rev 61385 (http://java.net/projects/glassfish/lists/commits/archive/2013-04/message/309)

From the end user's perspective, the maven plugin's co-ordinates remain the same as earlier releases i.e., org.glassfish.embedded:maven-embedded-glassfish-plugin, the version off course is 4.0-SNAPSHOT

Embedded Plugin documentations are at http://embedded-glassfish.java.net/nonav/plugindocs/3.1/plugin-info.html





[GLASSFISH-20256] The description coming w/ 404 error is not correct Created: 10/Apr/13  Updated: 12/Apr/13  Resolved: 12/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: oleksiys Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: oleksiys and Shing Wai Chan

 Description   

When we request a resource which doesn't exist, webcontainer reports 404 error w/ description like:
The requested resource (Not Found) is not available.

instead of providing the actual URL.
For sure before returning URL we have to check if for special HTML characters.



 Comments   
Comment by Shing Wai Chan [ 12/Apr/13 07:13 AM ]
  • What is the impact on the customer of the bug?
    Confusing error message.
  • What is the cost/risk of fixing the bug?
    One line java code change + a LocalStrings.properties file change.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE web tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_b85
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A
Comment by Shing Wai Chan [ 12/Apr/13 07:16 AM ]

This issue is similar to GLASSFISH-20254.

Comment by Shing Wai Chan [ 12/Apr/13 06:06 PM ]

In v3, the corresponding error message is:
"The requested resource () is not available."
which is also not good.

Look like grizzlyResponse.getMessage() returns a different value here.
I take a more detailed looked at those messages. There is no need to include the additional message there (as in Tomcat.)

Sending web-core/src/main/java/org/apache/catalina/valves/ErrorReportValve.java
Sending web-core/src/main/resources/org/apache/catalina/valves/LocalStrings.properties
Transmitting file data ..
Committed revision 61395.





[GLASSFISH-20254] Text returned by ContainerMapper as part of 404 error is not checked for special HTML characters Created: 10/Apr/13  Updated: 12/Apr/13  Resolved: 12/Apr/13

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

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

Tags: 4_0-approved
Participants: oleksiys

 Description   

The URL we send as part of 404 resource not found error is not checked for special HTML characters before it is sent back to client.



 Comments   
Comment by oleksiys [ 12/Apr/13 06:34 PM ]

fixed.

Repository: svn
Revision: 61398
Date: 2013-04-12 18:33:43 UTC

Log Message:
------------
+ fix issue #20254
http://java.net/jira/browse/GLASSFISH-20254
"Text returned by ContainerMapper as part of 404 error is not checked for special HTML characters"

We removed the URL, because a client knows the URL it requested.
Return the same messages as webcontainer does.





[GLASSFISH-20239] IllegalStateException if the async thread completed before the servlet thread Created: 09/Apr/13  Updated: 13/Apr/13  Resolved: 13/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: Shing Wai Chan and Tom Mueller

 Description   
An exception or error occurred in the container during the request processing
java.lang.IllegalStateException: Internal org.glassfish.grizzly.http.server.Response has not been set
	at org.glassfish.grizzly.http.server.Response.checkResponse(Response.java:1840)
	at org.glassfish.grizzly.http.server.Response.getStatus(Response.java:968)
	at org.apache.catalina.connector.Response.getStatus(Response.java:1070)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:364)
	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)
import java.io.*;
import javax.servlet.*;
import javax.servlet.annotation.*;
import javax.servlet.http.*;

@WebServlet(urlPatterns = {"/foo"}, asyncSupported=true)
public class MyServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        System.out.println("MyServlet");

        final AsyncContext asyncContext = req.startAsync();
        new Thread() {
            @Override
            public void run() {
                    asyncContext.complete();
            }
        }.start();

        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            //
        }

        System.out.println("MyServlet - leaving");
    }
}


 Comments   
Comment by Shing Wai Chan [ 09/Apr/13 05:12 PM ]

The actual async complete should be delay until the servlet is completed in this case.
Similar issue is identified for async dispatch.

Comment by Shing Wai Chan [ 12/Apr/13 09:33 PM ]

According to Servlet spec, the async complete should not take effect at that point.

  • What is the impact on the customer of the bug?
    The bug does not comform to the Servlet 3.1 spec.
  • What is the cost/risk of fixing the bug?
    Two java files change.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE web tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_b85
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A
Comment by Tom Mueller [ 12/Apr/13 09:44 PM ]

Approved for 4.0.

Comment by Shing Wai Chan [ 13/Apr/13 03:03 AM ]

Sending web-core/src/main/java/org/apache/catalina/connector/AsyncContextImpl.java
Sending web-core/src/main/java/org/apache/catalina/connector/Request.java
Transmitting file data ..
Committed revision 61411.





[GLASSFISH-20233] getSingleResult Fails: java.lang.CloneNotSupportedException Created: 08/Apr/13  Updated: 01/Apr/14  Resolved: 06/Nov/13

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: Bug Priority: Blocker
Reporter: reza_rahman Assignee: Mitesh Meswani
Resolution: Works as designed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


File Attachments: File cargo-tracker-test.war    
Issue Links:
Dependency
blocks CARGOTRACKER-1 Make project work on latest GlassFish... In Progress
Tags: 4_0_1-evangelists 4_0_1-review
Participants: Mitesh Meswani, qiang.l.liu and reza_rahman

 Description   

A fairly simple JPA query that was working on b76 is now failing. Below is the error I get. The code that generates the error is here: http://java.net/projects/cargotracker/downloads. It can be build via Maven and deployed. The error will occur on deployment. Is this a known problem? Please advise.

Target Invocation Exception: java.lang.CloneNotSupportedException: java.util.Arrays$ArrayList
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:851)
at org.eclipse.persistence.internal.jpa.QueryImpl.performPreQueryFlush(QueryImpl.java:962)
at org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:207)
at org.eclipse.persistence.internal.jpa.QueryImpl.getSingleResult(QueryImpl.java:516)
at org.eclipse.persistence.internal.jpa.EJBQueryImpl.getSingleResult(EJBQueryImpl.java:400)
at net.java.cargotracker.infrastructure.persistence.jpa.JpaCargoRepository.find(JpaCargoRepository.java:23)
at net.java.cargotracker.domain.model.handling.HandlingEventFactory.findCargo(HandlingEventFactory.java:60)
at net.java.cargotracker.domain.model.handling.HandlingEventFactory.createHandlingEvent(HandlingEventFactory.java:44)
at net.java.cargotracker.application.util.SampleDataGenerator.loadSampleCargos(SampleDataGenerator.java:129)
at net.java.cargotracker.application.util.SampleDataGenerator.loadSampleData(SampleDataGenerator.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1035)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:412)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:1949)
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:460)
... 44 more
Caused by: Exception [EclipseLink-6055] (Eclipse Persistence Services - 2.5.0.v20130321-85f6cb0): org.eclipse.persistence.exceptions.QueryException
Exception Description: The method invocation of the method [protected native java.lang.Object java.lang.Object.clone() throws java.lang.CloneNotSupportedException] on the object [[Leg{id=33, voyage=Voyage 0100S, loadLocation=Hong Kong [CNHKG], unloadLocation=New York [USNYC], loadTime=Mon Mar 02 00:00:00 EST 2009, unloadTime=Thu Mar 05 00:00:00 EST 2009}, Leg{id=34, voyage=Voyage 0200T, loadLocation=New York [USNYC], unloadLocation=Dallas [USDAL], loadTime=Fri Mar 06 00:00:00 EST 2009, unloadTime=Sun Mar 08 00:00:00 EST 2009}, Leg{id=35, voyage=Voyage 0300A, loadLocation=Dallas [USDAL], unloadLocation=Helsinki [FIHEL], loadTime=Mon Mar 09 00:00:00 EDT 2009, unloadTime=Thu Mar 12 00:00:00 EDT 2009}]], of class [class java.util.Arrays$ArrayList], triggered an exception.
Internal Exception: java.lang.reflect.InvocationTargetException
Target Invocation Exception: java.lang.CloneNotSupportedException: java.util.Arrays$ArrayList
at org.eclipse.persistence.exceptions.QueryException.methodInvocationFailed(QueryException.java:838)
at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.invokeCloneMethodOn(InterfaceContainerPolicy.java:245)
at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.cloneFor(InterfaceContainerPolicy.java:98)
at org.eclipse.persistence.mappings.CollectionMapping.buildBackupCloneForPartObject(CollectionMapping.java:186)
at org.eclipse.persistence.internal.indirection.IndirectionPolicy.backupCloneAttribute(IndirectionPolicy.java:74)
at org.eclipse.persistence.internal.indirection.TransparentIndirectionPolicy.backupCloneAttribute(TransparentIndirectionPolicy.java:76)
at org.eclipse.persistence.mappings.ForeignReferenceMapping.buildBackupClone(ForeignReferenceMapping.java:285)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildBackupClone(ObjectBuilder.java:502)
at org.eclipse.persistence.mappings.AggregateMapping.buildBackupClonePart(AggregateMapping.java:125)
at org.eclipse.persistence.mappings.AggregateMapping.buildBackupClone(AggregateMapping.java:114)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildBackupClone(ObjectBuilder.java:502)
at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.buildBackupClone(DeferredChangeDetectionPolicy.java:225)
at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.revertChanges(DeferredChangeDetectionPolicy.java:289)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.resumeUnitOfWork(UnitOfWorkImpl.java:5275)
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.writeChanges(RepeatableWriteUnitOfWork.java:470)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:846)
... 80 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.invokeMethod(PrivilegedAccessHelper.java:409)
at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.invokeCloneMethodOn(InterfaceContainerPolicy.java:240)
... 94 more
Caused by: java.lang.CloneNotSupportedException: java.util.Arrays$ArrayList
at java.lang.Object.clone(Native Method)
... 100 more



 Comments   
Comment by reza_rahman [ 08/Apr/13 11:48 PM ]

I'm not sure if it is causing this issue, but I had to turn off EclipseLink weaving at least for now: http://java.net/jira/browse/GLASSFISH-20209.

Comment by Mitesh Meswani [ 09/Apr/13 02:08 AM ]

This is tracked by corresponding EclipseLink issue - https://bugs.eclipse.org/bugs/show_bug.cgi?id=405226

Comment by reza_rahman [ 09/Apr/13 08:04 PM ]

As suspected, works when weaving is turned back on.

Comment by reza_rahman [ 06/Oct/13 04:03 AM ]

I am getting this same error, but now with GlassFish embedded. Any idea what's going on?

Comment by reza_rahman [ 06/Oct/13 04:13 PM ]

Attaching simple test war demonstrating the resurfacing of this issue in GlassFish embedded, blocking unit testing.

Comment by reza_rahman [ 06/Oct/13 04:21 PM ]

I've attached the simple war demonstrating the issue. The war works fine on the current nightly GlassFish build. It fails with almost all versions of the embedded container. Below is the stack trace (using glassfish-embedded-all-4.0-b92.jar) and the code used for the embedded container:

Local Exception Stack: 
Exception [EclipseLink-6055] (Eclipse Persistence Services - 2.5.0.v20130417-5763b06): org.eclipse.persistence.exceptions.QueryException
Exception Description: The method invocation of the method [protected native java.lang.Object java.lang.Object.clone() throws java.lang.CloneNotSupportedException] on the object [[]], of class [class java.util.Collections$EmptyList], triggered an exception.
Internal Exception: java.lang.reflect.InvocationTargetException
Target Invocation Exception: java.lang.CloneNotSupportedException: java.util.Collections$EmptyList
	at org.eclipse.persistence.exceptions.QueryException.methodInvocationFailed(QueryException.java:839)
	at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.invokeCloneMethodOn(InterfaceContainerPolicy.java:245)
	at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.cloneFor(InterfaceContainerPolicy.java:98)
	at org.eclipse.persistence.mappings.CollectionMapping.buildBackupCloneForPartObject(CollectionMapping.java:186)
	at org.eclipse.persistence.internal.indirection.IndirectionPolicy.backupCloneAttribute(IndirectionPolicy.java:74)
	at org.eclipse.persistence.internal.indirection.TransparentIndirectionPolicy.backupCloneAttribute(TransparentIndirectionPolicy.java:76)
	at org.eclipse.persistence.mappings.ForeignReferenceMapping.buildBackupClone(ForeignReferenceMapping.java:285)
	at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildBackupClone(ObjectBuilder.java:505)
	at org.eclipse.persistence.mappings.AggregateMapping.buildBackupClonePart(AggregateMapping.java:125)
	at org.eclipse.persistence.mappings.AggregateMapping.buildBackupClone(AggregateMapping.java:114)
	at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildBackupClone(ObjectBuilder.java:505)
	at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.buildBackupClone(DeferredChangeDetectionPolicy.java:225)
	at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.revertChanges(DeferredChangeDetectionPolicy.java:289)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.resumeUnitOfWork(UnitOfWorkImpl.java:5275)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.synchronizeAndResume(UnitOfWorkImpl.java:5224)
	at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.synchronizeAndResume(RepeatableWriteUnitOfWork.java:555)
	at org.eclipse.persistence.transaction.AbstractSynchronizationListener.afterCompletion(AbstractSynchronizationListener.java:228)
	at org.eclipse.persistence.transaction.JTASynchronizationListener.afterCompletion(JTASynchronizationListener.java:79)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:557)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:515)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
	at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:493)
	at com.sun.ejb.containers.AbstractSingletonContainer.access$000(AbstractSingletonContainer.java:81)
	at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:654)
	at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:396)
	at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:219)
	at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:180)
	at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:158)
	at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:166)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
	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.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
	at net.java.cargotracker.application.BookingServiceTest.testRegisterNew(BookingServiceTest.java:152)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.invokeMethod(PrivilegedAccessHelper.java:409)
	at org.eclipse.persistence.internal.queries.InterfaceContainerPolicy.invokeCloneMethodOn(InterfaceContainerPolicy.java:240)
	... 70 more
Caused by: java.lang.CloneNotSupportedException: java.util.Collections$EmptyList
	at java.lang.Object.clone(Native Method)
	... 76 more
GlassFish glassfish = GlassFishRuntime.bootstrap().newGlassFish();
glassfish.start();
File war = new File("c:\\temp\\cargo-tracker-test.war");
Deployer deployer = glassfish.getDeployer();
deployer.deploy(war);

It's even worse with glassfish-embedded-all-4.0.1-b01.jar and glassfish-embedded-all-4.0.1-b02.jar - the container can't even be bootstrapped.

Unit testing is all but impossible with these bugs - I think we need to look into what's going on with the embedded container builds quickly...

Comment by qiang.l.liu [ 06/Nov/13 09:00 AM ]

Dynamic Weaving is turned on whenever you run app in full server or embedded mode, unless you explicitly specify "org.glassfish.persistence.embedded.weaving.enabled" to false.

But in your test case(cargo-tracker), it looks like the entities are loaded(by the unit test classes) before the JPA container is deployed. So Weaving don't happen on the entities. You can enable Static Weaving when compiling to work around this issue. If this is a acceptable solution, I can provide the enable-Static-Weaving instructions.

There may be another issue with the test case, which is the http port of embedded server is 8181, but the test case use 8080 instead when run Jersy client. Please see test-ejb-jar.xml.





[GLASSFISH-20232] Flow discovery ordering problem Created: 08/Apr/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 15 minutes
Time Spent: 15 minutes
Original Estimate: 30 minutes

Tags: 4_0-approved
Participants: Ed Burns and shreedhar_ganapathy

 Description   

An app with a Java only flow doesn't work with flow scoped beans.

I have the fix in hand for this already, but am filing this for the sake of the change control process.



 Comments   
Comment by Ed Burns [ 08/Apr/13 10:43 PM ]
  • What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?

Markus Eisele already reported this.

Is it a regression?

No.

Does it meet other bug fix criteria (security, performance, etc.)?

No

What CTS failures are caused by this bug?

None known.

What is the cost/risk of fixing the bug

  • How risky is the fix? How much work is the fix? Is the fix complicated?

Minimal risk.

Is there an impact on documentation or message strings?

No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

None, dev tests are sufficient.

Which is the targeted build of 4.0 for this fix?

TBD

Comment by Ed Burns [ 08/Apr/13 10:45 PM ]

http://java.net/jira/browse/GLASSFISH-20232

SECTION: Modified Files
----------------------------
M jsf-ri/src/main/java/com/sun/faces/flow/FlowHandlerImpl.java

  • Instead of polling the config manager to see if there are flows, use
    the addFlow() method.
Comment by Ed Burns [ 11/Apr/13 04:15 PM ]

This is fixed and will be included in Mojarra 2.2.0-m14, due by COB Monday 15 April 2013.

Comment by shreedhar_ganapathy [ 19/Apr/13 05:09 PM ]

Hi Ed
Did this get integrated?
If yes, can you close this issue?

Comment by Ed Burns [ 19/Apr/13 05:16 PM ]

Integrated in b85





[GLASSFISH-20230] 4.0 Deployment Performance - writing out domain.xml twice for one deployment Created: 08/Apr/13  Updated: 15/Apr/13  Resolved: 15/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: Hong Zhang Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: devx_web 4_0-approved
Participants: Hong Zhang, Masoud Kalali and Tom Mueller

 Description   

In GlassFish 4.0, the initial deployment of a simple web application (after a fresh installation, start domain and deploy) triggers the writing out of the domain.xml twice: the profile collected for GlassFish 4.0 have two invocations of DomainXmlPersistence.save (2 invocations) which took about 5.4% of overall deployment time; whereas in the profile collected for GlassFish 3.1.2, there is one invocation of DomainXmlPersistence.save which took about 3.4% of the time.

In GlassFish 4.0, the first (extra) invocation happens in web container initialization:

In appserver/web/jspcaching-connector/src/main/java/org/glassfish/jspcaching/integration/GlassFishTldProvider.java, postConstruct method

WebContainer webContainer = cfg.getExtensionByType(WebContainer.class);

Then this invokes

./nucleus/admin/config-api/src/main/java/com/sun/enterprise/config/modularity/parser/ModuleConfigurationLoader.java, createConfigBeanForType method which triggers the domain.xml writing.

While this is part of the config modularity feature (aka zero config), based on the discussion with Tom, this should not produce a write of the domain.xml (these changes from config modularity should be just put in memory until there is another transaction that actually changes them).

So we should investigate how we could elimiate this extra domain.xml writing.

The second invocation is expected which happens at the end of the deployment to add the application related entries to the domain.xml.

The other related thing I observed for server start up: in GlassFish 4.0, after I start domain with a fresh installation, the domain.xml.bak will be created. Whereas in GlassFish 3.1.2, I don't see domain.xml.bak get created after the domain is started. Tom confirmed he is seeing the same thing and we don't want to write the domain.xml when we start the server. So we should investigate how we could elimiate this domain.xml writing also.



 Comments   
Comment by Masoud Kalali [ 10/Apr/13 07:15 AM ]
  • What is the impact on the customer of the bug? Deployment time is longer than expected.
  • How likely is it that a customer will see the bug and how serious is the bug? Customer would notice the change in application deployment time if they compare the time between 3.1.2 and 4.0.
  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)? It is a performance related bug.
  • What CTS failures are caused by this bug? No CTS is failing.
  • What is the cost/risk of fixing the bug? No risk, cost is very low.
  • How risky is the fix? How much work is the fix? Is the fix complicated? No risk and cost is very low, a fix is already devised and can be committed after approval process.
  • Is there an impact on documentation or message strings? No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish? None.
  • Which is the targeted build of 4.0 for this fix? 83
  • If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages.
Comment by Hong Zhang [ 10/Apr/13 01:16 PM ]

Masoud: thanks for the quick turn around! Will you fix address the initial deployment and also the issue reported for server start up?

Comment by Tom Mueller [ 10/Apr/13 08:17 PM ]

The initial domain.xml.bak file is created the first time the domain is started as a result of the following modifications to the configuration:

  • managed-job-config
  • batch-runtime-configuration
  • jms-service
  • connector-connection-pool
  • connector-resource
  • resource-ref

These configuration modifications cause the domain.xml to written 6 times, once for each transaction.
Since these changes are written to the domain.xml file, these transactions are not repeated the next time the server is started. However, if these 6 writes are avoided, then these 6 transactions will need to be repeated for every server start, so that may have a performance impact.

So the real concern is the writing of the domain.xml during application deployment. These writes are the result of the following modifications to the configuration:

  • cdi-service
  • web-container
  • 29 changes related to deploying the application

So there are actually 3 writes in 4.0 rather than the 1 write in 3.1.2. Eliminating the writes due to the config modularity changes will correct this problem.

However, if the cdi-service and web-container elements are never written to the domain.xml, then those two transactions will need to be repeated each time the server is started which might have a performance impact.

Comment by Tom Mueller [ 15/Apr/13 12:13 AM ]

Fixed in revision 61422.





[GLASSFISH-20229] drop-and-create does not work Created: 08/Apr/13  Updated: 04/Sep/13  Resolved: 06/May/13

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

Type: Bug Priority: Major
Reporter: reza_rahman Assignee: Mitesh Meswani
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks CARGOTRACKER-1 Make project work on latest GlassFish... In Progress
Tags:
Participants: Mitesh Meswani and reza_rahman

 Description   

javax.persistence.schema-generation-action=drop-and-create does not actually drop tables. This seems to be an issue of EclipseLink not getting a shutdown/undeploy callback from GlassFish in time. I am using the default Derby database through NetBeans.

The app can be found here: http://java.net/projects/cargotracker/downloads.



 Comments   
Comment by Mitesh Meswani [ 08/Apr/13 08:03 PM ]

The behavior is in line with JPA 2.1 specs. Undeployment will not drop the tables.
If you want the classic GlassFish behavior of dropping tables at undeployment, do not use any of javax.persistence.schema-generation* properties and use eclipselink.ddl-generation=drop-and-create-tables

Comment by Mitesh Meswani [ 08/Apr/13 08:04 PM ]

Closing as "works as designed".

Comment by reza_rahman [ 09/Apr/13 08:19 PM ]

Are we sure this is correct? Basically, the behavior I am seeing is that the "drop" part never happens in any circumstances and the behavior is equivalent to "create".

Comment by reza_rahman [ 09/Apr/13 08:24 PM ]

Noting that eclipselink.ddl-generation=drop-and-create-tables does not work either (it used to work sporadically in b76).

Comment by reza_rahman [ 10/Apr/13 02:49 AM ]

Beginning to note a pattern here: eclipselink.ddl-generation=drop-and-create-tables works as long as I explicitly undeploy the app and then shut down GlassFish. If I shutdown without doing an undeploy or if the deploy fails for any reason, things get messed up.

I'll try to see how this behavior translates to javax.persistence.schema-generation.

Comment by Mitesh Meswani [ 10/Apr/13 02:55 AM ]

Beginning to note a pattern here: eclipselink.ddl-generation=drop-and-create-tables works as long as I explicitly undeploy the app and then shut down GlassFish. If I shutdown without doing an undeploy or if the deploy fails for any reason, things get messed up

When using eclipselink.ddl-generation property, the drop happens at undeploy/redeploy (and not shutdown of appsrever). Can you please clarify (1) what do you mean by "If I shutdown without doing undeploy.." (2) When/how does undeploy fail?

Comment by reza_rahman [ 10/Apr/13 03:04 AM ]

OK, that helps in understanding what might be going on.

By shutting down the server without an undeploy, I mean just hitting the [X] button on the NetBeans GlassFish console output panel. To undeploy before shutting down, you have to go to "Services", select the GlassFish instance, select Applications and then undeploy the application.

When I just do a shutdown, things get really messed up and drop-create stops working correctly.

I've actually not seen the undeploy fail yet. Because my application is being actively developed, things don't always deploy. When the deploy fails (even once), things seem to get really messed up too.

I'll experiment some more and confirm these patterns for sure so you can replicate them.

Comment by reza_rahman [ 11/Apr/13 04:26 PM ]

Confirming the pattern: with eclipselink.ddl-generation=drop-and-create-tables the drop stops working if the server is shutdown and the app is not undeployed explicitly first. The drop also stops working if there is a deployment error. Once things stop working, a redeploy does not help - the only option is to wipe the database manually.

Will look into javax.persistence.schema-generation* next.

Comment by reza_rahman [ 11/Apr/13 05:31 PM ]

I have not been able to get the standard schema generation drop to work at all. Here is what I have:

<property name="javax.persistence.schema-generation.database.action"
value="drop-and-create" />
<property name="javax.persistence.schema-generation.create-database-schemas"
value="true" />

Any guidance is appreciated, I'd prefer to stick to the standard for this application. To get a copy of the application, please email me at reza.rahman@oracle.com.

Comment by Mitesh Meswani [ 25/Apr/13 06:56 PM ]

Fixed with recent integration of EclipseLink

Comment by reza_rahman [ 04/May/13 06:25 PM ]

It still does not work for me on build 87.

Comment by reza_rahman [ 04/May/13 09:03 PM ]

Still does not work. The problems seems to be that constraints aren't dropped before tables are wiped?

Comment by Mitesh Meswani [ 06/May/13 06:02 PM ]

Reza and me discussed this and it looks like this might be a NetBeans issue. During Reza's workflow, NetBeans indicates that app is being redeployed however it actually does not happen and hence tables are not being dropped. Marking the bug as FIXED. Reza will open a separate bug against NetBeans





[GLASSFISH-20221] cdi tck test failing org.jboss.cdi.tck.tests.deployment.initialization.ApplicationInitializationLifecycleTest 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_b85

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

Tags:
Participants: jjsnyder83

 Description   

Failing on Weld 2.0.0.CR1



 Comments   
Comment by jjsnyder83 [ 10/Apr/13 09:20 PM ]

Committed revision 61355





[GLASSFISH-20220] cdi tck test failing org.jboss.cdi.tck.tests.deployment.discovery.enterprise.EnterpriseBeanDiscoveryTest Created: 08/Apr/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

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

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

Tags:
Participants: jjsnyder83

 Description   

Failing on Weld 2.0.0.CR1

Should be fixed when Phil commits changes for session beans being bean-defining.



 Comments   
Comment by jjsnyder83 [ 11/Apr/13 02:10 AM ]

Committed revision 61359.

Comment by jjsnyder83 [ 11/Apr/13 02:16 AM ]

testImplicitBeanArchiveModeNone is failing again





[GLASSFISH-20219] cdi tck test failing org.jboss.cdi.tck.tests.deployment.discovery.BeanDiscoveryTest 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_b85

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

Tags:
Participants: jjsnyder83

 Description   

Failing on Weld 2.0.0.CR1



 Comments   
Comment by jjsnyder83 [ 10/Apr/13 02:43 PM ]

Implicit bdas are built incorrectly. Phil is fixing.

Also retest the following tests when this is fixed:
org.jboss.cdi.tck.tests.definition.bean.custom.CustomBeanImplementationTest

Comment by jjsnyder83 [ 10/Apr/13 08:43 PM ]

committed 61350





[GLASSFISH-20215] No endpoint for creating SSL for protocol Created: 08/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

Status: Resolved
Project: glassfish
Component/s: rest-interface
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: New Feature Priority: Major
Reporter: Anissa Lam Assignee: Jason Lee
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: console 4_0-approved
Participants: Anissa Lam, Jason Lee and Tom Mueller

 Description   

In fixing GLASSFISH-18111, Ryan has added an option for type to take in protocol , so that SSL can be created for the protocol.
For example, one can create a protocol and then create the <ssl> for it.

%asadmin create-protocol TEST1
%asadmin create-ssl --certname s1as --type protocol TEST1

However, there is no endpoint for creating ssl for a protocol.
There is one for creating ssl for network-listener
http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener/http-listener-1/create-ssl

but not something like this:
http://localhost:4848/management/domain/configs/config/server-config/network-config/protocols/protocol/myProtocol/create-ssl



 Comments   
Comment by Jason Lee [ 08/Apr/13 10:31 PM ]

I've added the @RestEndpoint mappings. I'll run tests and start change control in the morning.

Comment by Jason Lee [ 09/Apr/13 03:40 PM ]
  • What is the impact on the customer of the bug?
    Without this change, parts of the console will not work
  • What is the cost/risk of fixing the bug?
    Minimal. The change just adds metadata annotations
  • How risky is the fix? How much work is the fix? Is the fix complicated?
    Not very.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Admin Dev Tests
  • Which is the targeted build of 4.0 for this fix?
    b86
Index: admin/util/src/main/java/com/sun/enterprise/admin/commands/CreateSsl.java
===================================================================
--- admin/util/src/main/java/com/sun/enterprise/admin/commands/CreateSsl.java	(revision 61229)
+++ admin/util/src/main/java/com/sun/enterprise/admin/commands/CreateSsl.java	(working copy)
@@ -104,6 +104,14 @@
         params={
             @RestParam(name="id", value="$parent"),
             @RestParam(name="type", value="http-listener")
+        }),
+    @RestEndpoint(configBean=Protocol.class,
+        opType=RestEndpoint.OpType.POST, 
+        path="create-ssl", 
+        description="create-ssl",
+        params={
+            @RestParam(name="id", value="$parent"),
+            @RestParam(name="type", value="protocol")
         })
 })
 public class CreateSsl implements AdminCommand {
@@ -146,6 +154,7 @@
      *
      * @param context information
      */
+    @Override
     public void execute(AdminCommandContext context) {
         final ActionReport report = context.getActionReport();
         Target targetUtil = habitat.getService(Target.class);
@@ -198,6 +207,7 @@
         Protocol protocol = networkConfig.findProtocol(name);
         if (protocol == null && create) {
             protocol = (Protocol) ConfigSupport.apply(new SingleConfigCode<Protocols>() {
+                @Override
                 public Object run(Protocols param) throws TransactionFailure {
                     Protocol newProtocol = param.createChild(Protocol.class);
                     newProtocol.setName(name);
@@ -241,6 +251,7 @@
         }
         try {
             ConfigSupport.apply(new SingleConfigCode<JmxConnector>() {
+                @Override
                 public Object run(JmxConnector param)
                     throws PropertyVetoException, TransactionFailure {
                     Ssl newSsl = param.createChild(Ssl.class);
Comment by Tom Mueller [ 09/Apr/13 03:49 PM ]

Approved for 4.0.

Comment by Jason Lee [ 09/Apr/13 03:53 PM ]

Change committed (r61249).





[GLASSFISH-20214] cdi tck test org.jboss.cdi.tck.tests.implementation.simple.resource.broken.type.ws.ResourceDefinitionWithDifferentTypeTest failing Created: 08/Apr/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

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

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

Tags:
Participants: jjsnyder83

 Description   

When a web service app fails deployment in cdi it's causing NPE's in various places in web service container load/unload.






[GLASSFISH-20210] Unable to lookup concurrent/__defaultManagedExecutorService from batch connector Created: 07/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Closed
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: Mahesh Kannan Assignee: anthony.lai
Resolution: Works as designed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-20196 BATCH CLI: asadmin set-batch-runtime-... Resolved
Tags:
Participants: anthony.lai and Mahesh Kannan

 Description   

I am seeing something strange. I am not sure if the issue that I am seeing is due to 20205 or not:

The batch runtime uses concurrent/__defaultManagedExecutorService to get hold of a ManagedExecutorService. With the
latest build I am unable to do a jndi lookup using:
(new InitialContext()).lookup(" concurrent/__defaultManagedExecutorService");

However, (new InitialContext()).lookup("java:comp/DefaultManagedExecutorService") is working.

I think we should allow the direct lookup of concurrent/__defaultManagedExecutorService.

Here is the stack trace I am seeing:

javax.naming.NamingException: Lookup failed for 'concurrent/__defaultManagedExecutorService' 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} [Root exception is javax.naming.NameNotFoundException: concurrent]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at org.glassfish.batch.spi.impl.BatchRuntimeHelper.lookupExecutorService(BatchRuntimeHelper.java:237)
at org.glassfish.batch.spi.impl.BatchRuntimeHelper.access$200(BatchRuntimeHelper.java:76)
at org.glassfish.batch.spi.impl.BatchRuntimeHelper$GlassFishBatchExecutorServiceProvider.getExecutorService(BatchRuntimeHelper.java:216)
at com.ibm.jbatch.container.services.impl.SPIDelegatingThreadPoolServiceImpl.executeTask(SPIDelegatingThreadPoolServiceImpl.java:43)
at com.ibm.jbatch.container.impl.BatchKernelImpl.startJob(BatchKernelImpl.java:135)
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:105)
at com.oracle.javaee7.samples.batch.api.PayrollJobSubmitterServlet.submitJobFromXML(PayrollJobSubmitterServlet.java:163)
at com.oracle.javaee7.samples.batch.api.PayrollJobSubmitterServlet.processRequest(PayrollJobSubmitterServlet.java:97)
at com.oracle.javaee7.samples.batch.api.PayrollJobSubmitterServlet.doGet(PayrollJobSubmitterServlet.java:178)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)



 Comments   
Comment by anthony.lai [ 09/Apr/13 05:00 PM ]

Does the suggestion from Tom work for you:

Since "concurrent/__defaultManagedExecutorService" is (or should be) a private interface, why does the batch runtime depend on it? Can we make the batch runtime depend on java:comp/DefaultManagedExecutorService which is a standard interface?

If you really need to look up concurrent/__defaultManagedExecutorService directory, then it is possible to @Inject DefaultManagedExecutorService before doing the access which will force the former to be created.

Comment by anthony.lai [ 10/Apr/13 11:27 PM ]

GLASSFISH-20196 has been fixed by injecting ManagedExecutorService.ManagedExecutorServiceConfigActivator





[GLASSFISH-20208] Edit Thread Pool requires class name, but none is provided/shown on web gui Created: 06/Apr/13  Updated: 12/Apr/13  Resolved: 12/Apr/13

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: pbelbin Assignee: oleksiys
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 7 x64 jdk 7 u 17


Tags: console 4_0-approved
Participants: Anissa Lam, oleksiys and pbelbin

 Description   

configurations/server-config/thread pools/http-thread-pool

detail pane is shown with no class name value, and this appears to be a mandatory value in order to save any changes.

therefore I am unable to make any changes, as gui refuses to allow save of values.



 Comments   
Comment by Anissa Lam [ 06/Apr/13 10:12 PM ]

This seems to be a change in the grizzly code.

In 3.x, there is a default classname for thread pool, and thats whats displayed in the console.
~/GF/3.1.2/gf-pb23/glassfish/bin 88) asadmin get configs.config.server-config.thread-pools.thread-pool.http-thread-pool
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.classname=com.sun.grizzly.http.StatsThreadPool
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.idle-thread-timeout-seconds=900
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.max-queue-size=4096
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.max-thread-pool-size=5
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.min-thread-pool-size=2
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.name=http-thread-pool
Command get executed successfully.

However, in 4.0, this classname is gone.

~/Awork/GF/glassfish4/glassfish/bin 147) asadmin get configs.config.server-config.thread-pools.thread-pool.http-thread-pool
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.idle-thread-timeout-seconds=900
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.max-queue-size=4096
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.max-thread-pool-size=5
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.min-thread-pool-size=5
configs.config.server-config.thread-pools.thread-pool.http-thread-pool.name=http-thread-pool
Command get executed successfully.

Notice that the min-thread-pool-size is also changed.

There is no notification to the GUI team about the classname change. I am not sure whats the intended change. If this is a bug or this is by design for 4.0

Transfer to Grizzly team. If classname is not needed and should not be displayed, reassign to admin-gui so i can make the change.

Comment by oleksiys [ 12/Apr/13 11:42 PM ]

fixed

Repository: svn
Revision: 61410
Date: 2013-04-12 23:41:42 UTC

Log Message:
------------
+ fix issue #20208
http://java.net/jira/browse/GLASSFISH-20208
"Edit Thread Pool requires class name, but none is provided/shown on web gui"

integrating Grizzly 2.3.1





[GLASSFISH-20194] BATCH CLI: asadmin set-batch-runtime-configuration without options doesn't seems valid Created: 05/Apr/13  Updated: 07/Apr/13  Resolved: 07/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: Bug Priority: Minor
Reporter: arunkumar_s Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arunkumar_s and Mahesh Kannan

 Description   

Tested with latest nightly.

asadmin set-batch-runtime-configuration
Command set-batch-runtime-configuration executed successfully.

The above command doesn't make any sense. The command must have operand -x or(and) -d



 Comments   
Comment by Mahesh Kannan [ 07/Apr/13 02:46 PM ]

Fixed.

svn commit -m "Fix for 20194, and partial fix for 20196. QL Passed"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/SetBatchRuntimeConfiguration.java
Sending batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Adding batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/GlassFishBatchValidationException.java
Transmitting file data ...
Committed revision 61217.





[GLASSFISH-20183] Compilation warning in web-core Created: 04/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: Shing Wai Chan

 Description   

While compiling web-core, we see the following:

[WARNING] /export/gf4/src/all/main/appserver/web/web-core/src/main/java/org/apache/catalina/loader/WebappLoader.java:[952,18] [unchecked] unchecked conversion
[WARNING] required: PrivilegedExceptionAction<T>
found: <anonymous PrivilegedExceptionAction>
where T is a type-variable:
T extends Object declared in method <T>doPrivileged(PrivilegedExceptionAction<T>)
/export/gf4/src/all/main/appserver/web/web-core/src/main/java/org/apache/catalina/loader/WebappLoader.java:[951,41] [unchecked] unchecked method invocation: method doPrivileged in class AccessController is applied to given types
[WARNING] required: PrivilegedExceptionAction<T>
found: <anonymous PrivilegedExceptionAction>
where T is a type-variable:
T extends Object declared in method <T>doPrivileged(PrivilegedExceptionAction<T>)

The above new code is introduced in svn 61113 for GlassFish-20035.

Adding generic will solve the issue.



 Comments   
Comment by Shing Wai Chan [ 04/Apr/13 10:58 PM ]
  • What is the impact on the customer of the bug?
    No.
  • What is the cost/risk of fixing the bug?
    Add generic. It is a one line change.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    No.
  • Which is the targeted build of 4.0 for this fix?
    4.0_b85
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A
Comment by Shing Wai Chan [ 04/Apr/13 11:27 PM ]

Sending web-core/src/main/java/org/apache/catalina/loader/WebappLoader.java
Transmitting file data .
Committed revision 61182.

Comment by Shing Wai Chan [ 05/Apr/13 05:59 PM ]

I also notice the following compilation warning in war-util.

WARNING] /export/gf4/src/all/main/appserver/web/war-util/src/main/java/com/sun/enterprise/glassfish/web/WarHandler.java:[217,24] [unchecked] unchecked conversion
[WARNING] required: PrivilegedExceptionAction<T>
found: SetPermissionsAction
where T is a type-variable:
T extends Object declared in method <T>doPrivileged(PrivilegedExceptionAction<T>)

It is also a generic issue.
The fix is in security module as follows:
Revisions:
----------
61203

Modified Paths:
---------------
trunk/main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/perms/PermsArchiveDelegate.java





[GLASSFISH-20165] Final integration for JMS RI, to version 2.0 Created: 04/Apr/13  Updated: 17/Apr/13  Due: 15/Apr/13  Resolved: 17/Apr/13

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

Type: Bug Priority: Major
Reporter: Ed Bratt Assignee: Jill Sato
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation 4_0-approved
Participants: Ed Bratt, Jill Sato and michael.y.chen

 Description   

Tracking issue for final JMS integration. Any show-stopper bugs will be linked to this issue. As of this date, the only change planned is to bump the revision to 2.0. Corresponding maven artifacts as well as RI binary and source bundles will be created from this build.

Information for the 4.0 bug review process:

What is the impact on the customer of the bug?
Should be minimal if no other issues are attached.

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?

Required to bring the API serial ID to 2.0

What is the cost/risk of fixing the bug?

Minimal. Tests have already been performed to assure this build will complete as planned.

Is there an impact on documentation or message strings?

No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

MQ QA will verify, prior to final integration into GlassFish RI / 4.0

Which is the targeted build of 4.0 for this fix?

Build 86 (RC2)



 Comments   
Comment by michael.y.chen [ 04/Apr/13 04:01 AM ]

This is approved. I thought Nigel wants to integ during build 85 or build 86 rather than build 84 since he wants to see the ballot results for other specs.

Comment by Ed Bratt [ 04/Apr/13 01:49 PM ]

This will be build 86. I have corrected the description

Comment by Jill Sato [ 04/Apr/13 03:59 PM ]

I just want to clarify that for the "final" JMS integration, we will be updating:
MQ 5.0 b15
and
JMS 2.0

Comment by Jill Sato [ 17/Apr/13 06:03 PM ]

JMS 2.0 (final) and MQ 5.0 b14 has been integrated into GF.





[GLASSFISH-20163] configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.max-save-post-size-bytes has no effect Created: 04/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: Shing Wai Chan

 Description   

The maxSavePostSize is introduced to configure the max save post size internally.
The Grizzly configure max-save-post-size-bytes in 2.3.

We suppose to configure it as follows:
asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.max-save-post-size-bytes=5000

And the above Grizzly code has been integrated April 2 evening.
The web container has not invoke the setter in the backend even though it is set in asadmin.



 Comments   
Comment by Shing Wai Chan [ 04/Apr/13 01:11 AM ]
  • What is the impact on the customer of the bug?
    Cannot configure the MaxSavePostSize. The default is 4*1024.
  • What is the cost/risk of fixing the bug?
    Just get the value from config and set it to connector. I have already fixed a fix locally.
  • Is there an impact on documentation or message strings?
    Yes, please add the information about this attribute.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE pe/web
  • Which is the targeted build of 4.0 for this fix?
    4.0_b85
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A
Comment by Shing Wai Chan [ 04/Apr/13 04:09 PM ]

Sending web-glue/src/main/java/com/sun/enterprise/web/connector/coyote/PECoyoteConnector.java
Transmitting file data .
Committed revision 61167.





[GLASSFISH-20142] Accessing an @Inject JMSContext in a @ServerEndpoint leads to org.jboss.weld.context.ContextNotActiveException Created: 03/Apr/13  Updated: 17/Apr/13  Resolved: 17/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: myfear Assignee: jjsnyder83
Resolution: Cannot Reproduce Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 1.7_15
Win7 x64


Tags: fishcat
Participants: jjsnyder83 and myfear

 Description   

The example app is here: https://www.dropbox.com/s/n8uhy2uka8p5vo4/websockets-demo.zip

launch with button click from here: http://localhost:8080/websockets-demo/

org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:662)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:74)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:82)
at org.glassfish.jms.injection.RequestedJMSContextManager$Proxy$_$$_WeldClientProxy.getType(Unknown Source)
at org.glassfish.jms.injection.InjectableJMSContext.delegate(InjectableJMSContext.java:121)
at org.glassfish.jms.injection.ForwardingJMSContext.createProducer(ForwardingJMSContext.java:61)
at net.eisele.samples.websockets.demo.HelloEndpoint.boradcastMessage(HelloEndpoint.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:431)
at org.glassfish.tyrus.core.AnnotatedEndpoint.access$100(AnnotatedEndpoint.java:83)
at org.glassfish.tyrus.core.AnnotatedEndpoint$WholeHandler$1.onMessage(AnnotatedEndpoint.java:518)
at org.glassfish.tyrus.core.SessionImpl.notifyMessageHandlers(SessionImpl.java:305)
at org.glassfish.tyrus.core.EndpointWrapper.onMessage(EndpointWrapper.java:462)
at org.glassfish.tyrus.server.TyrusEndpoint.onMessage(TyrusEndpoint.java:163)
at org.glassfish.tyrus.websockets.DefaultWebSocket.onMessage(DefaultWebSocket.java:138)
at org.glassfish.tyrus.websockets.frametypes.TextFrameType.respond(TextFrameType.java:66)
at org.glassfish.tyrus.websockets.DataFrame.respond(DataFrame.java:102)
at org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler.onDataAvailable(TyrusHttpUpgradeHandler.java:113)
at org.apache.catalina.connector.InputBuffer$ReadHandlerImpl.processDataAvailable(InputBuffer.java:472)
at org.apache.catalina.connector.InputBuffer$ReadHandlerImpl.onDataAvailable(InputBuffer.java:440)
at org.glassfish.grizzly.http.io.InputBuffer.append(InputBuffer.java:854)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:222)
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)



 Comments   
Comment by jjsnyder83 [ 11/Apr/13 09:25 PM ]

Please email me the zip...I cannot open the attached zip: j.j.snyder@oracle.com

Comment by jjsnyder83 [ 17/Apr/13 06:16 PM ]

I could not reproduce the error. When I clicked on the link I got:

Hello World!





[GLASSFISH-20140] BATCH CLI: asadmin list-batch-job-executions <instanceid> with a running job instance id not shows the job execution details Created: 03/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arunkumar_s and Mahesh Kannan

 Description   

Tested with latest nightly b83.

1) Start any job
2) Get the instance id of the currently running job(instanceid)
3) In CLI asadmin list-batch-job-executions -l <instanceid>

Issue: Command executed successfully, but no job executions displayed. May be if not possible to display running job execution details, user should get some error message.

Same case for asadmin list-batch-job-steps -l <executionid>(of a running Job)



 Comments   
Comment by Mahesh Kannan [ 03/Apr/13 08:16 AM ]

Nice catch! For running jobs, jobExecution.getEndTime() returns null causing an NPE in CLI.
Will fix it tomorrow.

Comment by Mahesh Kannan [ 04/Apr/13 04:02 PM ]

This is resovled. Basically, for a running job, the end time returns null and hence the NPE.

svn commit -m "Integrate b23 jars for Batch. Also fix GlassFish-20139 and GlassFish-20140. QL Passed"
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/GlassFishBatchSecurityHelper.java
Sending appserver/pom.xml
Transmitting file data ......
Committed revision 61166.





[GLASSFISH-20139] BATCH CLI: asadmin list-batch-jobs not listing batch jobs when any job is running Created: 03/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arunkumar_s and Mahesh Kannan

 Description   

Tested with latest nightly b83

1) Start any batch job
2) In CLI run asadmin list-batch-jobs -l

Issue --> Command executed successfully, but no jobs displayed.



 Comments   
Comment by arunkumar_s [ 03/Apr/13 07:09 AM ]

same case for list-batch-job-executions -l when any job process running.

Comment by Mahesh Kannan [ 03/Apr/13 08:17 AM ]

Same root cause as 20140

Comment by Mahesh Kannan [ 04/Apr/13 04:02 PM ]

This is resovled. Basically, for a running job, the end time returns null and hence the NPE.

svn commit -m "Integrate b23 jars for Batch. Also fix GlassFish-20139 and GlassFish-20140. QL Passed"
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/GlassFishBatchSecurityHelper.java
Sending appserver/pom.xml
Transmitting file data ......
Committed revision 61166.





[GLASSFISH-20136] Installer sets AS_JAVA incorrectly and other JDK related problems Created: 03/Apr/13  Updated: 17/Apr/13  Resolved: 17/Apr/13

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: Tom Mueller Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Tags: 4_0-approved
Participants: Snjezana Sevo-Zenzerovic and Tom Mueller

 Description   

When running the installer for the b82 web profile, I'm seeing the following behavior related to the JDK selection page.

1. The installer is not finding the version of JDK 7 that I have installed. I have both a C:\Program Files (x86)\Java directory and a C:\Program Files\Java directory. In the latter is the jdk1.7.0_17 directory, the only valid JDK for GF 4 that I have on my system. The installer says it could not find a valid JDK and that I must choose one using the 2nd radio button.

2. I choose the jdk1.7.0_17 directory and the installer continues but is unable to create the domain. The installer says that the configuration was completed successfully even though the domain creation failed.

3. In the glassfish\config\asenv.bat file, I have the following line:

set AS_JAVA=C:\Program Files (x86)\Java

which is incorrect. This cause asadmin to not function correctly.

4. The uninstall fails with an error about not being able to find the required version of the JDK in the directory listed in (3).



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 11/Apr/13 02:30 PM ]

Item 1. is caused by openInstaller framework's limited ability to reliably detect all Windows JDK installations, especially 64 bit JDK installations. At this point we can't do much about this since we really need to extend openInstaller JDK handling interfaces. This part will have to be deferred to future release.

Items 2. and 3. are due to the fact that installer logic still does not always pick up explicitly provided JDK location in typical installation scenario and incorrectly falls back on the parent directory of the JDK used for installer runtime . This is handled in GlassFish specific install configuration code and will be fixed

Item 4. is side effect of 3. so will be implicitly fixed.

Comment by Snjezana Sevo-Zenzerovic [ 11/Apr/13 02:34 PM ]
  • What is the impact on the customer of the bug?

Not a regression, but issues are becoming more visible and prominent for newer Windows releases. There is significant usability impact on Windows installation since JDK selection is not reliable and subsequent default domain creation and product runtime are severely affected.

  • What is the cost/risk of fixing the bug?

openInstaller related part of the fix will be deferred due to relatively high cost and risk. However, changes to GlassFish installer configuration code are low/moderate risk .

  • Is there an impact on documentation or message strings?

No.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Regular Windows installer testing should be sufficient to identify regressions. Some FishCat program participants cover this functionality, too.

  • Which is the targeted build of 4.0 for this fix?

b85

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

N/A

Comment by Tom Mueller [ 11/Apr/13 05:20 PM ]

Approved for 4.0. Please create a separate issue for #1 and add a comment to this issue with the number of the issue.

Comment by Snjezana Sevo-Zenzerovic [ 17/Apr/13 10:07 AM ]

Filed issue GLASSFISH-20330 to track the first item. Other items addressed in b85.





[GLASSFISH-20123] OSGi meta-information incorrect Created: 26/Mar/13  Updated: 16/Apr/13  Resolved: 16/Apr/13

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 11 hours, 11 minutes
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: Ed Burns and Tom Mueller

 Description   

Bill Shannon's tool showed up some errors in our OSGi metadata in the org.glassfish:javax.faces:2.2.0-m12 jar. These need to be fixed before M13.

>>>>> On Tue, 26 Mar 2013 11:57:08 -0700 (PDT), Bill Shannon said:

EB> Hello Bill,
EB>
EB> To that end, can you please check:
EB>
EB> https://maven.java.net/index.html#nexus-search;gav~org.glassfish~javax.faces~2.2.0-m12~~
EB>
EB> and
EB>
EB> https://maven.java.net/index.html#nexus-search;gav~javax.faces~javax.faces-api~2.2-m12~~

B> Here's the errors I get:

B> API jar file: javax.faces-api.jar
B> OSGi Bundle-SymbolicName: javax.faces-api
B> OSGi bundle specversion: 2.1.99.m12
B> OSGi Bundle-Version: 2.1.99.m12
B> Maven group ID, artifact ID: javax.faces:javax.faces-api
B> Maven version: 2.2-m12
B> Maven API jar file: javax.faces-api-2.2-m12.jar
B> Jar Extension-Name: javax.faces
B> jar Specification-Version: 2.1.99.12
B> jar Implementation-Version: 2.2-m12

B> Implementation jar file: javax.faces.jar
B> OSGi Bundle-SymbolicName: org.glassfish.javax.faces
B> OSGi bundle specversion: 2.1.99.m12
B> OSGi Bundle-Version: 2.1.99.m12
B> Maven group ID, artifact ID: org.glassfish:javax.faces
B> Maven version: 2.2.0-m12
B> Maven impl jar file: javax.faces-2.2.0-m12.jar
B> jar Extension-Name: javax.faces
B> jar Specification-Version: 2.1.99.12
B> jar Implementation-Version: 2.2.0-m12

B> Checking API jar file:
B> https://maven.java.net/content/repositories/public/javax/faces/javax.faces-api/2.2-m12/javax.faces-api-2.2-m12.jar
B> ERROR: Attribute Bundle-Version is 2.2 but should be 2.1.99.m12
B> ERROR: Attribute Specification-Version is 2.2 but should be 2.1.99.12
B> ERROR: Attribute Implementation-Version is 2.2 but should be 2.2-m12

B> Checking implementation jar file:
B> https://maven.java.net/content/repositories/public/org/glassfish/javax.faces/2.2.0-m12/javax.faces-2.2.0-m12.jar
B> ERROR: Attribute Bundle-Version is 2.2.0.m12-SNAPSHOT but should be 2.1.99.m12
B> ERROR: Attribute Specification-Version is 2.2 but should be 2.1.99.12
B> ERROR: Attribute Implementation-Version is 2.2.0-m12-SNAPSHOT but should be
B> 2.2.0-m12
B> WARNING: jar file includes class in wrong package: com.sun.faces.renderkit

B> And lots more warnings like that, which you can ignore.
B> But the errors should be fixed.



 Comments   
Comment by Ed Burns [ 29/Mar/13 06:59 PM ]

Now, looking in the MANIFEST.MF for javax.faces-2.2.0-m12.jar, I don't
see the string "99" in there at all. Why should the Bundle-Version be
2.1.99.m12?

B> ERROR: Attribute Specification-Version is 2.2 but should be 2.1.99.12

The version of the JSF spec is indeed 2.2, so why should it be
2.1.99.12?

B> ERROR: Attribute Implementation-Version is 2.2.0-m12-SNAPSHOT but should be
B> 2.2.0-m12

Does this mean that the Implementation-Version should exactly match the
<version> of the pom associated with this jar artifact?

B> WARNING: jar file includes class in wrong package: com.sun.faces.renderkit

I'm not sure how to resolve this one.

I see that your calendar says you are not available til 4pm today and I
will be unavailable at that time. Can you please leve me as detailed
instructions as you can saying how I should fix my jar so that the
2.2.0-m13, which we plan to generate Monday, will pass muster with your
tool?

Comment by Ed Burns [ 29/Mar/13 10:08 PM ]

Patch
Index: jsf-ri/build.xml
===================================================================
— jsf-ri/build.xml (revision 11823)
+++ jsf-ri/build.xml (working copy)
@@ -659,32 +659,57 @@

<target name="jars" depends="compile">

+<!--
+
+https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules
+
+The Maven and OSGi Packaging and Naming Guidelines state that for
+non-final artifacts a value "less than" the final version number
+must be used for all OSGi version numbers. The inputs to this build
+script take final version numbers. It would be nice if we could
+derive the "less than" values programmatically.
+
+For example, if ${impl.version.number} is 2.2.0-m12, the value should be
+2.1.99.m12. The Maven and OSGi versioning rules say the numeric value
+should be "less than" the final release version number until the product
+is actually final. Thus, 2.1.99 is the closest thing 2.2.0 that is
+still less than 2.2.0. They also say you should not have dashes in the
+value, hence the "-" gets replaced with ".".
+
+Unfortunately, this is difficult to accomplish with ant, so we will hard
+code the values for now. These values must be updated whenever we release
+a new version.
+
+-->
+
<copy file="${basedir}/mojarra-jsf-impl.bnd" tofile="tmp.bnd"/>
+
+<!-- start of properties that must be update when incrementing version numbers -->
+
+<!-- Spec version is something like 2.2 -->
+
<replace file="tmp.bnd"
token="@spec.version@"
- value="${spec.version}"/>
+ value="2.1.99.13"/>
+
+<!-- osgi.version is based on impl.version.number, which is something like
+ 2.2.0-m12 -->
+
<replace file="tmp.bnd"
+ token="@osgi.version@"
+ value="2.1.99.m13"/>
+
+<!-- end of properties that must be update when incrementing version numbers -->
+
+ <replace file="tmp.bnd"
token="@impl.name@"
value="${impl.name}"/>
<replace file="tmp.bnd"
token="@impl.version@"
- value="${impl.version}"/>
+ value="${impl.version.number}"/>
<replace file="tmp.bnd"
token="@full.impl.version@"
value="${full.impl.version} ${svn.revision.url}"/>
- <if>
- <equals arg1="${build.type}" arg2=""/>
- <then>
- <replace file="tmp.bnd"
- token="@osgi.version@"
- value="${impl.version.number}"/>
- </then>
- <else>
- <replace file="tmp.bnd"
- token="@osgi.version@"
- value="${impl.version.number}${build.type}"/>
- </else>
- </if>
<replace file="tmp.bnd"
token="@extension.name@"
value="javax.faces"/>
Index: jsf-api/build.xml
===================================================================
— jsf-api/build.xml (revision 11823)
+++ jsf-api/build.xml (working copy)
@@ -629,32 +629,58 @@
-->
<target name="jars" depends="build">

+<!--
+
+https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules
+
+The Maven and OSGi Packaging and Naming Guidelines state that for
+non-final artifacts a value "less than" the final version number
+must be used for all OSGi version numbers. The inputs to this build
+script take final version numbers. It would be nice if we could
+derive the "less than" values programmatically.
+
+For example, if ${impl.version.number} is 2.2.0-m12, the value should be
+2.1.99.m12. The Maven and OSGi versioning rules say the numeric value
+should be "less than" the final release version number until the product
+is actually final. Thus, 2.1.99 is the closest thing 2.2.0 that is
+still less than 2.2.0. They also say you should not have dashes in the
+value, hence the "-" gets replaced with ".".
+
+Unfortunately, this is difficult to accomplish with ant, so we will hard
+code the values for now. These values must be updated whenever we release
+a new version.
+
+-->
+
<copy file="${basedir}/mojarra-jsf-api.bnd" tofile="tmp.bnd"/>
+
+<!-- start of properties that must be update when incrementing version numbers -->
+
+<!-- Spec version is something like 2.2 -->
+
<replace file="tmp.bnd"
token="@spec.version@"
- value="${spec.version}"/>
+ value="2.1.99.13"/>
+
+<!-- osgi.version is based on impl.version.number, which is something like
+ 2.2.0-m12 -->
+
<replace file="tmp.bnd"
+ token="@osgi.version@"
+ value="2.1.99.m13"/>
+
+ <replace file="tmp.bnd"
+ token="@impl.version@"
+ value="2.2-m13"/>
+
+<!-- end of properties that must be update when incrementing version numbers -->
+
+ <replace file="tmp.bnd"
token="@impl.name@"
value="${impl.name}"/>
<replace file="tmp.bnd"
- token="@impl.version@"
- value="${impl.version}"/>
- <replace file="tmp.bnd"
token="@full.impl.version@"
value="${full.impl.version}"/>

  • <if>
  • <equals arg1="${build.type}" arg2=""/>
    - <then>
    - <replace file="tmp.bnd"
    - token="@osgi.version@"
    - value="${impl.version.number}"/>
    - </then>
    - <else>
    - <replace file="tmp.bnd"
    - token="@osgi.version@"
    - value="${impl.version.number}${build.type}"/>
  • </else>
  • </if>
    <replace file="tmp.bnd"
    token="@extension.name@"
    value="javax.faces"/>
    @@ -922,7 +948,7 @@

<target name="mvn.deploy.release.local" depends="strip.api.jar">
<mvn.deploy.release.local type="api"

  • version="${spec.version}"/>
    + version="${spec.version}-m13"/>
    </target>

<target name="strip.api.jar"

Comment by Ed Burns [ 01/Apr/13 04:30 PM ]

Found this problem when deploying a simple war after using the Mojarra with this fix applied:

Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.main.web.weld-integration [274]: Unable to resolve 274.0: missing requirement [274.0] osgi.wiring.package; (&(osgi.wiring.package=com.sun.faces.spi)(version>=2.2.0)(!(version>=3.0.0)))
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2037)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:210)
... 66 more
MultiException stack 2 of 2

Because of this problem, I am going to revert r11824 and re-open the bug.

Comment by Ed Burns [ 02/Apr/13 09:58 PM ]
  • What is the impact on the customer of the bug?

Milestone builds are using final version numbers for OSGi meta-information.

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?

If the customer uses a milestone build it will not have an "older" OSGi meta-information set than the final release build.

  • What is the cost/risk of fixing the bug?

Low because an incorrectly implemented fix will cause apps to fail to deploy.

How risky is the fix? How much work is the fix? Is the fix complicated?

The only complexity of this fix is how it relates to the jsf integration module in GlassFish.

  • Is there an impact on documentation or message strings?

No.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

None, Mojarra dev tests will cover it.

  • Which is the targeted build of 4.0 for this fix?

TBD

Comment by Tom Mueller [ 02/Apr/13 10:02 PM ]

Approved for 4.0.

Comment by Ed Burns [ 10/Apr/13 08:31 PM ]

Safe to integrate when < http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_2_2_0_GLASSFISH_3_1_2_2_NO_CLUSTER/19/ > and < http://slc03qna.us.oracle.com:7070/hudson/view/Mojarra%202.2/job/2_2_x-test-glassfish-4_0/40/ > are clean.

Comment by Ed Burns [ 11/Apr/13 04:25 PM ]

Both of those jobs are clean.

This is fixed and will be included in Mojarra 2.2.0-m14, due by COB Monday 15 April 2013.

Comment by Ed Burns [ 16/Apr/13 02:45 PM ]

Integrated with 2.2.0-m14, committed as

r61425 | rogerk | 2013-04-15 09:06:17 -0400 (Mon, 15 Apr 2013) | 213 lines

http://java.net/jira/browse/GLASSFISH-20292 http://java.net/jira/browse/GLASSFISH-20232 http://java.net/jira/browse/GLASSFISH-20123 http://java.net/jira/browse/GLASSFISH-20122

http://java.net/jira/browse/GLASSFISH-20292

M jsf-ri/conf/share/facelets_jsf_core.taglib.xml

f:attributes - MISSING WHOLE TAG
f:passThroughAttribute - MISSING WHOLE TAG
f:passThroughAttributes - MISSING WHOLE TAG
f:ajax - MISSING delay, resetValues ATTR
f:view - MISSING transient, contracts ATTR
f:selectItems - MISSING rendered, actionListener ATTR

M jsf-ri/conf/share/html_basic.taglib.xml

h:inputFile - MISSING WHOLE TAG
h:button - MISSING role, disableClientWindow ATTR
h:commandButton - MISSING role ATTR
h:commandLink - MISSING role ATTR
h:link - MISSING role, disableClientWindow ATTR
h:doctype - MISSING WHOLE TAG

Sending jsf-ri/conf/share/facelets_jsf_core.taglib.xml
Sending jsf-ri/conf/share/html_basic.taglib.xml
Transmitting file data ..
Committed revision 11873.

http://java.net/jira/browse/GLASSFISH-20232

M jsf-ri/src/main/java/com/sun/faces/flow/FlowHandlerImpl.java

  • Instead of polling the config manager to see if there are flows, use
    the addFlow() method.
    Sending jsf-ri/src/main/java/com/sun/faces/flow/FlowHandlerImpl.java
    Transmitting file data .
    Committed revision 11852.

http://java.net/jira/browse/GLASSFISH-20123

M jsf-ri/build-pre-maven-rename.xml
M jsf-api/build-pre-maven-rename.xml

  • Apply the changes from "svn diff -r 11859:11860" to the
    "pre-maven-rename" variant.

Sending jsf-api/build-pre-maven-rename.xml
Sending jsf-ri/build-pre-maven-rename.xml
Transmitting file data ..
Committed revision 11872.

M jsf-ri/build.xml

  • change mvn.deploy.release.local and mvn.deploy.release to depend on m14.

M jsf-ri/mojarra-jsf-impl.bnd

  • change OSGi Implementation-Version to be 2.2.0-m14.
  • change OSGi Bundle-Version to be 2.1.99.b14

M common/ant/maven.xml

  • If the build.type is not -SNAPSHOT, activate the check-module property
    when invoking maven. This causes the

<groupId>org.glassfish.build</groupId>
<artifactId>spec-version-maven-plugin</artifactId>
<version>1.1</version>

plugin to be invoked, as shown in this output

[INFO] Building jar: /Users/ejburns/Documents/JavaEE/workareas/mojarra-MOJARRA_2_2_0_GLASSFISH_4_0/jsf-api/build/mvn/target/javax.faces-api-2.2-m14.jar
[INFO] [build-helper:attach-artifact {execution: attach-artifacts}]
[INFO] [spec-version:check-module {execution: default}]
[INFO] [source:jar-no-fork {execution: attach-sources}]
[INFO] Building jar: /Users/ejburns/Documents/JavaEE/workareas/mojarra-MOJARRA_2_2_0_GLASSFISH_4_0/jsf-ri/build/mvn/target/javax.faces-2.2.0-m14.jar
[INFO] [build-helper:attach-artifact {execution: attach-artifacts}]
[INFO] [spec-version:check-module {execution: default}]
[INFO] [source:jar-no-fork {execution: attach-sources}]

M common/ant/template/jsf-impl-pom-template.xml
M common/ant/template/jsf-api-pom-template.xml

  • invoke the spec-version-maven-plugin if the check-module property is
    activated.

M jsf-api/mojarra-jsf-api.bnd

  • Change OSGi Implementation-Version to be 2.2.0-m14
  • Change OSGi Bundle-Version to be 2.1.99.b14

M jsf-api/build.xml

  • change mvn.deploy.release.local and mvn.deploy.release to depend on m14
    Sending common/ant/maven.xml
    Sending common/ant/template/jsf-api-pom-template.xml
    Sending common/ant/template/jsf-impl-pom-template.xml
    Sending jsf-api/build.xml
    Sending jsf-api/mojarra-jsf-api.bnd
    Sending jsf-ri/build.xml
    Sending jsf-ri/mojarra-jsf-impl.bnd
    Transmitting file data .......
    Committed revision 11860.

To preverve backward compatibility with the now deprecated Facelets
ResourceResolver, ensure it gets consulted on ViewHandler0.viewExists().

r=mriem

SECTION: Modified Files
----------------------------
M jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFaceletFactory.java
M jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
M jsf-demo/sandbox/flow_and_contract/app/pom.xml
M jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/OutcomeTargetRenderer.java

  • Unrelated change. Don't renderd the flow attributes on outcomeTarget
    components unless there are flows.

D jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts
D jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts/leftNav
D jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts/topNav

  • Unrelated change, the focus of this demo changed so that now the flows
    and contracts are bundled in jars, not with the app.

A test/agnostic/vdl/facelets/resource-resolver
A test/agnostic/vdl/facelets/resource-resolver/nbactions.xml
A test/agnostic/vdl/facelets/resource-resolver/src
A test/agnostic/vdl/facelets/resource-resolver/src/test
A test/agnostic/vdl/facelets/resource-resolver/src/test/java
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/VerifyResourceResolverUsageIT.java
A test/agnostic/vdl/facelets/resource-resolver/src/main
A test/agnostic/vdl/facelets/resource-resolver/src/main/java
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/TestResolver.java
A test/agnostic/vdl/facelets/resource-resolver/src/main/resources
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/web.xml
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/glassfish-web.xml
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/a.xhtml
A test/agnostic/vdl/facelets/resource-resolver/pom.xml

  • New test
    Sending jsf-demo/sandbox/flow_and_contract/app/pom.xml
    Deleting jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts
    Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
    Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFaceletFactory.java
    Sending jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/OutcomeTargetRenderer.java
    Adding test/agnostic/vdl/facelets/resource-resolver
    Adding test/agnostic/vdl/facelets/resource-resolver/nbactions.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/pom.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/src
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/TestResolver.java
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/resources
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/glassfish-web.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/web.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/a.xhtml
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/VerifyResourceResolverUsageIT.java
    Transmitting file data ...........
    Committed revision 11850.

SECTION: Modified Files
----------------------------
M jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java

  • Found by jsp-flash systest-per-webapp.

Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
Transmitting file data .
Committed revision 11851.





[GLASSFISH-20122] JSF 2.2 not fully compatible with ResourceResolver Created: 31/Mar/13  Updated: 16/Apr/13  Resolved: 16/Apr/13

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: arjan tijms Assignee: Ed Burns
Resolution: Fixed Votes: 1
Remaining Estimate: 0 minutes
Time Spent: 3 hours, 34 minutes
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: arjan tijms, Ed Burns and Tom Mueller

 Description   

In JSF 2.2 the Facelets ResourceResolver was deprecated in favor of the ResourceHandler.

Mojarra keeps supporting the ResourceResolver by letting ViewHandler#buildView still (indirectly) call ResourceResolver, but installs a default implementation that calls the new ResourceHandler#createViewResource.

This support is however not complete. ViewHandler#viewExists calls ResourceHandler#createViewResource directly without any delegation to the ResourceResolver. As a result, JSF 2.1 applications that use ResourceResolver only work partially. E.g. a URL managed by such resolver can be requested as a top level view, but h:links back to such URL won't work.

The following code demonstrates this:

"test/TestResolver.class"
@FaceletsResourceResolver
public class TestResolver extends ResourceResolver {
    
    private final ResourceResolver resourceResolver;

    public TestResolver(ResourceResolver resourceResolver) {
        this.resourceResolver = resourceResolver;
    }

    @Override
    public URL resolveUrl(String path) {
        if ("/b.xhtml".equals(path)) {
            path = "/a.xhtml";
        }
        
        return resourceResolver.resolveUrl(path);
    }
    
}
"a.xhtml"
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
>
    
    <h:body>
   
        <h:link value="real link" outcome="/a.xhtml" />
        <h:link value="virtual link" outcome="/b.xhtml" />
        
    </h:body>
</html>

Deploying just these two files to the context root and requesting http://localhost:8080/b.jsf will render the page, but the link to /b.xhtml will not render as a link. The link to /a.xhtml will be rendered as a link.

On JSF 2.1 (replacing the annotation with an entry in web.xml) both links will be rendered correctly when /b.xhtml is requested.



 Comments   
Comment by Ed Burns [ 02/Apr/13 09:48 PM ]
  • What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?

links do not work if the customer is using a JSF 2.0 ResourceResolver.

Is it a regression?

Yes.

Does it meet other bug fix criteria (security, performance, etc.)?

No

What CTS failures are caused by this bug?

None known.

  • What is the cost/risk of fixing the bug

How risky is the fix? How much work is the fix? Is the fix complicated?

I expect the fix can be done with small changes to two or three source files. The fix will be developed
using TDD to mitigate the risk.

  • Is there an impact on documentation or message strings?

No.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

None, dev tests are sufficient.

  • Which is the targeted build of 4.0 for this fix?

TBD

Comment by Tom Mueller [ 02/Apr/13 10:03 PM ]

Approved for 4.0

Comment by Ed Burns [ 08/Apr/13 07:31 PM ]

When <http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_2_2_0_GLASSFISH_3_1_2_2_NO_CLUSTER/17/> completes successfully, forward port this to trunk.

Comment by Ed Burns [ 11/Apr/13 04:15 PM ]

This is fixed and will be included in Mojarra 2.2.0-m14, due by COB Monday 15 April 2013.

Comment by Ed Burns [ 16/Apr/13 02:45 PM ]

Integrated with 2.2.0-m14, committed as

r61425 | rogerk | 2013-04-15 09:06:17 -0400 (Mon, 15 Apr 2013) | 213 lines

http://java.net/jira/browse/GLASSFISH-20292 http://java.net/jira/browse/GLASSFISH-20232 http://java.net/jira/browse/GLASSFISH-20123 http://java.net/jira/browse/GLASSFISH-20122

http://java.net/jira/browse/GLASSFISH-20292

M jsf-ri/conf/share/facelets_jsf_core.taglib.xml

f:attributes - MISSING WHOLE TAG
f:passThroughAttribute - MISSING WHOLE TAG
f:passThroughAttributes - MISSING WHOLE TAG
f:ajax - MISSING delay, resetValues ATTR
f:view - MISSING transient, contracts ATTR
f:selectItems - MISSING rendered, actionListener ATTR

M jsf-ri/conf/share/html_basic.taglib.xml

h:inputFile - MISSING WHOLE TAG
h:button - MISSING role, disableClientWindow ATTR
h:commandButton - MISSING role ATTR
h:commandLink - MISSING role ATTR
h:link - MISSING role, disableClientWindow ATTR
h:doctype - MISSING WHOLE TAG

Sending jsf-ri/conf/share/facelets_jsf_core.taglib.xml
Sending jsf-ri/conf/share/html_basic.taglib.xml
Transmitting file data ..
Committed revision 11873.

http://java.net/jira/browse/GLASSFISH-20232

M jsf-ri/src/main/java/com/sun/faces/flow/FlowHandlerImpl.java

  • Instead of polling the config manager to see if there are flows, use
    the addFlow() method.
    Sending jsf-ri/src/main/java/com/sun/faces/flow/FlowHandlerImpl.java
    Transmitting file data .
    Committed revision 11852.

http://java.net/jira/browse/GLASSFISH-20123

M jsf-ri/build-pre-maven-rename.xml
M jsf-api/build-pre-maven-rename.xml

  • Apply the changes from "svn diff -r 11859:11860" to the
    "pre-maven-rename" variant.

Sending jsf-api/build-pre-maven-rename.xml
Sending jsf-ri/build-pre-maven-rename.xml
Transmitting file data ..
Committed revision 11872.

M jsf-ri/build.xml

  • change mvn.deploy.release.local and mvn.deploy.release to depend on m14.

M jsf-ri/mojarra-jsf-impl.bnd

  • change OSGi Implementation-Version to be 2.2.0-m14.
  • change OSGi Bundle-Version to be 2.1.99.b14

M common/ant/maven.xml

  • If the build.type is not -SNAPSHOT, activate the check-module property
    when invoking maven. This causes the

<groupId>org.glassfish.build</groupId>
<artifactId>spec-version-maven-plugin</artifactId>
<version>1.1</version>

plugin to be invoked, as shown in this output

[INFO] Building jar: /Users/ejburns/Documents/JavaEE/workareas/mojarra-MOJARRA_2_2_0_GLASSFISH_4_0/jsf-api/build/mvn/target/javax.faces-api-2.2-m14.jar
[INFO] [build-helper:attach-artifact {execution: attach-artifacts}]
[INFO] [spec-version:check-module {execution: default}]
[INFO] [source:jar-no-fork {execution: attach-sources}]
[INFO] Building jar: /Users/ejburns/Documents/JavaEE/workareas/mojarra-MOJARRA_2_2_0_GLASSFISH_4_0/jsf-ri/build/mvn/target/javax.faces-2.2.0-m14.jar
[INFO] [build-helper:attach-artifact {execution: attach-artifacts}]
[INFO] [spec-version:check-module {execution: default}]
[INFO] [source:jar-no-fork {execution: attach-sources}]

M common/ant/template/jsf-impl-pom-template.xml
M common/ant/template/jsf-api-pom-template.xml

  • invoke the spec-version-maven-plugin if the check-module property is
    activated.

M jsf-api/mojarra-jsf-api.bnd

  • Change OSGi Implementation-Version to be 2.2.0-m14
  • Change OSGi Bundle-Version to be 2.1.99.b14

M jsf-api/build.xml

  • change mvn.deploy.release.local and mvn.deploy.release to depend on m14
    Sending common/ant/maven.xml
    Sending common/ant/template/jsf-api-pom-template.xml
    Sending common/ant/template/jsf-impl-pom-template.xml
    Sending jsf-api/build.xml
    Sending jsf-api/mojarra-jsf-api.bnd
    Sending jsf-ri/build.xml
    Sending jsf-ri/mojarra-jsf-impl.bnd
    Transmitting file data .......
    Committed revision 11860.

To preverve backward compatibility with the now deprecated Facelets
ResourceResolver, ensure it gets consulted on ViewHandler0.viewExists().

r=mriem

SECTION: Modified Files
----------------------------
M jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFaceletFactory.java
M jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
M jsf-demo/sandbox/flow_and_contract/app/pom.xml
M jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/OutcomeTargetRenderer.java

  • Unrelated change. Don't renderd the flow attributes on outcomeTarget
    components unless there are flows.

D jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts
D jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts/leftNav
D jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts/topNav

  • Unrelated change, the focus of this demo changed so that now the flows
    and contracts are bundled in jars, not with the app.

A test/agnostic/vdl/facelets/resource-resolver
A test/agnostic/vdl/facelets/resource-resolver/nbactions.xml
A test/agnostic/vdl/facelets/resource-resolver/src
A test/agnostic/vdl/facelets/resource-resolver/src/test
A test/agnostic/vdl/facelets/resource-resolver/src/test/java
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
A test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/VerifyResourceResolverUsageIT.java
A test/agnostic/vdl/facelets/resource-resolver/src/main
A test/agnostic/vdl/facelets/resource-resolver/src/main/java
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
A test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/TestResolver.java
A test/agnostic/vdl/facelets/resource-resolver/src/main/resources
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/web.xml
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/glassfish-web.xml
A test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/a.xhtml
A test/agnostic/vdl/facelets/resource-resolver/pom.xml

  • New test
    Sending jsf-demo/sandbox/flow_and_contract/app/pom.xml
    Deleting jsf-demo/sandbox/flow_and_contract/app/src/main/webapp/contracts
    Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
    Sending jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFaceletFactory.java
    Sending jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/OutcomeTargetRenderer.java
    Adding test/agnostic/vdl/facelets/resource-resolver
    Adding test/agnostic/vdl/facelets/resource-resolver/nbactions.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/pom.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/src
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/TestResolver.java
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/resources
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/glassfish-web.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/WEB-INF/web.xml
    Adding test/agnostic/vdl/facelets/resource-resolver/src/main/webapp/a.xhtml
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver
    Adding test/agnostic/vdl/facelets/resource-resolver/src/test/java/com/sun/faces/test/agnostic/vdl/facelets/resource_resolver/VerifyResourceResolverUsageIT.java
    Transmitting file data ...........
    Committed revision 11850.

SECTION: Modified Files
----------------------------
M jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java

  • Found by jsp-flash systest-per-webapp.

Sending jsf-ri/src/main/java/com/sun/faces/application/view/FaceletViewHandlingStrategy.java
Transmitting file data .
Committed revision 11851.





[GLASSFISH-20073] The installer/uninstaller progress bar is not shown completely. Created: 27/Mar/13  Updated: 17/Apr/13  Resolved: 17/Apr/13

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Mohamed Taman Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 SP1
glassfish-4.0-b81-windows-ml


Tags: fishcat 4_0-approved
Participants: Mohamed Taman, Snjezana Sevo-Zenzerovic and Tom Mueller

 Description   

While installing / Uninstalling the Glassfish, the progress screen progress bar, doesn't appears completely, the screen shows half of it, you should resize the screen to show the complete progress bar.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 27/Mar/13 04:33 PM ]

I am aware of this and I will adjust the windows sizes to avoid both this problem and slightly squashed progress panel images.

Comment by Snjezana Sevo-Zenzerovic [ 11/Apr/13 02:38 PM ]
  • What is the impact on the customer of the bug?

Usability impact - out of the box installer window size is too small to effectively convey progress information.

  • What is the cost/risk of fixing the bug?

Low risk/cost. Window sizes are defined in ui preferences file and need to be adjusted, no changes to Java code itself.

  • Is there an impact on documentation or message strings?

No.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Visual inspection during GUI installer testing.

  • Which is the targeted build of 4.0 for this fix?

b85

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

N/A

Comment by Tom Mueller [ 11/Apr/13 05:21 PM ]

Approved for 4.0.

Comment by Snjezana Sevo-Zenzerovic [ 17/Apr/13 12:11 AM ]

Window size increased so that progress bar is not cut off. Overall layout is not quite ideal yet, but further improvements would require progress panel image size update and will be done in subsequent release.





[GLASSFISH-20036] EJB's declaration of roles used in role references Created: 25/Mar/13  Updated: 11/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 4.0
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: Craig Perez
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: Craig Perez and Tom Mueller

 Description   

The EJB spec requires that role references be declared either by annotation (@DeclareRole or @RolesAllowed) or by security-role-ref within the EJB deployment descriptor. The EJB sepc does not consider the definition of a security-role within the EJB deployment descriptor, as an implicit declaration of a corresponding security-role-ref for the role (given that the security-role-ref has not otherwise been declared).



 Comments   
Comment by Craig Perez [ 25/Mar/13 08:37 PM ]

There are couple areas to address:

  • Adding of the EJBRoleRefPermission grants
  • Handling of the IllegalStateException when invoking isCallerInRole()
Comment by Craig Perez [ 09/Apr/13 11:36 PM ]
  • What is the impact on the customer of the bug?

Existing EJB security-role-ref handling not conformant with
JACC 1.5 and EJB 3.2 specifications

  • What is the cost/risk of fixing the bug?

Small, the code changes update EJB role reference handling
and remove exceptions thrown when role references where
not found to be declared at run-time.

  • Is there an impact on documentation or message strings?

No

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

CTS7 JACC TCK, EJB tests

  • Which is the targeted build of 4.0 for this fix?

b85

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

N/A

Comment by Tom Mueller [ 10/Apr/13 02:08 AM ]

Approved for 4.0.

Comment by Craig Perez [ 10/Apr/13 03:21 PM ]

[glassfish~svn:61324] GLASSFISH-20036 - EJB's declaration of roles used in role references

Project: glassfish
Repository: svn
Revision: 61324
Author: crperez
Date: 2013-04-10 15:12:58 UTC
Link:

Log Message:
------------
GLASSFISH-20036 - EJB's declaration of roles used in role references

  • Add handling of EJBRoleRefPermission based on security-role declarations
  • Remove exception for isCallerInRole() when security-role-ref not decalred
    Reviewed by Ron Monzillo, Marina Vatkina
    Passed JACC TCK, QuickLook, findbugs, CTS smoke, devtests EJB Web Admin

Revisions:
----------
61324

Modified Paths:
---------------
trunk/main/appserver/ejb/ejb-container/src/main/java/org/glassfish/ejb/security/application/EJBSecurityManager.java
trunk/main/appserver/ejb/ejb-full-container/src/main/java/org/glassfish/ejb/mdb/MessageBeanContextImpl.java
trunk/main/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/containers/EJBContextImpl.java

Comment by Craig Perez [ 10/Apr/13 03:28 PM ]

[glassfish~svn:61325] GLASSFISH-20036 - Add in the devtest cases based on security-role-ref han

Project: glassfish
Repository: svn
Revision: 61325
Author: crperez
Date: 2013-04-10 15:14:50 UTC
Link:

Log Message:
------------
GLASSFISH-20036 - Add in the devtest cases based on security-role-ref handling

  • any authenticated user role not declared explictly
  • role references to security roles not required

Revisions:
----------
61325

Modified Paths:
---------------
trunk/v2/appserv-tests/devtests/security/jaccmr8/client/Client.java
trunk/v2/appserv-tests/devtests/security/jaccmr8/ejb/HelloStatefulEJB.java
trunk/v2/appserv-tests/devtests/security/jaccmr8/ejb/HelloEJB.java
trunk/v2/appserv-tests/devtests/security/jaccmr8/descriptor/ejb-jar.xml

Comment by Craig Perez [ 11/Apr/13 05:23 PM ]

[glassfish~svn:61366] GLASSFISH-20036 - Remove commented code blocks

Project: glassfish
Repository: svn
Revision: 61366
Author: crperez
Date: 2013-04-11 17:01:48 UTC
Link:

Log Message:
------------
GLASSFISH-20036 - Remove commented code blocks

Revisions:
----------
61366

Modified Paths:
---------------
trunk/main/appserver/ejb/ejb-full-container/src/main/java/org/glassfish/ejb/mdb/MessageBeanContextImpl.java
trunk/main/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/containers/EJBContextImpl.java





[GLASSFISH-20019] Uninstaller stuck on 0% without any progress around 45 min. Created: 24/Mar/13  Updated: 16/Apr/13  Resolved: 16/Apr/13

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b85

Type: Bug Priority: Critical
Reporter: Mohamed Taman Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 SP1
Glassfish v4 b80


Tags: fishcat installer 4_0-approved
Participants: Mohamed Taman, Snjezana Sevo-Zenzerovic and Tom Mueller

 Description   

running uninstall.exe failed to uninstall the products and stuck on 0% without any progress around 45 min.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 25/Mar/13 01:44 PM ]

Mohammad, was this the same uninstall run as described in issue GLASSFISH-20019? If so, I believe that the failure is due to the fact that you used JDK 6 and not JDK 7 for installer runtime. Even in that case this is a valid issue since uninstaller should handle that situation more gracefully, but please confirm that you are able to proceed with uninstallation if you provide explicit path to JDK 7 installation.

Comment by Mohamed Taman [ 25/Mar/13 03:58 PM ]

Snjezana,

I ran the uninstaller with JDK 7 and it works fine and uninstall the Glassfish successfully, but leaving some folders as the following:

C:\glassfish4>tree
Folder PATH listing for volume System
Volume serial number is DAAD-A878
C:.
├───glassfish
│   └───lib
│       └───registration
├───install
│   ├───bin
│   ├───lib
│   │   ├───external
│   │   │   ├───apache
│   │   │   ├───beanshell
│   │   │   ├───charva
│   │   │   ├───chaxml
│   │   │   ├───freemarker
│   │   │   ├───jaxb
│   │   │   ├───jdom
│   │   │   └───swixml
│   │   ├───platforms
│   │   ├───providers
│   │   ├───resources
│   │   │   ├───dependency
│   │   │   ├───model
│   │   │   ├───org
│   │   │   │   └───openinstaller
│   │   │   │       └───resources
│   │   │   ├───templates
│   │   │   └───view
│   │   └───sims
│   └───metadata
│       ├───dependency
│       ├───model
│       ├───templates
│       └───view
└───var
    └───install
        ├───config
        │   └───Domain
        └───pkgdb
            ├───sims-product
            └───uninstall
Comment by Snjezana Sevo-Zenzerovic [ 25/Mar/13 04:14 PM ]

Thanks for confirmation, Mohamed. I'll look into those leftovers - most of the files that are listed belong to openInstaller framework and are actually required to run uninstaller. I believe we had a hook in native executable which would kick in and remove these files after we are done using them so I'll try to find out if there is an issue with that.

Comment by Snjezana Sevo-Zenzerovic [ 11/Apr/13 03:27 PM ]

Given that we can't easily update uninstall native wrapper to enforce JDK 7 usage or provide message to that effect, it is hard to fix the root cause at this point.

However, given that Windows installer/uninstaller are in fact able to run using JDK 6 runtime provided that we also compile our custom install configuration extensions with 1.6 target, it would IMO make sense to reconfigure maven compiler plugin in installer module and enable this. This would mitigate some of the issues with Windows JDK detection and improve usability. Such installer would still independently enforce the use of JDK 7 for GlassFish runtime.

  • What is the impact on the customer of the bug?

While this is not a regression, there is significant usability impact with newer Windows versions and increased 64 bit JDK usage. So, it may be worthwhile to be able to run installer with any JDK that is automatically detected by the wrapper.

  • What is the cost/risk of fixing the bug?

Low/moderate risk. We tested and run an almost identical installer code base in 3.1.x release using JDK 6.

  • Is there an impact on documentation or message strings?

Possible limited impact on installation guide (need to document the ability to run installer/uninstaller using JDK 6 or higher on Windows platform).

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Regular installer testing plus several installer runs using explicitly provided path to JDK 6 installation.

  • Which is the targeted build of 4.0 for this fix?

b85

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

N/A

Comment by Tom Mueller [ 11/Apr/13 05:24 PM ]

Approved for 4.0





[GLASSFISH-20018] NPE at com.sun.enterprise.deployment.ServiceReferenceDescriptor.hasGenericServiceInterface(ServiceReferenceDescriptor.java:277) Created: 24/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

Type: Bug Priority: Blocker
Reporter: jjsnyder83 Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved
Participants: jjsnyder83 and Lukas Jungmann

 Description   

This is causing CDI tck failure.

A WebSerficeRef is defined like so:
@WebServiceRef
public SheepWS sheepWS;

WebServiceRefHandler.processAWsRef is constructing ServiceReferenceDescriptor via the no-arg constructor (line 234). Later at line 322 wsclientAnn is null which is causing a AnnotationProcessorException to be thrown. This exception is not caught anywhere and so eventually ServiceReferenceDescriptor.hasGenericServiceInterface is called causing the NPE. Here's the stack trace:

[2013-03-24T15:34:26.403-0400] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=44 _ThreadName=Thread-4] [timeMillis: 1364153666403] [levelValue: 1000] [[
java.lang.RuntimeException
at org.glassfish.javaee.core.deployment.JavaEEDeployer.prepare(JavaEEDeployer.java:229)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:922)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:431)
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(Unknown Source)
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:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:235)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:257)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:329)
at org.glassfish.admin.rest.resources.TemplateListOfResource.post(TemplateListOfResource.java:164)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:350)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:345)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:214)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:207)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:203)
at org.glassfish.jersey.internal.Errors.process(Errors.java:251)
at org.glassfish.jersey.internal.Errors.process(Errors.java:233)
at org.glassfish.jersey.internal.Errors.process(Errors.java:203)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:190)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:865)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:318)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
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(Unknown Source)
Caused by: java.lang.RuntimeException
at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:290)
at com.sun.enterprise.deployment.util.ModuleContentLinker.accept(ModuleContentLinker.java:96)
at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:852)
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
at org.glassfish.web.deployment.descriptor.WebBundleDescriptorImpl.visit(WebBundleDescriptorImpl.java:1958)
at org.glassfish.web.deployment.descriptor.WebBundleDescriptorImpl.visit(WebBundleDescriptorImpl.java:1948)
at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:844)
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
at org.glassfish.webservices.codegen.JaxRpcRICodegen.run(JaxRpcRICodegen.java:161)
at org.glassfish.webservices.JAXRPCCodeGenFacadeImpl.run(JAXRPCCodeGenFacadeImpl.java:60)
at org.glassfish.javaee.core.deployment.JavaEEDeployer.prepare(JavaEEDeployer.java:218)
... 59 more
Caused by: java.lang.NullPointerException
at com.sun.enterprise.deployment.ServiceReferenceDescriptor.hasGenericServiceInterface(ServiceReferenceDescriptor.java:277)
at com.sun.enterprise.deployment.ServiceReferenceDescriptor.hasGeneratedServiceInterface(ServiceReferenceDescriptor.java:281)
at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:233)
... 69 more]]



 Comments   
Comment by Lukas Jungmann [ 25/Mar/13 01:37 AM ]

Can you share full test case with me, ie via email, or point me to the sources at github, please?
Thanks!

Comment by Lukas Jungmann [ 25/Mar/13 10:33 PM ]

got failing CDI TCK test from JJ and based on the first look and JSR-224, section 7.9 (pages 100-101) it is likely that the test is expecting undefined behaviour. But will double check.

Comment by Lukas Jungmann [ 27/Mar/13 10:56 PM ]

SheepWS is not a class annotated with @WebServiceClient nor the @WebServiceRef.value is defined for the field.

during deployment there are also following warnings:

SEVERE:   Class must be annotated with a interface javax.xml.ws.WebServiceClient annotation
 symbol : interface javax.xml.ws.WebServiceClient
 location: interface org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWS
SEVERE:   Class must be annotated with a interface javax.xml.ws.WebServiceClient annotation
 symbol : interface javax.xml.ws.WebServiceClient
 location: interface org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWS
SEVERE:   Annotations processing failed for file:/home/lukas/NetBeansProjects/WebApplication3/build/web/
SEVERE:   Unsupported deployment descriptors element org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSProducer/sheepWS value com.sun.enterprise.deploy.shared.FileArchive@15fbbf77.
S
Comment by Lukas Jungmann [ 11/Apr/13 06:04 PM ]

cause and fix lies in web services area only

Comment by Lukas Jungmann [ 11/Apr/13 06:28 PM ]
  • What is the impact on the customer of the bug?
    will see failing CDI TCK test
  • How likely is it that a customer will see the bug and how serious is the bug?
    whenever he tries to have web service and its client in the same application unit - this is not recommended but allowed by JSR-109
  • What CTS failures are caused by this bug?
    none
  • What is the cost/risk of fixing the bug?
    the fix is available
  • Is there an impact on documentation or message strings?
    no
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    reqular web services related tests, CTS
  • Which is the targeted build of 4.0 for this fix?
    4.0_b85
  • If this an integration of a new version of a component from another project?
    no
Comment by Lukas Jungmann [ 11/Apr/13 06:29 PM ]

http://java.net/projects/glassfish/sources/svn/revision/61363





[GLASSFISH-20007] Can't update glassfish modules using update tool. Created: 23/Mar/13  Updated: 25/Apr/13  Resolved: 12/Apr/13

Status: Closed
Project: glassfish
Component/s: l10n
Affects Version/s: None
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Mohamed Taman Assignee: clyang
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 SP1
Glassfish v4 b80


Tags: fishcat updatetool
Participants: clyang, kumara, michael.y.chen, Mohamed Taman and sunny-gui

 Description   

while opening the admin console --> update center --> update tool and selecting available updates then process to update, after a while I got the following error alongside other modules but the same error:

Launching GlassFish on Felix platform
Mar 23, 2013 2:12:15 AM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner createBundleProvisioner
INFO: Create bundle provisioner class = class com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.
Mar 23, 2013 2:12:16 AM com.sun.enterprise.glassfish.bootstrap.LogFacade log
WARNING: Failed to install file:/E:/Utilities/Glassfish_v4/glassfish/modules/appclient-server-core-l10n.jar.
org.osgi.framework.BundleException: Could not create bundle object.
	at org.apache.felix.framework.Felix.installBundle(Felix.java:2940)
	at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165)
	at com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.install(BundleProvisioner.java:445)
	at com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.installBundles(BundleProvisioner.java:205)
	at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.java:142)
	at org.glassfish.embeddable.GlassFishRuntime._bootstrap(GlassFishRuntime.java:157)
	at org.glassfish.embeddable.GlassFishRuntime.bootstrap(GlassFishRuntime.java:110)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:112)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
	at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:54)
Caused by: java.lang.IllegalArgumentException: invalid version "${project.osgi.version}": non-numeric "${project"
	at org.osgi.framework.Version.parseInt(Version.java:170)
	at org.osgi.framework.Version.<init>(Version.java:126)
	at org.apache.felix.framework.util.VersionRange.parse(VersionRange.java:98)
	at org.apache.felix.framework.util.manifestparser.ManifestParser.parseFragmentHost(ManifestParser.java:1335)
	at org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:146)
	at org.apache.felix.framework.BundleRevisionImpl.<init>(BundleRevisionImpl.java:118)
	at org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1199)
	at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:96)
	at org.apache.felix.framework.Felix.installBundle(Felix.java:2887)
	... 13 more
Caused by: java.lang.NumberFormatException: For input string: "${project"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:481)
	at java.lang.Integer.parseInt(Integer.java:527)
	at org.osgi.framework.Version.parseInt(Version.java:168)
	... 21 more


 Comments   
Comment by kumara [ 23/Mar/13 12:40 AM ]

This seems like an error in creating appclient-server-core-l10n.jar – the version property in manifest is not numeric.

Comment by michael.y.chen [ 11/Apr/13 07:26 PM ]

Claire thinks this is already fixed. Need to verify the fix.

Comment by clyang [ 12/Apr/13 04:38 PM ]

Issues should be resolved in b83 and later builds.

Comment by clyang [ 12/Apr/13 04:39 PM ]

should be resolved in b83 and later builds.

Comment by clyang [ 16/Apr/13 08:40 PM ]

Hi Sunny,
I believe this has been fixed.
Do you mind verifying it in the next build?
Thanks, Claire

Comment by sunny-gui [ 25/Apr/13 06:09 AM ]

Could not reproduce this issue. Update Tool Bootstrap is not configured during install GF and no available update in the Admin Console.
will attach screen shots for your reference.

Comment by sunny-gui [ 25/Apr/13 06:11 AM ]

Due to limited privilege, can not attach screen shot.

Comment by clyang [ 25/Apr/13 02:42 PM ]

Issue not reproducible in b86.
Close the bug.





[GLASSFISH-19992] Tracking bug for cdi tck failure org.jboss.cdi.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest Created: 21/Mar/13  Updated: 18/Apr/13  Resolved: 18/Apr/13

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

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

Tags:
Participants: jjsnyder83

 Description   

test failing is testSerializeSFSB. There is a discussion going on about the container's responsibility for serializing during passivation.



 Comments   
Comment by jjsnyder83 [ 22/Mar/13 01:04 AM ]

I got back some info from Marina and Mahesh which I forwarded to JBoss tck team.

Comment by jjsnyder83 [ 26/Mar/13 02:11 PM ]

Must fork the Weld porting package and rewrite org.jboss.weld.tck.BeansImpl to use GlassFish-specific
ObjectOutputStream/ObjectInputStream.

It should be quite straightforward (the porting package contains only three classes and one cdi-tck.properties file).

The weld porting package source:
https://github.com/weld/core/tree/2.0/porting-package/1.1

Comment by jjsnyder83 [ 18/Apr/13 01:58 PM ]

Fixed in GlassFish test runner.





[GLASSFISH-19986] GET http://localhost:4848/theme/META-INF/com_sun_faces_ajax.js 404 (Not Found) Created: 21/Mar/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b85

Type: Bug Priority: Minor
Reporter: myfear Assignee: Anissa Lam
Resolution: Cannot Reproduce Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 4.0 (build 80)


Tags: fishcat
Participants: Anissa Lam and myfear

 Description   

The Admin UI produces an error in latest Chrome Version 25.0.1364.172 m



 Comments   
Comment by Anissa Lam [ 25/Mar/13 03:08 PM ]

I see this once in a while, will need sometime to investigate.
Can you reproduce this consistently ?
I believe even if the msg shows up, there is no noticeable issue with the console. Downgrading to minor. If thats the case, please add info of what is broken when you see this.

Comment by Anissa Lam [ 19/Apr/13 09:46 PM ]

I haven't seen this for many builds. Don't think this is related to browser, but I have been using Chrom 18.0.1025.168 , Firefox and Safari and haven't seen this ever since i kept an eye on this error.
I have upgraded to Chrome 26.0.1410.65 and so far haven't seen this also.

Closing as cannot reproduce. If you can still reproduce this with latest build, feel free to reopen.
thanks.





[GLASSFISH-19946] Add ability to turn on/off global support for CDI. Created: 19/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

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

Tags:
Participants: jjsnyder83 and tlcksnyder

 Comments   
Comment by jjsnyder83 [ 21/Mar/13 02:59 PM ]

See https://issues.jboss.org/browse/CDI-321

Comment by jjsnyder83 [ 22/Mar/13 07:03 PM ]

Make sure we also check the isJCDIEnabled method in the JCDI service

Comment by jjsnyder83 [ 22/Mar/13 07:37 PM ]

globally disabling CDI means that a beans.xml must be present for an archive to be a bda, e.g. no implicit archives. If there is a beans.xml the "bean-discovery-mode" element must still be honored.

Comment by jjsnyder83 [ 09/Apr/13 04:17 PM ]

The config item is there. We need to access it. WeldUtils.isEnableImplicitCDI() is the method to use. To change the value use asadmin (false is the default)

asadmin create-module-config cdi-service
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=true

Comment by jjsnyder83 [ 09/Apr/13 09:04 PM ]

Revision 61270 has the changes needed for this.

Comment by tlcksnyder [ 11/Apr/13 01:51 PM ]

Implemented.





[GLASSFISH-19943] Audit module (webInvocation callback) tests failed in GF4.0 Created: 19/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: None
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: sonialiu Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

build 80
OEL5.8


Issue Links:
Dependency
depends on GLASSFISH-20160 asadmin get command referring to a de... Resolved
Tags: 4_0-approved
Participants: Shing Wai Chan, sonialiu and Tim Quinn

 Description   

There are 4 tests failed in Audit module. Steps to reproduce the bug:

1. Install GF4.0, start domain
2. Checkout SQE workspace:
cvs co appserver-sqe/bootstrap.xml
(CVSROOT: :pserver:<your cvs user>@sunsw.us.oracle.com:/m/jws
cd appserver-sqe
ant -f bootstrap.xml co-security
3.set following env. variables
S1AS_HOME <GF install dir>, for example: /export/sonia/v4/glassfish4/glassfish
SPS_HOME <appserver-sqe>, for example: /export/sonia/appserver-sqe
ANT_HOME <ant location>, for example: /export/sonia/ant-1.7.1
JAVA_HOME <java location>, for example: /export/sonia/jdk1.7.0_04
4. cd <workspace dir>/appserver-sqe/, run "ant startDerby" to start derby database
5. cd <workspace dir>/appserver-sqe/pe/security/auditmodule/, run "ant v3". The following tests failed
update-j2ee-status-searchstrings:
[java] WS HOME appserver-sqe
[java] ====>isPositive property is true
[java] *** Check for expected string in actual file ***
[java] Expected String:SQEPluggableAuditModule::authentication(testuser3,file,true) found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::authentication(j2ee,file,false) found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::webInvocation(null,null,null,hasUserDataPermission,true) NOT found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::webInvocation(testuser3,BASIC,testuser3,hasResourcePermission,true) NOT found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::webInvocation(null,null,null,hasUserDataPermission,true) NOT found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::webInvocation(j2ee,BASIC,j2ee,hasResourcePermission,false) NOT found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::ejbInvocation(j2ee,MethodPermissionsBean,public abstract com.sun.s1peqe.security.authoriz.methodperms.MethodPermRemote com.sun.s1peqe.security.authoriz.methodperms.MethodPermRemoteHome.create(java.lang.String) throws java.rmi.RemoteException,javax.ejb.CreateException,true) found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::ejbInvocation(j2ee,MethodPermissionsBean,public abstract java.lang.String com.sun.s1peqe.security.authoriz.methodperms.MethodPermRemote.authorizedMethod(java.lang.String,int) throws java.rmi.RemoteException,true) found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::ejbInvocation(j2ee,MethodPermissionsBean,public abstract java.lang.String com.sun.s1peqe.security.authoriz.methodperms.MethodPermRemote.sayGoodbye() throws java.rmi.RemoteException,false) found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::ejbAsWebServiceInvocation(StateTaxIFPort,true) found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::webServiceInvocation(/TaxCalWSServlet/statetaxservlet,StateTaxIFPort,true) found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::serverStarted()...invoked after server started found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Expected String:SQEPluggableAuditModule::serverShutdown()...invoked after server shutdown found in file /export/sonia/v4/glassfish4/glassfish/domains/domain1/logs/sqeaudit.log
[java] Generating report at /export/sonia/appserver-sqe/test_results.xml
[java]
[java]
[java] -----------------------------------------
[java] - Audit ejbAsWebServiceInvocation callback-ejbws: PASS -
[java] - Audit ejbInvocation callback-authuser-2: PASS -
[java] - Audit authentication callback-validuser: PASS -
[java] - Audit webInvocation callback-authuser-res: FAIL -
[java] - Audit webInvocation callback-unauthuser-data: FAIL -
[java] - Audit webServiceInvocation callback-servletws: PASS -
[java] - Audit webInvocation callback-authuser-data: FAIL -
[java] - Audit webInvocation callback-unauthuser-res: FAIL -
[java] - Audit serverStarted callback-Started: PASS -
[java] - Audit ejbInvocation callback-authuser: PASS -
[java] - Audit authentication callback-invaliduser: PASS -
[java] - Audit serverShutdown callback-Shutdown: PASS -
[java] - Audit ejbInvocation callback-unauthuser: PASS -
[java] -----------------------------------------
[java] Total PASS: 9
[java] Total FAIL: 4
[java] Total DNR: 0


It seems to me that the audit module is not properly loaded by container, otherwise the audit module will write to the file and messages should be displayed in server.log. These tests were passing in V3.x and failed for GF4.0 only.
The test expect to see following messages:
PluggableAuditModule Audit webInvocation callback-authuser-data|SQEPluggableAuditModule::webInvocation(null,null,null,hasUserDataPermission,true)|
PluggableAuditModule Audit webInvocation callback-authuser-res|SQEPluggableAuditModule::webInvocation(testuser3,BASIC,testuser3,hasResourcePermission,true)|
PluggableAuditModule Audit webInvocation callback-unauthuser-data|SQEPluggableAuditModule::webInvocation(null,null,null,hasUserDataPermission,true)|
PluggableAuditModule Audit webInvocation callback-unauthuser-res|SQEPluggableAuditModule::webInvocation(j2ee,BASIC,j2ee,hasResourcePermission,false)|



 Comments   
Comment by Tim Quinn [ 03/Apr/13 10:31 PM ]

A few more details about this...

At least part of this problem is because the domain.xml configuration does not contain the element for <audit-module name="default"...> in the <security-service>.

The 3.1.2.2 domain.xml contained it. I've opened a separate issue for that problem which is now blocking this one.

Part of the test's "setup" target tries to run

set server-config.security-service.audit-module.default.property.auditOn=true

but the <audit-module> section illustrated here

...
  <configs>
    <config name="server-config>
    ...
      <security-service>
        ...
        <audit-module name="default"...>

is not in domain.xml so the test reports

[exec] Command set failed.
[exec] remote failure: No configuration found for server-config.security-service.audit-module.default.property.auditOn

In 3.1.2.2 there was an explicit section for this "default" audit-module, present but disabled.

That's the topic of the other issue I opened GLASSFISH-20160

Comment by Tim Quinn [ 04/Apr/13 09:02 PM ]

I am reassigning this to the web container team.

I have a fix in my workspace for the related issue GLASSFISH-20160 but that does not fix the failing test.

The output Sonia is seeing is the same that I saw. The test finds the auditing messages as expected for authentication, EJB invocation, web services invocation, and start-up and shutdown. It's just the web invocation notifications that are not recorded as the test expects. That implies that the audit class is being plugged in correctly but there is something specific to the web invocations that is skipping the auditing.

I even enabled the default auditor using

asadmin set server-config.security-service.audit-module.default.property.auditOn=true
asadmin set server-config.security-service.audit-enabled=true

and a breakpoint at the com.sun.enterprise.security.ee.Audit#webInvocation method was never reached, even though a breakpoint at (for example) serverShutdown was.

Comment by Shing Wai Chan [ 05/Apr/13 11:48 PM ]

There is a mismatch in security auditing code.
In AuditManager and AuditModule, we have
webInvocation(String user, Object req, String type, boolean success);
In Audit, we have
webInvocation(String user, HttpServletRequest req, String type, boolean success);

In v3, we have always HttpServletRequest in the second argument.
And SQE is implementing the latter method. This explains why it is not invoked.

This changes is introduced in svn 48354 with the following comments:
"Cleaning up security/core by moving EE specific classes to core-ee. Pre-Req for integrating security/core into nucleus. Ran QL".

Comment by Shing Wai Chan [ 05/Apr/13 11:57 PM ]

The AuditModule and AuditModule have moved to nucleus/security/core which does not depend on javax.servlet-api in this moment.

Comment by Tim Quinn [ 06/Apr/13 03:53 PM ]

If I understand correctly, the change in rev. 48354 changed the type of the second argument in AuditModule#webInvocation from HttpServletRequest to Object (because a subsequent change moved AuditModule (and AuditManager) from appserver into nucleus where HttpServletRequest would not be available).

The SQE class sqe/apserver-sqe/pe/security/auditmodule/simple/src/SQEPluggableAuditModule.java which extends AuditModule did (and still does) contain this method

public void webInvocation(String user, HttpServletRequest req, String type, boolean status)

which used to override the same-named method in AuditModule but no longer does because of the change in the signature of the method in AuditModule.

So it seems that the fix for this is for the SQE test class to:

1. change the signature of its method to

public void webInvocation(String user, Object req, String type, boolean status)

then check and cast the type of "req" to HttpServletRequest, and

2. add @Override to the methods that it overrides from AuditModule so that any changes like this in the future would result in errors when compiling the test class rather than runtime errors that are harder to track down.

So I have changed the component to "test" and reassigned this to Sonia.

Comment by Shing Wai Chan [ 07/Apr/13 12:54 AM ]

In v3 and possibly earlier, com.sun.appserv.security.AuditModule is a public interface. See for instance, http://docs.oracle.com/cd/E19355-01/820-4282/beabw/index.html .
Users create their own audit class by extending AuditModule.
With the new interface change, it will introduce a backward incompatibility here for user.

Comment by Tim Quinn [ 07/Apr/13 06:28 PM ]

Looks like this one's coming back to me.

Comment by Tim Quinn [ 11/Apr/13 12:07 AM ]
  • What is the impact on the customer of the bug?
    Regression. A published API has changed, breaking compatibility. At least one SQE test fails that tests the public API fails.
  • What is the cost/risk of fixing the bug?
    The fix is conceptually simple but moderate in practice. We have had to move the publicly documented classes from nucleus into an appserver module (to restore the broken API which depends on the servlet-api module). But some of the behavior had to remain in nucleus, and this required new base classes in nucleus which the moved classes could extend, changes in nucleus so references to the moved classes became references to the new base classes, a new service in the app server that extends a nucleus service, and changing some injection sites in the app server to inject this new app server service instead of the nucleus service.
  • Is there an impact on documentation or message strings?
    The current documentation does not identify which module a user needs to build against when extending one of the published classes, but it should so there probably should be a doc change – not because of the fix but because the earlier doc was incomplete anyway.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE tests.
  • Which is the targeted build of 4.0 for this fix?
    b85
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in?
    n/a
Comment by Tim Quinn [ 11/Apr/13 06:16 PM ]

I would have attached this as a separate document if I could, so I'm just including it as a long comment instead. This is a description of the underlying problem and the solution approach I sent to the reviewers.

General problem:

In 2011, in the early days of GlassFish 4.0, a lot of work went into separating nucleus-only code from app server code.

One class affected was the abstract class com.sun.appserv.security.AuditModule. In GF 3.x this class's webInvocation method accepted an argument of type HttpServletRequest. Because no nucleus module should depend on the servlet API module (which defines HttpServletRequest) that argument was changed to be of type Object as part of the nucleus/appserver separation.

This allowed the nucleus module to compile without depending on the servlet API module, but it also changed the public interface and therefore broke backward compatibility. These changes correct that.

How Auditing Works (basically) Today

Nucleus contains the AuditManager class (a @Service) which records what AuditModules are configured. Both nucleus and EE components @Inject AuditManager and then invoke its methods to report audited events. AuditManager then broadcasts the events to the registered AuditModules.

General idea of the solution

Restoring the AuditModule API to its published form requires moving it to an appserver module that depends on the servlet-api module, and that means that AuditManager (in nucleus) would not see it. So we need to do more.

Basically we need to:

1. Move the package com.sun.appserv.security and all its classes (they are all publicly documented) from nucleus/security/core to appserver/common/glassfish-api-ee.

2. Nucleus still needs to refer to at least some methods on each of those classes, so create new base classes for each in nucleus/security/core (which the com.sun.appserv.security classes extend) and have nucleus refer to the base classes.

Conceptually, that's all. The details are quite a bit more involved. Here are the details:

1. Move the publicly-documented classes.

a. Move the com.sun.appserv.security package (and its classes) from nucleus/security/core to appserver/common/glassfish-api-ee, adjusting both osgi.properties files accordingly. The other classes in that package (AppservCertificateLoginModule, AppservPasswordLoginModule, AppservRealm, and ProgrammaticLoginPermission) are not EE-specific but they are also publicly documented as being in that package so they move too to avoid split packages.
b. For each class AppservX in com.sun.appserv.security create a nucleus counterpart BaseX in nucleus/security/core in package com.sun.enterprise.security and have AppservX extend BaseX. (The base class for ProgrammaticLoginPermission is BaseProgrammaticLoginPermission.) In each case move any non-EE methods to the base class.
c. Change all nucleus code that refers to any moved class so it refers to the base class instead. This preserves the effective public API of each of the com.sun.appserv.security classes.

2. Deal with the AuditManager class. Nucleus and app server code used to @Inject the AuditManager class.

a. Convert AuditManager to a @Contract interface that specifies only nucleus-related methods.
b. Put the nucleus-related code from the old AuditManager class into the nucleus @Service BaseAuditManager which implements the new AuditManager interface.
c. Put the EE-specific code from the old AuditManager class into the new app server @Service AppServerAuditManager which extends BaseAuditManager (and therefore also implements AuditManager) and has a higher @Rank than BaseAuditManager. At runtime hk2 will prefer the app server AuditManager implementation and inject it at "@Inject AuditManager" sites as well as at "@Inject AppServerAuditManager" sites in app server modules.
d. Nucleus code that currently uses AuditManager uses BaseAuditManager instead.
e. Change app server code that used to inject AuditModule to inject @AppServerAuditManager so it can invoke the EE-specific methods.

Modules affected:

appserver/common/glassfish-ee-api
This module now hosts the com.sun.appserv.security package which used to reside in main/nucleus/security/core. The classes simply extend their new nucleus superclasses which are now in nucleus/security/core but in package com.sun.enterprise.security. Updated osgi.bundle accordingly.

appserver/ejb/ejb-container
Change old references to AuditManager to AppServerAuditManager instead.

appserver/security/core-ee
Added the com.sun.enterprise.security.ee.audit package to host AppServerAuditManager. Updated osgi.bundle accordingly.

appserver/security/webservices.security
Change old references to AuditManager to AppServerAuditManager.

nuclues/security/core
The com.sun.appserv.security package is gone, moved to appserver/common/glassfish-ee-api. New classes in the com.sun.enterprise.security package are the base superclasses for those moved classes. Change previous references to the moved classes to their new base class counterparts.

Here is the list of svn changes that make up this change:

A main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security
A + main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security/AppservRealm.java
A + main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security/AppservPasswordLoginModule.java
A + main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security/AppservCertificateLoginModule.java
A + main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security/ProgrammaticLoginPermission.java
A + main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security/AuditModule.java
M main/appserver/common/glassfish-ee-api/osgi.bundle
M main/appserver/common/glassfish-ee-api/pom.xml
M main/appserver/ejb/ejb-container/src/main/java/org/glassfish/ejb/security/application/EJBSecurityManager.java
M main/appserver/ejb/ejb-container/src/main/java/org/glassfish/ejb/security/factory/EJBSecurityManagerFactory.java
A main/appserver/security/core-ee/src/main/java/com/sun/appserv
A main/appserver/security/core-ee/src/main/java/com/sun/appserv/security
A main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/ee/audit
A + main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/ee/audit/LocalStrings.properties
A + main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/ee/audit/AppServerAuditManager.java
M main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/web/integration/WebSecurityManager.java
M main/appserver/security/core-ee/osgi.bundle
M main/appserver/security/core-ee/pom.xml
M main/appserver/security/webservices.security/src/main/java/com/sun/enterprise/security/webservices/WebServiceSecurity.java
M main/appserver/security/webservices.security/src/main/java/com/sun/enterprise/security/webservices/SecurityServiceImpl.java
M main/appserver/security/webservices.security/src/main/java/com/sun/enterprise/security/jmac/provider/config/PipeHelper.java
D main/nucleus/security/core/src/main/java/com/sun/appserv/security
D main/nucleus/security/core/src/main/java/com/sun/appserv/security/AppservRealm.java
D main/nucleus/security/core/src/main/java/com/sun/appserv/security/AppservCertificateLoginModule.java
D main/nucleus/security/core/src/main/java/com/sun/appserv/security/AppservPasswordLoginModule.java
D main/nucleus/security/core/src/main/java/com/sun/appserv/security/ProgrammaticLoginPermission.java
D main/nucleus/security/core/src/main/java/com/sun/appserv/security/AuditModule.java
A + main/nucleus/security/core/src/main/java/com/sun/enterprise/security/BaseAuditModule.java
A + main/nucleus/security/core/src/main/java/com/sun/enterprise/security/BaseCertificateLoginModule.java
M main/nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/IASRealm.java
M main/nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/PasswordLoginModule.java
M main/nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java
A + main/nucleus/security/core/src/main/java/com/sun/enterprise/security/BaseProgrammaticLoginPermission.java
M main/nucleus/security/core/src/main/java/com/sun/enterprise/security/audit/LocalStrings.properties
M main/nucleus/security/core/src/main/java/com/sun/enterprise/security/audit/AuditManager.java
A + main/nucleus/security/core/src/main/java/com/sun/enterprise/security/audit/BaseAuditManager.java
M main/nucleus/security/core/src/main/java/com/sun/enterprise/security/SecurityLifecycle.java
A + main/nucleus/security/core/src/main/java/com/sun/enterprise/security/BaseRealm.java
A + main/nucleus/security/core/src/main/java/com/sun/enterprise/security/BasePasswordLoginModule.java
M main/nucleus/security/core/src/main/java/com/sun/enterprise/security/SecurityConfigListener.java
M main/nucleus/security/core/src/main/java/com/iplanet/ias/security/auth/realm/IASRealm.java
M main/nucleus/security/core/src/main/java/com/iplanet/ias/security/auth/login/PasswordLoginModule.java
A main/nucleus/security/core/src/main/resources/com/sun/enterprise/security/audit
A + main/nucleus/security/core/src/main/resources/com/sun/enterprise/security/audit/LocalStrings.properties
M main/nucleus/security/core/osgi.bundle

Comment by Tim Quinn [ 11/Apr/13 06:48 PM ]

Fix checked in:

Project: glassfish
Repository: svn
Revision: 61370
Author: tjquinn
Date: 2013-04-11 18:42:02 UTC
Link:

Log Message:
------------
Fix for GLASSFISH-19943

In 2011, in the early days of GlassFish 4.0, a lot of work went into separating nucleus-only code from app server code.

One class affected was the abstract class com.sun.appserv.security.AuditModule. In GF 3.x this class's webInvocation method accepted an argument of type HttpServletRequest. Because no nucleus module should depend on the servlet API module (which defines HttpServletRequest) that argument was changed to be of type Object as part of the nucleus/appserver separation.

This allowed the nucleus module to compile without depending on the servlet API module, but it also changed the public interface and therefore broke backward compatibility. These changes correct that by, basically, moving the com.sun.appserv.security package from the nucleus/security/core module into appserver/common/glassfish-api-ee, but there is much more to it than that. Please see the issue where I've described in detail everything that's going on with this checkin.

Approved: Michael Chen
Reviewed: Jeff T (security changes), Marina (ejb changes), Romain (pom.xml and osgi.bundle changes)
Passed QL, the SQE test which failed before these changes, GlassFish admin dev tests, ejb dev tests, deploymenet dev tests

Revisions:
----------
61370

Modified Paths:
---------------
trunk/main/nucleus/security/core/osgi.bundle
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/IASRealm.java
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/LoginContextDriver.java
trunk/main/appserver/security/webservices.security/src/main/java/com/sun/enterprise/security/webservices/WebServiceSecurity.java
trunk/main/appserver/security/core-ee/osgi.bundle
trunk/main/appserver/common/glassfish-ee-api/pom.xml
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/login/PasswordLoginModule.java
trunk/main/appserver/ejb/ejb-container/src/main/java/org/glassfish/ejb/security/application/EJBSecurityManager.java
trunk/main/appserver/ejb/ejb-container/src/main/java/org/glassfish/ejb/security/factory/EJBSecurityManagerFactory.java
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/audit/AuditManager.java
trunk/main/appserver/security/core-ee/pom.xml
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/SecurityConfigListener.java
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/SecurityLifecycle.java
trunk/main/nucleus/security/core/src/main/java/com/iplanet/ias/security/auth/login/PasswordLoginModule.java
trunk/main/appserver/common/glassfish-ee-api/osgi.bundle
trunk/main/appserver/security/webservices.security/src/main/java/com/sun/enterprise/security/jmac/provider/config/PipeHelper.java
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/audit/LocalStrings.properties
trunk/main/appserver/security/webservices.security/src/main/java/com/sun/enterprise/security/webservices/SecurityServiceImpl.java
trunk/main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/web/integration/WebSecurityManager.java
trunk/main/nucleus/security/core/src/main/java/com/iplanet/ias/security/auth/realm/IASRealm.java

Added Paths:
------------
trunk/main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/ee/audit
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/BaseRealm.java
trunk/main/appserver/security/core-ee/src/main/java/com/sun/appserv
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/BaseProgrammaticLoginPermission.java
trunk/main/nucleus/security/core/src/main/resources/com/sun/enterprise/security/audit
trunk/main/nucleus/security/core/src/main/resources/com/sun/enterprise/security/audit/LocalStrings.properties
trunk/main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/ee/audit/LocalStrings.properties
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/BasePasswordLoginModule.java
trunk/main/appserver/security/core-ee/src/main/java/com/sun/appserv/security
trunk/main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security/AppservPasswordLoginModule.java
trunk/main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security
trunk/main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security/AppservCertificateLoginModule.java
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/BaseAuditModule.java
trunk/main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/ee/audit/AppServerAuditManager.java
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/BaseCertificateLoginModule.java
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/audit/BaseAuditManager.java
trunk/main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security/AppservRealm.java
trunk/main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security/AuditModule.java
trunk/main/appserver/common/glassfish-ee-api/src/main/java/com/sun/appserv/security/ProgrammaticLoginPermission.java





[GLASSFISH-19881] Incorrect Product name Created: 15/Mar/13  Updated: 11/Apr/13  Due: 22/Mar/13  Resolved: 11/Apr/13

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: jclingan Assignee: Snjezana Sevo-Zenzerovic
Resolution: Cannot Reproduce Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A


Tags: 4_0-approved
Participants: jclingan, Snjezana Sevo-Zenzerovic and Tom Mueller

 Description   

/appserver/distributions/glassfish/target/dependency/glassfish4/glassfish/config/branding/glassfish-version.properties contains "BG Server" as the product name property. This appears in the browser when booting the admin console "Starting BG Server 4.0". This should be changed, likely to "GlassFish Server Open Source Edition" if this belongs to the open source branding module.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 02/Apr/13 01:09 PM ]

I think we'll need to add branding module which will override branding properties file to appserver workspace. I'll try to get this in by b83.

Comment by Snjezana Sevo-Zenzerovic [ 11/Apr/13 02:43 PM ]
  • What is the impact on the customer of the bug?

Regression compared to previous releases and significant branding issue.

  • What is the cost/risk of fixing the bug?

Low/moderate risk. Very limited impact on product runtime, but fix does span multiple components (need to create appserver specific branding fragment module with appropriate values and integrate that module into packager).

  • Is there an impact on documentation or message strings?

No.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Admin GUI visual verification, possibly asadmin version subcommand regression testing.

  • Which is the targeted build of 4.0 for this fix?

b85

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

N/A

Comment by Tom Mueller [ 11/Apr/13 05:33 PM ]

I'm not seeing this in my private builds. The content of the glassfish-version.properties file is:

product_name=GlassFish Server Open Source Edition
brief_product_name=GlassFish Server
abbrev_product_name=glassfish
major_version=4
minor_version=0
update_version=
build_id=tomuell-private
version_prefix=
version_suffix=
default_domain_template=appserver-domain.jar
admin_client_command_name=asadmin

The source file (appserver/packager/appserver-base/src/main/resources/config/branding/glassfish-version.properties) has:

product_name=${product.name}
brief_product_name=${brief_product_name}
abbrev_product_name=${abbrev_product_name}
major_version=${major_version}
minor_version=${minor_version}
update_version=${update_version}
build_id=${build.id}
version_prefix=${version_prefix}
version_suffix=${version_suffix}
default_domain_template=${default_domain_template}
admin_client_command_name=${admin_client_command_name}

Product name is set to GlassFish in the appserver/pom.xml file:

<product.name>GlassFish Server Open Source Edition</product.name>

Is this product name being overridden by the build system somewhere?

Comment by Tom Mueller [ 11/Apr/13 05:35 PM ]

A fix for this issue is approved for 4.0. However, it appears that more analysis is required to understand where the problem actually is.

Also, the distribution that actually has this should be identified (the description doesn't do this).

Comment by jclingan [ 11/Apr/13 05:42 PM ]

Tom, I pull this from svn directly:

svn checkout https://svn.java.net/svn/glassfish~svn/trunk/main

I wasn't sure if this was leaking into another build, and that makes it a P1. Regardless, BG Server shouldn't exist anywhere in the trunk, and that would be a P2.

Comment by Snjezana Sevo-Zenzerovic [ 11/Apr/13 10:32 PM ]

This turned out to be a red herring of a sort. So far we are unable to reproduce this with any of RE produced builds or with two developer build setups (Tom's and mine). So, closing as non-reproducible.





[GLASSFISH-19872]  GlassFish does not correctly delist connections which are closed when CDI TransactionScope ends Created: 14/Mar/13  Updated: 13/Apr/13  Resolved: 13/Apr/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: David Zhao
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved jms-2-implementation
Participants: David Zhao, marina vatkina, michael.y.chen, Nigel Deakin and Tom Mueller

 Description   

I think I have found a bug in the enlistment/delistment of connections which are created using the new JMSContext injection CDI extension.

Here's a quick summary:
1. This concerns the case when an injected JMSContext has transaction scope.
2. Run a simple CMT business method that uses an injected JMSContext
3. When the business method completes the transaction is committed and the connection closed. The XAResource is committed and its connection returned to the pool, but something goes wrong with its delistment from the TM.
4. We then wait for idle-timeout-in-seconds seconds to pass
5. Then call the business method again. When the transaction is started the TM thinks the XAresource used in the previous call is still enlisted, and so calls start(). However since its connection has been (quite correctly) destroyed by the pool manager, this fails with an exception.

Here is the session bean:

@TransactionManagement(TransactionManagementType.CONTAINER) 
@Stateless
public class CMBean1 {

    @Inject
    @JMSConnectionFactory("jms/ConnectionFactory")
    JMSContext context;

    @Resource(mappedName="jms/MY_QUEUE")
    Queue queue;

    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void method5() {
	System.out.println("CMBean1.method5() entry");
	JMSProducer producer = context.createProducer();
	System.out.println("Sending message [Message 1]");
        producer.send(queue,"Message 1");

      	System.out.println("CMBean1.method5() exit");
    }
}

To reproduce this, deploy the above bean and call its business method. I reproduced this using glassfish-4.0-b80-03_13_2013. I also turned on the following logging:

com.sun.messaging.jms.ra.DirectXAResource.level=FINE
javax.jms.Connection.mqjmsra.level=FINE

The first time it is called it appears to work fine. Here's an edited extract from the server log for that operation. We'll refer to this in a moment.

INFO:   CMBean1.method5() entry
FINE:   MQJMSRA_DXA1101: DirectXAResource (1635975195) Start   (GlobalTransactionID=[B@3f6f1925, BranchQualifier=[B@16dbecac) 
        (Flags: TMNOFLAGS ), connectionId=5976344228131155712
FINE:   MQJMSRA_DC1101: connectionId=5976344228131155712:createSession():isTransacted=false:acknowledgeMode=1
INFO:   Sending message [Message 1]
INFO:   CMBean1.method5() exit
FINE:   MQJMSRA_DXA1101: DirectXAResource (1635975195) End     (GlobalTransactionID=[B@3f6f1925, BranchQualifier=[B@16dbecac) 
        (Flags: TMNOFLAGS TMSUCCESS ), connectionId=5976344228131155712
FINE:   MQJMSRA_DXA1101: DirectXAResource (1635975195) Commit  (GlobalTransactionID=[B@3f6f1925, BranchQualifier=[B@16dbecac)  
        (onePhase=true), connectionId=5976344228131155712
FINE:   MQJMSRA_DC1101: connectionId=5976344228131155712:close():
INFO:   Running caseJ 1 completed

Now we wait until the connections in the pool reach their idle-timeout-in-seconds. To make this easy to reproduce I had previously set the idle-timeout-in-seconds to 2 seconds.

Now we call the bean's business method again. This throws an exception. The (first) exception logged in the server log, together with nearby logging, is:

INFO:   Running caseJ 2
FINE:   MQJMSRA_DXA1101: DirectXAResource (1635975195) Start   
(GlobalTransactionID=[B@65982356, BranchQualifier=[B@67381735) (Flags: TMNOFLAGS ), connectionId=5976344228131155712
SEVERE:   startTransaction (XA) on JMSService:jmsdirect failed for connectionId:5976344228131155712
due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsservice.JMSServiceException:
startTransaction: connection ID not found: 5976344228131155712
WARNING:   JTS5041: The resource manager is doing work outside a global transaction
javax.transaction.xa.XAException
	at com.sun.messaging.jms.ra.DirectXAResource.sendStartToBroker(DirectXAResource.java:836)
	at com.sun.messaging.jms.ra.DirectXAResource.start(DirectXAResource.java:792)
	at com.sun.jts.jta.TransactionState.startAssociation(TransactionState.java:341)
	at com.sun.jts.jta.TransactionImpl.enlistResource(TransactionImpl.java:212)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.enlistResource(JavaEETransactionImpl.java:660)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistXAResource(JavaEETransactionManagerSimplified.java:1277)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistResource(JavaEETransactionManagerSimplified.java:368)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistComponentResources(JavaEETransactionManagerSimplified.java:1299)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistComponentResources(JavaEETransactionManagerSimplified.java:487)
	at com.sun.ejb.containers.EJBContainerTransactionManager.startNewTx(EJBContainerTransactionManager.java:312)
	at com.sun.ejb.containers.EJBContainerTransactionManager.preInvokeTx(EJBContainerTransactionManager.java:248)
	at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4451)
	at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1939)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy314.method5(Unknown Source)
	at beans.__EJB31_Generated__CMBean1__Intf____Bean__.method5(Unknown Source)
	at servlets.NewServlet.caseBug(NewServlet.java:121)
	at servlets.NewServlet.processRequest(NewServlet.java:52)
	at servlets.NewServlet.doGet(NewServlet.java:82)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	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:176)
	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)
Caused by: com.sun.messaging.jmq.jmsservice.JMSServiceException: startTransaction: connection ID not found: 5976344228131155712
	at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.checkConnectionId(IMQDirectService.java:2521)
	at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.startTransaction(IMQDirectService.java:1535)
	at com.sun.messaging.jms.ra.DirectXAResource.sendStartToBroker(DirectXAResource.java:811)
	... 47 more

It is obvious that something has gone wrong with the enlistment/delistment of resources since this that trace shows that the container is calling XAResource.start when the transaction is being started by the container. At this point no bean code has been executed and there should be no resources enlisted (registered) with the transaction manager.

However the logging shows that when the second transaction is being started, the transaction manager is calling XAResource.start on the same XAResource that was used in the previous transaction, even though the previous transaction has been committed and the connection has been closed (from the perspective of the application).

Look for where DirectXAResource (1635975195) is logged. The big number {[(1635975195)}} is a hashcode used to identify the XAResource instance.

More detailed analysis

Further investigation confirms that when the first transaction was committed by the container, after XAResource.end and XAResource.commit were called, the injected JMSContext scope ends and JMSContext.close is called. This calls Connection.close(), as shown in the above log. Using the debugger I have confirmed that the Connection has broadcast the required javax.resource.spi.ConnectionEvent.CONNECTION_CLOSED event which the container's ConnectionEventListener has received and uses to delist the resource. (Of course calling Connection.close() doesn't physically connection, it simply returns it to the pool).

Then, when idle-timeout-in-seconds is reached, the connection is physically closed by the container by calling the destroy method on the ManagedConnection.

Next, we call the bean's business method a second time. The CMT transaction is started by the container, which causes the TM to call start on all enlisted resources. At this point there shouldn't be any resources to enlist. However the TM somehow still has a reference to the XAResource that was used in the previous transaction and calls start. Since the underlying connection has been closed, this throws an exception. The error that is thrown is

SEVERE:   startTransaction (XA) on JMSService:jmsdirect failed for connectionId:5976344228131155712 
due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsservice.JMSServiceException: 
startTransaction: connection ID not found: 5976344228131155712

which means that start is called even though the connection is closed.

Steps to reproduce
I have created a NetBeans project which allows this bug to be demonstrated easily. It can be downloaded from http://java.net/projects/jms-spec/downloads/download/GlassFishIssue2.zip . Simply unzip this file, open it in NetBeans and deploy and run it. Wait for the browser to open, click on the link, and wait for the error. Then look at the server log.

If you don't to use NetBeans, the key files are:

  • src\java\beans\CMBean1.java - the session bean
  • src\java\servlets
    NewServlet
    - a simple servlet which calls the bean once, waits 3 seconds, and calls it again
  • setup\glassfish-resources.xml - defines the connection factory resource required by the application and sets its idle-timeout-in-seconds to 2.


 Comments   
Comment by Nigel Deakin [ 14/Mar/13 03:29 PM ]

I believe this bug is causing failures in the JMS CTS tests.

Comment by Nigel Deakin [ 21/Mar/13 04:41 PM ]

At the request of project management, setting fix version to 4.0 since this appears to cause CTS failures.

Comment by marina vatkina [ 26/Mar/13 06:59 PM ]

I think the issue is in the JMS container code, or in the JMS resource handling (check how JDBS connection timeouts are handled).

(I needed to call asadmin add-resources to add the jms/MY_QUEUE)

This is what's going on:

The enlist and delist for a single com.sun.messaging.jms.ra.DirectXAResource was done correctly and the resource became NOT_ASSOCIATED at the end of the 1st call.

On the 2nd call the enlist fails in preInvoke, but the TM code only logs this error (the change in v2 code from throwing exception to just logging it, is marked with bugid 4664284 - I'm not sure if we can find that old bug and the reason for the change now):

javax.transaction.xa.XAException
    at com.sun.messaging.jms.ra.DirectXAResource.sendStartToBroker(DirectXAResource.java:836)
    at com.sun.messaging.jms.ra.DirectXAResource.start(DirectXAResource.java:792)
    at com.sun.jts.jta.TransactionState.startAssociation(TransactionState.java:341)
    at com.sun.jts.jta.TransactionImpl.enlistResource(TransactionImpl.java:212)
...
Caused by: com.sun.messaging.jmq.jmsservice.JMSServiceException: startTransaction: connection ID not found: 1403783500477313536
    at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.checkConnectionId(IMQDirectService.java:2521)
    at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.startTransaction(IMQDirectService.java:1535)

So the method starts execution, and when it tries to use the resource, it fails with:

Caused by: com.sun.messaging.jmq.jmsserver.util.BrokerException: Unknown XID 6D6172696E612D7 (snip remainder)

But now the exception is propagated back to the caller, and there are also exceptions in postInvoke, which seems that the failure cause is different.

Comment by Nigel Deakin [ 27/Mar/13 10:05 AM ]

On the second call to the business method, when the transaction was started by the container,
the TM called XAResource.start on an obsolete (and destroyed) XAResource left over
from the previous call to the business method. Why was this? There should be no resources
enlisted at this point.

You mention that this causes a connection ID not found. This is what I reported in my
initial report, and is because the pool timeout has destroyed the connection.

Comment by marina vatkina [ 27/Mar/13 06:02 PM ]

I suspect it is the same problem as GLASSFISH-19769

Comment by David Zhao [ 28/Mar/13 01:49 AM ]

At the first time the CMT bean is called, when the EJB container completes TX, it triggers JMSContext @PreDestroy and then it sends javax.resource.spi.ConnectionEvent.CONNECTION_CLOSED event to connector runtime. So connector delists resource according to JCA spec. But when delisting occurs, connector runtime gets com.sun.enterprise.web.WebComponentInvocation(ComponentInvocation) from InvocationManager. Why WebComponentInvocation here? I guess EjbInvocation might be expected because it is called from EJB container.

"http-listener-1(1)" daemon prio=6 tid=0x326bdc00 nid=0x1f24 runnable [0x33afe000]
   java.lang.Thread.State: RUNNABLE
	at org.glassfish.api.invocation.ComponentInvocation.getTransaction(ComponentInvocation.java:172)
	at com.sun.enterprise.resource.rm.ResourceManagerImpl.unregisterResource(ResourceManagerImpl.java:273)
	at com.sun.enterprise.resource.rm.ResourceManagerImpl.delistResource(ResourceManagerImpl.java:235)
	at com.sun.enterprise.resource.pool.PoolManagerImpl.resourceClosed(PoolManagerImpl.java:379)
	at com.sun.enterprise.resource.allocator.ConnectorAllocator$ConnectionListenerImpl.connectionClosed(ConnectorAllocator.java:81)
	at com.sun.messaging.jms.ra.ConnectionEventListener.sendEvent(ConnectionEventListener.java:144)
	at com.sun.messaging.jms.ra.ManagedConnection.sendEvent(ManagedConnection.java:700)
	at com.sun.messaging.jms.ra.DirectConnection.close(DirectConnection.java:273)
	- locked <0x1204cf90> (a com.sun.messaging.jms.ra.DirectConnection)
	at com.sun.messaging.jms.ra.DirectConnection.close(DirectConnection.java:232)
	at com.sun.messaging.jmq.jmsclient.JMSContextImpl.close(JMSContextImpl.java:562)
	- locked <0x1204d098> (a java.util.HashSet)
	at org.glassfish.jms.injection.AbstractJMSContextManager.cleanup(AbstractJMSContextManager.java:117)
	- locked <0x11f4d2f0> (a org.glassfish.jms.injection.TransactedJMSContextManager)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
	at org.jboss.weld.annotated.runtime.RuntimeAnnotatedMembers.invokeMethod(RuntimeAnnotatedMembers.java:78)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:72)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:65)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:104)
	at org.jboss.weld.injection.producer.BeanInjectionTarget.preDestroy(BeanInjectionTarget.java:64)
	at org.glassfish.jms.injection.JMSCDIExtension$LocalBean.destroy(JMSCDIExtension.java:224)
	at org.jboss.weld.context.ForwardingContextual.destroy(ForwardingContextual.java:31)
	at org.glassfish.cdi.transaction.TransactionScopedBean.afterCompletion(TransactionScopedBean.java:78)
	at com.sun.jts.jta.SynchronizationImpl.after_completion(SynchronizationImpl.java:146)
	at com.sun.jts.CosTransactions.RegisteredSyncs.distributeAfter(RegisteredSyncs.java:191)
	at com.sun.jts.CosTransactions.TopCoordinator.afterCompletion(TopCoordinator.java:2589)
	- locked <0x120434e0> (a com.sun.jts.CosTransactions.TopCoordinator)
	at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:414)
	at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:231)
	- locked <0x12043580> (a com.sun.jts.CosTransactions.TerminatorImpl)
	at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:622)
	at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:331)
	at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:185)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:859)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4477)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2011)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1981)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy179.method5(Unknown Source)
	at beans.__EJB31_Generated__CMBean1__Intf____Bean__.method5(Unknown Source)
	at servlets.NewServlet.caseBug(NewServlet.java:112)
	at servlets.NewServlet.processRequest(NewServlet.java:52)
	at servlets.NewServlet.doGet(NewServlet.java:82)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	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:174)
	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)

Comment by marina vatkina [ 28/Mar/13 02:20 AM ]

That might explain why the resource wasn't unregistered from the EJB - it was registered while it was the EjbInvocation. Now we need to trace why the invocation has changed - the EJB container is clearly on the invocation stack...

Comment by David Zhao [ 28/Mar/13 03:33 AM ]

Debuging it further, It shows the EjbInvocation was poped up from InvocationManager before doing TX processing. That explains why the connector runtime gets WebComponentInvocation instead of expected EjbInvocation when delisting jms resource.

Class com.sun.ejb.containers.BaseContainer, around line 2000,

BaseContainer.java
if ( inv.ejb != null ) {
            // counterpart of invocationManager.preInvoke
            if (! inv.useFastPath) {
                invocationManager.postInvoke(inv);  <-- pop up EjbInvocation from InvocationManager.
                delistExtendedEntityManagers(inv.context);
            } else {
                doTxProcessing = doTxProcessing && (inv.exception != null);
            }
            
            try {
                if( doTxProcessing ) {
                    postInvokeTx(inv);  <-- process TX commitment, which will trigger jms resource delistment.
                }
            } catch (Exception ex) {
                _logger.log(Level.FINE, "ejb.postinvoketx_exception", ex);
                if (ex instanceof EJBException)
                    inv.exception = (EJBException) ex;
                else
                    inv.exception = new EJBException(ex);
            }
            
            releaseContext(inv);
        }
Comment by marina vatkina [ 01/Apr/13 06:36 PM ]

Adding __pm to both, the setup resource and the name for the injected resource worked!!!!

Now we need to test with the flag, and either just document its use in CAPS or figure out how to do it auto-magically.

Comment by Nigel Deakin [ 02/Apr/13 05:14 PM ]

Information for the 4.0 bug review process:

What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?

This is a new feature and by definition is not a regression, has no impact on existing applications and has no impact on performance. It causes intermittent failure of the CTS test com/sun/ts/tests/jms/ee20/cditests/usecases/Client.java#beanUseCaseB.

A new user who uses this feature is likely to hit this bug. Bug GLASSFISH-19872 causes intermittent failures (exceptions) in an important use case. Bug GLASSFISH-19769 causes constant failures in a use case where the behaviour is not defined, but which users are nevertheless likely to encounter.

What is the cost/risk of fixing the bug?

The fix is already written so there is no cost in fixing this bug.

The fix is quite simple, It fixes both GLASSFISH-19872 (this issue) and GLASSFISH-19769 (which is a different use case).

It is moderately risky as it involves changes to the way in which injected JMSContext resources are handled by the transaction manager.

The fix to GLASSFISH-19872 is limited because it involves following an approach already adopted for database resources.

The fix to GLASSFISH-19769 is more risky as it introduces a significant difference between the way that injected and non-injected JMSContext objects behave in the use case described in that issue. Even though no spec defines what behaviour is required, the fact that the two modes behave completely differently in this use case may be considered undesirable.

Is there an impact on documentation or message strings?

This release does not include documentation so there is no impact on documentation.

The behaviour should however probably be documented on the GlassFish wiki.

This change has no impact on message strings.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

All JMS CTS tests. All GlassFish devtest involving injection of JMSContext objects.

Which is the targeted build of 4.0 for this fix?

TBD

Comment by Tom Mueller [ 02/Apr/13 10:06 PM ]

Approved for 4.0

Comment by David Zhao [ 10/Apr/13 02:49 AM ]

Committed __PM workaround by revision 61190.

Comment by michael.y.chen [ 10/Apr/13 11:15 PM ]

Is this fixed with revision 61190?

Comment by marina vatkina [ 10/Apr/13 11:21 PM ]

Partially.

Comment by marina vatkina [ 13/Apr/13 07:33 PM ]

Enable workaround to use __pm resource upon request: either via "-Dorg.glassfish.jms.skip-resource-registration-in-transaction=true" or choosing an __pm resource for the JMSContext.

See rev 61418 of trunk/main/appserver/jms/gf-jms-injection/src/main/java/org/glassfish/jms/injection/InjectableJMSContext.java





[GLASSFISH-19850] Can't inject JMSContext when security manager is enabled Created: 13/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b85

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

Issue Links:
Dependency
blocks GLASSFISH-19774 Add QuickLook test case for JMSContex... Closed
Tags: jms-2-implementation
Participants: David Zhao, jjsnyder83 and Nigel Deakin

 Description   

When I tried to add the JMS injection quicklook case, I found it failed in hudson jobs because security manager is enabled by default in hudson jobs.

It is easy to be reproduced: Enable the security manager for the domain by adding an option in the JVM Settings and then restart glassfish domain/server. We can see the following exception when accessing the EJB/Web with JMSContext injection (deployment succeeds).

[2013-03-13T14:04:01.787+0800] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1363154641787] [levelValue: 800] [[
Loading application [injection] at [/injection]]]

[2013-03-13T14:04:01.849+0800] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1363154641849] [levelValue: 800] [[
injection was successfully deployed in 3,416 milliseconds.]]

[2013-03-13T14:04:02.910+0800] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core.security] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154642910] [levelValue: 800] [[
JACC Policy Provider: Failed Permission Check, context(injection/injection)- permission(("java.lang.reflect.ReflectPermission" "suppressAccessChecks"))]]

[2013-03-13T14:04:03.066+0800] [glassfish 4.0] [SEVERE] [ejb.stateless_ejbcreate_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154643066] [levelValue: 1000] [[
EJB5070: Exception creating stateless session bean : [SimpleEjb]]]

[2013-03-13T14:04:03.066+0800] [glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154643066] [levelValue: 900] [[
EJB5184:A system exception occurred during an invocation on EJB SimpleEjb, method: public boolean org.glassfish.tests.jms.injection.SimpleEjb.testRequestScope()]]

[2013-03-13T14:04:03.066+0800] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=26 _ThreadName=http-listener-1(1)] [timeMillis: 1363154643066] [levelValue: 900] [[

javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:435)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2534)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1924)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy310.testRequestScope(Unknown Source)
at org.glassfish.tests.jms.injection._EJB31_GeneratedSimpleEjbIntf__Bean_.testRequestScope(Unknown Source)
at org.glassfish.tests.jms.injection.TestServlet.processRequest(TestServlet.java:80)
at org.glassfish.tests.jms.injection.TestServlet.doGet(TestServlet.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:323)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:321)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:356)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:214)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1676)
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:176)
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)
Caused by: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:700)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)
... 46 more
Caused by: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:514)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)
... 48 more
Caused by: com.google.common.collect.ComputationException: org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy class for bean org.glassfish.jms.injection.JMSCDIExtension$LocalBean@e5472a with class class org.glassfish.jms.injection.RequestedJMSContextManager using classloader WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:400)
at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:181)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:681)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:745)
at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76)
at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:108)
at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:58)
at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:29)
at org.jboss.weld.injection.producer.DefaultInstantiator.newInstance(DefaultInstantiator.java:67)
at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:84)
at org.glassfish.jms.injection.JMSCDIExtension$LocalBean.create(JMSCDIExtension.java:208)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:687)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:745)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:88)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:368)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:377)
at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
at org.jboss.weld.injection.producer.StatelessSessionBeanInjector.inject(StatelessSessionBeanInjector.java:50)
at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:133)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:96)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance(JCDIServiceImpl.java:251)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1701)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:475)
... 50 more
Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy class for bean org.glassfish.jms.injection.JMSCDIExtension$LocalBean@e5472a with class class org.glassfish.jms.injection.RequestedJMSContextManager using classloader WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:298)
at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:253)
at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:100)
at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:157)
at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:147)
at org.jboss.weld.bean.proxy.ClientProxyProvider.access$000(ClientProxyProvider.java:49)
at org.jboss.weld.bean.proxy.ClientProxyProvider$1.apply(ClientProxyProvider.java:57)
at org.jboss.weld.bean.proxy.ClientProxyProvider$1.apply(ClientProxyProvider.java:53)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:358)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:396)
... 76 more
Caused by: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
at java.security.AccessController.checkPermission(AccessController.java:560)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:102)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:91)
at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:408)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:291)
... 88 more
]]



 Comments   
Comment by Nigel Deakin [ 19/Mar/13 12:34 PM ]

Setting fix version to 4.0. This bug currently causes failure of the JMSContext injection quicklook tests

Comment by jjsnyder83 [ 19/Mar/13 03:39 PM ]

JBoss is aware of the issue. See https://issues.jboss.org/browse/WELD-1242

Comment by David Zhao [ 10/Apr/13 02:30 AM ]

JJ,

I tried latest build with revision 67218, and can't reproduce the problem. Could you please verify if/when the defect is available to be closed?

-david

Comment by jjsnyder83 [ 10/Apr/13 10:47 AM ]

David,
Can you try it again on the latest trunk. Before you start quicklook do the following:

1) start GF
2) use asadmin to do the following 2 commands

asadmin create-module-config cdi-service
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=true

3) stop GF

4) run quicklook.

Then do it all over again except set the enable-implicit-cdi=false.

thanks,
JJ

Comment by David Zhao [ 11/Apr/13 07:57 AM ]

JJ,

I tried jms injection devtests and QL with both enable-implicit-cdi=true and enable-implicit-cdi=false against revision 61359, it worked fine and all passed.

-david





[GLASSFISH-19769] GlassFish does not correctly delist connections which are closed when CDI request ends Created: 05/Mar/13  Updated: 13/Apr/13  Resolved: 13/Apr/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: marina vatkina
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation 4_0-approved
Participants: David Zhao, marina vatkina, Nigel Deakin and Tom Mueller

 Description   

I think I have found a bug in the enlistment/delistment of connections which are created using the new JMSContext injection CDI extension.

Here's a quick summary:
1. This concerns the case when the injected JMSContext has request scope.
2. When the connection is created it is enlisted and saved in the EJBInvocation
3. When the business method returns and the CDI request ends, the connection is closed and the TM tries to remove it from its list of enlisted resources. However it looks in the WebComponentInvocation and so doesn't find it.
4. This means that the EJBInvocation still contains a resource, which causes an exception the next time the business method is called.

Here is the session bean in its simplest form:

@Inject JMSContext context;
@Inject UserTransaction ut;

void businessMethod(){
   JMSProducer producer = context.createProducer();
   ut.begin();
   // send message here (optional)
   ut.end();
}

To reproduce this, deploy and run the above bean. (Note that due to GLASSFISH-19760 you need to use glassfish-4.0-b78-02_26_2013 or earlier)

The first time it is called it appears to work fine. However the second time it is called the call to ut.begin() throws an internal exception which is caught at JavaEETransactionManagerSimplified.enlistComponentResources(ComponentInvocation) line: 1301. This causes XAResource.end() to be called before ut.begin() returns, which is obviously wrong.

This doesn't throw an exception to the bean unless you actually use the JMSProducer to send a message (within the transaction). This works the first time and fails the second time since the XAResource is in the wrong state.

More detailed analysis

Here's a more details analysis of the problem based on an examination using the debugger. This analysis may be incorrect, in which case please go back to the initial problem and assess what the cause it.

The call to context.createProducer() causes the {[JMSContext}}, and its underlying Connection, to be created. This follows the same code path as any other code in a session bean which creates a Connection: stack trace follows. The newly-created Connection's XAResource is registered with the transaction manager and added to a list of resources managed by the EJBInvocation. This has a context field which contains a SessionContextImpl. Its resources field is an ArrayList to which the new resource is added. Here's the stack trace for the point where this is done:

Daemon Thread [http-listener-1(3)] (Suspended (breakpoint at line 547 in JavaEETransactionManagerSimplified))	
	owns: RequestedJMSContextManager  (id=1839)	
	JavaEETransactionManagerSimplified.registerComponentResource(TransactionalResource) line: 547	
	ResourceManagerImpl.registerResource(ResourceHandle) line: 147	
	ResourceManagerImpl.enlistResource(ResourceHandle) line: 112	
	PoolManagerImpl.getResource(ResourceSpec, ResourceAllocator, ClientSecurityInfo) line: 211	
	ConnectionManagerImpl.getResource(int, PoolManager, ManagedConnectionFactory, ResourceSpec, Subject, ConnectionRequestInfo, ClientSecurityInfo, ConnectorDescriptor, boolean) line: 337	
	ConnectionManagerImpl.internalGetConnection(ManagedConnectionFactory, ResourcePrincipal, ConnectionRequestInfo, boolean, String, Object, boolean) line: 306	
	ConnectionManagerImpl.allocateConnection(ManagedConnectionFactory, ConnectionRequestInfo, String, Object) line: 195	
	ConnectionManagerImpl.allocateConnection(ManagedConnectionFactory, ConnectionRequestInfo, String) line: 170	
	ConnectionManagerImpl.allocateConnection(ManagedConnectionFactory, ConnectionRequestInfo) line: 165	
	DirectConnectionFactory._allocateConnection(String, String) line: 592	
	DirectConnectionFactory.createConnection(String, String) line: 266	
	DirectConnectionFactory.createConnection() line: 245	
	JMSContextImpl.<init>(ConnectionFactory, ContainerType, int) line: 206	
	DirectConnectionFactory.createContext(int) line: 291	
	RequestedJMSContextManager(AbstractJMSContextManager).createContext(String, JMSContextMetadata, ConnectionFactory) line: 78	
	RequestedJMSContextManager(AbstractJMSContextManager).getContext(String, String, JMSContextMetadata, ConnectionFactory) line: 93	
	RequestedJMSContextManager$Proxy$_$$_WeldClientProxy.getContext(String, String, JMSContextMetadata, ConnectionFactory) line: not available	
	InjectableJMSContext.delegate() line: 124	
	InjectableJMSContext(ForwardingJMSContext).createProducer() line: 61	
	BMBean1.method3() line: 37	
	GeneratedMethodAccessor105.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 601	
	EJBSecurityManager.runMethod(Method, Object, Object[]) line: 1038	
	EJBSecurityManager.invoke(Method, boolean, Object, Object[]) line: 1110	
	StatelessSessionContainer(BaseContainer).invokeBeanMethod(EjbInvocation) line: 4713	
	EjbInvocation.invokeBeanMethod() line: 630	
	AroundInvokeChainImpl.invokeNext(int, InterceptorManager$AroundInvokeContext) line: 822	
	EjbInvocation.proceed() line: 582	
	SessionBeanInterceptor.aroundInvoke(InvocationContext) line: 42	
	GeneratedMethodAccessor102.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 601	
	AroundInvokeInterceptor.intercept(InterceptorManager$AroundInvokeContext) line: 883	
	AroundInvokeChainImpl.invokeNext(int, InterceptorManager$AroundInvokeContext) line: 822	
	EjbInvocation.proceed() line: 582	
	_SystemInterceptorProxy_Serializable(SystemInterceptorProxy).doAround(InvocationContext, Method) line: 162	
	_SystemInterceptorProxy_Serializable(SystemInterceptorProxy).aroundInvoke(InvocationContext) line: 144	
	GeneratedMethodAccessor101.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 601	
	AroundInvokeInterceptor.intercept(InterceptorManager$AroundInvokeContext) line: 883	
	AroundInvokeChainImpl.invokeNext(int, InterceptorManager$AroundInvokeContext) line: 822	
	InterceptorManager.intercept(InterceptorManager$InterceptorChain, InterceptorManager$AroundInvokeContext) line: 369	
	StatelessSessionContainer(BaseContainer).__intercept(EjbInvocation) line: 4685	
	StatelessSessionContainer(BaseContainer).intercept(EjbInvocation) line: 4673	
	EJBLocalObjectInvocationHandler.invoke(Class, Method, Object[]) line: 212	
	EJBLocalObjectInvocationHandlerDelegate.invoke(Object, Method, Object[]) line: 88	
	$Proxy344.method3() line: not available	
	__EJB31_Generated__BMBean1__Intf____Bean__.method3() line: not available	
	NewServlet.caseG() line: 240	
	NewServlet.processRequest(HttpServletRequest, HttpServletResponse) line: 75	
	NewServlet.doGet(HttpServletRequest, HttpServletResponse) line: 113	
	NewServlet(HttpServlet).service(HttpServletRequest, HttpServletResponse) line: 687	
	NewServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 790	
	StandardWrapper.service(ServletRequest, ServletResponse, Servlet) line: 1682	
	StandardWrapperValve.invoke(Request, Response) line: 318	
	StandardContextValve.invoke(Request, Response) line: 160	
	StandardPipeline.doInvoke(Request, Response, boolean) line: 734	
	StandardPipeline.invoke(Request, Response) line: 673	
	StandardHostValve.invoke(Request, Response) line: 176	
	CoyoteAdapter.doService(Request, Request, Response, Response, boolean) line: 357	
	CoyoteAdapter.service(Request, Response) line: 260	
	ContainerMapper.service(Request, Response) line: 188	
	ContainerMapper(HttpHandler).doHandle(Request, Response) line: 164	
	HttpServerFilter.handleRead(FilterChainContext) line: 175	
	ExecutorResolver$9.execute(Filter, FilterChainContext) line: 119	
	DefaultFilterChain.executeFilter(FilterExecutor, Filter, FilterChainContext) line: 273	
	DefaultFilterChain.executeChainPart(FilterChainContext, FilterExecutor, int, int, DefaultFilterChain$FiltersState) line: 200	
	DefaultFilterChain.execute(FilterChainContext) line: 134	
	DefaultFilterChain.process(Context) line: 112	
	ProcessorExecutor.execute(Context) line: 77	
	TCPNIOTransport.fireIOEvent(IOEvent, Connection, IOEventProcessingHandler) line: 820	
	AbstractIOStrategy.fireIOEvent(Connection, IOEvent, IOEventProcessingHandler, Logger) line: 113	
	WorkerThreadIOStrategy.run0(Connection, IOEvent, IOEventProcessingHandler) line: 115	
	WorkerThreadIOStrategy.access$100(Connection, IOEvent, IOEventProcessingHandler) line: 55	
	WorkerThreadIOStrategy$WorkerThreadRunnable.run() line: 135	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).doWork() line: 564	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).run() line: 544	
	DefaultWorkerThread(Thread).run() line: 722	

Subsequently UserTransaction.begin is called and all the XAResource}}s in the above {{ArrayList are enlisted by calling XAresource.start().

Then UserTransaction.end is called. Again the XAResource}}s in the above {{ArrayList are delisted by calling XAresource.end().

Finally the business method returns, and a short time later the CDI session context ends. This causes the injected JMSContext's "dispose" method to be called which calls connection.close.

As with any call to connection.close(), this broadcasts a javax.resource.spi.ConnectionEvent.CONNECTION_CLOSED event which the container's ConnectionEventListener receives and uses to delist the resource. This is done using JavaEETransactionManagerSimplified.unregisterComponentResource. This calls invMgr.getCurrentInvocation() to return the current invocation which returns a WebComponentInvocation. This has no resources and so the XAResource is not unregistered.

Here's the stack trace for the code which performs the call to JavaEETransactionManagerSimplified.unregisterComponentResource.

	JavaEETransactionManagerSimplified.unregisterComponentResource(TransactionalResource) line: 415	
	ResourceManagerImpl.unregisterResource(ResourceHandle, int) line: 274	
	ResourceManagerImpl.delistResource(ResourceHandle, int) line: 235	
	PoolManagerImpl.resourceClosed(ResourceHandle) line: 379	
	ConnectorAllocator$ConnectionListenerImpl.connectionClosed(ConnectionEvent) line: 81	
	ConnectionEventListener.sendEvent(int, Exception, Object) line: 144	
	ManagedConnection.sendEvent(int, Exception, Object) line: 692	
	DirectConnection.close(boolean) line: 273	
	DirectConnection.close() line: 232	
	JMSContextImpl.close() line: 524	
	RequestedJMSContextManager(AbstractJMSContextManager).cleanup() line: 118	
	GeneratedMethodAccessor104.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 601	
	SecureReflections$13.work() line: 267	
	SecureReflections$13(SecureReflectionAccess<T>).run() line: 52	
	SecureReflections$13(SecureReflectionAccess<T>).runAsInvocation() line: 137	
	SecureReflections.invoke(Object, Method, Object...) line: 263	
	WeldMethodImpl<T,X>.invoke(Object, Object...) line: 174	
	ManagedBean<T>(AbstractClassBean<T>).defaultPreDestroy(T) line: 389	
	ManagedBean$ManagedBeanInjectionTarget<T>.preDestroy(T) line: 182	
	ManagedBean<T>.destroy(T, CreationalContext<T>) line: 305	
	SerializableContextualImpl<C,I>(ForwardingContextual<T>).destroy(T, CreationalContext<T>) line: 31	
	HttpRequestContextImpl(AbstractContext).destroy(String) line: 128	
	HttpRequestContextImpl(AbstractContext).destroy() line: 142	
	HttpRequestContextImpl(AbstractManagedContext).deactivate() line: 41	
	HttpRequestContextImpl(AbstractBoundContext<S>).deactivate() line: 72	
	HttpRequestContextImpl.deactivate() line: 86	
	WeldListener.requestDestroyed(ServletRequestEvent) line: 103	
	WebModule(StandardContext).fireRequestDestroyedEvent(ServletRequest) line: 5251	
	StandardHostValve.postInvoke(Request, Response) line: 257	
	CoyoteAdapter.doService(Request, Request, Response, Response, boolean) line: 359	
	CoyoteAdapter.service(Request, Response) line: 260	
	ContainerMapper.service(Request, Response) line: 188	
	ContainerMapper(HttpHandler).doHandle(Request, Response) line: 164	
	HttpServerFilter.handleRead(FilterChainContext) line: 175	
	ExecutorResolver$9.execute(Filter, FilterChainContext) line: 119	
	DefaultFilterChain.executeFilter(FilterExecutor, Filter, FilterChainContext) line: 273	
	DefaultFilterChain.executeChainPart(FilterChainContext, FilterExecutor, int, int, DefaultFilterChain$FiltersState) line: 200	
	DefaultFilterChain.execute(FilterChainContext) line: 134	
	DefaultFilterChain.process(Context) line: 112	
	ProcessorExecutor.execute(Context) line: 77	
	TCPNIOTransport.fireIOEvent(IOEvent, Connection, IOEventProcessingHandler) line: 820	
	AbstractIOStrategy.fireIOEvent(Connection, IOEvent, IOEventProcessingHandler, Logger) line: 113	
	WorkerThreadIOStrategy.run0(Connection, IOEvent, IOEventProcessingHandler) line: 115	
	WorkerThreadIOStrategy.access$100(Connection, IOEvent, IOEventProcessingHandler) line: 55	
	WorkerThreadIOStrategy$WorkerThreadRunnable.run() line: 135	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).doWork() line: 564	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).run() line: 544	
	DefaultWorkerThread(Thread).run() line: 722	

Now consider what happens the next time the business method is called.

When the connection is created it is registered in the EJBInvocation. This appears to be the same object as in the previous call, and so already contains the XAResource from the previous call. As a result, the EJBInvocation now contains two XAResource objects, which appear to be identical.

Then, when UserTransaction.begin() is called, the JavaEETransactionManagerSimplified attempts to enlist both. This works fine for the first XAResource, and XAResource.start is called. However when it tries to enlist the second XAResource, since this is the same object the JavaEETransactionManagerSimplified detects that this has already been enlisted, and so throws a "java.lang.IllegalStateException: Wrong XAState: 0". This is caught further up in the stack, in a catch block in JavaEETransactionManagerSimplified.enlistComponentResources. This invokes some cleanup code which causes XAResource.end() to be called. Remember we're still in UserTransaction.begin() here. This means that when UserTransaction.begin() returns, the XAResource is not in the correct state for it to be used by JMS.



 Comments   
Comment by marina vatkina [ 05/Mar/13 06:03 PM ]

Is this a stateless or a stateful session bean?

Comment by Nigel Deakin [ 06/Mar/13 10:08 AM ]

Stateless. I've supplied a test case directly.

Comment by Nigel Deakin [ 14/Mar/13 05:59 PM ]

I've confirmed that I still see this bug with glassfish-4.0-b80-03_13_2013

Comment by Nigel Deakin [ 14/Mar/13 06:10 PM ]

Test case available at
http://java.net/projects/jms-spec/downloads/download/GLASSFISH-19769.zip

Comment by marina vatkina [ 26/Mar/13 10:50 PM ]

I think the problem is in the JMS code that does not unregister JMSContext from the resource list early enough. Here are the details:

1. Currently JMSContext is registered with the TM during JMSContextImpl.<init> (-> DirectConnectionFactory.createConnection call).
2. Registering means adding resource to the resource list, which in EJB container is the bean context instance.
3. The bean context instance is created when the bean is created, and they stay together until the instance is destroyed.
4. The bean context is associated with the current invocation until the bean method completes (postInvoke completes).
5. A JDBC connection is unregistered at the time of the connection.close() but there is no corresponding method on the JMSContext for the user to call.
6. Unregister call from the JMSContext when it comes it is too late because the context is cleared from the invocation. Which means that it can't be removed from the list. But remember that the context itself stays around so the resource list actually stays there...
7. On the next run step #1 is executed again, but it's a List, so we have 2 resources, the old one and the new one.
8. The old one is re-enlisted, and the new one throws an exception (because they both point to the same resource?)
9. It all goes upside-down after that...

Note, the list is completely cleared only when component is destroyed.

Comment by marina vatkina [ 27/Mar/13 12:04 AM ]

JMS team needs to decide what's next....

Comment by David Zhao [ 27/Mar/13 07:33 AM ]

In this case, the request scoped JMSContext looks like being destroyed at web moudle servlet request end, not at ejb module method end because it is not ejb remote method invocation. Per CDI spec, the request context is destroyed:

at the end of the servlet request, after the service() method, all doFilter() methods, and all requestDestroyed() and onComplete() notifications return,
after the web service invocation completes,
after the asynchronous observer notification completes,
after the EJB remote method invocation, asynchronous method invocation, timeout or message delivery completes, or
after the message delivery to the MessageListener completes.

This can be verified by adding breakpoint at @PreDestroy method of RequestedJMSContextManager.

Daemon Thread [http-listener-1(4)] (Suspended (breakpoint at line 111 in AbstractJMSContextManager))	
	owns: RequestedJMSContextManager  (id=422)	
	RequestedJMSContextManager(AbstractJMSContextManager).cleanup() line: 111	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 57	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 601	
	SecureReflections$13.work() line: 264	
	SecureReflections$13(SecureReflectionAccess<T>).run() line: 52	
	SecureReflections$13(SecureReflectionAccess<T>).runAsInvocation() line: 137	
	SecureReflections.invoke(Object, Method, Object...) line: 260	
	RuntimeAnnotatedMembers.invokeMethod(AnnotatedMethod<X>, Object, Object...) line: 78	
	DefaultLifecycleCallbackInvoker<T>.invokeMethods(List<AnnotatedMethod<? super T>>, T) line: 72	
	DefaultLifecycleCallbackInvoker<T>.preDestroy(T, Instantiator<T>) line: 65	
	BeanInjectionTarget<T>(BasicInjectionTarget<T>).preDestroy(T) line: 104	
	BeanInjectionTarget<T>.preDestroy(T) line: 64	
	JMSCDIExtension$LocalBean.destroy(Object, CreationalContext) line: 224	
	SerializableContextualFactory$DefaultSerializableContextual<C,I>(ForwardingContextual<T>).destroy(T, CreationalContext<T>) line: 31	
	HttpRequestContextImpl(AbstractContext).destroyContextualInstance(ContextualInstance<T>) line: 150	
	HttpRequestContextImpl(AbstractContext).destroy() line: 163	
	HttpRequestContextImpl(AbstractManagedContext).deactivate() line: 41	
	HttpRequestContextImpl(AbstractBoundContext<S>).deactivate() line: 72	
	HttpRequestContextImpl.deactivate() line: 88	
	WeldListener.requestDestroyed(ServletRequestEvent) line: 168	
	WebModule(StandardContext).fireRequestDestroyedEvent(ServletRequest) line: 5261	
	StandardHostValve.postInvoke(Request, Response) line: 255	
	CoyoteAdapter.doService(Request, Request, Response, Response, boolean) line: 359	
	CoyoteAdapter.service(Request, Response) line: 260	
	ContainerMapper.service(Request, Response) line: 188	
	ContainerMapper(HttpHandler).runService(Request, Response) line: 191	
	ContainerMapper(HttpHandler).doHandle(Request, Response) line: 168	
	HttpServerFilter.handleRead(FilterChainContext) line: 189	
	ExecutorResolver$9.execute(Filter, FilterChainContext) line: 119	
	DefaultFilterChain.executeFilter(FilterExecutor, Filter, FilterChainContext) line: 288	
	DefaultFilterChain.executeChainPart(FilterChainContext, FilterExecutor, int, int, DefaultFilterChain$FiltersState) line: 206	
	DefaultFilterChain.execute(FilterChainContext) line: 136	
	DefaultFilterChain.process(Context) line: 114	
	ProcessorExecutor.execute(Context) line: 77	
	TCPNIOTransport.fireIOEvent(IOEvent, Connection, IOEventProcessingHandler) line: 838	
	AbstractIOStrategy.fireIOEvent(Connection, IOEvent, IOEventProcessingHandler, Logger) line: 113	
	WorkerThreadIOStrategy.run0(Connection, IOEvent, IOEventProcessingHandler) line: 115	
	WorkerThreadIOStrategy.access$100(Connection, IOEvent, IOEventProcessingHandler) line: 55	
	WorkerThreadIOStrategy$WorkerThreadRunnable.run() line: 135	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).doWork() line: 564	
	FixedThreadPool$BasicWorker(AbstractThreadPool$Worker).run() line: 544	
	DefaultWorkerThread(Thread).run() line: 722	
Comment by marina vatkina [ 27/Mar/13 05:59 PM ]

JMSContext needs to be unregistered earlier or a new instance should not be created and registered...

Comment by marina vatkina [ 01/Apr/13 06:36 PM ]

It's the same problem as in GLASSFISH-19872 because adding __pm to both, the setup resource and the name for the injected resource worked!!!!

Comment by marina vatkina [ 03/Apr/13 02:08 AM ]

Reopening as this issue needs to be addressed separately

Comment by Tom Mueller [ 11/Apr/13 01:52 PM ]

Approved for 4.0 since the fix for GLASSFISH-19872 fixes this bug too and it is approved.

Comment by marina vatkina [ 13/Apr/13 07:31 PM ]

Fixed by storing ComponentInvocation at which JMSContextEntry was created with the JMSContextEntry.

Sending gf-jms-injection/pom.xml
Sending gf-jms-injection/src/main/java/org/glassfish/jms/injection/AbstractJMSContextManager.java
Sending gf-jms-injection/src/main/java/org/glassfish/jms/injection/InjectableJMSContext.java
Sending gf-jms-injection/src/main/java/org/glassfish/jms/injection/JMSContextEntry.java
Transmitting file data ....
Committed revision 61418.





[GLASSFISH-19484] Windows installer version "glassfish-4.0-b69-windows-ml" installation stuck on 41%. Created: 29/Dec/12  Updated: 25/Apr/13  Resolved: 25/Apr/13

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 4.0_b69
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: Mohamed Taman Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 Professional SP1


Tags: adoptajsr
Participants: dm_zelensky, Mohamed Taman and Snjezana Sevo-Zenzerovic

 Description   

I am adopting a JSR 339 JAX-RS and installing the latest version glassfish 4_b69 on my machine.

While installation begins and the progress bar show the installation progress, It stuck on 41% and no more progress for more than one hour and more.

the same Issue I am facing from version glassfish 4_b67.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 24/Jan/13 03:39 PM ]

Do you still see this issue? I suspect that installer got stuck during UC client installation and this could be due to repository or proxy issues. If the issue persists, could you please try unchecking options to install and enable update client and see if that lets the installation go through?

Comment by dm_zelensky [ 27/Jan/13 12:46 AM ]

issue remains here with 4.0-b72, tested different possible options and scenarios that wizard provides. Not only "-ml" package but plain glassfish-4.0-b72-windows.exe also. (at Windows Server 2008 R2).
"run as administrator" tried also.

Comment by Snjezana Sevo-Zenzerovic [ 15/Feb/13 03:29 PM ]

This seems to be the duplicate of GLASSFISH-19634. Leaving this one open since it came in first. Needs some further investigation and setting up of 4.0 IPS repositories.

Comment by Snjezana Sevo-Zenzerovic [ 25/Apr/13 07:32 AM ]

I did reproduce this while fixing other recently reported Windows installation issues and this was actually caused by class version mismatch in the case where install wrapper picked up JDK or JRE 6 installation to use with installer runtime. Fix for issue GLASSFISH-20019 will also address this, so marking as fixed in b85.





[GLASSFISH-16186] Unable to convert ejbRef for ejb to a business object, the container picks the wrong interface Created: 09/Mar/11  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 4.0_b85

Type: Bug Priority: Major
Reporter: fabmars Assignee: jjsnyder83
Resolution: Fixed Votes: 11
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x86, JDK 1.6.0_24, Glassfish 3.1 GA, JSF2.


File Attachments: Text File GLASSFISH-16186.log     Zip Archive sources.zip     File truc-dev-autodeploy.ear    
Tags: 3_1_1-next 3_1_1-scrubbed 3_1_2-exclude weld-int-required
Participants: fabmars, jjsnyder83, marina vatkina, scatari, Sivakumar Thyagarajan and tlcksnyder

 Description   

I've been converting a quite big site from EE5 to EE6, with CDI of course.
There's ONE sole thing that bugs me but it's quite peculiar.

I have:

  • @Named @Stateless TimeProviderImpl extends SimpleTimeProvider implements LocalTimeProvider.
  • SimpleTimeProvider implements TimeProvider (the latter defining some methods, the former implementing them. No annotations.)
  • LocalTimeProvider is @Local and also extends TimeProvider and does nothing more.

If I read the EJB 3.1 spec §4.9.7, I believe I'm still compliant.

Now, if I try to access this EJB from my web application with EL or through a ManagedBean where it's @Inject injected, I get the exception below.
If I try to access it through the ManagedBean where it's @EJB injected, my page displays correctly (as it used to work in EE5).

Example and logs are attached. Deploy EAR and call http://localhost:8080/TrucWeb/test.jsf

We're somewhere around these but it's slightly different.
http://java.net/jira/browse/GLASSFISH-13040
http://java.net/jira/browse/GLASSFISH-11140
https://issues.jboss.org/browse/WELD-301
https://issues.jboss.org/browse/WELD-305
https://issues.jboss.org/browse/WELD-381
https://issues.jboss.org/browse/WELD-625

If i had to take a wild guess I'd say the issue lies in the Glassfish/Weld integration.



 Comments   
Comment by Sivakumar Thyagarajan [ 13/Jun/11 08:45 AM ]

Transferring to the EJB container team for further evaluation and confirm if this scenario is valid. During investigation, it appears that in EJBContainerServicesImpl.getBusinessObject() for this EJBRef, the business interface com.dummy.time.TimeProvider doesn't seem to belong to the list of local business interfaces for that EJB.

Comment by marina vatkina [ 13/Jun/11 04:16 PM ]

For an interface to be an EJB business interface, it needs to be explicitly denoted as such on the class that is marked as @Stateless. Interfaces implemented by the superclasses, are not component interfaces.

Comment by fabmars [ 15/Jun/11 08:08 AM ]

Excuse me but the point never was to have com.dummy.time.TimeProvider as a business interface. Based on this assumtion, Marina's reasoning definitely makes sense.

But this is NOT the point of the issue, neither this of the attached example.

The point is that something here works with the EJB container and NOT with the CDI container. Please consider reopening this issue and reassigning.

Comment by marina vatkina [ 15/Jun/11 01:24 PM ]

reopening as it seems like a CDI error

Comment by marina vatkina [ 15/Jun/11 01:26 PM ]

Siva,

See in the description:

*Now, if I try to access this EJB from my web application with EL or through a ManagedBean where it's @Inject injected, I get the exception below.
If I try to access it through the ManagedBean where it's @EJB injected, my page displays correctly*

Comment by Sivakumar Thyagarajan [ 15/Jun/11 11:25 PM ]

Marina: Yes, this appears to work in the @EJB case and not in the @Inject case, as for handling the @Inject case, the weld integration code goes through the EJBContainerServices API to resolve an EJB reference, and the EJBContainerServicesImpl doesn't seem to provide com.dummy.time.TimeProvider as a business interface for that ejb-ref.

Assigning to Cheng who handles EJB and requesting him to investigate further.

Comment by marina vatkina [ 15/Jun/11 11:54 PM ]

Siva,

EJB container is correct - com.dummy.time.TimeProvider is not a business interface. Weld integration shouldn't ask for it.

Back to cdi.

Comment by Sivakumar Thyagarajan [ 19/Jun/11 09:29 AM ]

Here is the scenario. An injection of
@Inject
private LocalTimeProvider timeProvider1;
is performed in a SessionScoped Bean.

The Weld bean proxy for the SessionBean Object reference being injected(timeProvider1) tries to get [1] the BusinessObject when a method is invoked on it. Weld seems to use [2] the declaring class of the method being invoked to determine the business interface. Though the business interface of the Bean is set to com.dummy.time.LocalTimeProvider, the class that declares the method being invoked ("getThisMonth()") is com.dummy.time.TimeProvider.

Therefore, the Weld implementation calls SessionObjectReferenceImpl.getBusinessObject("com.dummy.time.TimeProvider"), which fails, as TimeProvider is not a Business interface. As per [3], the businessInterfaceType must be a type of the business interface of the bean. Weld appears to be incorrect in asking through the SPI for a Business Object for a non-Business interface. Filed a Weld issue https://issues.jboss.org/browse/WELD-921 to get this fixed.

[1] https://github.com/weld/core/blob/76c31d311cf1ff449eb2d5c80943b913651bed96/impl/src/main/java/org/jboss/weld/bean/proxy/EnterpriseBeanProxyMethodHandler.java#L123
[2]https://github.com/weld/core/blob/76c31d311cf1ff449eb2d5c80943b913651bed96/impl/src/main/java/org/jboss/weld/bean/proxy/EnterpriseBeanProxyMethodHandler.java#L146
[3] https://github.com/weld/api/blob/master/weld-spi/src/main/java/org/jboss/weld/ejb/api/SessionObjectReference.java#L31

Comment by Sivakumar Thyagarajan [ 14/Nov/11 08:50 AM ]

The Weld 1.1.3 release that is being integrated into 3.1.2 does not have a fix for WELD-921, and so marking this as 3_1_2-exclude

Comment by scatari [ 06/Dec/11 06:32 PM ]

https://issues.jboss.org/browse/WELD-921 seems to be fixed in 1.2.0 Beta1. We recently integrated 1.1.4 to GF 3.1.2. Can we selectively port fixes from 1.2.0 to 1.1.4?

Comment by Sivakumar Thyagarajan [ 11/Dec/11 03:50 PM ]

@scatari: Selectively including fixes from another branch, would require GlassFish to create a modified release of Weld, and so we are not doing that. The fix for WELD-921 has only been targetted for 1.2.0.Beta1 IIRC.

Marking this issue as "3_1_2_exclude", as a fix doesn't seem to be available in the 3.1.2 timeframe.

Comment by Sivakumar Thyagarajan [ 10/Dec/12 05:27 AM ]

Transferring to JJ Snyder

Comment by tlcksnyder [ 28/Mar/13 05:20 PM ]

Weld bug https://issues.jboss.org/browse/WELD-921 is targeted for Weld 2.0.0.CR1. Retest with CR1.

Comment by jjsnyder83 [ 02/Apr/13 07:05 PM ]

Committed revision 61099.





Generated at Thu Apr 17 17:23:23 UTC 2014 using JIRA 4.0.2#472.