<< Back to previous view

[GLASSFISH-20302] Java EE 7 SDK cobundles with MacOS JDK do not correctly install JDK content Created: 12/Apr/13  Updated: 16/Apr/13  Resolved: 13/Apr/13

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

Type: Bug Priority: Critical
Reporter: Snjezana Sevo-Zenzerovic 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: bhavya_h_s, Snjezana Sevo-Zenzerovic and Tom Mueller

 Description   

Java EE 7 SDK cobundles with JDK 7u17 for MacOS do not install JDK content files. The root cause is incorrect JDK openInstaller component definition which does not contain reference to InstallableUnit for MacOS platform. Including change control data.

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

This issue renders Java EE SDK with JDK cobundle for MacOS unusable since final installation image does not contain JDK files.

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

Low risk. Component definition needs to include reference to InstallableUnit archive which contains JDK payload content.

  • 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/SDK distribution testing.

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

SDK b84.

  • 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



 Comments   
Comment by Tom Mueller [ 12/Apr/13 07:15 PM ]

Approved for 4.0.

Comment by bhavya_h_s [ 16/Apr/13 06:22 AM ]

Verified the fix with B84.
jdk1.7_17 is bundled properly and new directory for jdk is created under $INSTALL_HOME

$ ls glassfish4/
bin/ glassfish/ install/ jdk7/ pkg/ uninstall.exe updatetool/
docs/ index.html javadb/ mq/ samples/ uninstall.sh var/

$ glassfish4/jdk7/bin/java -version
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)





[GLASSFISH-20293] SDK 4.0 - Websocket tictactoe client sample fails to build - missing javafx.jar error Created: 12/Apr/13  Updated: 17/Apr/13  Resolved: 17/Apr/13

Status: Closed
Project: glassfish
Component/s: web_socket
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

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

Installed java_ee_sdk-7-b83-unix.sh*, on OEL6 machine, using Maven version 3.0.5. Configured Maven environment as noted in http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/BG+Development+Environment+Guide, using JDK 1.7.0_13 for Linux.


Tags:
Participants: Alex Pineda and Daniel

 Description   

In the "Building, Deploying, and Running the Application" instructions it states that run client one has to do the following:

"Running the client standalone application. Note: We need two client endpoints, so you may need to do the operations below twice in two different terminal.

cd app_dir/client

mvn clean install"

o [test@wolfrun] $ cd $WORKSPACE/glassfish4/samples/websocket/tictactoe/client
o [test@wolfrun] $ mvn install

The following error is reported.
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.glassfish-samples:tictactoe-client:jar:4.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-jar-plugin is missing. @ line 88, column 21
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building tictactoe-client 4.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for com.oracle:javafx:jar:2.2 is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.079s
[INFO] Finished at: Thu Apr 11 17:12:34 PDT 2013
[INFO] Final Memory: 5M/149M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project tictactoe-client: Could not resolve dependencies for project org.glassfish-samples:tictactoe-client:jar:4.0-SNAPSHOT: Failure to find com.oracle:javafx:jar:2.2 in http://gf-maven.us.oracle.com/nexus/content/groups/internal-gf-nexus/ was cached in the local repository, resolution will not be reattempted until the update interval of internal-glassfish-nexus has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

There is a note on the instructions that if "any exceptions from JavaFX, you may need to check if the client pom.xml is using the correct PATH to jfxrt.jar". When I look at the tictactoe/client/pom.xml file, it points to <javafx.runtime.lib.jar>${java.home}/jre/lib/jfxrt.jar</javafx.runtime.lib.jar> and I can see it on my system under $JAVA_HOME/jre/lib/jfxrt.jar . So, it looks like my environment is proper. Not sure where the problem lies.



 Comments   
Comment by Daniel [ 12/Apr/13 06:40 PM ]

@Alex,
Can I know your configurations for the path of Java_Home?

Comment by Alex Pineda [ 12/Apr/13 06:56 PM ]

I have configured JAVA_HOME in my ~/.bashrc file and is set as:
export JAVA_HOME=/usr/local/tools/jdk1.7.0_13

Is set a system variable and is my PATH
[test@wolfrun] $ $ echo $JAVA_HOME
/usr/local/tools/jdk1.7.0_13

[test@wolfrun] $ echo $PATH
/usr/local/tools/jdk1.7.0_13/bin:/usr/local/tools/ant-1.7.1/bin:/home/agpineda/workspace/glassfish4/glassfish/bin:/usr/local/tools/maven-3.0.5/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/NX/bin:.

I hope this helps.

My guess is that somewhere in a property file I need to modify java.home and add my location, but I don't know where this variable is located at and the documentation does not provide the information.

Comment by Daniel [ 12/Apr/13 08:14 PM ]

@Alex

Could you please try run the commend first:
mvn install:install-file -Dfile=$JAVA_HOME/jre/lib/jfxrt.jar -DgroupId=com.oracle -DartifactId=javafx -Dversion=2.2 -Dpackaging=jar

And then, try to run 'mvn install' under /client

Dose it work? please let me know. Thanks

Comment by Alex Pineda [ 17/Apr/13 05:10 AM ]

Tried your suggestion and I see in build 84 that you have added the instructions to the index.html file. It worked for me. Issue is resolved. Please update the bug accordingly.

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

The sample requires JavaFx lib which is included in JDK, but still need to be imported into local maven repository. So that developers can add JavaFx lib from pom.xml like other dependencies.

Updated the documentation to guide user install JavaFx lib first before running the sample.

mvn install:install-file -Dfile=$JAVA_HOME/jre/lib/jfxrt.jar -DgroupId=com.oracle -DartifactId=javafx -Dversion=2.2 -Dpackaging=jar

Commited version 1124

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

Bug fixed





[GLASSFISH-20271] Creating a Topic via CLI results in a strange AdminUI display -> Topic is listed as a Connection Facotry Created: 10/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

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

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

Windows/Linux, Glassfish 3.1.2.2


Tags:
Participants: Anissa Lam and kickmetoandy

 Description   

When i create a Topic in a unzipped glassfish via the command
./asadmin create-jms-resource --restype javax.jms.Topic testTopic2
Then the admin UI displays the just created testTopic2 as a Destination Resource and as a Connection Factory.
If i select the entry under the connection factory i get an error and the following message in the log:
SEVERE: RestResponse.getResponse() gives FAILURE. endpoint = 'http://localhost:4848/management/domain/resources/connector-connection-pool/testTopic2'; attrs = '{}'



 Comments   
Comment by Anissa Lam [ 10/Apr/13 09:26 PM ]

This has been fixed in GlassFish 4.0 when we redo the JMS pages.
This now shows up correctly under Connectors -> Admin Object Resource
and
JMS Resources -> Destination Resources.





[GLASSFISH-20261] ADMINGUI : log level does not described some values Created: 10/Apr/13  Updated: 12/Apr/13  Resolved: 12/Apr/13

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

Type: Bug Priority: Major
Reporter: RameshT Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WIN 7 FF19 IE


Tags: doc log values
Participants: Anissa Lam, Mike Fitch and RameshT

 Description   

Module log level ( server-config -> logger setttings -> log levels )

levels are described as:
Level

Drop-down list from which you can select a logging level to be applied to all selected modules.
Change Level

Button to change the logging level for one or more selected modules.

The following log levels are available. They are listed in order from highest to lowest.

SEVERE

Events that interfere with normal program execution.
WARNING

Warnings, including exceptions.
INFO

Messages related to server configuration or server status, excluding errors.
CONFIG

Messages related to server configuration.
FINE

Minimal verbosity.
FINER

Moderate verbosity.
FINEST

Maximum verbosity.
OFF

No logging messages.
===============================

In the above "ALERT and "EMERGENCY" are not described in the document.



 Comments   
Comment by Mike Fitch [ 10/Apr/13 03:37 PM ]

Information about these two levels was included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152. This would appear in GlassFish nightly builds beginning 4Apr2013.

Comment by RameshT [ 12/Apr/13 10:40 AM ]

I donot see the values list in Build84 ( promoted ) and Build85 ( nightly ).
Hence reopening the issue.

Issue 1 : "ALERT and "EMERGENCY" are not described in the documentAttached the screenshot.

Issue 2 : In the RHS table of content is not listing.

Issue 3 : In IE and OEL FF I am seeing 404 - not found

Comment by Mike Fitch [ 12/Apr/13 03:54 PM ]

This was working in the Apr 5, 2013 nightly. Something has changed since then in the online help machinery because the help itself hasn't changed. Therefore, setting the Fix Version to Unknown and assigning to admin_gui and Anissa Lam to look into.

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

Sorry, i am very confused.
Can you tell me whats the issue here ?
what exactly is not working ? gui screen doesn't have ALERT/EMERGENCY or the OLH doesn't have that described ?
Which version is fine (if such version exists) and which version is broken ?

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

Actually the entire online help is not available. Every page gives 404 error in build 84.
GLASSFISH-20301 is opened for that.
I don't know why Ramesh said he didn't see the specified value, when the page itself is not available at all.

I assign this back to Mike, since this is about the content of particular page. He can close this after the GLASSFISH-20301 is fixed.

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

Remarking this issue as Resolved/Fixed and resetting the Fix Version to 4.0_b84_RC1.

The help for the "Module Log Levels" screen was updated to include the following:

EMERGENCY
The server is in an unusable state. A severe system failure or panic has occurred.

ALERT
A particular service is in an unusable state. Automatic recovery is not possible.

This change was committed to main-docs in svn revision 61142 and appeared in 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 shows these changes. 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.





[GLASSFISH-20253] Can't update, the update center reports "Cannot find specified Config Resource. Config may have been deleted." Created: 09/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

Type: Bug Priority: Critical
Reporter: Mohamed Taman Assignee: Anissa Lam
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MAC OS X 10.8.3


Tags: fishcat updatecenter
Participants: Anissa Lam and Mohamed Taman

 Description   

While I am navigating the admin server, the message "Total # of available updates : 1" has been appeared, which is above Common tasks tree pan.

1- Click on update icon, and the system will navigate you to the Available Updates page.

2- After a while the page opened and show the following error message "Cannot find specified Config Resource. Config may have been deleted." and there is no button to update.



 Comments   
Comment by Anissa Lam [ 09/Apr/13 11:52 PM ]

This is duplicate of GLASSFISH-20156 which has been fixed.
Please wait for build 84 -RC1 to verify the fix.





[GLASSFISH-20248] Regression: @Interceptors on method in a superclass of @ManagedBean is ignored Created: 09/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

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

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

Tags: 4_0-approved
Participants: marina vatkina

 Description   

This is a regression from early versions introduced by changes to support lifecycle callback method-level interceptors. The change is to restore previous iteration on all public methods of the managed bean (getMethods() vs. getDeclaredMethods()).

  • What is the impact on the customer of the bug?
    Interceptors spec non-compliant behavior, and the previous changes were not correct as they caused CTS regressions
  • How likely is it that a customer will see the bug and how serious is the bug?
    It will break existing applications with superclasses in @ManagedBean's
  • What CTS failures are caused by this bug?
    MB interceptors tests
  • What is the cost/risk of fixing the bug?
    1 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?
    ManagedBean 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


 Comments   
Comment by marina vatkina [ 10/Apr/13 05:47 AM ]

Sending dol/src/main/java/com/sun/enterprise/deployment/annotation/handlers/ManagedBeanHandler.java
Committed revision 61282.





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

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

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

Tags:
Participants: arungupta, jjsnyder83 and TangYong

 Description   

For a bean defined as:

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

b83 is throwing the following error:

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

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

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



 Comments   
Comment by TangYong [ 10/Apr/13 02:09 PM ]

arungupta, jjsnyder83

My analyze is as following:

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

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

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

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

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

Combining with 1 and 2, the exception happened.

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

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

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

Thanks
--Tang

Comment by TangYong [ 10/Apr/13 02:37 PM ]

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

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

Made the transactional interceptors implement Serializable.
Committed revision 61342.





[GLASSFISH-20246] batch related log messages when undeploying an application Created: 09/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

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

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

Tags:
Participants: Mahesh Kannan and Tom Mueller

 Description   

The following log messages are output when undeploying a simple web application (just an index.jsp file that does not use batch):

[#|2013-04-09T16:53:28.341-0500|INFO|glassfish 4.0||_ThreadID=102;_ThreadName=Thread-3;_TimeMillis=1365544408341;_LevelValue=800;|
  ** BatchRuntimeHelper:: App Undeployed. tagName: server-config:helloworld|#]

[#|2013-04-09T16:53:28.341-0500|INFO|glassfish 4.0||_ThreadID=102;_ThreadName=pool-20-thread-1;_TimeMillis=1365544408341;_LevelValue=800;|
  Error while purging jobs: java.lang.NullPointerException|#]


 Comments   
Comment by Mahesh Kannan [ 10/Apr/13 05:03 AM ]

This is fixed.

svn commit -m "Fix for 20246. Had to handle the corner case where server is restarted and immediately app is undeployed"
Sending batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Transmitting file data .
Committed revision 61280.





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

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

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

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


Tags:
Participants: adriaaaaan, Jeremy_Lv and jjsnyder83

 Description   

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

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

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

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



 Comments   
Comment by adriaaaaan [ 10/Apr/13 09:11 AM ]

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

Comment by Jeremy_Lv [ 10/Apr/13 09:24 AM ]

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

Comment by adriaaaaan [ 10/Apr/13 10:15 AM ]

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





[GLASSFISH-20235]  WebSocket API 1.0-rc5 and Tyrus 1.0-rc3 integration Created: 09/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

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

Tags: 4_0-approved
Participants: Pavel Bucek and Tom Mueller

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

Fixed functionality; no breaking change.

  • 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?

blocker for Tyrus (we have to implement latest API version). No regression, no other criteria, no CTS failures.

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

cost - nothing (already done); risk - not applicable.

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

already answered above.

  • Is there an impact on documentation or message strings?

no.

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

WebSocket TCK suite.

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

b84

  • related issues:

WEBSOCKET_SPEC-180
TYRUS-166
TYRUS-169
TYRUS-170
TYRUS-168

  • patch:
Index: appserver/pom.xml
===================================================================
--- appserver/pom.xml	(revision 61239)
+++ appserver/pom.xml	(working copy)
@@ -120,8 +120,8 @@
         <jaxr.version>JAXR_RA_20091012</jaxr.version>
         <weld.version>2.0.0.CR1</weld.version>
         <wsdl4j.version>1.6.2</wsdl4j.version>
-        <websocket-api.version>1.0-rc4</websocket-api.version>
-        <tyrus.version>1.0-rc2</tyrus.version>
+        <websocket-api.version>1.0-rc5</websocket-api.version>
+        <tyrus.version>1.0-rc3</tyrus.version>
         <jsonp.version>1.0-b06</jsonp.version>
         <concurrent-api.version>1.0-b06</concurrent-api.version>
         <concurrent.version>1.0-b07</concurrent.version>


 Comments   
Comment by Tom Mueller [ 09/Apr/13 02:14 PM ]

Approved for 4.0.





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

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

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

Tags:
Participants: jjsnyder83

 Description   

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



 Comments   
Comment by jjsnyder83 [ 10/Apr/13 03:07 PM ]

Fixed with Weld 2.0.0.CR2





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

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

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

Tags:
Participants: jjsnyder83

 Comments   
Comment by jjsnyder83 [ 08/Apr/13 03:09 PM ]

Committed revision 61226.





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

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

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
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 03:30 PM ]

Fixed by JBoss





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

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

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
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 [ 08/Apr/13 11:31 PM ]

Committed revision 61235.





[GLASSFISH-20216] [Dev Tests Failed] Some of the deployment dev tests failed Created: 08/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

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

Win7, Mac OS.


Tags: 40_regression
Participants: Hong Zhang and Jeremy_Lv

 Description   

When I run the dev tests of the deployment comp, Some of the test case failed. Here's my steps about reproduce.
1). Update the latest source of glassfish and dev tests.

2). unzip the built glassfish zip file into a disk

3). Set the following env. variables as below:
S1AS_HOME=<glassfish v3 installation>
APS_HOME=<appserv-tests>

4). Check the following env. variables to set with these values:
SECURE=false
DEPL_TARGET=PE
Nothing needs to be done if you don't have these env. var set.

5). Start the domain.
asadmin start-domain -v

6). Simply type "ant all" from appserv-tests/devtests/deployment.

7). After run all of the tests, you will find some informations as follows:
[echo] [PASSED] AppClientAnnotationTest : testDescriptors,
[echo] [FAILED] EjbAnnotationTest : testDescriptors,
[echo] [FAILED] InheritanceAnnotationTest : testDescriptors,
[echo] [PASSED] WebAnnotationTest : testDescriptors,

All in all, the EjbAnnotationTest and InheritanceAnnotationTest shouldn't be failed.

BTW: I have run the dev tests in my personal MAC OS, it seems these two tests still can't be passed.



 Comments   
Comment by Jeremy_Lv [ 08/Apr/13 11:27 AM ]

Here's some of the error messages comes out when I only run the EjbAnnotationTest.

[junit] ------------- Standard Error -----------------
    [junit] 4 08, 2013 7:15:55 午後 devtests.deployment.util.StandaloneProcessor
 run
    [junit] 情報: processing E:\GF_MAIN\appserv-tests/devtests/deployment/build
    [junit] 4 08, 2013 7:15:56 午後 devtests.deployment.util.DescriptorContentCo
mparator compareContent
    [junit] SEVERE: last compared Field = private java.util.Map org.glassfish.de
ployment.common.Descriptor.displayNames
    [junit] ------------- ---------------- ---------------

Sometimes the Standard Error will be as follows:

[junit] ------------- Standard Error -----------------
    [junit] 4 08, 2013 7:18:08 午後 devtests.deployment.util.StandaloneProcessor
 run
    [junit] 情報: processing E:\GF_MAIN\appserv-tests/devtests/deployment/build
    [junit] 4 08, 2013 7:18:09 午後 devtests.deployment.util.DescriptorContentCo
mparator compareContent
    [junit] SEVERE: last compared Field = private boolean org.glassfish.ejb.depl
oyment.descriptor.EjbSessionDescriptor.isStateless
    [junit] ------------- ---------------- ---------------

I did run about all of the devtest on windows at 09/Nov/12 and all of the tests have passed. So I add the tags as a 40_regression issues.

Comment by Jeremy_Lv [ 08/Apr/13 01:44 PM ]

I have revert the dev test version to the r56938 and test the gfv4.0-b62 on my Mac OS and the deployment annotation test run successfully.

I have also confirmed the latest version of dev tests and glassfish released version and the EjbAnnotationTest and InheritanceAnnotationTest will be failed.

Comment by Jeremy_Lv [ 08/Apr/13 02:23 PM ]

Hong:
I have just confirm the dev tests about r59448 you have checked in caused this issue, I have just run dev tests changed at r59448 and gfv4.0-b77 and this phenomenon can be reproduced.

please take a look about the golden file changes you have checked in to reflected new name space.

Thanks

Jeremy

Comment by Hong Zhang [ 08/Apr/13 02:42 PM ]

The test changes were made to go with the changes in the GlassFish workspace to change schema namespace from java.sun.com to jcp.org. Do you have both latest GlassFish build as well as test workspace when you ran these tests? It's strange that the corresponding name space test change would cause issues on windows but not other platforms. Can you check what the name space look like in the generated xml (that will be used to compare with the golden file)? For each sub test directory, the generated xml should be under its META-INF subdirectory.

Comment by Jeremy_Lv [ 08/Apr/13 02:50 PM ]

it not only happened on windows platform but also happened in my personal Mac OS 10.8.3.

Do you have both latest GlassFish build as well as test workspace when you ran these tests?

yes, I have update both of the dev tests and glassfish resource to test the dev tests.

Can you check what the name space look like in the generated xml (that will be used to compare with the golden file)? For each sub test directory, the generated xml should be under its META-INF subdirectory.

fine, I will check about it later.

BTW: The issue is not only happened in my win7 platform but also my Mac OS 10.8.3 although it can be passed on ubuntu platform.

Comment by Jeremy_Lv [ 08/Apr/13 03:31 PM ]

Hong:

I have sent the generated xml file to you through my gmail, pl. take a look about it.

Thanks

Comment by Jeremy_Lv [ 09/Apr/13 02:02 AM ]

Hong:

I have confirmed this issue is occurred by the description language defined as “en”. After I have delete all of the definition about xml:lang=”en” and the tests can be run successfully.

Here’s some in the test results to test the annotation:

[echo] [PASSED] AppClientAnnotationTest : testDescriptors,
[echo] [PASSED] EjbAnnotationTest : testDescriptors,
[echo] [PASSED] InheritanceAnnotationTest : testDescriptors,
[echo] [PASSED] WebAnnotationTest : testDescriptors,

Here's the changes:

Index: ejb/goldenfiles/ejb-jar.xml
===================================================================
--- ejb/goldenfiles/ejb-jar.xml	(revision 61221)
+++ ejb/goldenfiles/ejb-jar.xml	(working copy)
@@ -2,7 +2,7 @@
 <ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" metadata-complete="true" version="3.2" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
   <enterprise-beans>
     <session>
-      <display-name xml:lang="en">myStatefulTest1</display-name>
+      <display-name>myStatefulTest1</display-name>
       <ejb-name>myStatefulTest1</ejb-name>
       <business-remote>test.ejb.stateful.SFHello</business-remote>
       <ejb-class>test.ejb.stateful.StatefulTest1</ejb-class>
@@ -35,7 +35,7 @@
       <passivation-capable>true</passivation-capable>
     </session>
     <session>
-      <display-name xml:lang="en">StatefulTest2</display-name>
+      <display-name>StatefulTest2</display-name>
       <ejb-name>StatefulTest2</ejb-name>
       <business-remote>test.ejb.stateful.SFHello</business-remote>
       <ejb-class>StatefulTest2</ejb-class>
@@ -48,7 +48,7 @@
       <passivation-capable>true</passivation-capable>
     </session>
     <session>
-      <display-name xml:lang="en">myStatelessTest1</display-name>
+      <display-name>myStatelessTest1</display-name>
       <ejb-name>myStatelessTest1</ejb-name>
       <business-local>test.ejb.stateless.SLHello</business-local>
       <ejb-class>test.ejb.stateless.StatelessTest1</ejb-class>
@@ -86,7 +86,7 @@
       </security-identity>
     </session>
     <session>
-      <display-name xml:lang="en">StatelessTest2</display-name>
+      <display-name>StatelessTest2</display-name>
       <ejb-name>StatelessTest2</ejb-name>
       <business-local>test.ejb.stateless.SLHello</business-local>
       <ejb-class>test.ejb.stateless.StatelessTest2</ejb-class>
Index: inheritance/goldenfiles/ejb-jar.xml
===================================================================
--- inheritance/goldenfiles/ejb-jar.xml	(revision 61221)
+++ inheritance/goldenfiles/ejb-jar.xml	(working copy)
@@ -2,7 +2,7 @@
 <ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" metadata-complete="true" version="3.2" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
   <enterprise-beans>
     <session>
-      <display-name xml:lang="en">StatefulTest2</display-name>
+      <display-name>StatefulTest2</display-name>
       <ejb-name>StatefulTest2</ejb-name>
       <business-remote>test.ejb.SFHello1</business-remote>
       <ejb-class>StatefulTest2</ejb-class>
@@ -27,7 +27,7 @@
         <lookup-name>java:comp/DefaultDataSource</lookup-name>
       </resource-ref>
       <resource-env-ref>
-        <description xml:lang="en">testing</description>
+        <description>testing</description>
         <resource-env-ref-name>test.ejb.StatefulTest/ejbContext</resource-env-ref-name>
         <resource-env-ref-type>javax.ejb.EJBContext</resource-env-ref-type>
         <injection-target>
@@ -75,7 +75,7 @@
       <passivation-capable>true</passivation-capable>
     </session>
     <session>
-      <display-name xml:lang="en">myStatefulTest</display-name>
+      <display-name>myStatefulTest</display-name>
       <ejb-name>myStatefulTest</ejb-name>
       <business-remote>test.ejb.SFHello1</business-remote>
       <ejb-class>test.ejb.StatefulTest1</ejb-class>
@@ -117,7 +117,7 @@
         <lookup-name>java:comp/DefaultDataSource</lookup-name>
       </resource-ref>
       <resource-env-ref>
-        <description xml:lang="en">testing</description>
+        <description>testing</description>
         <resource-env-ref-name>test.ejb.StatefulTest/ejbContext</resource-env-ref-name>
         <resource-env-ref-type>javax.ejb.EJBContext</resource-env-ref-type>
         <injection-target>
@@ -155,7 +155,7 @@
       <passivation-capable>true</passivation-capable>
     </session>
     <session>
-      <display-name xml:lang="en">StatefulTest</display-name>
+      <display-name>StatefulTest</display-name>
       <ejb-name>StatefulTest</ejb-name>
       <business-local>test.ejb.SFHello</business-local>
       <ejb-class>test.ejb.StatefulTest</ejb-class>
@@ -180,7 +180,7 @@
         <lookup-name>java:comp/DefaultDataSource</lookup-name>
       </resource-ref>
       <resource-env-ref>
-        <description xml:lang="en">testing</description>
+        <description>testing</description>
         <resource-env-ref-name>test.ejb.StatefulTest/ejbContext</resource-env-ref-name>
         <resource-env-ref-type>javax.ejb.EJBContext</resource-env-ref-type>
         <injection-target>
Comment by Hong Zhang [ 09/Apr/13 01:18 PM ]

I see. I guess the localization part of the description is not generated the same on all platforms.
You can go ahead and check in your fixes once you confirm the tests run successfully on windows as well as other platform.
Thanks for your investigation on this and solving the mystery!

Comment by Jeremy_Lv [ 09/Apr/13 02:04 PM ]

The changes has been checked in, the committed revision is 61247...





[GLASSFISH-20205] concurrent config created at startup rather than when used Created: 05/Apr/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

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

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

Tags: devx_web 4_0-approved
Participants: Tom Mueller

 Description   

The concurrent/concurrent-connector module defines several startup services for initializing the config beans for the module. These config beans are not actually needed until they are used, so if the initialization can be deferred, this could improve startup time.

Proposed fix: remove the @RunLevel annotations from the activator services and instead add an @Inject for those services in the Default*Service classes and in the list commands. With this change, we see about a 2-4% reduction in the developer scenario performance regression.



 Comments   
Comment by Tom Mueller [ 05/Apr/13 07:19 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 performance regression from 3.1.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?

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?
    Concurrent related tests.
  • Which is the targeted build of 4.0 for this fix?
    b84.
  • 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 [ 05/Apr/13 07:19 PM ]

Approved for 4.0

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

Fixed on the trunk in revision 61212.





[GLASSFISH-20204] Update HttpServletRequest.upgrade to throw ServletException Created: 05/Apr/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

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

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   

Per discussion in expert group, HttpServletRequest.upgrade will throw ServletException when the class cannot be initialized. GlassFish need to integrate the latest javax.servlet-api jar and update the corresponding part of the code.



 Comments   
Comment by Shing Wai Chan [ 05/Apr/13 06:16 PM ]
  • What is the impact on the customer of the bug?
    This is for Servlet 3.1 compliance.
  • What is the cost/risk of fixing the bug?
    update the javax.servlet-api.jar and update the corresponding code. The risk is low.
  • Is there an impact on documentation or message strings?
    Yes, the corresponding signature needs to be updated if it is in the documentation.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE pe/web tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_b84
  • 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.
    It is api/javaee-api/javax.servlet.
    The changes are svn 61156, 61168 (javadoc changes), 61202 (signature change mentioned above), 61204 (copyright update)
Comment by Tom Mueller [ 05/Apr/13 06:40 PM ]

Approved for 4.0.

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

Sending appserver/web/web-core/src/main/java/org/apache/catalina/connector/Request.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/connector/RequestFacade.java
Sending nucleus/pom.xml
Transmitting file data ...
Committed revision 61213.





[GLASSFISH-20198] BATCH GUI: Batch Execution Sort by Step Name throws HTTP Status 500 error Created: 05/Apr/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

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

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

Tags: 4_0-approved
Participants: Anissa Lam, arunkumar_s and Tom Mueller

 Description   

Tested with latest nightly b84

1) Click Execution steps of any batch execution.
2) Click sort by stepname

[2013-04-05T18:58:42.671+0530] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=40 _ThreadName=admin-listener(1)] [timeMillis: 1365168522671] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834)
at com.sun.faces.context.PartialViewContextImpl.createPartialResponseWriter(PartialViewContextImpl.java:475)
at com.sun.faces.context.PartialViewContextImpl.access$300(PartialViewContextImpl.java:73)
at com.sun.faces.context.PartialViewContextImpl$DelayedInitPartialResponseWriter.getWrapped(PartialViewContextImpl.java:619)
at javax.faces.context.PartialResponseWriter.startDocument(PartialResponseWriter.java:116)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handlePartialResponseError(AjaxExceptionHandlerImpl.java:199)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handle(AjaxExceptionHandlerImpl.java:124)
at javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
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: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 Anissa Lam [ 05/Apr/13 05:23 PM ]

The sorting key was wrong and thus the sorting gives an error.
Its a simple fix to change the sorting key.

  • What is the impact on the customer of the bug?
    They cannot sort the table based on StepName.
  • How likely is it that a customer will see the bug and how serious is the bug?
    If they try to sort by step names.
  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    no. this is new feature, the sort key wasn't specified correctly.
  • What CTS failures are caused by this bug?
    CTS doesn't test console.
  • What is the cost/risk of fixing the bug?
    It is an easy, one word fix.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Repeat the steps as reported here.

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

Comment by Tom Mueller [ 05/Apr/13 06:09 PM ]

Approved for 4.0. Note: changes related to batch are exempted from the change control process until 4/10.

Comment by Anissa Lam [ 05/Apr/13 06:15 PM ]

Fix checked in. 4/6 nightly build should have the fix.

Log Message:
------------
GLASSFISH-20198. Fix the sorting key for Step Name when sorting the Batch Steps table.

Revisions:
----------
61209

Modified Paths:
---------------
trunk/main/appserver/admingui/full/src/main/resources/batch/batchStepListing.jsf





[GLASSFISH-20196] BATCH CLI: asadmin set-batch-runtime-configuration able to set wrong values to the lookup name Created: 05/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

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

Issue Links:
Dependency
depends on GLASSFISH-20210 Unable to lookup concurrent/__default... Closed
Tags:
Participants: arunkumar_s and Mahesh Kannan

 Description   

Tested with latest nightly

Able to set Datasource look up values to Executor lookup service and vice versa.

bin/asadmin set-batch-runtime-configuration -d concurrent/__defaultManagedExecutorService
Command set-batch-runtime-configuration executed successfully.

bin/asadmin set-batch-runtime-configuration -x jdbc/__TimerPool
Command set-batch-runtime-configuration executed successfully.

Issue --> Set batch runtime configuration should allow to set only possible values



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

This has been fixed as part of svn commit 61217. However, I am not closing this until GlassFish-20210 is 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.

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

Resolved. Not set-batch-runtime-configuration command does validation.
svn commit -m "Fix for 20121, 20196. QL Passed"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchRuntimeConfiguration.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/SetBatchRuntimeConfiguration.java
Sending batch/glassfish-batch-connector/pom.xml
Sending batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeConfiguration.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/ManagedServiceActivator.java
Transmitting file data ......
Committed revision 61253.





[GLASSFISH-20190] BATCH CLI: asadmin list-batch-jobs --output with invalid values throws Null Pointer exception Created: 05/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

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.

asadmin list-batch-jobs --output somename

Issue --> throws Null pointer exception

remote failure: java.lang.NullPointerException
IllegalArgument null
Command list-batch-jobs failed

In my opinion, a proper error message should be displayed to the users.

Same case for all the Batch CLI Commands



 Comments   
Comment by Mahesh Kannan [ 09/Apr/13 09:41 PM ]

svn commit -m "Fix for 20190 and 20188. QL Passed"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommand.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommandProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutionsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobStepsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobsProxy.java
Transmitting file data ......
Committed revision 61272.





[GLASSFISH-20189] BATCH CLI: asadmin list-batch-jobs --long not listing Instance Count values 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_b84_RC1

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.

Issue -> Not shows Instance Count values for jobs when running asadmin list-batch-jobs -l



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

This has been fixed on Friday's build itself.





[GLASSFISH-20188] ADMINGUI :Batch Process for an Instance throws NPE Created: 05/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

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

Win 7 IE 9


Tags: NPE admin-gui batch console
Participants: Anissa Lam, Mahesh Kannan and RameshT

 Description   

Create an instance named : Inst1
select the instance ( inst1 )
select batch tab menu.
Got an error as :
"An error has occurred
java.lang.NullPointerException"



 Comments   
Comment by Anissa Lam [ 05/Apr/13 03:18 PM ]

The stack trace shows the NPE is from backend, and the console screen is able to display that error properly, saying
An error has occurred
java.lang.NullPointerException

Assign to Mahesh. Here is the exception.

[#|2013-04-05T08:16:42.038-0700|SEVERE|glassfish 4.0|javax.enterprise.system.core|_ThreadID=139;_ThreadName=admin-listener(7);_TimeMillis=1365175002038;_LevelValue=1000;_MessageID=NCLS-CORE-00003;|
Exception while running a command
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:542)
at org.glassfish.batch.ListBatchJobsProxy.postInvoke(ListBatchJobsProxy.java:108)
at org.glassfish.batch.AbstractListCommandProxy.execute(AbstractListCommandProxy.java:122)
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 org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:235)
at org.glassfish.admin.rest.resources.TemplateExecCommand.executeCommandLegacyFormat(TemplateExecCommand.java:161)
at org.glassfish.admin.rest.resources.TemplateCommandGetResource.processGetLegacyFormat(TemplateCommandGetResource.java:75)
at sun.reflect.GeneratedMethodAccessor120.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)

#]
Comment by Mahesh Kannan [ 09/Apr/13 09:42 PM ]

svn commit -m "Fix for 20190 and 20188. QL Passed"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommand.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommandProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutionsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobStepsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobsProxy.java
Transmitting file data ......
Committed revision 61272.





[GLASSFISH-20187] 508: Context Information - multiple values cannot selected - using only keyboard Created: 05/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

Type: Bug Priority: Major
Reporter: RameshT Assignee: andriy.zhdanov
Resolution: Works as designed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

win7 FF19


Tags: admin-gui 508 adminconsole list
Participants: andriy.zhdanov, Anissa Lam and RameshT

 Description   

Context Information - multiple values cannot selected - using keyboard

Context Information has multiple list of values.
with the help of only the keyboard ( no mouse usage ) cannot select 2 or 3 values in the list.
Ex : Selecting (classloader and Security ) or ( Classloader and workarea )

Note : consecutive values can be selected with the help of keyboards but nonconsecutive cannot be selected with the help of only keyboard ( no mouse should be used )



 Comments   
Comment by Anissa Lam [ 09/Apr/13 01:19 AM ]

Evaluation from Andriy:

I have managed to work out keystroke in Firefox

  • with down/up arrow keys select first element
  • hold control key and with down/up arrow key locate another element
  • while holding control key, press space bar - another element is selected additionally to already selected

There is no instruction on internet for other browser, but i guess someone using only keyboard navigation will know how to do this since this is possible with FF.





[GLASSFISH-20186] Batch process : configuration document is not clear Created: 05/Apr/13  Updated: 15/May/13  Resolved: 15/May/13

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

Type: Bug Priority: Major
Reporter: RameshT Assignee: Gail Risdal
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

win7 - FF19 same on all other platform / browser.


Tags: admin-gui batch-process document
Participants: Alex Pineda, Gail Risdal, Mike Fitch and RameshT

 Description   

Batch process configuration document page does not give any details.

document page :
=========================
Instance Name Cluster Name <--- wrong
The name of the GlassFish cluster or server instance to which the configuration applies. This is a read-only field.
Executor Service Lookup Name
XXX. <------- Wrong
Data Source Lookup Name
XXX. <------- Wrong

Related asadmin Commands
==============================

This is same for the all other batch document online help screens.



 Comments   
Comment by Gail Risdal [ 08/Apr/13 05:25 PM ]

Batch online help was not complete as of build 83.

Comment by Mike Fitch [ 10/Apr/13 03:32 PM ]

Accessible in current GlassFish builds.

The changes were included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152. This would appear in GlassFish nightly builds beginning 4Apr2013.

Comment by RameshT [ 12/Apr/13 10:17 AM ]

The issue is seen in build 84 ( promoted ) and build 85 ( nightly). Hence reopening the issue

Checked with latest build ( Build 84 Promoted ) and Build 85 (nightly ) . Both donot have the updated help document.

Issue 1 :

  • Batch job executions – help document does not given properly

Issue 2 :

  • Batch runtime configurations - throws 404 file not found

I have checked this in windows / OEL platforms with FF / IE browsers.

Comment by Alex Pineda [ 14/May/13 11:57 PM ]

Added Release Notes tag as this issue should be documented and communicated to the Glassfish users.

Comment by Mike Fitch [ 15/May/13 04:54 PM ]

This issue was resolved when originally noted. A different bug, GLASSFISH-20301, caused all online help pages to throw error 404 (except pages that were already in the browser's cache, and that was old content in this case).

When that issue was resolved on 14Apr2013, the online help began to be displayed again.

I have confirmed that this issue is fixed the latest build 89 nightly.

I am removing the release note tag as this issue is resolved.





[GLASSFISH-20185] Enable Secure Admin page does not show the error msg from backend to user. Created: 05/Apr/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

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

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

Tags: 4_0-approved
Participants: Anissa Lam

 Description   

Go to Server (Admin Server) page and click the "Secure Administration ...." button.
This goes to the Secure Administration page. If you try to enable Secure Admin and there is error, the error msg from backend is not shown properly.

User will see this if they try to enable secure admin without adding another admin user or add a password to the 'admin' user.



 Comments   
Comment by Anissa Lam [ 05/Apr/13 01:12 AM ]
  • What is the impact on the customer of the bug?
    User will not know that they may need to add another admin user or add a password before enabling secure admin.
  • How likely is it that a customer will see the bug and how serious is the bug?
    Pretty common if user wants to enable secure admin, since out-of-box open source edition doesn't have any password set for 'admin'.
  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    yes, a regression introduced back in build 78 when fixing GLASSFISH-18429
  • What CTS failures are caused by this bug?
    CTS doesn't test console.
  • What is the cost/risk of fixing the bug?
    minimal. It is a very localized fix.
  • Is there an impact on documentation or message strings?
    No,
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Follow the above steps and enable secure admin to ensure the error msg is shown correctly.
  • Which is the targeted build of 4.0 for this fix?
    build 84.
Comment by Anissa Lam [ 05/Apr/13 04:55 AM ]

Log Message:
------------
GLASSFISH-20185. Should include alertMsg_1.inc which doesn't check for config existence.

Revisions:
----------
61187

Modified Paths:
---------------
trunk/main/appserver/admingui/common/src/main/resources/appServer/securityAdmin.jsf





[GLASSFISH-20184] [Regression] SDK 4.0 - Websocket sample (auction) fails to build Created: 04/Apr/13  Updated: 12/Apr/13  Resolved: 10/Apr/13

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

Type: Bug Priority: Major
Reporter: Alex Pineda Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Installed java_ee_sdk-7-b82-jdk7-linux-x64.sh*, on OEL6 machine, using Maven version 3.0.5. Configured Maven environment as noted in http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/BG+Development+Environment+Guide


Issue Links:
Duplicate
duplicates GLASSFISH-20173 [SDK]Java EE 7 sample-webSocket-auction Resolved
Tags: 40-regression
Participants: Alex Pineda and Pavel Bucek

 Description   

No issues building this sample in promoted java_ee_sdk build 81, however, with java_ee_sdk build 82, it fails when executing:

o [test@wolfun] $ mvn install

The error seen is:
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WebSocket Auction Sample Application 4.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] — maven-compiler-plugin:2.4:compile (default-compile) @ auction —
[INFO] Compiling 7 source files to /home/agpineda/workspace/glassfish4/samples/websocket/auction/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] $TEST/workspace/glassfish4/samples/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/decoders/AuctionMessageDecoder.java:[50,50] error: cannot find symbol
[ERROR] symbol: class Adapter
location: interface Decoder
$TEST/workspace/glassfish4/samples/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/encoders/AuctionMessageEncoder.java:[50,50] error: cannot find symbol
[ERROR] symbol: class Adapter
location: interface Encoder
$TEST/glassfish4/samples/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/AuctionServer.java:[66,37] error: incompatible types
[ERROR] required: Class<? extends Decoder>
found: Class<AuctionMessageDecoder>
$TEST/workspace/glassfish4/samples/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/AuctionServer.java:[69,37] error: incompatible types
[ERROR] required: Class<? extends Encoder>
found: Class<AuctionMessageEncoder>
$TEST/workspace/glassfish4/samples/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/decoders/AuctionMessageDecoder.java:[50,7] error: AuctionMessageDecoder is not abstract and does not override abstract method destroy() in Decoder
[ERROR] $TEST/workspace/glassfish4/samples/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/encoders/AuctionMessageEncoder.java:[50,7] error: AuctionMessageEncoder is not abstract and does not override abstract method encode(Object) in Text
[ERROR] $TEST/workspace/glassfish4/samples/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/encoders/AuctionMessageEncoder.java:[52,4] error: method does not override or implement a method from a supertype
[INFO] 7 errors
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.350s
[INFO] Finished at: Thu Apr 04 16:13:02 PDT 2013
[INFO] Final Memory: 12M/212M

This problem is seen on both Full and Web java_ee_sdk distributions.



 Comments   
Comment by Pavel Bucek [ 10/Apr/13 12:15 AM ]

fixed in the trunk

Comment by Pavel Bucek [ 10/Apr/13 03:58 PM ]

BTW this is duplicate of http://java.net/jira/browse/GLASSFISH-20173

Comment by Alex Pineda [ 12/Apr/13 04:33 PM ]

Verified fix in SDK promoted build 83. Mark the bug as resolved.

Comment by Pavel Bucek [ 12/Apr/13 04:56 PM ]

it already is marked as resolved..





[GLASSFISH-20181] copy right (year) not right in appserver/security/core-ee/osgi.bundle Created: 04/Apr/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

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

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

Tags: 4_0-approved
Participants: spei

 Description   

Copy right not updated in



 Comments   
Comment by spei [ 05/Apr/13 12:22 PM ]

Committed revision 61189.





[GLASSFISH-20180] disable --target <cluster> "<app>:a*" - failed: I/O Error: ContentType does not define boundary Created: 04/Apr/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

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

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

Tags: 4_0-approved
Participants: aelena and Hong Zhang

 Description   

OEL6 machine. Promoted b83. Regression versioning issue.

Were deployed two versions of the the app with names:

<app>:a1 and <app>:a2.

Then I've executed:

asadmin disable --target <cluster> "<app>:*"

(after that executed show-component-status, deployed an app with a name <app>:dcb)
Then executed:

asadmin disable --target <cluster> "<app>:a*"

This disable command failed with such message:

I/O Error: ContentType does not define boundary
Command disable failed.



 Comments   
Comment by Hong Zhang [ 04/Apr/13 09:17 PM ]

I was able to reproduce the issue. Thanks for the steps.
When is the last build where this set of the steps still worked?

Comment by aelena [ 04/Apr/13 09:40 PM ]

I've checked old results. It worked for b49, but stopped to work for b50.

Comment by Hong Zhang [ 05/Apr/13 03:41 PM ]

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?

If the customer tries to disable or enable a verisioned application two times in a row on a cluster target, the second time will fail. It is a regression (it worked in build 49 but not in build 50 according to QA). 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 just move some initialization code earlier so the information that needs to be accessed by the supplemental command is populated for the no-op command. 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 enable and disable commands.

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

b84

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

Comment by Hong Zhang [ 05/Apr/13 05:21 PM ]

Move the initialization of suppInfo earlier in the DisableCommand and EnableCommand so it can be accessed by PostStateCommand when the disable or enable operation is an no-op operation (if the application is already in that state).





[GLASSFISH-20173] [SDK]Java EE 7 sample-webSocket-auction Created: 04/Apr/13  Updated: 10/Apr/13  Resolved: 05/Apr/13

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

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

Java ee 7 build 82
Maven 3.0.3
Latest build of samples


Issue Links:
Duplicate
is duplicated by GLASSFISH-20184 [Regression] SDK 4.0 - Websocket samp... Resolved
Tags:
Participants: Daniel and Pavel Bucek

 Description   

Can not compile and run the sample, there is something wrong with the dependencies?

Operations:
1 'mvn clean verify cargo:run'

Errors:
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.844s
[INFO] Finished at: Wed Apr 03 22:40:28 PDT 2013
[INFO] Final Memory: 12M/210M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.4:compile (default-compile) on project auction: Compilation failure: Compilation failure:
[ERROR] /home/daniel/Oracle_Project/glassfish-samples~svn/trunk/ws/javaee7/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/encoders/AuctionMessageEncoder.java:[50,50] error: cannot find symbol
[ERROR] symbol: class Adapter
[ERROR] location: interface Encoder
[ERROR] /home/daniel/Oracle_Project/glassfish-samples~svn/trunk/ws/javaee7/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/decoders/AuctionMessageDecoder.java:[50,50] error: cannot find symbol
[ERROR] symbol: class Adapter
[ERROR] location: interface Decoder
[ERROR] /home/daniel/Oracle_Project/glassfish-samples~svn/trunk/ws/javaee7/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/AuctionServer.java:[66,37] error: incompatible types
[ERROR] required: Class<? extends Decoder>
[ERROR] found: Class<AuctionMessageDecoder>
[ERROR] /home/daniel/Oracle_Project/glassfish-samples~svn/trunk/ws/javaee7/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/AuctionServer.java:[69,37] error: incompatible types
[ERROR] required: Class<? extends Encoder>
[ERROR] found: Class<AuctionMessageEncoder>
[ERROR] /home/daniel/Oracle_Project/glassfish-samples~svn/trunk/ws/javaee7/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/encoders/AuctionMessageEncoder.java:[50,7] error: AuctionMessageEncoder is not abstract and does not override abstract method encode(Object) in Text
[ERROR] /home/daniel/Oracle_Project/glassfish-samples~svn/trunk/ws/javaee7/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/encoders/AuctionMessageEncoder.java:[52,4] error: method does not override or implement a method from a supertype
[ERROR] /home/daniel/Oracle_Project/glassfish-samples~svn/trunk/ws/javaee7/websocket/auction/src/main/java/org/glassfish/samples/websocket/auction/decoders/AuctionMessageDecoder.java:[50,7] error: AuctionMessageDecoder is not abstract and does not override abstract method destroy() in Decoder
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException



 Comments   
Comment by Pavel Bucek [ 05/Apr/13 12:04 AM ]

it was not updated to very latest API (released on Tuesday).

should be fixed in few hours.

Comment by Pavel Bucek [ 05/Apr/13 10:20 AM ]

fixed in the glassfish-samples trunk.





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

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

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

GF 4.0 promoted build 81


Tags:
Participants: jjsnyder83, Jozef Hartinger, kchung, Manfred Riem and marfous

 Description   

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

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

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



 Comments   
Comment by Manfred Riem [ 27/Mar/13 10:23 PM ]

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

Comment by marfous [ 28/Mar/13 01:52 PM ]

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

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

Thanks a lot...

Comment by Manfred Riem [ 04/Apr/13 02:40 PM ]

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

Comment by kchung [ 04/Apr/13 03:06 PM ]

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

3. Support EL 3.0 (JSR 341).

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

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

Comment by jjsnyder83 [ 04/Apr/13 03:45 PM ]

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

Comment by Jozef Hartinger [ 04/Apr/13 08:59 PM ]

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

Comment by jjsnyder83 [ 10/Apr/13 03:32 PM ]

Fixed by Weld in 2.0.0.CR1





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

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

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

Tags:
Participants: jjsnyder83

 Description   

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

I sent email to JBoss.



 Comments   
Comment by jjsnyder83 [ 07/Apr/13 07:45 PM ]

Fixed in Weld 2.0.0.CR1





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

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

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

Tags:
Participants: jjsnyder83

 Comments   
Comment by jjsnyder83 [ 04/Apr/13 11:24 AM ]

Committed revision 61161.





[GLASSFISH-20164] missing max save post size bytes under network-confg/protocols/http-listener-1/http. Created: 04/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-20166 OLH: need to add this attribute to t... Sub-task Open Mike Fitch  
Tags: 4_0-approved
Participants: Anissa Lam, Shing Wai Chan and Tom Mueller

 Description   

As mentioned in http://java.net/jira/browse/GLASSFISH-20163 , a new attribute max-save-post-size-bytes is added.
And this should be configurable in admin console.



 Comments   
Comment by Anissa Lam [ 04/Apr/13 04:26 AM ]
  • What is the impact on the customer of the bug?
    User will need to use CLI set command to change this attribute.
  • How likely is it that a customer will see the bug and how serious is the bug?
    If the user always use console to manage the console, and need to set such attribute.
  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    Not a regression, this is a new attribute that is added today.
  • What CTS failures are caused by this bug?
    CTS doesn't test console.
  • What is the cost/risk of fixing the bug?
    minimal. It is a very localized fix.
  • Is there an impact on documentation or message strings?
    Yes, online help will want to add this attribute. Localization will need to be done for the Label string and help text.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Go to the console screen and see this attribute can be saved and retrieved properly.
  • Which is the targeted build of 4.0 for this fix?
    build 84.
Comment by Tom Mueller [ 04/Apr/13 02:10 PM ]

Approved for 4.0

Comment by Anissa Lam [ 04/Apr/13 04:59 PM ]

Log Message:
------------
GLASSFISH-20164. Add UI for max-save-post-size-bytes.

Revisions:
----------
61169

Modified Paths:
---------------
trunk/main/appserver/admingui/web/src/main/resources/org/glassfish/web/admingui/Strings.properties
trunk/main/appserver/admingui/common/src/main/resources/shared/editPageLoadDefaultButton.inc
trunk/main/appserver/admingui/web/src/main/resources/grizzly/httpAttr.inc





[GLASSFISH-20162] EJB 3.2 Remove support for lifecycle callback method-level interceptors Created: 03/Apr/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

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

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

Tags: 4_0-approved
Participants: marina vatkina

 Description   

See http://java.net/jira/browse/INTERCEPTORS_SPEC-20 and http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-04/message/1 for the description of the problem.

The feature is being removed from the interceptors spec, so it should be removed from the implementation.



 Comments   
Comment by marina vatkina [ 04/Apr/13 01:21 AM ]
  • What is the impact on the customer of the bug?
    EJB spec non-compliant behavior, and the previous changes were not correct as they caused CTS regressions
  • What is the impact on the customer of the bug?
    Less risky than the original changes. 2 days of work max
  • 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 CTS, QA regression tests
  • Which is the targeted build of 4.0 for this fix?
    the next available
  • Is this an integration of a new version of a component from another project?
    no
Comment by marina vatkina [ 05/Apr/13 12:10 AM ]

svn commit deployment/dol ejb/ejb-container
Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/ManagedBeanDescriptor.java
Sending ejb/ejb-container/src/main/java/org/glassfish/ejb/deployment/descriptor/EjbDescriptor.java
Transmitting file data ..
Committed revision 61185





[GLASSFISH-20161] Final manpages and online help need to be picked up by GlassFish Created: 03/Apr/13  Updated: 03/Apr/13  Resolved: 03/Apr/13

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

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

Tags: 4_0-approved
Participants: Mike Fitch

 Description   

The final manpages and online help for GlassFish 4.0 are available in main-docs version 4.0-b27. GlassFish needs to pick up this content.

Here's the diff of trunk/main/nucleus/pom.xml:

— C:/DOCUME~1/MFITCH~1.ST-/LOCALS~1/Temp/pom.xm-revBASE.svn001.tmp.xml Wed Apr 3 15:38:31 2013
+++ D:/svn_glassfish/trunk-main/nucleus/pom.xml Wed Apr 3 15:37:40 2013
@@ -124,7 +124,7 @@
<glassfish-management-api.version>3.2.0-b001</glassfish-management-api.version>
<btrace.version>1.0.5</btrace.version>
<opendmk.version>1.0-b01-ea</opendmk.version>

  • <v3-docs.version>4.0-b26</v3-docs.version>
    + <v3-docs.version>4.0-b27</v3-docs.version>
    <v3-docs-l10n.version>4.0-b03</v3-docs-l10n.version>
    <l10n.version>3.1-b41</l10n.version>
    <asm.version>3.1</asm.version>


 Comments   
Comment by Mike Fitch [ 03/Apr/13 10:47 PM ]
  • What is the impact on the customer of the bug?

Customers won't have the final manpage and online help content in the 4.0 release.

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

None/Very Low.
The work is already done, and the change has already been tested in a local build of GlassFish.

  • Is there an impact on documentation or message strings?

Not on message strings. Of course on documentation: the fix is to include new documentation.

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

Any they want to. None needed that I can think of.

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

4.0_b84_RC1

  • 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.

See http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=11729
All the issues therein with a Fix Version of 4.0_b84_RC1 or 4.0 are included.

Comment by Mike Fitch [ 03/Apr/13 11:33 PM ]

Committed in svn revision 61152.





[GLASSFISH-20160] asadmin get command referring to a default configured item fails Created: 03/Apr/13  Updated: 06/Apr/13  Resolved: 06/Apr/13

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

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

Issue Links:
Dependency
blocks GLASSFISH-19943 Audit module (webInvocation callback)... Resolved
Tags: 4_0-approved
Participants: Tim Quinn

 Description   

In 3.1.2.2 one can do this:

adc6140581:3.1.2.2 $ ./glassfish3/glassfish/bin/asadmin get server-config.security-service.audit-module.default.*
server-config.security-service.audit-module.default.classname=com.sun.enterprise.security.Audit
server-config.security-service.audit-module.default.name=default
server-config.security-service.audit-module.default.property.auditOn=false
Command get executed successfully.

In 4.0 this happens:

adc6140581:publish $ ./glassfish4/glassfish/bin/asadmin get server-config.security-service.audit-module.default.*
remote failure: Dotted name path server-config.security-service.audit-module.default.* not found.
Command get failed.

This is causing SQE tests to fail, as reported in GLASSFISH-19943

I am assigning this to Masoud, at least to start with.



 Comments   
Comment by Tim Quinn [ 03/Apr/13 09:40 PM ]

Linking this to the issue SQE filed.

Comment by Tim Quinn [ 03/Apr/13 09:48 PM ]

I meant to point out that in 3.1.2.2 the domain.xml contains an explicit audit-module element - and subelements - for the "default" module.

In 4.0 the SecurityServices config bean provides a default value for getAuditModules() (which returns "default").

Does this need to be addressed by restoring some previously-removed elements?

Comment by Tim Quinn [ 04/Apr/13 04:06 PM ]

Back in 2011 quite a bit of work was done to separate the appserver configuration and classes from the nucleus configuration and classes.

The audit-module section of domain.xml referred to a class that was moving from nucleus into the new appserver server/core-ee module, so the nucleus domain.xml template was revised to remove the audit-module section but that section was never placed into the new appserver-specific domain.xml template. The absence of that section in the appserver domain.xml is at least part of the reason the SQE tests mentioned in GLASSFISH-19943 are failing.

  • What is the impact on the customer of the bug?
    This is a regression.
  • What is the cost/risk of fixing the bug?
    Small - restoring the inadvertently-dropped <audit-module> element to the appserver domain.xml template.
  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    The test mentioned in GLASSFISH-19943
  • Which is the targeted build of 4.0 for this fix?
    b84
  • 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 Tim Quinn [ 04/Apr/13 09:29 PM ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 61179
Author: tjquinn
Date: 2013-04-04 21:27:30 UTC
Link:

Log Message:
------------
GLASSFISH-20160 - asadmin get command referring to a default configured item fails

Back in 2011 quite a bit of work was done to separate the appserver configuration and classes from the nucleus configuration and classes.

The audit-module section of domain.xml referred to a class that was moving from nucleus into the new appserver server/core-ee module, so the nucleus domain.xml template was revised (one of the changes in svn rev 48070) to remove the audit-module section but that section was never placed into the new appserver-specific domain.xml template which was created a short while later.

This change restores the audit-module section in the server-config and default-config sections.

Reviewed by Tom Mueller
Approved by Michael
Passed QL tests

Revisions:
----------
61179

Modified Paths:
---------------
trunk/main/appserver/admin/template/src/main/resources/config/domain.xml

Comment by Tim Quinn [ 05/Apr/13 04:23 PM ]

The earlier fix to this issue, which added back a removed section of XML, introduced an error in the upgrade logic which is heavily dependent on the order of data in the domain.xml template.

The original change should stand but we now need to correct the upgrade logic to work with the corrected domain.xml template.

  • What is the impact on the customer of the bug?
    The upgrade (via start-domain --upgrade) does not work and leaves a CPU-bound DAS running.
  • What is the cost/risk of fixing the bug?
    The repair to the upgrade logic is relatively minor, updating it so it conforms to what is in the revised template domain.xml.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    The GlassFish admin devtests which include the upgrade test.
  • Which is the targeted build of 4.0 for this fix?
    b84
  • 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 Tim Quinn [ 06/Apr/13 03:47 PM ]

Fix checked in:

Project: glassfish
Repository: svn
Revision: 61214
Author: tjquinn
Date: 2013-04-05 23:16:32 UTC
Link:

Log Message:
------------
Additional fix for GLASSFISH-20160 - asadmin get command referring to a default configured item fails

An earlier check-in restored a long-ago removed bit of the domain.xml template for the default security audit-module, but that confused the upgrade logic that had been changed when the audit-module had been removed earlier.

This change fixes the upgrade problem.

Approved by Tom
Reviewed by Tom
Passed QL, the upgrade GlassFish admin devtest

Revisions:
----------
61214

Modified Paths:
---------------
trunk/main/nucleus/admin/config-api/src/main/java/org/glassfish/config/support/DefaultConfigUpgrade.java





[GLASSFISH-20156] Installed components throws error Created: 03/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

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

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

Win 8 IE 9


Tags: 4_0-approved admin-gui adminconsole common tasks
Participants: Anissa Lam and RameshT

 Description   

Installed components are not displayed.

steps to follow,

common tasks -> update center -> installed components

throws errors as :
cannot find specified config Resources. Config may have been deleted.



 Comments   
Comment by Anissa Lam [ 04/Apr/13 04:16 PM ]

When fixing GLASSFISH-18429, the 'original' alert msg is modified to add the testing of existing config to ensure that the object wasn't deleted by other means. All jsf pages that doesn't need this test should change to include another alert files. The update tools screen missed to make that change.

  • What is the impact on the customer of the bug?
    Depends where the user navigate to the update tool pages, they will see error message not relevant to update tools.
  • How likely is it that a customer will see the bug and how serious is the bug?
    If the user goes to the updatetool page as the 1st thing after launching console.
  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    yes, a regression introduced back in build 78 when fixing GLASSFISH-18429
  • What CTS failures are caused by this bug?
    CTS doesn't test console.
  • What is the cost/risk of fixing the bug?
    minimal. It is a very localized fix.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Repeat the same test by going to update tool screens WITHOUT going to any config screen first.
  • Which is the targeted build of 4.0 for this fix?
    build 84.
Comment by Anissa Lam [ 04/Apr/13 08:28 PM ]

Log Message:
------------
GLASSFISH-20156. Should include alertMsg_1.inc which doesn't check for existence of a config.

Revisions:
----------
61177

Modified Paths:
---------------
trunk/main/appserver/admingui/updatecenter/src/main/resources/ucConfig.jsf
trunk/main/appserver/admingui/updatecenter/src/main/resources/updateCenterContent.jsf
trunk/main/appserver/admingui/updatecenter/src/main/resources/pkgDetails.jsf
trunk/main/appserver/admingui/updatecenter/src/main/resources/acceptLicense.jsf

Comment by Anissa Lam [ 04/Apr/13 09:05 PM ]

Log Message:
------------
GLASSFISH-20156. One more fix to ensure the URL displayed is correct.

Revisions:
----------
61178

Modified Paths:
---------------
trunk/main/appserver/admingui/updatecenter/src/main/resources/ucCommonTask.jsf

Diffs:





[GLASSFISH-20155] BATCH RI: Retryable exception not reprocess the current chunk Created: 03/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

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

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

Tags:
Participants: arunkumar_s, Kaushik Mukherjee and ScottKurz

 Description   

Tested with latest nightly

1) Start a job with some retryable exceptions

In my app, i throwed some retryable exceptions specified in job xml in ItemWriter.

PFD says it will reprocess the chunk if any retryable exceptions occur.

Is the job start read,process,write from the beginning of the chunk?

Issue --> It is not reprocessing the chunk again. It just continues read,process,write items with chunk item count=1



 Comments   
Comment by ScottKurz [ 03/Apr/13 08:07 PM ]

Could you please point me to the application? (Maybe it is one you already shared but just to be clear please link to it here.) Thanks

Comment by arunkumar_s [ 04/Apr/13 02:21 AM ]

Sample Application:

Latest from https://www.dropbox.com/s/eu78eidm31mveid/SimpleListeners.war

Test 4 reads,process,write with chunk itemcount =3. After 3 item read and process, write method throws retryable exception. But the chunk is not rollback by start reading the chunk values again. Its just continues reading next items with itemcount=1

Sample application src code found in https://www.dropbox.com/s/b3jgecloghnofic/SimpleListeners.zip

Comment by ScottKurz [ 04/Apr/13 11:34 AM ]

Based on looking at your source, this would seem to be working as designed.

The way that the "cursor position" within the chunk loop is maintained is via the calls to
open(Serializable checkpoint) and checkpointInfo().

So your test Reader should look like this:

public class SimpleItemReader ...
private int index = 0;
final int MAX_VALUE=6;

public void open(Serializable checkpoint) throws Exception { index = (Integer)checkpoint; }
public String readItem() throws Exception { return index < MAX_VALUE ? Integer.toString(index++) : null; }
public Serializable checkpointInfo() throws Exception { return index; }
...

--------

Please reopen if you see a problem after making an adjustment like that.

Comment by arunkumar_s [ 04/Apr/13 05:20 PM ]

Made adjustment:
public void open(Serializable checkpoint) throws Exception
{
if(checkpoint!=null){index = (Integer)checkpoint;}
else{index=0;} // If the retryable exception happens in first chunk, then no checkpointInfo() is called, so set back the index items to zero
}
public String readItem() throws Exception { return index < MAX_VALUE ? Integer.toString(index++) : null; }
public Serializable checkpointInfo() throws Exception { return index; }

I modified the Test4 in the app such that exception occurs in ItemWriter when second chunk is getting written. First chunk successfully committed as there are no exceptions happened, but it throws new Batch Container Service exception while second chunk is being rollbacked although retryable listener is called.

[2013-04-04T22:37:51.296+0530] [glassfish 4.0] [WARNING] [] [com.ibm.jbatch.container.impl.ChunkStepControllerImpl] [tid: _ThreadID=556 _ThreadName=concurrent/__defaultManagedExecutorService-managedThreadFactory-Thread-21] [timeMillis: 1365095271296] [levelValue: 900] [[
Caught exception in chunk processing]]

[2013-04-04T22:37:51.296+0530] [glassfish 4.0] [WARNING] [] [com.ibm.jbatch.container.impl.BatchletStepControllerImpl] [tid: _ThreadID=556 _ThreadName=concurrent/__defaultManagedExecutorService-managedThreadFactory-Thread-21] [timeMillis: 1365095271296] [levelValue: 900] [[
Caught exception executing step: com.ibm.jbatch.container.exception.BatchContainerServiceException: com.ibm.jbatch.container.exception.BatchContainerServiceException: Cannot persist the checkpoint data for [step1]
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeCoreStep(ChunkStepControllerImpl.java:654)
at com.ibm.jbatch.container.impl.BaseStepControllerImpl.execute(BaseStepControllerImpl.java:134)

I suspect after CheckPointInfo is called in ItemWriter once, then for the next chunk rollback this issue happens
Updated sample app: https://www.dropbox.com/s/eu78eidm31mveid/SimpleListeners.war
Updated Sample application src code found in https://www.dropbox.com/s/b3jgecloghnofic/SimpleListeners.zip

Comment by Kaushik Mukherjee [ 04/Apr/13 08:43 PM ]

It looks like the Serializable checkpoint data was not being persisted correctly so the chunk loop could never complete. This will be fixed in the next RI drop.





[GLASSFISH-20154] need to throw IllegalStateException if UserTransaction is used from @Transactional method Created: 03/Apr/13  Updated: 15/Apr/13  Resolved: 15/Apr/13

Status: Closed
Project: glassfish
Component/s: None
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b84_RC1

Type: Task Priority: Blocker
Reporter: paul_parkinson Assignee: paul_parkinson
Resolution: Fixed Votes: 0
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Tags:
Participants: marina vatkina and paul_parkinson

 Description   

Need to implement this bit from JTA 1.2 spec:

"If an attempt is made to call any method of the UserTransaction interface from within the scope of a bean or method annotated with @Transactional and a Transactional.TxType other than NOT_SUPPORTED or NEVER, an IllegalStateException must be thrown."



 Comments   
Comment by paul_parkinson [ 10/Apr/13 05:01 PM ]

svn commit -m "fixes and features for JIRA GLASSFISH-20247 and GLASSFISH-20154"
Sending appserver/transaction/internal-api/src/main/java/com/sun/enterprise/transaction/api/JavaEETransactionManager.java
Sending appserver/transaction/jta/src/main/java/com/sun/enterprise/transaction/JavaEETransactionManagerSimplified.java
Sending appserver/transaction/jta/src/main/java/com/sun/enterprise/transaction/UserTransactionImpl.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorBase.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorMandatory.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorNever.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorNotSupported.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorRequired.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorRequiresNew.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorSupports.java
Transmitting file data ..........
Committed revision 61342.

Comment by marina vatkina [ 11/Apr/13 07:45 PM ]

There are several problems with the solution:

a) a BMT EJB will be denied UTx access if called from a transactional CDI bean

b) no module outside transaction should depend on the 'jta' module

Comment by paul_parkinson [ 11/Apr/13 08:10 PM ]

Hi Marina, inline...

>There are several problems with the solution:
Please let me know if there are others if you mean more than the two you mention here.

>a) a BMT EJB will be denied UTx access if called from a transactional CDI bean
Yes, that is actually the appropriate behavior as EJB/CMT and CDI/@Transactional do not coordinate with each other according to spec (the user would need to call outside an @Tranactional scope or from within TxType NOT_SUPPORTED or NEVER). I believe you and I did discuss this case with Bill and Linda already but we can discuss this offline more if you like.

>b) no module outside transaction should depend on the 'jta' module
I don't think there is any such dependency in these changes/solution.
I actually need to make changes to the solution regardless as you know and there won't be any jta dependencies in the new changes/solution either.

Comment by marina vatkina [ 11/Apr/13 09:04 PM ]

>a) a BMT EJB will be denied UTx access if called from a transactional CDI bean
Yes, that is actually the appropriate behavior as EJB/CMT and CDI/@Transactional do not coordinate with each other according to spec (the user would need to call outside an @Tranactional scope or from within TxType NOT_SUPPORTED or NEVER). I believe you and I did discuss this case with Bill and Linda already but we can discuss this offline more if you like.

CDI/@Transactional should not break the rules in the EJB spec. And the latter says that the container suspends the transaction when invoking BMT bean:

"When a client invokes a business method via one of the enterprise bean’s client views, the container suspends any transaction that may be associated with the client request"

Comment by paul_parkinson [ 15/Apr/13 12:52 AM ]

svn commit -m "GLASSFISH-20154 need to throw IllegalStateException if UserTransaction is used from @Transactional method (re)work"
Sending appserver/transaction/internal-api/src/main/java/com/sun/enterprise/transaction/api/JavaEETransactionManager.java
Sending appserver/transaction/jta/src/main/java/com/sun/enterprise/transaction/JavaEETransactionManagerSimplified.java
Sending appserver/transaction/jta/src/main/java/com/sun/enterprise/transaction/UserTransactionImpl.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorBase.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorMandatory.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorNever.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorNotSupported.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorRequired.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorRequiresNew.java
Sending appserver/web/weld-integration/src/main/java/org/glassfish/cdi/transaction/TransactionalInterceptorSupports.java
Sending nucleus/common/glassfish-api/src/main/java/org/glassfish/api/invocation/ComponentInvocation.java
Transmitting file data ...........
Committed revision 61423.





[GLASSFISH-20150] BATCH RI: SkipWriteListener is called no of items processed rather than no of times exception thrown 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_b84_RC1

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

Tags:
Participants: arunkumar_s, Kaushik Mukherjee and ScottKurz

 Description   

Tested with latest glassfish nightly + b22

My sample Job XML

<?xml version="1.0" encoding="UTF-8"?>
<job id="PayRollJobListeners" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="TESTNO" value="#{jobParameters['TESTNO']}"/>
</properties>
<step id="step1">
<listeners>
<listener ref="SampleSkipReadListener"></listener>
<listener ref="SampleSkipWriteListener"></listener>
<listener ref="SampleSkipProcessListener"></listener>
<listener ref="SampleRetryReadListener"></listener>
<listener ref="SampleRetryWriteListener"></listener>
<listener ref="SampleRetryProcessListener"></listener>
</listeners>
<chunk item-count="3" skip-limit="3">
<reader ref="SimpleItemReader"></reader>
<processor ref="SimpleItemProcessor"></processor>
<writer ref="SimpleItemWriter"></writer>
<skippable-exception-classes>
<include class="java.lang.ArithmeticException"/>
</skippable-exception-classes>
</chunk>
</step>
</job>

SimpleItemReader will read 6 items one by one.
I have introduced ArithmeticException in SimpleItemWriter writeItems method. As per chunk item-count my SimpleItemWriter writeItems called only twice as there are only 6 items from the reader. So skip-limit value set to 3 should complete the JOB successfully

Issue --> After writeItems Arithmetic Exception thrown, SkipWriterListener is called 3 times(chunk count) and job process next chunk it makes the JOB to FAILED bcoz of Arithmetic Exception

Attached Sample App: https://www.dropbox.com/s/eu78eidm31mveid/SimpleListeners.war

Deploy the app and start Job2 from http://<server>:<port>/SimpleListeners/JobSubmitterServlet



 Comments   
Comment by ScottKurz [ 03/Apr/13 06:32 PM ]

I thought this had come up on the spec ML and we'd decided on # of items. Looking back at the spec now I only see, clearly, that it's saying # of exceptions.

Thanks for catching that. Let me look into this...

Comment by Kaushik Mukherjee [ 03/Apr/13 09:09 PM ]

Looks like the RI was counting the exceptions against each item in the write chunk. This is fixed for the next drop.

Comment by ScottKurz [ 04/Apr/13 06:35 PM ]

Fixed in jbatch 1.0-b24





[GLASSFISH-20149] BATCH RI: Skippable include class exceptions not caught with default skip-limit values 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_b84_RC1

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

Tags:
Participants: arunkumar_s, Kaushik Mukherjee and ScottKurz

 Description   

Tested with latest build b22

Have a chunk job with skippable exception include classes

Sample chunk element:

<chunk item-count="2">
...
</chunk>

skip-limit by PFD "The default is no limit.". Does it mean infinite maximum value or zero by default?

If the value is infinite value, then this bug is valid

The specified skippable exception include classes exception thrown inside chunk job, skippable listeners don't catch the exception and Job Failed with FAILED status.

Issue -> If skippable exception include classes is thrown in job processing, then it should skip the exceptions and continue the job processing

Attached sample application : https://www.dropbox.com/s/eu78eidm31mveid/SimpleListeners.war

Deploy the app and click StartJob1 from the servlet http://<server>:<port>/SimpleListeners/JobSubmitterServlet

Job1 has Arithmetic exception thrown in Item Processor which is not caught by skippable exception include class and the Job fails with FAILED Status

Job XML Chunk:

<chunk item-count="3">
<reader ref="SimpleItemReader"></reader>
<processor ref="SimpleItemProcessor"></processor>
<writer ref="SimpleItemWriter"></writer>
<skippable-exception-classes>
<include class="java.lang.ArithmeticException"/>
</skippable-exception-classes>
</chunk>



 Comments   
Comment by Kaushik Mukherjee [ 03/Apr/13 08:19 PM ]

We'll have a fix for this in the next RI drop.

Comment by ScottKurz [ 04/Apr/13 06:36 PM ]

Fixed in jbatch 1.0-b24





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

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

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

Tags:
Participants: jjsnyder83




[GLASSFISH-20144] BATCH RI: getEndTime() from Step Executions throws Null Pointer Exception 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_b84_RC1

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

Tags:
Participants: arunkumar_s and ScottKurz

 Description   

Tested with latest nightly.

1) Start a long running Job.

StepExecution.getEndTime() of the currently running execution throws Null Pointer Exception

[2013-04-03T15:32:48.687+0530] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=28 _ThreadName=http-listener-1(2)] [timeMillis: 1364983368687] [levelValue: 900] [[
StandardWrapperValve[JobSubmitterServlet]: Servlet.service() for servlet JobSubmitterServlet threw exception
java.lang.NullPointerException
at com.ibm.jbatch.container.jobinstance.StepExecutionImpl.getEndTime(StepExecutionImpl.java:80)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.listJobExecutionDetails(JobSubmitterServlet.java:312)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.processRequest(JobSubmitterServlet.java:157)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.doPost(JobSubmitterServlet.java:471)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
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)
]]



 Comments   
Comment by ScottKurz [ 03/Apr/13 06:38 PM ]

Got it.. will fix in next drop.

Comment by ScottKurz [ 04/Apr/13 06:36 PM ]

Fixed in jbatch 1.0-b24





[GLASSFISH-20135] new WARNING logged in server.log when launch console Created: 02/Apr/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

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

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

Tags: 4_0-approved
Participants: Anissa Lam and Shing Wai Chan

 Description   

Recently, a few WARNING is showing up server.log when server starts and console is launched.

this WARNING message shows up in server.log after i started the server and then launch console.

[#|2013-04-02T12:26:25.860-0700|WARNING|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=88;_ThreadName=Thread-9;_TimeMillis=1364930785860;_LevelValue=900;|
JACC: For the URL pattern /resource/*, all but the following methods were uncovered: GET|#]

[#|2013-04-02T12:26:25.879-0700|WARNING|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=88;_ThreadName=Thread-9;_TimeMillis=1364930785879;_LevelValue=900;|
JACC: For the URL pattern /theme/com/*, all but the following methods were uncovered: GET|#]

[#|2013-04-02T12:26:25.879-0700|WARNING|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=88;_ThreadName=Thread-9;_TimeMillis=1364930785879;_LevelValue=900;|
JACC: For the URL pattern /theme/META-INF/*, all but the following methods were uncovered: GET|#]

[#|2013-04-02T12:26:25.880-0700|WARNING|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=88;_ThreadName=Thread-9;_TimeMillis=1364930785880;_LevelValue=900;|
JACC: For the URL pattern /theme/org/*, all but the following methods were uncovered: GET|#]

[#|2013-04-02T12:26:27.208-0700|INFO|glassfish 4.0|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=88;_ThreadName=Thread-9;_TimeMillis=1364930787208;_LevelValue=800;_MessageID=jsf.config.listener.version;|
Initializing Mojarra 2.2.0-m12 (-SNAPSHOT 20130320-0201 https://svn.java.net/svn/mojarra~svn/tags/2.2.0-m12@11773) for context ''|#]

[#|2013-04-02T12:26:29.469-0700|INFO|glassfish 4.0|javax.enterprise.web|_ThreadID=88;_ThreadName=Thread-9;_TimeMillis=1364930789469;_LevelValue=800;_MessageID=AS-WEB-GLUE-00172;|
Loading application [__admingui] at [/]|#]

This need to be addressed.



 Comments   
Comment by Anissa Lam [ 02/Apr/13 11:19 PM ]

Advice from Craig is to remove the line
<http-method>GET</http-method>
in web.xml which is for the images, css etc. specified in the security constraint.

Hi Tim, Anissa,

These messages are the result of adding support for the handling of uncovered HTTP methods. There is logging requirement in the Servlet 3.1 specification to indicate where uncovered methods exist in the application.

For the URL patterns listed below, all the HTTP methods except for GET are unprotected by the security constraints of the admingui.

-Craig

I see, there are sections of the admingui that get opened up and the warning results because you only listed a single HTTP method in the security constraint.

<!-- resources like images, css, etc. that don't need protection -->
<security-constraint>
<web-resource-collection>
<web-resource-name>public</web-resource-name>
<url-pattern>/theme/com/*</url-pattern>
<url-pattern>/theme/org/*</url-pattern>
<url-pattern>/resource/*</url-pattern>
<url-pattern>/theme/META-INF/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
</security-constraint>

Simply remove the <http-method> element and then all HTTP methods will be "covered" by this security constraint. Then end result is that the desired behavior based on the comment is achieved.

Comment by Shing Wai Chan [ 02/Apr/13 11:32 PM ]

In the given web.xml, combing with another security-constraint, those files will only be accessible by users with role admin for http method other than GET.
If the above http-method is removed, then this means those files will be accessible by any users for all http method.
If there is no essential information there, then this is ok.

An alternative solution is to use the web.xml 3.1 schema and then add <deny-uncovered-http-methods/> element in web.xml. In this case, no one will be able to access those files through http method other than GET.

Comment by Anissa Lam [ 03/Apr/13 09:39 PM ]

I modified the web.xml to use the 3.1 , here is how it looks like.
My understanding is that, I should add <deny-uncovered-http-methods/>, and specify GET for those resources , that will be the correct way to do, and shouldn't get any WARNING.

However, doing that still generates the WARNING message.

I can't attach the entire web.xml, but here is the new segment:

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee web-app_3_1.xsd" version="3.1">

...
...
<error-page>
<exception-type>javax.faces.application.ViewExpiredException</exception-type>
<location>/</location>
</error-page>
<deny-uncovered-http-methods/>
<security-constraint>
<web-resource-collection>
<web-resource-name>protected</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>

<!-- resources like images, css, etc. that don't need protection -->
<security-constraint>
<web-resource-collection>
<web-resource-name>public</web-resource-name>
<url-pattern>/theme/com/*</url-pattern>
<url-pattern>/theme/org/*</url-pattern>
<url-pattern>/resource/*</url-pattern>
<url-pattern>/theme/META-INF/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
</security-constraint>

---------------
I don't know why the WARNING is still showing up. Waiting for input from Shing Wai & Craig.

Comment by Anissa Lam [ 03/Apr/13 10:51 PM ]

Actually a closer look to server.log shows that the WARNING message is now changed to INFO with the above changes.

[#|2013-04-03T15:08:53.874-0700|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=86;_ThreadName=Thread-8;_TimeMillis=1365026933874;_LevelValue=800;|
JACC: For the URL pattern /resource/*, all but the following methods have been excluded: GET|#]

[#|2013-04-03T15:08:53.899-0700|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=86;_ThreadName=Thread-8;_TimeMillis=1365026933899;_LevelValue=800;|
JACC: For the URL pattern /theme/com/*, all but the following methods have been excluded: GET|#]

[#|2013-04-03T15:08:53.899-0700|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=86;_ThreadName=Thread-8;_TimeMillis=1365026933899;_LevelValue=800;|
JACC: For the URL pattern /theme/META-INF/*, all but the following methods have been excluded: GET|#]

[#|2013-04-03T15:08:53.900-0700|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=86;_ThreadName=Thread-8;_TimeMillis=1365026933900;_LevelValue=800;|
JACC: For the URL pattern /theme/org/*, all but the following methods have been excluded: GET|#]

So, upgrading to Servlet 3.1 so we can get the <deny-uncovered-http-methods> will be able to avoid the WARNING.

I will go through the approval process to commit the change.

Comment by Anissa Lam [ 05/Apr/13 01:29 AM ]

These WARNING are the result of adding support for the handling of uncovered HTTP methods. There is logging requirement in the Servlet 3.1 specification to indicate where uncovered methods exist in the application.

We can upgrade the console to user Servlet 3.1 and then add the new tag <deny-uncovered-http-methods/>, but that will still triggers some msg, although that is INFO instead of WARNING.

In order to avoid any msg relating to those resources URL, the solution is to add another security constraint that denies any method except GET for any user. This means even the 'admin' user cannot POST to those resources. Since those resources are just images, css files, the only method needed is 'GET'. So, highly restricting the method to GET is fine. This is a suggestion from Ron & Shing Wai.

I will send the web.xml for review to the security team, Web Container team and Ron Monzillo for review before checking in.

  • What is the impact on the customer of the bug?
    No functional impact, but user may worry that the console is not secure.
  • How likely is it that a customer will see the bug and how serious is the bug?
    They will see this WARNING everytime when server start and console launched.
  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    No.
  • What CTS failures are caused by this bug?
    CTS doesn't test console.
  • What is the cost/risk of fixing the bug?
    Change is in web.xml, doesn't affect any feature. Add one more 'set' of security constraint to avoid the WARNING.
  • Is there an impact on documentation or message strings?
    No,
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Ensure that no WARNING is given out when launch console.
  • Which is the targeted build of 4.0 for this fix?
    build 84.
Comment by Anissa Lam [ 05/Apr/13 06:22 PM ]

Log Message:
------------
GLASSFISH-20135. Add extra security constraint so that WARNING or INFO will not be triggered when the console launch, due to Servlet 3.1 spec.
This extra constraint means the specified URL pattern only allows GET, anyone, not even the admin is allowed to do any other method.
Reviewed by Craig Perez, Ron Monzillo and Shing Wai.

Revisions:
----------
61210

Modified Paths:
---------------
trunk/main/appserver/admingui/war/src/main/webapp/WEB-INF/web.xml





[GLASSFISH-20121] Lookup failed for JNDI name: jdbc/__TimerPool for standalone instances/cluster Created: 01/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

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.

1) Deploy sample batch applications in standalone instances/clusters and try to access the app.

Issue -->
[2013-04-01T19:25:52.859+0530] [glassfish 4.0] [SEVERE] [] [com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl] [tid: _ThreadID=30 _ThreadName=http-listener-1(4)] [timeMillis: 1364824552859] [levelValue: 1000] [[
Lookup failed for JNDI name: jdbc/__TimerPool. One cause of this could be that the batch runtime is incorrectly configured to EE mode when it should be in SE mode.]]



 Comments   
Comment by Mahesh Kannan [ 09/Apr/13 04:20 PM ]

Changed the default to jdbc/__default. Note that you need to start derby before running batch apps. This is exactly what needs to be done to run ejb timer apps





[GLASSFISH-20119] BATCH RI: IllegalStateException when restarting a running JOB Created: 01/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_b84_RC1

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

Issue Links:
Related
is related to GLASSFISH-19870 Batch RI : Batch Exceptions : Restart... Resolved
Tags:
Participants: arunkumar_s and ScottKurz

 Description   

Tested with latest integrated b22 with latest glassfish nightly.

On top of bug http://java.net/jira/browse/GLASSFISH-19870, try to restart a already running job throws Illegal State Exception

java.lang.IllegalStateException: On restart, we didn't find an earlier batch status.
at com.ibm.jbatch.container.jobinstance.JobExecutionHelper.validateJobInstanceNotCompleteOrAbandonded(JobExecutionHelper.java:165)



 Comments   
Comment by ScottKurz [ 02/Apr/13 09:48 PM ]

OK.. I think the point you are making here is that we could use something like JobRestartException as a blanket unchecked exception rather than IllegalStateException.

That sounds better. Didn't make b23 but will do for the next drop.

Comment by ScottKurz [ 04/Apr/13 06:36 PM ]

Fixed in jbatch 1.0-b24





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

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

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

Tags:
Participants: jjsnyder83

 Comments   
Comment by jjsnyder83 [ 01/Apr/13 05:51 PM ]

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

Comment by jjsnyder83 [ 07/Apr/13 07:46 PM ]

Fixed in Weld 2.0.0.CR1





display logical-jndi-name for JDBC resources (GLASSFISH-20105)

[GLASSFISH-20106] OLH for jdbc-resources Created: 29/Mar/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

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

Type: Sub-task Priority: Major
Reporter: Anissa Lam Assignee: Gail Risdal
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Anissa Lam and Gail Risdal

 Description   

both jdbc-resources table and the edit jdbc screen will have the logical-jndi-names displayed if it applies.



 Comments   
Comment by Gail Risdal [ 02/Apr/13 11:05 PM ]

Added 'Logical JNDI Name' to the reference help for the pages.

These changes will become accessible in GlassFish when the next main-docs build is promoted and picked up by GlassFish builds.

Comment by Gail Risdal [ 04/Apr/13 09:01 PM ]

Accessible in current GlassFish builds.

This addition was included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152.





[GLASSFISH-20100] Batch RI: Transition Elements not working other than COMPLETED exit status Created: 29/Mar/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

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

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

Tags:
Participants: arunkumar_s and ScottKurz

 Description   

Tested with latest nightly.

Steps:

1) <fail on="COMPLETED" exit-status="EARLY COMPLETION"/> in Job XML for a <step> element.

This works fine.Step which exits with COMPLETED exit status sets the JOB exit status as EARLY COMPLETION

I tried with other possibilities given below, but these possibilities wont set the JOB exit status as expected.

<fail on="FAILED" exit-status="EARLY FAIL"/>
I have thrown an exception in a process execution,so the step fails with FAILED exit status. Step exit status get set as FAILED, but <fail> element didn't work.

<fail on="STOPPED" exit-status="EARLY STOP"/>
Used JobOperator.stop() to stop a process execution

The same case applies to all other transition elements: end,next,stop



 Comments   
Comment by ScottKurz [ 01/Apr/13 05:57 PM ]

We have a few of these tests doing similar things in the TCK that have passed on every released version.

Can you make the test app and/or logs available?

Comment by arunkumar_s [ 02/Apr/13 10:44 AM ]

Couldn't able to attach here.

Attached the deployable war file in https://www.dropbox.com/s/8yn5fcwtqv0dwfu/SampleBatchlets.war

http://<Server>:<port>/SampleBatchlets/SimpleBatchletServlet

Has three tests, One for Running a Job till it completes, Second Running a Job and Stopping in between , and third an Interrupted JOB(throwing some exceptions in Job process in between)

Transition elements in Job XML.

<fail on="COMPLETED" exit-status="EARLY COMPLETION"/>
<fail on="STOPPED" exit-status="EARLY STOP"/>
<fail on="FAILED" exit-status="EARLY FAIL"/>

Comment by ScottKurz [ 02/Apr/13 08:22 PM ]

Now that I see what you're doing, I believe that we may indeed have had a gap here that we closed in more recent drops, which I think should go into the 4.0_b83 build.

I need to come back to this and give it some more thought and maybe try your app. In the meantime, I would suggest that if you get the b83 build before I get back to this that you might give it a try.

Comment by ScottKurz [ 08/Apr/13 03:10 PM ]

Hi,

This issue forced us to go back to the EG and rethink a couple of our implementation details. It looks like where we're ending up is that the
normal completion and exception thrown paths will work as your test expects (once we deliver a fix).

On the other hand, there'll be no transitions after a stop. JobOperator.stop() means stop, as soon as possible (roughly speaking).

So these two exit statuses will be seen, but not the "EARLY STOP".

<fail on="COMPLETED" exit-status="EARLY COMPLETION"/>
<fail on="FAILED" exit-status="EARLY FAIL"/>

After a stop, you could check for BatchStatus.STOPPED on job/step completion. You could also do something like use a StepListener and/or JobListener to query the current BatchStatus and set a special "is stopping" exit status on the JobContext.

Note while the artifacts are still executing you'll see BatchStatus of STOPPING, not (yet) STOPPED.

Will deliver this change with our next drop, probably today.

Comment by ScottKurz [ 10/Apr/13 02:09 PM ]

Resolved,

But as I mentioned the STOPPED portion of the test needs to change since it isn't valid.





[GLASSFISH-20098] BATCH GUI: Batch Help page is not available Created: 29/Mar/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

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

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

Tags:
Participants: Anissa Lam, arunkumar_s, Gail Risdal and Mike Fitch

 Description   

Tested with latest nightly

1) Login admin GUI page.
2) Select batch tab for any server target.
3) Click help button

Batch Page shows 404 error.



 Comments   
Comment by Anissa Lam [ 29/Mar/13 06:34 AM ]

The Batch online help set is not integrated to the build yet. Transfer to doc so they can ensure its working after integration.

Comment by Mike Fitch [ 01/Apr/13 03:26 PM ]

Initial help pages for the following pages were added in main-docs build 4.0-b26, which began getting picked up by GlassFish as of revision 61028 (29-Mar-2013 nightly):

  • Batch Job Execution Details
  • Batch Job Execution Steps
  • Batch Job Executions
  • Batch Runtime Configuration

These initial pages will be finalized by GlassFish build 4.0_b84_RC1.

Comment by Gail Risdal [ 04/Apr/13 09:02 PM ]

Accessible in current GlassFish builds.

This addition was included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152.





[GLASSFISH-20093] [Batch RI] Halfway Terminated Job Executions Created: 28/Mar/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

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

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

Tags:
Participants: arunkumar_s and ScottKurz

 Description   

Tested with latest nightly b82.

Steps:

1) Started a long running Job.
2) Killed the Job Process(here i killed Glassfish Process). Now the Job Execution killed/terminated halfway with status (STARTED)

Is getRunningExecutions() always returns the Job executions with state STARTED or really returns the actual running jobs?

If i try to abandon the halfway terminated job it says javax.batch.operations.JobExecutionIsRunningException

If i try to stop using joboperator.stop() the halfway terminated job then it says javax.batch.operations.JobExecutionNotRunningException

The user might actually get confused because of contradictory exceptions in this exceptional case



 Comments   
Comment by ScottKurz [ 02/Apr/13 08:33 PM ]

I made a fix which I believe will address this but I'll let you verify. We are delivering now in jbatch 1.0-b23, so I think that should make it into the b83.





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

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

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

Tags:
Participants: jjsnyder83

 Description   

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



 Comments   
Comment by jjsnyder83 [ 26/Mar/13 08:57 PM ]

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

testProcessInjectionTargetEventFiredForJsfManagedBean

Comment by jjsnyder83 [ 07/Apr/13 11:37 PM ]

The test has been removed from the tck suite.





[GLASSFISH-20043] OLH: common task page Created: 26/Mar/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b84_RC1

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

Tags:
Participants: Anissa Lam, Gail Risdal and Mike Fitch

 Description   

I fixed couple issues related to common task page.
The following is added also:

  • List Password Aliases
  • Create JDBC resource

Will be nice if we can add that to the OLH page, but if we can't, that should be ok too. You can lower that to P4.



 Comments   
Comment by Mike Fitch [ 26/Mar/13 03:25 PM ]

Set Fix Version to 4.0 so this issue would show up on 4.0 queries.

Comment by Gail Risdal [ 02/Apr/13 10:59 PM ]

Added 'To Create a JDBC Connection Pool'; did not add 'List Password Aliases' (task topic not available)

These additions will become accessible in GlassFish when the next main-docs build is promoted and picked up by GlassFish builds.

Comment by Gail Risdal [ 03/Apr/13 09:52 PM ]

Meant to say:
Added "To Create a JDBC Resource" ...

Comment by Gail Risdal [ 04/Apr/13 09:16 PM ]

Accessible in current GlassFish builds.

This addition was included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152.





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

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

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

Tags:
Participants: jjsnyder83

 Description   

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

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

Failed tests: testResourceInvocation(org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest): Exception attempting to inject Env-Prop: org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSProducer/sheepWS@Field-Injectable Resource. Class name = org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSProducer Field name=sheepWS@javax.jws.WebServiceRef@@@ into class org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSProducer: Lookup failed for 'java:comp/env/org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSProducer/sheepWS' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}



 Comments   
Comment by jjsnyder83 [ 25/Mar/13 11:03 PM ]

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

Comment by jjsnyder83 [ 08/Apr/13 12:21 AM ]

Fixed in Weld 2.0.0.CR1

Comment by jjsnyder83 [ 08/Apr/13 11:43 AM ]

Verify this still works on Weld 2.0.0.CR1





[GLASSFISH-20001] Time to time getting java.lang.InstantiationException from the ApplicationFilterConfig.java:135) Created: 22/Mar/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: mikc22 Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jitu, mikc22, Pavel Bucek, Shing Wai Chan and shreedhar_ganapathy

 Description   

The following testcase:

svn co https://svn.java.net/svn/tyrus~source-code-repository
cd tyrus~source-code-repository/trunk/tests/qa/websockets-lifecycle-test
mvn -v
#Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
#Maven home: /opt/netbeans/java/maven
#Java version: 1.7.0_11, vendor: Oracle Corporation
#Java home: /opt/jdk1.7.0_11/jre
#Default locale: en_US, platform encoding: UTF-8
#OS name: "linux", version: "3.2.0-27-generic", arch: "amd64", family: "unix"
mvn -Dtest=LifeCycleAnnotatedTest -Dwebsocket.container=glassfish -Dtyrus.test.port=8080 -Dglassfish.installRoot=/home/mikc/glassfish4/glassfish/ clean install

is sometimes failing for me with this exception:

WebModule[/websockets-lifecycle-test]Exception starting filter WebSocket filter
java.lang.InstantiationException
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:135)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:5297)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5909)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2291)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1937)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
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)



 Comments   
Comment by Shing Wai Chan [ 25/Mar/13 08:49 PM ]

The stack trace indicates that the WebSocket filter has failed to instantiate.
Assign to web socket team for further investigation.

Comment by jitu [ 25/Mar/13 09:04 PM ]

wondering why the webcontainer is instantiating the filter, when tyrus instantiates the filter as follows:

TyrusServletFilter filter = ctx.createFilter(TyrusServletFilter.class);
filter.setClasses(classes);
final FilterRegistration.Dynamic reg = ctx.addFilter("WebSocket filter", filter);

Also, none of the tyrus classes is in the stack trace, so for some reason container is trying to instantiate the filter. Note sure why.

Comment by Pavel Bucek [ 25/Mar/13 09:40 PM ]

additionally, it might be hitting issue with not correctly registering TyrusFilter (we were registering instance we've created), which should be already fixed in the trunk - this is against Glassfish build 81.

we should re-test when Tyrus 1.0-b14 is integrated.

Comment by Pavel Bucek [ 10/Apr/13 12:16 AM ]

mikc22, is this issue still valid? (I don't think so..)

Comment by Pavel Bucek [ 10/Apr/13 02:21 PM ]

cannot reproduce (linux, mac)

most likely fixed with changing the way how TyrusServletFilter is instantiated.

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

Can you close this issue if this issue is no longer reproducible?

Comment by Pavel Bucek [ 24/Apr/13 06:01 AM ]

test issue





set-log-level returns error when trying to set log level to ALERT and EMERGENCY (GLASSFISH-19995)

[GLASSFISH-19996] Logger Settings screen added 2 new Log Levels Created: 21/Mar/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b84_RC1

Type: Sub-task Priority: Major
Reporter: Anissa Lam Assignee: Gail Risdal
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Anissa Lam, Gail Risdal and Mike Fitch

 Description   

I just added 2 new Log Level : ALERT and EMERGENCY to the Logger Settings -> Logger Level screen.
We will need to update any doc about log levels.

But until this bug is fixed, you will see error on the GUI screen if you want to change to these 2 levels.
You will see these 2 new log level in both the LogViewer and this screen starting from tomorrow's (3/22) nightly build.



 Comments   
Comment by Mike Fitch [ 26/Mar/13 03:25 PM ]

Set Fix Version to 4.0 so this issue would show up on 4.0 queries.

Comment by Gail Risdal [ 29/Mar/13 09:14 PM ]

Added ALERT and EMERGENCY to the following in the OLH:

To Configure Log Levels - added to the list of levels

Module Log Levels - added the following:

EMERGENCY
The server is in an unusable state. A severe system failure or panic has occurred.

ALERT
A particular service is in an unusable state. Automatic recovery is not possible.

These changes will become accessible in GlassFish when the next main-docs build is promoted and picked up by GlassFish builds.

Comment by Gail Risdal [ 04/Apr/13 09:12 PM ]

Accessible in current GlassFish builds.

This addition was included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152.





[GLASSFISH-19981] An error has occurred - Cannot find specified Config Resource. Config may have been deleted. Created: 21/Mar/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Minor
Reporter: myfear Assignee: Anissa Lam
Resolution: Fixed Votes: 0
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, myfear and Snjezana Sevo-Zenzerovic

 Description   

Clicking on "Update Tool" leads to this message.
No log messages in logfile.



 Comments   
Comment by myfear [ 21/Mar/13 05:54 AM ]

Seems to be hard to reproduce.
Second and following clicks work.
You can "trigger" that if you access the http://localhost:4848/updateCenter/update.jsf page directly.

Comment by Snjezana Sevo-Zenzerovic [ 21/Mar/13 09:45 AM ]

Moving to appropriate subcategory.

Comment by Anissa Lam [ 21/Mar/13 05:22 PM ]

I have tried many times and cannot reproduce it. Also as the reporter mentioned, this is hard to reproduce.
Going to the direct URL is not documented and not supported.
Based on the above, I am lowering this to 'minor'. May get to this after looking at other higher priority bugs.

Comment by Anissa Lam [ 02/Apr/13 05:33 PM ]

I am closing this as not reproducible. I assume even in the rare case where u see this, u can refresh the browser and that will go away.

Comment by Anissa Lam [ 04/Apr/13 08:32 PM ]

Re-open to change resolution.

Comment by Anissa Lam [ 04/Apr/13 08:34 PM ]

Finally able to reproduce the issue.
After launching the console, if u go to the update tools screens before going to any configuration screen, then the error message will show up.
This and GLASSFISH-20156 is the same issue.
This is now fixed.





[GLASSFISH-19967] When registering the product, it gives me and error on registration page. Created: 20/Mar/13  Updated: 22/Apr/13  Resolved: 02/Apr/13

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

Type: Bug Priority: Major
Reporter: Mohamed Taman Assignee: Snjezana Sevo-Zenzerovic
Resolution: Cannot Reproduce Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 SP1
Glassfish ML v4 build 80


Tags: fishcat
Participants: jclingan, Mohamed Taman and Snjezana Sevo-Zenzerovic

 Description   

After closing the installer, it opens a web page asking for registering the product, and when entered my oracle username/password, it redirecting me to page titled "ORACLE PRODUCT REGISTRATION" and show the following message:

Sorry, there was a problem with your registration:



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 21/Mar/13 03:39 PM ]

Need further investigation - it is quite possible that you may not be able to register the product before it gets officially released.

Comment by jclingan [ 21/Mar/13 04:00 PM ]

I tried this on build 80 and it worked fine. Since I already had an account, I had to log in to OTN. After logging in, I got the "Thank you for registering" message.

Comment by Snjezana Sevo-Zenzerovic [ 02/Apr/13 01:03 PM ]

This worked for me on several tries, so this was presumably transient problem with registration server. Will keep an eye on it during the remainder of the test cycle and reopen as needed.

Comment by jclingan [ 10/Apr/13 04:41 PM ]

I have not been able to duplicate this problem. If someone else cannot duplicate it, then I will close this issue.

Thanks.

Comment by Mohamed Taman [ 11/Apr/13 07:56 AM ]

I have faced it again after installing version 4_b83.

I have an oracle Id which I use for download and registrations.

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

Mohamed,

was this last failure still happening with ML distribution and if so, with which locale? If that is the case, could you please try the latest English GF distribution and see if it is reproducible in that case. If that doesn't work either I guess we need to start debugging server side.

Comment by jclingan [ 22/Apr/13 06:53 PM ]

I did finally reproduce the problem, but not consistently. It works sometimes, and sometimes not. Same installation, just attempts at different times. I am not sure that this is a problem with GlassFish. It may be the backend registration system. When it does work, I can even install the same installation (UUID) multiple times, so that's not the problem.





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

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

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

Tags:
Participants: jjsnyder83

 Comments   
Comment by jjsnyder83 [ 19/Mar/13 07:29 PM ]

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

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

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

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

Comment by jjsnyder83 [ 21/Mar/13 12:26 AM ]

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

Comment by jjsnyder83 [ 07/Apr/13 07:33 PM ]

Committed revision 61218.





[GLASSFISH-19932] ADMINGUI : Context Information - Enabled - Options is not defined in the document Created: 19/Mar/13  Updated: 12/Apr/13  Resolved: 12/Apr/13

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: RameshT Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 , FF-19


Tags: admin-gui context services
Participants: Anissa Lam, Gail Risdal, Mike Fitch and RameshT

 Description   

Tested in 4.0 Build 80.

context information in context services has enabled as a column. It is not defined in the help document.
Help document description:
===============================
Context Information

The context to be propagated to threads: Classloader, JNDI, Security, or WorkArea. If no context is specified (the default), all context types are propagated.
================================



 Comments   
Comment by Anissa Lam [ 19/Mar/13 02:28 PM ]

Transfer to docs. But i think the docs is not ready for review yet.

Comment by Gail Risdal [ 04/Apr/13 09:04 PM ]

Accessible in current GlassFish builds.

This addition was included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152.

Comment by Mike Fitch [ 04/Apr/13 09:55 PM ]

Removed the following from the Status Whiteboard field, as it was mistakenly entered there instead of in the Comment field on 26/Mar/13:

Added information about the 'Context Information Enabled' checkbox/functionality to the online help.

This addition will become accessible in GlassFish when the next main-docs build is promoted and picked up by GlassFish builds.

Comment by RameshT [ 12/Apr/13 11:27 AM ]

I have checked this with GlassFish Build 85 ( Nightly ).
I can see 404- not found with LHS Blank screen.
Browser : FF19 & IE

Hence I am reopening the issue.

Comment by Mike Fitch [ 12/Apr/13 03:56 PM ]

This was working in the Apr 5, 2013 nightly. Something has changed since then in the online help machinery because the help itself hasn't changed. Therefore, setting the Fix Version to Unknown and assigning to admin_gui and Anissa Lam to look into.

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

Assign this back to Mike.
He can comment on the content part and mark this closed.
The 404 error issue is tracked by GLASSFISH-20301.

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

Remarking this issue as Resolved/Fixed and resetting the Fix Version to 4.0_b84_RC1.

The help for "Context Information" was updated to the following:

The contexts to propagate to threads: Classloader, JNDI, Security, or WorkArea. Context propagation can be enabled or disabled. If enabled, the selected contexts are propagated. If disabled, none of the contexts are propagated, even if they are selected. The default value is Enabled, with all four contexts selected.

This change was made in the help for both "Edit Context Service" and "New Context Service". This change was committed to main-docs in svn revision 61142 and appeared in 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 shows these changes. 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.





[GLASSFISH-19911] BATCH CLI: asadmin list-batch-jobs -o not working with the options specified in help Created: 18/Mar/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

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

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, Mahesh Kannan and michael.y.chen

 Description   

Tested with 4.0 b80

asadmin list-batch-jobs --help shows the below options for -o or --output. But all of them are not working as expected. Eg: Help shows job-name as one option, but actually jobname only works

--output, -o
Displays specific details about each job. Use a comma-separated
list to specify the details you want to display and their order.
The values are case-insensitive. The job-name and instance-count
column headings are displayed by default.

Possible values are as follows:

job-name
Displays the name of the job.

instance-count
Displays the number of job instances that are running.

execution-id
Displays the execution ID of a particular job instance.

status
Displays the status of the job.

exit-status
Displays the exit status of the job.

start-time
Displays the start time of the job.

end-time
Displays the finish time of the job.

job-parameters
Displays the job parameters.



 Comments   
Comment by michael.y.chen [ 25/Apr/13 05:09 AM ]

I assume this is fixed.

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

This has been fixed a while back by Gail Risdal.

Here is the command output:

asadmin list-batch-jobs --help
list-batch-jobs(1) asadmin Utility Subcommands list-batch-jobs(1)

NAME
list-batch-jobs - lists batch jobs

SYNOPSIS
list-batch-jobs [--help]
[--target target]
[--long={false|true}]
[--output output]
[--header={false|true}]

[job_name]

DESCRIPTION
The list-batch-jobs subcommand lists batch jobs and job details.

OPTIONS
--help, -?
Displays the help text for the subcommand.

--target
Specifies the target for which to list batch jobs and job details.
Valid values are as follows:

server
Lists batch jobs for the default server instance server and is
the default value.

cluster-name
Lists batch jobs for every server instance in the cluster.

instance-name
Lists batch jobs for a particular server instance.

--long, -l
Displays detailed information about batch jobs. The default value
is false.

--output, -o
Displays specific details about batch jobs. Use a comma-separated
list to specify the details to display and their order. The values
are case-insensitive. The jobname and instancecount column headings
are displayed by default.

Possible values are as follows:

jobname
Displays the name of the job.

appname
Displays the name of the application.

instancecount
Displays the number of job instances.

instanceid
Displays the ID assigned to the job instance.

executionid
Displays the ID assigned to the execution of the batch job. A
new execution is created the first time a job is started and
every time the existing execution is restarted.

batchstatus
Displays the status of the job as set by the batch runtime.

starttime
Displays the start time of the job.

endtime
Displays the finish time of the job.

exitstatus
Displays the status of the job as set by the Job XML for the
job or by the batch application. By default, the exit status
and the batch status are the same unless the exit status is
explicitly overridden.

--header, -h
Specifies whether column headings are displayed when the --long
option is used. The default value is true. To suppress the
headings, set the --header option to false.

OPERANDS
job_name
The name of the job for which to list details.

EXAMPLES
Example 1, Listing Batch Jobs
This example lists batch jobs for the default server instance.

asadmin> list-batch-jobs
JOBNAME INSTANCECOUNT
payroll 9
bonus 6
Command list-batch-jobs executed successfully.

EXIT STATUS
0
subcommand executed successfully

1
error in executing the subcommand

SEE ALSO
list-batch-job-executions(1), list-batch-job-steps(1),
set-batch-runtime-configuration(1), list-batch-runtime-configuration(1)

asadmin(1M)

Java EE 7 13 Feb 2013 list-batch-jobs(1)
Command list-batch-jobs executed successfully.





[GLASSFISH-19887] [508] Row has empty header in the Context Services Created: 15/Mar/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b84_RC1

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

508 Windows 7 / FireFox 19.0 , GF 4.0 b78


Tags: 4_0-approved admin-gui gf-4-0-508
Participants: Anissa Lam, RameshT and Tom Mueller

 Description   

In the Context services in the right window, a row has an empty header. All the tables should have row and column Headers defined to meet accessibility standards.
In the OGHAG Table analyzer report got the following message:

"WARNING: column has EMPTY header (TABLE-1)"

The same thing occurs for Managed thread Factories , Managed Executor Services , Managed scheduled executor services.



 Comments   
Comment by Anissa Lam [ 27/Mar/13 04:13 AM ]

This is similar to whats reported in GLASSFISH-19494 and datatable in GLASSFISH-19491.

The concurrent resources table has more than 1 column that set 'rowHeader' to true. This is now fixed.
The select box has toolTip to it.

Comment by RameshT [ 05/Apr/13 11:27 AM ]

Checked in Bulid83 and got the same failures. Hence reopening the issue.

Comment by Anissa Lam [ 09/Apr/13 10:01 PM ]
  • What is the impact on the customer of the bug?
    This is 508 issues, will have minor impact on people who needs accessibility compliance software.
  • How likely is it that a customer will see the bug and how serious is the bug? It is likely that they see the bug.
    Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    Not a regression. This is new screen.
  • What CTS failures are caused by this bug?
    CTS doesn't include console
  • What is the cost/risk of fixing the bug?
    The fix will need to add a column header to the Selection column. This touches a number of files, but there is no code change, just add a header name.

How risky is the fix? How much work is the fix? Is the fix complicated?
Risk is low as there is no code change, just add a name to the column header.

  • Is there an impact on documentation or message strings?
    Need to add one key to Strings.properties.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Sameas reported here.
  • Which is the targeted build of 4.0 for this fix?
    84
Comment by Tom Mueller [ 09/Apr/13 10:10 PM ]

Approved for 4.0.

Comment by Anissa Lam [ 09/Apr/13 11:37 PM ]

Log Message:
------------
GLASSFISH-19887. Add the Header Text for Select column for all the tables that allows selections.

Revisions:
----------
61274

Modified Paths:
---------------
trunk/main/appserver/admingui/web/src/main/resources/configuration/httpListeners.jsf
trunk/main/appserver/admingui/common/src/main/resources/security/auditModules/auditModules.jsf
trunk/main/appserver/admingui/web/src/main/resources/grizzly/networkListeners.jsf
trunk/main/appserver/admingui/common/src/main/resources/applications/targetListing.jsf
trunk/main/appserver/admingui/web/src/main/resources/grizzly/transports.jsf
trunk/main/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java
trunk/main/appserver/admingui/common/src/main/resources/applications/lifecycleTargetListing.jsf
trunk/main/appserver/admingui/common/src/main/resources/security/msgSecurity/msgSecurity.jsf
trunk/main/appserver/admingui/common/src/main/resources/configuration/configurations.jsf
trunk/main/appserver/admingui/web/src/main/resources/grizzly/transportsTable.inc
trunk/main/appserver/admingui/cluster/src/main/resources/cluster/clusters.jsf
trunk/main/appserver/admingui/cluster/src/main/resources/shared/instancesTable.inc
trunk/main/appserver/admingui/common/src/main/resources/configuration/systemProperties.jsf
trunk/main/appserver/admingui/web/src/main/resources/grizzly/protocols.jsf
trunk/main/appserver/admingui/corba/src/main/resources/iiopListeners.jsf
trunk/main/appserver/admingui/common/src/main/resources/security/realms/realms.jsf
trunk/main/appserver/admingui/common/src/main/resources/configuration/configurationSystemProperties.jsf
trunk/main/appserver/admingui/cluster/src/main/resources/cluster/listEjbTimers.jsf
trunk/main/appserver/admingui/common/src/main/resources/applications/deployTable.inc
trunk/main/appserver/admingui/full/src/main/resources/resourcesTable.inc
trunk/main/appserver/admingui/jca/src/main/resources/securityMapsTable.inc
trunk/main/appserver/admingui/common/src/main/resources/resourceNode/confidentialPropsTable.inc
trunk/main/appserver/admingui/jca/src/main/resources/poolTable.inc
trunk/main/appserver/admingui/common/src/main/resources/security/msgSecurity/providers.jsf
trunk/main/appserver/admingui/common/src/main/resources/monitor/monitoringPage.jsf
trunk/main/appserver/admingui/common/src/main/resources/javaConfig/jvmOptionsTable.inc
trunk/main/appserver/admingui/common/src/main/resources/security/jacc/jaccProviders.jsf
trunk/main/appserver/admingui/common/src/main/resources/shared/propertyDescTable.inc
trunk/main/appserver/admingui/common/src/main/resources/resourceNode/targetResourceTable.inc
trunk/main/appserver/admingui/common/src/main/resources/security/realms/manageUsers.jsf
trunk/main/appserver/admingui/common/src/main/resources/appServer/pswdAliases.jsf
trunk/main/appserver/admingui/web/src/main/resources/configuration/threadPools.jsf
trunk/main/appserver/admingui/web/src/main/resources/configuration/virtualServers.jsf
trunk/main/appserver/admingui/common/src/main/resources/configuration/loggerLevels.jsf
trunk/main/appserver/admingui/cluster/src/main/resources/cluster/clusterNew.jsf
trunk/main/appserver/admingui/jdbc/src/main/resources/poolTable.inc
trunk/main/appserver/admingui/jms-plugin/src/main/resources/shared/resourcesTable.inc
trunk/main/appserver/admingui/common/src/main/resources/resourceNode/resourceEditTargets.jsf
trunk/main/appserver/admingui/jms-plugin/src/main/resources/physdest/physDestTable.jsf
trunk/main/appserver/admingui/cluster/src/main/resources/shared/appSingleTargetTable.inc
trunk/main/appserver/admingui/updatecenter/src/main/resources/ucTable.jsf
trunk/main/appserver/admingui/jca/src/main/resources/connectorsPoolTable.inc
trunk/main/appserver/admingui/core/src/main/resources/org/glassfish/admingui/core/Strings.properties
trunk/main/appserver/admingui/jca/src/main/resources/resourcesTable.inc
trunk/main/appserver/admingui/common/src/main/resources/applications/lifecyclesTable.inc
trunk/main/appserver/admingui/cluster/src/main/resources/node/nodes.jsf
trunk/main/appserver/admingui/cluster/src/main/resources/cluster/migrateEjbTimers.jsf
trunk/main/appserver/admingui/jca/src/main/resources/resourceAdapterConfigs.jsf
trunk/main/appserver/admingui/jdbc/src/main/resources/resourcesTable.inc
trunk/main/appserver/admingui/cluster/src/main/resources/cluster/clusterResources.jsf
trunk/main/appserver/admingui/concurrent/src/main/resources/resourcesTable.inc





[GLASSFISH-19883] [508] ERROR : Update center image link dont have text Created: 15/Mar/13  Updated: 08/Apr/13  Resolved: 08/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b84_RC1

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

508 Windows 7 / FireFox 19.0 , GF 4.0 b78


Tags: admin-gui gf-4-0-508
Participants: Anissa Lam and RameshT

 Description   

After loading the admin console update center link ( Below Oracle GlassFish Server image ) dont have the link text.
Got error in OGHAG link test.



 Comments   
Comment by Anissa Lam [ 29/Mar/13 06:37 AM ]

When console is first loaded, the update count, even if there is any, may not shown up until after the first click on anything which triggers the header refresh.
Before the first click, only the image is shown. I have added the 'alt' to the image to ensure that image will be read out.

After the first click, if there is any update, there will be text next to the image if there is any updates available. At this point, both the 'alt' and tooltip will include both 'update tools' and the # of updates.

fix is available, but can't check in as java.net seems down.

Comment by Anissa Lam [ 29/Mar/13 06:49 AM ]

Fix committed.

Log Message:
------------
GLASSFISH-19883. Fix 508 issue for update center image.

Revisions:
----------
60998

Modified Paths:
---------------
trunk/main/appserver/admingui/updatecenter/src/main/resources/updatesAvailable.inc

Comment by RameshT [ 05/Apr/13 07:58 AM ]

The issue is still seen in build 83. No update image text is displayed.

Also with this a regression occured.

when you click the update image at first time it is working as expected.
If you click at second time it throws error as :
"An Error has occured
Cannot find specified Config Resource. Config may have been deleted. "

Hence reopening the issue.

This is occurring in win8 - IE10 and win7-FF19.0.

Comment by Anissa Lam [ 08/Apr/13 03:37 PM ]

The config error you are seeing is due to GLASSFISH-20156.
The fix for that bug goes in on 4/4 and didn't make it to build 83.
So, please verify with the latest nightly build, or any build after 4/6.





[GLASSFISH-19879] digest authentication security test failed in GF4.0 Created: 14/Mar/13  Updated: 03/Apr/13  Resolved: 03/Apr/13

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b84_RC1

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:

linux


Tags: 4_0-approved
Participants: sonialiu and Tim Quinn

 Description   

This test was blocked by bug 17578. After fixing the bug, I ran the test and it still failed. Here are the 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/digestauth, run "ant all"
the test failed and the following exceptions displayed in server.log
[2013-03-14T15:34:52.490-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core.security.com.sun.enterprise.security.auth.login] [tid: _ThreadID=29 _ThreadName=http-listener-1(4)] [timeMillis: 1363300492490] [levelValue: 800] [[
SEC5046: Audit: Authentication refused for [j2ee].]]

[2013-03-14T15:34:52.490-0700] [glassfish 4.0] [WARNING] [web.login.failed] [javax.enterprise.system.container.web.com.sun.web.security] [tid: _ThreadID=29 _ThreadName=http-listener-1(4)] [timeMillis: 1363300492490] [levelValue: 900] [[
WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed: java.lang.NullPointerException
at com.sun.enterprise.security.ee.auth.login.DigestLoginModule.login(DigestLoginModule.java:104)
at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:992)
at com.sun.web.security.RealmAdapter.authenticate(RealmAdapter.java:523)
at org.apache.catalina.authenticator.DigestAuthenticator.authenticate(DigestAuthenticator.java:302)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1434)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:580)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:702)
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)

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



 Comments   
Comment by Tim Quinn [ 03/Apr/13 05:32 AM ]

I placed a null check in the DigestLoginModule to avoid the NPE, and now I see a different failure in the test. Still looking.

run:
     [echo] running httpdigest client - /scratch/tjquinn/gf/sqe/appserver-sqe/build/pe/i386_adc6140581_Linux/sec/classes
     [java] wait... 
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Exception in thread "main" java.net.ProtocolException: Server redirected too many  times (20)
     [java] 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1635)
     [java] 	at org.jvnet.glassfish.comms.test.sec.HttpDigestClient.main(HttpDigestClient.java:47)
     [java] Java Result: 1
     [echo] Waiting for 10 secs ...
Comment by Tim Quinn [ 03/Apr/13 05:32 AM ]

Assigning this to me, at least for the moment.

Comment by Tim Quinn [ 03/Apr/13 04:47 PM ]

In the failing test RealmAdapter.authenticate:581 creates a DigestCredentials object and attaches it to the Subject and then invokes LoginContextDriver.login passing the new credentials.

The DigestLoginModule.login method is invoked as part of LoginContextDriver.login processing, but it looks for the digest creds to process by using an instanceof check on each of the Subject's private credentials. And there is the problem, because DigestLoginModule is checking for

com.sun.enterprise.security.ee.auth.login.DigestCredentials (in the appserver/security/core-ee module)

whereas the RealmAdapter has created a

com.sun.enterprise.security.auth.login.DigestCredentials (in the main/nucleus/security/core module)

Neither class extends the other, so the instanceof check in the DigestLoginModule fails and it never sees the digest credentials and authentication never happens.

A candidate fix in which the DigestLoginModule checks for and works with both types of DigestCredentials allows the failing SQE test to pass.

Comment by Tim Quinn [ 03/Apr/13 04:52 PM ]
  • What is the impact on the customer of the bug?
    This is a regression; SQE tests which passed now fail.
  • What is the cost/risk of fixing the bug?
    The candidate fix is a few lines of code, isolated to one method of one class.
  • 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 pe/security tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_b84 (assuming b83 is already done)
  • 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 Tim Quinn [ 03/Apr/13 06:10 PM ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 61146
Author: tjquinn
Date: 2013-04-03 18:08:42 UTC
Link:

Log Message:
------------
Fix for GLASSFISH-19879 - digest authentication security test failed in GF4.0

RealmAdapter.authenticate:581 creates a DigestCredentials object and attaches it to the Subject and then invokes LoginContextDriver.login passing the new credentials.

The DigestLoginModule.login method is invoked as part of LoginContextDriver.login processing, but it looks for the digest creds to process by using an instanceof check on each of the Subject's private credentials. And there is the problem, because DigestLoginModule is checking for

com.sun.enterprise.security.ee.auth.login.DigestCredentials (in the appserver/security/core-ee module)

whereas the RealmAdapter has created a

com.sun.enterprise.security.auth.login.DigestCredentials (in the main/nucleus/security/core module)

Neither class extends the other, so the instanceof check in the DigestLoginModule fails and it never sees the digest credentials and authentication never happens.

With this change the DigestLoginModule checks for and works with both types of DigestCredentials allows the failing SQE test to pass.

Reviewed: Jeff T.
Approved: Michael C.
Tests: QL, the failing SQE test

Revisions:
----------
61146

Modified Paths:
---------------
trunk/main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/ee/auth/login/DigestLoginModule.java





[GLASSFISH-19876] glassfish-osgi-gui has become part of default distribution when it should not be Created: 14/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

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

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Romain Grécourt and Sanjeeb Sahoo

 Description   

Compare this:
$ unzip -l glassfish-4.0-b80.zip | grep felix-webconsole-extension
13630 03-13-2013 15:07 glassfish4/glassfish/modules/autostart/felix-webconsole-extension.jar
vs:

$ unzip -l /home/ss141213/download/glassfish-3.1.2.2.zip | grep felix-webconsole-extension

Same is true for autostart/org.apache.felix.webconsole.jar and glassfish-osgi-console-plugin.jar

This is likely to have performance impact - both startup time and memory.



 Comments   
Comment by Romain Grécourt [ 14/Mar/13 07:08 PM ]

I've removed the ips package from the ips distribution creation process. See svn rev #60468.
Leaving open for future IPS packaging review.





[GLASSFISH-19870] Batch RI : Batch Exceptions : Restarting a running job execution starts a new job execution Created: 14/Mar/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

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

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

Issue Links:
Related
is related to GLASSFISH-20119 BATCH RI: IllegalStateException when ... Resolved
Tags:
Participants: arunkumar_s and ScottKurz

 Description   

Tested with latest nightly : glassfish-4.0-b80-03_13_2013

Steps:

1) Restart a job execution which is currently running

Issue --> Creates a new Job execution with FAILED status

Not sure this is a bug or request as JobOperator.restart(executionid) doesn't have JobExecutionIsRunningException defined in RI ,but it should throw JobExecutionIsRunningException



 Comments   
Comment by ScottKurz [ 27/Mar/13 04:28 AM ]

There are a couple aspects to this one.

First, it's not clear whether you're saying that you're doing:

// Restart, then do restart with the execution ID from the new restart, while first restart is still running

long exec1Id = jo.start(...)
long exec2Id = jo.restart(exec1Id, null);
long exec3Id = jo.restart(exec2Id, null);

OR:

// Restart, then do restart with the execution ID from the new restart

long exec1Id = jo.start(...)
long exec2Id = jo.restart(exec1Id, null);
long exec3Id = jo.restart(exec1Id, null);

----------

The second case we've addressed in 1.0-b21. It will actually be treated via JobExecutionNotMostRecentException, since
the 2nd time 'exec1Id' is passed, it is no longer the most recent.

The first is not fixed and I don't want to promise yet it will be in b22.

I agree JobExecutionIsRunningException would be a natural candidate ... but given that we hope to have frozen the API at this point, I'd suggest we can deal with this via JobRestartException.

Comment by arunkumar_s [ 27/Mar/13 06:19 AM ]

Job execution has to be in a State(Failed/Stopped) to restart the execution. If a Job is in Started State, and trying to restart the same job execution then the user should get JobExecutionIsRunningException or JobRestartException

Comment by ScottKurz [ 03/Apr/13 09:06 PM ]

Just doing another pass here. This is still a problem even in the latest code.

Comment by ScottKurz [ 04/Apr/13 06:37 PM ]

Fixed in jbatch 1.0-b24





[GLASSFISH-19840] JPA2.1: script for the generateSchema call was not found. Created: 12/Mar/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b84_RC1

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

RHL6.x and JDK1.7.0_10


Tags:
Participants: Mitesh Meswani and sherryshen

 Description   

glassfish-4.0-b79.zip

appserver-sqe/pe/ejb/jpa20/war/schemageneration
The test app failed to deploy war
when persistence.xml
<property name="javax.persistence.sql-load-script-source"
value="/tmp/insert_derby.sql"/>



 Comments   
Comment by sherryshen [ 12/Mar/13 03:29 PM ]

On the test machine, sql file exits.
# cat /tmp/insert_derby.sql
INSERT INTO SG_PROJ (ID , NAME) VALUES (2,'myProj2');
#
exception in server.log
[2013-03-08T17:36:31.090-0800] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=76 _ThreadName=Thread-4] [timeMillis: 1362792991090] [levelValue: 1000] [[
javax.persistence.PersistenceException: The source script: /tmp/insert_derby.sql for the generateSchema call was not found.

Comment by sherryshen [ 12/Mar/13 04:31 PM ]

On 3/12/2013 8:53 AM, Guy Pelletier wrote:
> Hi Sherry,
>
> Have you tried "file://tmp/insert_derby.sql"?
>
> The reason for the error is that java is throwing a MalformedURLException, which we should be including in our error message (so I will add that).
>
> Cheers,
> Guy

Comment by sherryshen [ 12/Mar/13 04:33 PM ]

Hi Guy,

Thanks for the feedback. I verified the
insert_derby.sql script in the following
way. Please review and let me know what
is the problem.
Thanks!

Sherry
1) remove javax.persistence.sql-load-script-source line in persistence.xml

2) deploy app, which create table
$ ant setup build deploy

3) use sql script to insert data from ant, OK.
$ant insert-db

execute-sql-common:
[echo] ***** db.url=jdbc:derby://localhost:1527/testdb;retrieveMessagesFromServerOnGetMessage=true;create=true;user=dbuser;password=dbpassword; ; dbuser : dbpassword *****
[sql] Executing resource: /root/.hudson/jobs/core-das/workspace/appserver-sqe/pe/ejb/jpa20/war/schemageneration/sql/insert_derby.sql
[sql] 1 rows affected
[sql] 1 of 1 SQL statements executed successfully

BUILD SUCCESSFUL
Total time: 5 seconds

4) use sql script to check data from ant, OK, found 2, myProj2
$ant check-db
execute-sql-common:
[echo] ***** db.url=jdbc:derby://localhost:1527/testdb;retrieveMessagesFromServerOnGetMessage=true;create=true;user=dbuser;password=dbpassword; ; dbuser : dbpassword *****
[sql] Executing resource: /root/.hudson/jobs/core-das/workspace/appserver-sqe/pe/ejb/jpa20/war/schemageneration/sql/check_derby.sql
[sql] ID,NAME
[sql] 2,myProj2
[sql]
[sql] 0 rows affected
[sql] 1 of 1 SQL statements executed successfully

BUILD SUCCESSFUL
Total time: 4 seconds

5) run test to find data
$ant run
run:
[java] WS HOME appserver-sqe
[java] url=http://localhost:8080/schemageneration/test?tc=test1
[java] url=http://localhost:8080/schemageneration/test?tc=test2
[java] Generating report at /root/.hudson/jobs/core-das/workspace/appserver-sqe/test_results.xml
[java]
[java]
[java] -----------------------------------------
[java] - JPA21-schemageneration-war-test2: PASS -
[java] - JPA21-schemageneration-war-test1: PASS -
[java] -----------------------------------------
[java] Total PASS: 2
[java] Total FAIL: 0
[java] Total DNR: 0
[java] -----------------------------------------
test2: found this data, 2, myProj2

6) use sql to check db, OK.
Note that 1, myProj1 is persisted from test1.

execute-sql-common:
[echo] ***** db.url=jdbc:derby://localhost:1527/testdb;retrieveMessagesFromServerOnGetMessage=true;create=true;user=dbuser;password=dbpassword; ; dbuser : dbpassword *****
[sql] Executing resource: /root/.hudson/jobs/core-das/workspace/appserver-sqe/pe/ejb/jpa20/war/schemageneration/sql/check_derby.sql
[sql] ID,NAME
[sql] 2,myProj2
[sql] 1,myProj1
[sql]
[sql] 0 rows affected
[sql] 1 of 1 SQL statements executed successfully

BUILD SUCCESSFUL
Total time: 4 seconds

Comment by sherryshen [ 12/Mar/13 09:12 PM ]

Feedback from Guy:
Another bit of information pulled from the spec:

"When scripts are packaged as part of the persistence application, these properties must specify locations
relative to the root of the persistence unit. When scripts are provided externally (or when schema generation
is to occur into script files, as described below), strings corresponding to file URLs must be specified.
In Java EE environments, such file URL specifications must be absolute paths (not relative). In
Java EE environments, all source and target file locations must be accessible to the application server
deploying the persistence unit."

So couple things to verify, one that there is permission to access the file and that your path is an absolute path.

With the help from Guy.
The error (script for for the generateSchema call was not found.) was resolved with using
<property name="javax.persistence.sql-load-script-source"
value="file:/tmp/load.sql"/>
Guy will revise EclipseLink for better message.

Comment by sherryshen [ 20/Mar/13 07:52 PM ]

I tracked the issue with
https://bugs.eclipse.org/bugs/show_bug.cgi?id=403939

Comment by Mitesh Meswani [ 10/Apr/13 11:27 PM ]

Fixed with recent integration of EclipseLink





[GLASSFISH-19838] asadmin redeploy --upload command does not work Created: 12/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b84_RC1

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

Tags:
Participants: martin.mares and Tom Mueller

 Description   

asadmin redeploy --upload FAILS
while:
asadmin redeploy OK
asadmin deploy --upload OK

Together with it I see also related minnot issue that command fails by NullPointerExceptin created in catch block. It is because there is unchecked manipulation with field assigned from the middle of related try block. So, when try block fails before this assignment then original exception is hidden by non-relevant NPE. See DeployCommand around line 305.

What I know

After very short investigation I found out that core of issue is that file to deploy (refered by DeployCommand.path) exists (in standard upload directory) but it is empty.
I also have theory why it is. Originally is path param injected into ReDeployCommand . Then ReDeployCommand calls DeployCommand using standard invocation in CommandRunnerImpl. Path is loaded from Payload.inbound. But Payload.inboud use stream as data source for its parts. So, for second call when injecting into DeployCommand.path it has no more data in stream because all of original stream was loaded when injecting into ReDeployCommand.

Contract of Payload that can contains stream is there from history but in current version we really use it in command call case. Before it was created from Zip file entry. So, it was possible to reenter it.
We need first to choose what to do with Payload contract. If payload part is created from stream we can

  • copy stream to file just after construction
  • copy stream to file while loading
  • update entry when we move data to file from Payload somewhere in CommandRunnerImpl or related class. = This solution is my favorite because max one file for one Payload.part will be created.


 Comments   
Comment by martin.mares [ 12/Mar/13 02:58 PM ]

I assigned this issue to Tom because I need opponent for choosing fix method.

Comment by Tom Mueller [ 12/Mar/13 04:01 PM ]

Agree with your analysis and the recommended solution (#3).

Comment by martin.mares [ 11/Apr/13 11:19 AM ]

Fixed





Add console support for 'batch' which is added for EE7 (GLASSFISH-19208)

[GLASSFISH-19734] Provide OLH for Batch screens Created: 27/Feb/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

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

Type: Sub-task Priority: Critical
Reporter: Anissa Lam Assignee: Gail Risdal
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Anissa Lam and Gail Risdal

 Description   

There will be 3 new screens added for Batch. This subtask is for tracking for OLH.
Please refer to the GLASSFISH-19208 for more info.

The screen is added in the 'common' plugin, if there is any change, will let the doc team know.



 Comments   
Comment by Anissa Lam [ 11/Mar/13 04:09 AM ]

All screens for batch support has been delivered.
Besides OLH, the inline help will need some editing as well. Its at the end of the Strings.properties file in the 'common' module.
It has the 'batch' as the key prefix.

Comment by Gail Risdal [ 30/Mar/13 05:47 AM ]

OLH for the batch screens has been written and the inline help has been edited.

The inline help is visible in current builds; the OLH will become accessible in GlassFish when the next main-docs build is promoted and picked up by GlassFish builds.

Comment by Gail Risdal [ 04/Apr/13 09:06 PM ]

Accessible in current GlassFish builds.

This addition was included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152.





[GLASSFISH-19657] OLH: add deployment-order to the resource page Created: 08/Feb/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

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

Type: Task Priority: Major
Reporter: Anissa Lam Assignee: Gail Risdal
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-19656 Add deployment-order to all the resou... Resolved
Tags:
Participants: Anissa Lam, Gail Risdal and Mike Fitch

 Description   

Refer to the gui issue. GLASSFISH-19656



 Comments   
Comment by Mike Fitch [ 12/Feb/13 03:58 PM ]

Changed "Fix Version" to MS7 to align with change to parent engineering issue.

Comment by Gail Risdal [ 25/Mar/13 11:43 PM ]

Added "Deployment Order" content to the OLH.

The OLH will become accessible in GlassFish when the next main-docs build is promoted and picked up by GlassFish builds.

Comment by Gail Risdal [ 04/Apr/13 09:07 PM ]

Accessible in current GlassFish builds.

This addition was included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152.





[GLASSFISH-19578] OLH needed for JSR 236 resources screen Created: 23/Jan/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

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

Type: New Feature Priority: Critical
Reporter: Anissa Lam Assignee: Gail Risdal
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-19405 Add Console support for JSR 236 Resolved
Tags:
Participants: Anissa Lam and Gail Risdal

 Description   

Hong is working on the config beans and CLI for JSR 236. I have updated GLASSFISH-19405 about the new screens in console.
Not sure if there is other docs bug created relating to JSR 236, such as the admin docs.



 Comments   
Comment by Gail Risdal [ 25/Mar/13 11:05 PM ]

Created online help for the Concurrent Resources screens.

The OLH will become accessible in GlassFish when the next main-docs build is promoted and picked up by GlassFish builds.

Comment by Gail Risdal [ 04/Apr/13 09:09 PM ]

Accessible in current GlassFish builds.

This addition was included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152.





[GLASSFISH-19551] ServletContainerInitializer#onStartup doesn't provide all classes specified in @HandlesTypes Created: 17/Jan/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

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

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

Issue Links:
Dependency
blocks TYRUS-64 Get rid of @ApplicationConfig once ht... Resolved
Tags:
Participants: Mahesh Kannan, Shing Wai Chan and stepan.kopriva

 Description   

Let's have the following ServletContainerInitializer implementation, where ServerApplicationConfiguration is an Interface.

===============
@HandlesTypes({WebSocketEndpoint.class, ServerApplicationConfiguration.class, Endpoint.class})
public class ReadListenerServletContainerInitializer implements ServletContainerInitializer {
public void onStartup(Set<Class<?>> classes, ServletContext ctx) throws ServletException {
===============

According to javadoc for @HandlesTypes, all application classes implementing the ServerApplicationConfiguration should be passed in onStartup(...), but they aren't. However, this works for annotations and for application classes that extend the class specified in @HandlesTypes.



 Comments   
Comment by Shing Wai Chan [ 22/Jan/13 09:44 PM ]

I have looked at the test war and found the following:
./WEB-INF/classes/META-INF/services/javax.servlet.ServletContainerInitializer

According Servlet 3.0 spec, the above file must be resided in a jar under WEB-INF/lib.
Therefore the above file will not be loaded by Servlet 3.0 container.

Comment by Shing Wai Chan [ 23/Jan/13 02:58 AM ]

First, GlassFish does more than what the spec says. It will scan scan META-INF/services, too.

Second, even if I repackage the application correctly, it still have issues for ServerApplicationConfiguration.
The issue is that in ServletContainerInitializerUtil#checkAgainstInterestList, we have

Type type = classsInfo.getBy(c.getName());

type is null when c is ServerApplicationConfiguration.

And classInfo is obtained from WebModule#getTypes as follows:

if (wmInfo.getDeploymentContext()!=null) {
            return wmInfo.getDeploymentContext().getTransientAppMetaData(Types.class.getName(), Types.class);
        } else {
            return null;
        }
Comment by Shing Wai Chan [ 23/Jan/13 07:03 AM ]

After debugging, I notice that in one of the API call
classInfo.getBy("javax.websocket.server.ServerApplicationConfiguration")
returning null where classInfo is a org.glassfish.hk2.classmodel.reflect.impl.TypesCtr
which implements org.glassfish.hk2.classmodel.reflect.Types.

From the debugger, I notice that classInfo has a ConcurrentHashMap containing 3 elements
corresponding to keys: org.glassfish.hk2.classmodel.reflect.AnnotationType,
org.glassfish.hk2.classmodel.reflect.ClassModel, org.glassfish.hk2.classmodel.reflect.InterfaceModel.

When I invoke, classInfo.getAllTypes(), it only returns elements from the first two.
And "javax.websocket.server.ServerApplicationConfiguration" associates to the third element.

Comment by Shing Wai Chan [ 06/Feb/13 10:53 PM ]

This is fixed in HK 2.1.57.

Comment by stepan.kopriva [ 13/Feb/13 09:57 AM ]

ServletContainerInitializer doesn't provide classes specified in @HandlesTypes for the following configuration:

Let's have the following setup:

1)
@HandlesTypes(ServerEndpointConfiguration.class)
public class ReadListenerServletContainerInitializer implements ServletContainerInitializer ...

2)
public class DefaultServerConfiguration implements ServerEndpointConfiguration... // both DefaultServerConfiguration and ServerEndpointConfiguration are in javax.websocket-api, to which there is a dependency in application pom.xml.

3)
public class Config extends DefaultServerConfiguration // this class is in the deployed application.

Now the problem is that Config is not present in classes parameter in ReadListenerServletContainerInitializer.(Set<Class<?>> classes, ServletContext ctx) throws ServletException.

Comment by Shing Wai Chan [ 13/Feb/13 11:57 AM ]

This test scenario is different from the original one. There may be an issue in model data. Need more investigation.

Comment by Shing Wai Chan [ 13/Feb/13 10:35 PM ]

In ServletContainerInitializerUtil#checkAgainstInterestList, we have

Type type = classInfo.getBy(c.getName());

where classInfo is Types.
When c is the interface javax.websocket.server.ServerEndpointConfiguration,
type is null.

From the debugger, I observe the following inside the classInfo:
there is no information for ServerEndpointConfiguration
(ii) Even though org.glassfish.bugs.Config extends DefaultServerConfiguration which implements ServerEndpointConfiguration, it is associated to ClassModel internal ConcurrentHashMap.

Comment by Mahesh Kannan [ 04/Mar/13 03:21 AM ]

OK, The root cause is that the ClassModel for the super classes's interfaces are not instantiated unless it is referenced directly from the application classes. Working on the fix...

Comment by Mahesh Kannan [ 05/Mar/13 07:03 AM ]

I see that DefaultServerEndpointConfiguration is defined as a non-public class:

final class DefaultServerEndpointConfiguration implements ServerEndpointConfiguration { ..... }

So, how can Config extend DefaultServerConfiguration ?

Comment by Mahesh Kannan [ 14/Mar/13 03:29 AM ]

With the latest jar, I am now seeing:

[2013-03-13T19:54:24.884-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=43 _ThreadName=admin-listener(2)] [timeMillis: 1363229664884] [levelValue: 1000] [[
Exception while loading the app : CDI deployment failure:sun.reflect.annotation.TypeNotPresentExceptionProxy
java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:673)
at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:480)
at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:306)
at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:241)
at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:88)
at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:70)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3089)
at java.lang.Class.getAnnotation(Class.java:3048)
at java.lang.Class.isAnnotationPresent(Class.java:3061)
at org.jboss.weld.util.Beans.isVetoed(Beans.java:520)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:105)
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:147)
at org.jboss.weld.bootstrap.BeanDeployment.createClasses(BeanDeployment.java:211)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:419)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:192)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
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$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.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
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)
]]

Comment by Mahesh Kannan [ 25/Mar/13 08:30 PM ]

Committed revision 4445 to fix this issue.
Will close this once hk2 is integrated

svn commit -m "Fix for GlassFish-19551. QL passed and devtests/web passed"
Sending class-model/osgi.bundle
Sending class-model/pom.xml
Sending class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/Parser.java
Sending class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/ParsingContext.java
Sending class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/impl/AnnotatedElementImpl.java
Sending class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/impl/ModelClassVisitor.java
Adding class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/util/ClassModelActivator.java
Adding class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/util/CommonModelRegistry.java
Transmitting file data ........
Committed revision 4445.

Comment by Mahesh Kannan [ 05/Apr/13 01:14 AM ]

This is resolved with hk2-79 integration.

The original svn commit info:

svn commit -m "Fix for GlassFish-19551. QL passed and devtests/web passed"
Sending class-model/osgi.bundle
Sending class-model/pom.xml
Sending class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/Parser.java
Sending class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/ParsingContext.java
Sending class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/impl/AnnotatedElementImpl.java
Sending class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/impl/ModelClassVisitor.java
Adding class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/util/ClassModelActivator.java
Adding class-model/src/main/java/org/glassfish/hk2/classmodel/reflect/util/CommonModelRegistry.java
Transmitting file data ........
Committed revision 4445.





[GLASSFISH-19525] Enabling secure admin fails if admin realm is configured to use LDAP instead of the provided FileRealm Created: 11/Jan/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

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

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

Issue Links:
Related
is related to GLASSFISH-20182 configure-ldap-for-admin command shou... Open
Tags: 4_0-approved
Participants: javashawn, Tim Quinn and Tom Mueller

 Description   

Shawn reported this in the GlassFish forum.

If the admin realm is configured, for instance, to use LDAP instead of the build-in FileRealm, then enabling secure admin fails with an exception similar to this:

javax.enterprise.system.tools.admin.com.sun.enterprise.security.admin.cli|_ThreadID=17; _ThreadName=Thread-2;ClassName=org.glassfish.api.ActionReport;MethodName=failure;|Error enabling secure admin
org.jvnet.hk2.config.TransactionFailure: java.lang.NullPointerException
  at com.sun.enterprise.security.admin.cli.EnableSecureAdminCommand.run(EnableSecureAdminCommand.java:151)
  at com.sun.enterprise.security.admin.cli.SecureAdminCommand.execute(SecureAdminCommand.java:891)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
  at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
  at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
  at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
  at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
  at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:117)
...several other higher classes that may not be meaningful...
  at java.lang.Thread.run(Unknown Source)


 Comments   
Comment by Tim Quinn [ 14/Jan/13 03:44 PM ]

Because enabling secure admin allows remote administration the system is trying to make sure that no admin user has an empty password.

The code for this check is not correctly handling the case in which an admin realm other than the default file realm has been configured.

So far there does not seem to be a good workaround, but we are still looking.

Comment by Tim Quinn [ 14/Jan/13 04:54 PM ]

Fix checked in for 4.0 (trunk).

Project: glassfish
Repository: svn
Revision: 58369
Author: tjquinn
Date: 2013-01-14 16:50:21 UTC
Link:

Log Message:
------------
Fix for 19525

Before allowing a user to enable secure admin the system checks to make sure that there are no admin users in the default file realm with empty passwords, which would be a security risk. That checking code failed if the user configures a non-default admin realm, such as LDAP, throwing a NPE.

This change skips the check if the admin realm is not the file realm.

Tests: QL

Revisions:
----------
58369

Modified Paths:
---------------
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminHelperImpl.java

Comment by Tim Quinn [ 04/Apr/13 12:55 PM ]

The earlier fix for this was not correct, and when using an LDAP realm for admin authentication the enable-secure-admin command still fails incorrectly.

  • What is the impact on the customer of the bug?
    Any customer using an LDAP admin security realm who tries to enable secure admin will encounter this problem.
  • What is the cost/risk of fixing the bug?
    The fix is a one-line (actually a one-word) fix. I have it in my local workspace and it resolves the problem.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
  • Which is the targeted build of 4.0 for this fix?
    b84
  • 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 [ 04/Apr/13 02:09 PM ]

Approved for 4.0.

Comment by javashawn [ 04/Apr/13 03:26 PM ]

I just wanted to point out that we have found a workaround for this issue that applies to v3.1.2.2. We discovered this issue documented here when we tried to setup admin for LDAP by creating a GlassFish domain based on a domain template (customized to change the admin-realm to use the LDAP realm).

We were able to workaround the issue by doing the following:
1. Instead of using the customized domain template we now use the default template (domain.xml) to create our GlassFish domain.
2. We enable-secure-admin (server must be running).
3. We then add a LDAP realm:
create-auth-realm --classname com.sun.enterprise.security.auth.realm.ldap.LDAPRealm --property jaas-context=ldapRealm:group-mapping=[ldap group to control admin access]->asadmin:group-search-filter=[LDAP group search filter]:search-bind-password=[LDAP bind account password - we use a PW alias here]:search-bind-dn=[LDAP search bind dn]:base-dn=[LDAP base dn]:directory=[LDAP server url] ldap-admin-realm
4. Delete the file-based admin-realm:
asadmin delete-auth-realm admin-realm
5. Stop the domain.
6. Rename the ldap-admin-realm that you just created to "admin-realm" in the domain's domain.xml. We're using the Ant "replace" task to do this.
7. Start the domain.

On a side note, when we originally began working with setting up GF admin realm to use LDAP we were trying to understand why the configure-ldap-for-admin subcommand only let you set the basedn and ldap-group attributes? This is what started us down the path of using a domain template that populated the other attributes (such as group-search-filter). It seems like the configure-ldap-for-admin command should allow for setting the same properties available for the LDAPRealm?

Comment by Tim Quinn [ 04/Apr/13 10:04 PM ]

Fix checked in:

Project: glassfish
Repository: svn
Revision: 61180
Author: tjquinn
Date: 2013-04-04 22:02:22 UTC
Link:

Log Message:
------------
GLASSFISH-19525 - Enabling secure admin fails if admin realm is configured to use LDAP instead of the provided FileRealm

An earlier fix for this issue correctly sidestepped the check of the file admin realm for admins with empty passwords when LDAP was configured for admin authentication but a method incorrectly returned "true" in that case when it should have returned "false."

Reviewed by Jeff T
Approved by Tom M
Passed QL tests, manual test with LDAP admin configured and enabling (and disabling) secure admin

Revisions:
----------
61180

Modified Paths:
---------------
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminHelperImpl.java

Comment by Tim Quinn [ 04/Apr/13 10:25 PM ]

javashawn,

I've created GLASSFISH-20182 to capture your improvement request. Thanks, and thanks for sharing the workaround.





[GLASSFISH-19428] com.sun.appserv.iiop.endpoints does not support IPV6 Created: 11/Dec/12  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

Type: Bug Priority: Major
Reporter: lzg5039 Assignee: Harshad Vilekar
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


File Attachments: Text File RoundRobinPolicy.patch    
Tags: 4_0-approved
Participants: Harshad Vilekar, lzg5039, shreedhar_ganapathy and Tom Mueller

 Description   

because the IPV6 address contains ":",so when the value of "com.sun.appserv.iiop.endpoints" contains IPV6 address,the following code which is marked ★ can not get the correct ip and port

Directory: orb\orb-iiop\src\main\java\
Package: org.glassfish.enterprise.iiop.impl
Class:RoundRobinPolicy

private ClusterInstanceInfo makeClusterInstanceInfo(String str, 
    int weight) {

    String[] host_port = str.split(":");  ★
    String server_identifier = ""; //for bootstrapping, can be ""
    String type = CLEAR_TEXT; //will be clear_text for bootstrapping
    SocketInfo socketInfo = new SocketInfo(
        type, host_port[0], Integer.parseInt( host_port[1]) );
    List<SocketInfo> sil = new ArrayList<SocketInfo>(1) ;
    sil.add( socketInfo ) ;

    return new ClusterInstanceInfo(server_identifier, weight, sil);
}


 Comments   
Comment by shreedhar_ganapathy [ 13/Dec/12 06:35 PM ]

Reassigning to Orb component

Comment by Harshad Vilekar [ 20/Feb/13 02:14 AM ]

Colon ( characters in IPv6 address conflicts with the established syntax - where the colon is used to terminate the host path before a port number. This works with literal ipv4 address. Update host:port string parsing to support literal IPv6 address.

Comment by lzg5039 [ 22/Feb/13 10:01 AM ]

Harshad Vilekar:
Thanks for you to help me to fix this bug. Can I create a fix for the bug, and someone help me to review it in the future?

Comment by Harshad Vilekar [ 25/Feb/13 05:39 AM ]

linzhengguo: Yes, please test your fix with:

1. literal ipv6 format address,
2. literal ipv4 address, and
3. regular hostname.

Then attach the file diff for review.

Comment by lzg5039 [ 26/Feb/13 09:02 AM ]

Harshad Vilekar:
I hava done the following tests, and set address by "com.sun.appserv.iiop.endpoints"
>1. literal ipv6 format address,
Test OK
>2. literal ipv4 address, and
Test OK
>3. regular hostname.
Test OK
>4. ipv6 mix with ipv4
Test OK

Comment by lzg5039 [ 26/Feb/13 09:04 AM ]

Harshad Vilekar:
My fix as follows,you also can the attach file

 
Directory: orb\orb-iiop\src\main\java\
Package: org.glassfish.enterprise.iiop.impl
Class:RoundRobinPolicy

private ClusterInstanceInfo makeClusterInstanceInfo(String str, 
    int weight) {
-   String[] host_port = str.split(":");//delete this code

    //support IPV6 begin add the following code
+   String[] host_port = new String[2];
+   int i = str.lastIndexOf(':');
+   host_port[0] = str.substring(0,i);
+   host_port[1] = str.substring(i+1);
    //support IPV6 end

    String server_identifier = ""; //for bootstrapping, can be ""
    String type = CLEAR_TEXT; //will be clear_text for bootstrapping
    SocketInfo socketInfo = new SocketInfo(
        type, host_port[0], Integer.parseInt( host_port[1]) );
    List<SocketInfo> sil = new ArrayList<SocketInfo>(1) ;
    sil.add( socketInfo ) ;

    return new ClusterInstanceInfo(server_identifier, weight, sil);
}
Comment by Harshad Vilekar [ 05/Apr/13 07:03 AM ]
  • What is the impact on the customer of the bug? Support literal ipv6 address in IIOP endpoint list.
  • How likely is it that a customer will see the bug and how serious is the bug? Only when using ipv6 addresses, rather than host names.
  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)? Not a regression.
  • What CTS failures are caused by this bug? No CTS failures.
  • What is the cost/risk of fixing the bug? Fix is ready, under regression test.
  • How risky is the fix? How much work is the fix? Is the fix complicated? Fix is isolated. Not very complex.
  • Is there an impact on documentation or message strings? No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish? Cluster Tests with Remote EJB Apps.
  • Which is the targeted build of 4.0 for this fix? b84
  • Is this an integration of a new version of a component from another project ? No
Comment by Tom Mueller [ 05/Apr/13 02:07 PM ]

Approved for 4.0. Please update the fix version field to the correct build.

Comment by Harshad Vilekar [ 09/Apr/13 12:29 AM ]

Reviewed and Committed the fix suggested by lzg5039. svn revision #61237.





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

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

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

Windows 7 64bit, JDK 1.6.0_29 32bit


File Attachments: Zip Archive jee-resources.zip    
Tags:
Participants: arjavdesai, jjsnyder83 and titmus

 Description   

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

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

I attached a test case which demonstrates this bahaviour.



 Comments   
Comment by jjsnyder83 [ 08/Apr/13 09:02 PM ]

Committed revision 61234.





[GLASSFISH-18825] asadmin deploy must not use the provided file name but the actual file name to guess an application name Created: 22/Jun/12  Updated: 16/Apr/13  Resolved: 16/Apr/13

Status: Closed
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1.1_b12
Fix Version/s: 4.0_b84_RC1

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF3.1.1 Win7 Pro SP1 64Bit JDK1.6.0_26


Tags:
Participants: Hong Zhang, Jeremy_Lv and mkarg

 Description   

asadmin deploy guesses the application name by simply taking the provided file name (excluding extension). This might work nice on Linux, but is a problem on Windows as that operating system is not case sensitive. This is leading to problems:

Sample Scenario:

Physical name of EAR to deploy is "Sample.ear".

Administrator type "asadmin deploy sample.ear" which IS WORKING, but will guess the application name to be lower case.

When trying to undeploy, another administrator (not knowing of the typo) want to undeploy. He finds the local file "Sample.ear" so he thinks he must type UPPER case "asadmin undeploy Sample", which is NOT WORKING as GF is case sensitive.

A solution for this is simple: GF must not guess the application name by using the PROVIDED file name, but instead it must check the File system for the ACTUAL file name instead. So the guessed deploy name will be in the exact same spelling.



 Comments   
Comment by Jeremy_Lv [ 10/Oct/12 02:07 AM ]

mkarg:

Administrator type "asadmin deploy sample.ear" which IS WORKING, but will guess the application name to be lower case.

The phenomenon in the latest version of GFV4.0: if physical name of EAR to deploy is "Sample.ear", when you type "asadmin deploy sample.ear", the application will be deployed successfully and named as Sample because the application name is Sample.ear. It will not guess the application name to be lower case.

When trying to undeploy, another administrator (not knowing of the typo) want to undeploy. He finds the local file "Sample.ear" so he thinks he must type UPPER case "asadmin undeploy Sample", which is NOT WORKING as GF is case sensitive.

Nowadays, the application can be undeployed as "asadmin undeploy Sample" successfully. However, while another administrator want to undeploy an application . I think he will type as "asadmin list-applications" to list the applications and undeploy the application can be list in the command.

Thanks.

Comment by Jeremy_Lv [ 15/Apr/13 08:10 AM ]

Nowadays, the feature of deploment is worked as desigend just as mkarg documented.

Comment by Hong Zhang [ 16/Apr/13 02:22 AM ]

Thanks Jeremy. Please mark the issue as fixed if things are working as expected now.

Comment by Jeremy_Lv [ 16/Apr/13 02:27 AM ]

Worked as expected.





[GLASSFISH-18805] Redeploying should not alter application startup order Created: 14/Jun/12  Updated: 10/Apr/13  Resolved: 10/Apr/13

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

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

Tags:
Participants: Hong Zhang, Jeremy_Lv and Paul Benedict

 Description   

Application load order is defined in domain.xml by the ordering of <application> tags. When I redeploy an app, the app's <application> tag moves to the bottom of the list.

I think this behavior should be changed.

Current behavior is very annoying since I must maintain a strict ordering of EJB applications. For example, C depends on B depends on A, with regard to EJB resources. Therefore, after I deploy, I must go in and manually edit domain.xml to keep my server working.



 Comments   
Comment by Jeremy_Lv [ 24/Oct/12 05:42 AM ]

Hong:
The logic about setting the properties to the domain.xml are as follows:
1).it will cleanup the properties about the redeployed applications by executing DeployCommand#execute

Properties undeployProps = handleRedeploy(name, report);

2).Then it will do the same operation as deploy does. After load the deployment application it will setting the properties to the domain.xml by executing DeployCommand#execute

deployment.registerAppInDomainXML(appInfo, deploymentContext, t);

All in all,I think it is hard to locate the app's <application> tag to the original position before redeploy. The reason is that there's no symbol to perserv when deleting the app's <application> tag from domain.xml.
BTW, If it is necessary to enhance this scenario, I will look into it and try to attach my patch as soon as possible.

Comment by Hong Zhang [ 24/Oct/12 01:39 PM ]

Right, when an application is redeployed, it's appended to the last in the list of the applications in domain.xml (that list determines the loading order of the application during server start up). In GlassFish 4.0, one of the features we will add is the deployment order feature which has been requested a couple times in the past. With that, user could specify a deployment order when the application is deployed, and the applications will be loaded based on the order. So user could use that feature to resolve this problem s/he has. We will mark this issue as fixed when that feature is available.

Comment by Jeremy_Lv [ 10/Apr/13 01:17 PM ]

Hong:

It seems the new features about deployment order has been developed by GeraldIngalls.

IMHO, I think the application can be deployed as asadmin deploy --deploymentorder 1 test_sample1.war.

However, when I was trying the deployment command with option as --deploymentorder, NPE will occurred as follows:

[2013-04-10T21:12:35.938+0800] [glassfish 4.0] [SEVERE] [NCLS-ADMIN-00011] [javax.enterprise.system.tools.admin.security.authorization] [tid: _ThreadID=38 _ThreadName=admin-listener(5)] [timeMillis: 1365599555938] [levelValue: 1000] [[
  An unexpected exception occurred.
java.lang.RuntimeException: java.lang.NullPointerException
	at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:314)
	at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:184)
	at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:180)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:356)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.authorize(CommandSecurityChecker.java:180)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1203)
	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 org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
	at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
	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$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.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
	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 com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:581)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:573)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.createEntryEnumeration(InputJarArchive.java:451)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.entries(InputJarArchive.java:203)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.access$100(InputJarArchive.java:74)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$1.enumeration(InputJarArchive.java:166)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$CollectionWrappedEnumeration.<init>(InputJarArchive.java:724)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.getDirectories(InputJarArchive.java:161)
	at org.glassfish.javaee.full.deployment.EarDetector.isEARFromIntrospecting(EarDetector.java:142)
	at org.glassfish.javaee.full.deployment.EarDetector.handles(EarDetector.java:110)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.getArchiveHandler(ApplicationLifecycle.java:211)
	at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:246)
	... 52 more
]]
Comment by Jeremy_Lv [ 10/Apr/13 01:19 PM ]

I think the NPE shouldn't come out even I type the wrong command..

Comment by Hong Zhang [ 10/Apr/13 01:32 PM ]

Jeremy: I could not reproduce this, what exact command did you use when you saw the NPE? From the stack trace, it seems unrelated to the deploymentorder option, but something with the archive itself. You can try to just use deploy command with no options to deploy the archive, see if you still get the error. We still need to make the deployment code more robust (no NPE, but a good error message) if the archive is not constructed properly, but that's another issue.

Comment by Jeremy_Lv [ 10/Apr/13 03:04 PM ]

Hong:

Sorry, it is my fault to use the invalid test case, the error cames out because of the OS can't extract the invalid war file.

Yeah, I can find some configuration about deploymentorder written in the domain.xml. But I still confused about the situation the deploymentorder can be of the same value between different applications.

Thanks

Jeremy

Comment by Hong Zhang [ 10/Apr/13 03:24 PM ]

No problem. For the applications which are deployed with the same deployment order (either explicitly or they just both use default), whichever is deployed first will be loaded first during server start up.

Please see the man page for more detailed explanation (do asadmin deploy --help).

And I am marking this issue as fixed as the deployment order feature is in GlassFish 4.0 now.

Comment by Jeremy_Lv [ 10/Apr/13 03:34 PM ]

I see. I got to know some detailed information about it through the deployment one pager.
https://wikis.oracle.com/display/GlassFish/GlassFish+4.0+Deployment+One+Pager#GlassFish4.0DeploymentOnePager-DeploymentOrder

Thanks





cannot set addresslist-iterations to -1 (GLASSFISH-4773)

[GLASSFISH-18795] Valid value range for jms service Address List Iterations attribute Created: 11/Jun/12  Updated: 01/Apr/13  Resolved: 01/Apr/13

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b40
Fix Version/s: 4.0_b84_RC1

Type: Sub-task Priority: Major
Reporter: Simon Meng Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Mike Fitch and Simon Meng

 Description   

The glassfish document does not mention the valid value range for jms service Address List Iterations attribute. The exact value range is [-1, 2147483647]

You can see the Address List Iterations attribute in following location.
http://localhost:4848 --> Common Tasks --> Configurations --> server-config --> Java Message Service



 Comments   
Comment by Mike Fitch [ 14/Mar/13 11:25 PM ]

Changed Fix Version to 4.0 so issue will show up on 4.0* queries. Actual commitment and build # TBD.

Comment by Mike Fitch [ 24/Mar/13 07:43 PM ]

Added information to the write-up of Address List Iterations on the help page for this screen:

"The number of times the JMS service iterates through the AddressList in an effort to establish (or reestablish) a connection. A value of -1 indicates that the number of attempts is unlimited. The default value is 3. The maximum value is 2147483647."

This addition will become accessible in GlassFish when the next main-docs build is promoted and picked up by GlassFish builds.

Comment by Mike Fitch [ 01/Apr/13 03:42 PM ]

Included in main-docs build 4.0-b26, which started getting picked up by GlassFish builds as of revision 61028.





[GLASSFISH-18572] comment feature missing from multimode documentation Created: 29/Mar/12  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b84_RC1

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

Tags:
Participants: Mike Fitch and Tom Mueller

 Description   

The multimode command permits a '#' to be used as a comment character in the input file.
This is not documented on the multimode manual page.



 Comments   
Comment by Mike Fitch [ 14/Mar/13 11:08 PM ]

Changed Fix Version to 4.0 so issue will show up on 4.0* queries. Actual commitment and build # TBD.

Comment by Mike Fitch [ 01/Apr/13 03:36 PM ]

Added the following to the description of multimode:

"When you use a file, you can include comment lines in the file by entering the hash symbol (#) as the first character of the line."

This addition will become available in GlassFish builds when the next version of main-docs is picked up by GlassFish.

Comment by Mike Fitch [ 04/Apr/13 09:50 PM ]

This addition was included in main-docs build 4.0-b27, which started getting picked up by GlassFish builds as of revision 61152 (03-Apr-2013).





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

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

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

all


Tags:
Participants: gcruscoe, jjsnyder83, Sivakumar Thyagarajan, TangYong and tlcksnyder

 Description   

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

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

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

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

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

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



 Comments   
Comment by Sivakumar Thyagarajan [ 10/Dec/12 05:25 AM ]

Transferring to JJ Snyder

Comment by tlcksnyder [ 28/Mar/13 08:58 PM ]

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

Comment by TangYong [ 07/Apr/13 05:57 AM ]

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

-Tang

Comment by jjsnyder83 [ 07/Apr/13 07:40 PM ]

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





[GLASSFISH-18404] RoundRobinPolicy.getAddressPortList does not support IPV6 Created: 24/Feb/12  Updated: 09/Apr/13  Resolved: 09/Apr/13

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

Type: Bug Priority: Major
Reporter: lzg5039 Assignee: Harshad Vilekar
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Tags: 4_0-approved
Participants: Cheng Fang, Harshad Vilekar, lzg5039 and Tom Mueller

 Description   

all of the V2,V3 and V4 have the method of RoundRobinPolicy.getAddressPortList,in the enviroment of V3 and V4 have the following code

 for (InetAddress addr : addresses) {
    if (addr instanceof Inet4Address) {
         addrs.add( addr ) ;
    }
}

but there is not above code in the enviroment of V2.

Beacause of add these codes ,the V3 and V4 do not support IPV6.So I do not know why need to add these codes.
If I add following code,the V3 and V4 will support IPV6?

 for (InetAddress addr : addresses) {
    if (addr instanceof Inet6Address) {
         addrs.add( addr ) ;
    }
}


 Comments   
Comment by Cheng Fang [ 24/Feb/12 03:56 AM ]

Posting the complete method here. Note the comment about not supporting IPv6. Not sure why.

    public List<String> getAddressPortList(String host, String port) {
        // Get the ip addresses corresponding to the host.
        // XXX this currently does NOT support IPv6.
        try {
            InetAddress [] addresses = InetAddress.getAllByName(host);
            List<InetAddress> addrs = new ArrayList<InetAddress>() ;
            for (InetAddress addr : addresses) {
                if (addr instanceof Inet4Address) {
                    addrs.add( addr ) ;
                }
            }

            List<String> ret = new ArrayList<String>() ;
            for (InetAddress addr : addrs) {
                ret.add( addr.getHostAddress() + ":" + port ) ;
            }

            // We return a list of <IP ADDRESS>:<PORT> values
            return ret;
        } catch (UnknownHostException ukhe) {
            warnLog( "unknown.host", host, ukhe.getMessage() );
            return new ArrayList<String>() ;
        }
    }

The change is part of the following commit:
r41437 | kcavanaugh | 2010-10-06 17:17:04 -0400 (Wed, 06 Oct 2010) | 6 lines
Changed paths:
M /trunk/v3/common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/GroupInfoServiceObserverImpl.java
M /trunk/v3/common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/RoundRobinPolicy.java
M /trunk/v3/common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialContext.java
M /trunk/v3/common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialContextProviderImpl.java
M /trunk/v3/common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialInitContextFactory.java
M /trunk/v3/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/GlassFishORBManager.java
M /trunk/v3/orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/IiopFolbGmsClient.java
M /trunk/v3/pom.xml
M /trunk/v3/security/ejb.security/src/main/java/com/sun/enterprise/iiop/security/SecIORInterceptor.java

Re(re)-integration of IIOP FOLB.

  • Fixed a problem in IiopFolbGmsClient that cause the QL failure
  • Also integrating the (corrected) ORB b007.

QL tests all passed this time (I missed one failure last time).

Comment by Cheng Fang [ 24/Feb/12 04:01 AM ]

Harshad, can you take a look from orb side?

Comment by lzg5039 [ 07/Mar/13 11:44 AM ]

Because there is bug of GLASSFISH-19428 in the glassfish v3/v4,so glassfish v3/v4 does not support IPV6.
If the GLASSFISH-19428 is fixed,v3/v4 will support IPV6. But the method of RoundRobinPolicy.getAddressPortList still only add IPV4 address to list,so I modify the RoundRobinPolicy.getAddressPortList as following(I modify the code which is marked ★)

 
    public List<String> getAddressPortList(String host, String port) {
        // Get the ip addresses corresponding to the host.
        // XXX this currently does NOT support IPv6.
        try {
            InetAddress [] addresses = InetAddress.getAllByName(host);
            List<InetAddress> addrs = new ArrayList<InetAddress>() ;
            for (InetAddress addr : addresses) {
                // add "|| addr instanceof Inet6Address", it will add IPV6 address to addrs
                if (addr instanceof Inet4Address || addr instanceof Inet6Address) { ★
                    addrs.add( addr ) ;
                }
            }

            List<String> ret = new ArrayList<String>() ;
            for (InetAddress addr : addrs) {
                ret.add( addr.getHostAddress() + ":" + port ) ;
            }

            // We return a list of <IP ADDRESS>:<PORT> values
            return ret;
        } catch (UnknownHostException ukhe) {
            warnLog( "unknown.host", host, ukhe.getMessage() );
            return new ArrayList<String>() ;
        }

}

Comment by Harshad Vilekar [ 05/Apr/13 06:57 AM ]
  • What is the impact on the customer of the bug? Support literal ipv6 address in IIOP endpoint list.

How likely is it that a customer will see the bug and how serious is the bug? Only when using ipv6 address, rather than host name.

  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)? Not a regression.
  • What CTS failures are caused by this bug? No CTS failures.
  • What is the cost/risk of fixing the bug? Fix is ready, under regression test.

How risky is the fix? How much work is the fix? Is the fix complicated? Fix is isolated. Not very complex.

  • Is there an impact on documentation or message strings? No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish? Cluster Tests with Remote EJB Apps.
  • Which is the targeted build of 4.0 for this fix? b84
  • Is this an integration of a new version of a component from another project ? No
Comment by Tom Mueller [ 05/Apr/13 02:06 PM ]

Approved for 4.0.

Comment by Harshad Vilekar [ 09/Apr/13 12:28 AM ]

Reviewed and Committed the fix suggested by lzg5039. svn revision #61237.





[GLASSFISH-18356] HttpServletRequest.login does not work correctly with single sign on (SSO) JSESSIONIDSSO cookie is not sent. Created: 13/Feb/12  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.1, 3.1.2_b21
Fix Version/s: 4.0_b84_RC1

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

Linux, Java 1.7.0_02, Glassfish 3.1.1 Release and 3.1.2-b22


File Attachments: Zip Archive single-sign-on.zip    
Tags: 3_1_2-exclude 3_1_2-next 4_0-approved
Participants: adriaaaaan, javabeats, Joe Di Pol, kumara, manuel_b, Shing Wai Chan and skrall

 Description   

Configure Glassfish for SSO, and add a user to the file realm from the Admin Console:

Configurations->server-config->HTTP Service: SSO: Enabled
Configurations->server-config->Security: Default Principal To Role Mapping: Enabled
Configurations->server-config->Realms->file: Add a user with username: "username" password: "password" and role of "customrole"

Deploy the attached war file. (It's inside the zip file, which contains the war and src).

If you login using the FORM login method, (The third link) you will be logged into the web application, and receive a JSESSIONSSO cookie. So going to another web application in the same realm will not prompt for credentials.

Logout / close browser, try to login using the HttpServletLogin method (The second link), something like http://localhost:8080/single-sign-on/login?u=username&p=password you will be logged in, but the JSESSIONIDSSO cookie is not sent. So going to another web application in the same realm will prompt for credentials.

The JSESSIONIDSSO cookie should be sent, and navigating to another web application in the same realm should not prompt for credentials.



 Comments   
Comment by kumara [ 13/Feb/12 08:40 PM ]

-> web_container

Comment by Shing Wai Chan [ 13/Feb/12 11:32 PM ]

The org.apache.catalina.connector#login and #authenticate methods are quite different from Tomcat code.
In Tomcat, the logic is delegated back to Authenticator.

Security team may like to compare this with Tomcat 7 code base.

Please go through the bug fix guidelines in https://wikis.oracle.com/display/GlassFish/GuidelinesOnBugFixesFor312

Comment by Joe Di Pol [ 17/Feb/12 07:52 PM ]

Too late to address in 3.1.2. Tagging for consideration in next release.

Comment by adriaaaaan [ 20/Apr/12 09:10 AM ]

I'm guessing theres not going to be a 3.1.3? Is there any chance of a workaround as we've counting on using sso for some time but have been constantly prevented from doing so by endless bugs

Comment by javabeats [ 20/Apr/12 01:03 PM ]

Agreed. A patch or update would be welcome, rather than having us all upgrade production systems in a hurry to 3.2 to finally have SSO directly from Glassfish.

Comment by adriaaaaan [ 14/Sep/12 02:39 PM ]

Any movement on this issue? It was tagged for next release but that has come and gone. Is there any known workaround (for example creating the cookie manually?). where does the ssoid come from? Thanks

Comment by manuel_b [ 27/Dec/12 11:24 AM ]

Hi everybody,
I have the same issue. So our problem is the following: We have a sign up form on an html page. This sign up form is send to a rest servlet in a webapp. The servlets registers the user and logs the user in. After logging in the user is redirected to another web app. Now he has to reenter his just created credentials again.

Unfortunately no JSESSIONIDSSO cookie is set by the Rest servlet.

Comment by adriaaaaan [ 20/Mar/13 10:38 AM ]

bump? Surely this has to be considered for gf4? Theres no point in having sso if you can't use it. We login via rest and can't use sso unless this is resolved. Is there not any kind of workaround or way to set the cookie manually?

Comment by Shing Wai Chan [ 03/Apr/13 06:33 PM ]
  • What is the impact on the customer of the bug?
    SSO not working for programmatic login.
  • What is the cost/risk of fixing the bug?
    The SSO should be unregistered when it is logout.
    Also, the J2EEInstanceListener should not call the 196 logout as in 3.x.
  • 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 pe/security tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_b84 (assuming b83 is already done)
  • 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 12:09 AM ]

While fixing another issue, part of the fix is done in svn 60610.
The following code resolved the issue for logout.
This completes the fix for the issue.

Sending appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/Authenticator.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/Realm.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/authenticator/AuthenticatorBase.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/connector/Request.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/realm/RealmBase.java
Sending appserver/web/web-glue/src/main/java/com/sun/web/server/J2EEInstanceListener.java
Sending nucleus/common/common-util/src/main/java/com/sun/enterprise/security/integration/RealmInitializer.java
Transmitting file data ........
Committed revision 61154.





[GLASSFISH-18111] create-ssl fails for protocol admin-listener in default-config or any of copied default-config Created: 02/Jan/12  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2_b16
Fix Version/s: 4.0_b84_RC1

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

Issue Links:
Dependency
blocks GLASSFISH-17462 Lack of ssl.json and file-cache optio... Closed
Tags: 3_1_2-exclude 3_1_2_review console 4_0-approved
Participants: Anissa Lam, Ryan Lubke, srinik76 and Tom Mueller

 Description   

Running asadmin command

./asadmin create-ssl --type network-listener --target default-config --certname c1 admin-listener

fails with following error

remote failure: Network Listener named admin-listener to which this ssl element is being added already has an ssl element.
Command create-ssl failed.

Tried to debug createSsl.java found that even though admin-listener protocol does not have any listeners assigned to it, it takes admin-listener listener as the assigned listener for this protocol and it fails. This logic needs to be redesigned.



 Comments   
Comment by srinik76 [ 02/Jan/12 02:00 PM ]

Because of this issue GUI page fails in the protocols->admin-listner->SSL tab with 404 error

Comment by Ryan Lubke [ 05/Jan/12 05:40 AM ]

I believe the error from the asadmin command in the description is in fact correct.

The network listener in default-config, references the following protocol:

<protocol name="pu-protocol">
    <port-unification>
        <protocol-finder protocol="sec-admin-listener" name="http-finder" classname="com.sun.grizzly.config.HttpProtocolFinder"></protocol-finder>
        <protocol-finder protocol="admin-http-redirect" name="admin-http-redirect" classname="com.sun.grizzly.config.HttpProtocolFinder"></protocol-finder>
    </port-unification>
</protocol>

These reference:

<protocol security-enabled="true" name="sec-admin-listener">
    <http default-virtual-server="__asadmin" encoded-slash-enabled="true">
         <file-cache></file-cache>
    </http>
    <ssl client-auth="want" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="glassfish-instance"></ssl>
</protocol>

Perhaps when reviewing the domain.xml, you were looking at the server-config instead of default-config?

If I change the command such that the target is server-config, it works as expected.

Comment by Anissa Lam [ 05/Jan/12 06:03 AM ]

Hi Ryan,
The issue is that under "default-config" , the protocol named "admin-listener" does not have <ssl> element.

<protocol name="admin-listener">
<http default-virtual-server="__asadmin" max-connections="250">
<file-cache enabled="false" />
</http>
</protocol>

User wants to create <ssl> under this protocol. It should be allowed, right ? So, user issue this command but see the error.

%asadmin create-ssl --type network-listener --target default-config --certname c1 admin-listener
remote failure: Network Listener named admin-listener to which this ssl element is being added already has an ssl element.
Command create-ssl failed.

Why does it say it already has an ssl element ? it certainly doesn't.
It should be able to create <ssl> under this protocol.

Comment by Ryan Lubke [ 05/Jan/12 06:27 AM ]

The command doesn't modify the protocol with the name 'admin-listener'. It updates the protocol associated with the network-listener.
As stated previously, the protocol associated with network-listener 'admin-listener' does have an ssl element associated with it.

Comment by Anissa Lam [ 05/Jan/12 06:51 AM ]

I know whats the confusion now.

Usage: asadmin [asadmin-utility-options] create-ssl --certname <certname>
-type <type> [-ssl2enabled[=<ssl2enabled(default:false)>]]
[--ssl2ciphers <ssl2ciphers>]
[--ssl3enabled[=<ssl3enabled(default:true)>]]
[--ssl3tlsciphers <ssl3tlsciphers>]
[--tlsenabled[=<tlsenabled(default:true)>]]
[--tlsrollbackenabled[=<tlsrollbackenabled(default:true)>]]
[--clientauthenabled[=<clientauthenabled(default:false)>]]
[--target <target(default:server)>] [?|-help[=<help(default:false)>]]
[listener_id]

[listener_id] can be the network-listener name, OR protocol-name.
It will assume it is the protocol-name IF there is no network-listener with that name exists.

Can you tell me then, how to create the <ssl> element under the protocol "admin-listener" for "default-config" ?
thanks.

Comment by Ryan Lubke [ 05/Jan/12 04:45 PM ]

Without linking that protocol to a listener, there doesn't appear to be a way to do so at this point in time. However, I need to ask: why do you need to update a protocol that isn't being used?

Comment by Ryan Lubke [ 06/Jan/12 04:55 AM ]

Anyone?

Comment by srinik76 [ 06/Jan/12 05:15 AM ]

In GUI, when user selects a protocol edit and then selects SSL tab, if there is no SSL for that protocol gui tries to create a SSL for the protocol and this case admin-listener protocol under default-config does not have a listener associated with that so it throws 404 error in GUI page.

Comment by Ryan Lubke [ 06/Jan/12 05:17 AM ]

But why show an unused protocol at all?

Comment by Ryan Lubke [ 06/Jan/12 05:18 AM ]

At any rate, given the limitations outlined previously, it may be best to rename the admin-listener protocol to admin-listener-protocol so that that it doesn't have the same name as the listener.

Comment by Anissa Lam [ 06/Jan/12 05:24 AM ]

Sorry, I missed your question yesterday.
Ryan, Perfect, I vote for that.
This means the domain.xml template needs to be changed. Are you going to take care of that ?
thanks.

Comment by Ryan Lubke [ 06/Jan/12 05:27 AM ]

I'll look into it. I suspect it won't just be the template. I'll check to see if the protocol name is hard-coded anywhere in our code base.

Comment by Anissa Lam [ 06/Jan/12 06:13 AM ]

When we work on the UI to hide some of the protocols, Tim told us to look at SecureAdminCommands.java under 3.1.2/security/.
It has defined the related protocol and network listener name there, not hard coding them.

Comment by Ryan Lubke [ 06/Jan/12 03:03 PM ]

So, I was looking through the code and there is at least one place where the named protocol "admin-listener" is hard-coded.

Thinking about this more, it's probably not a good idea to rename this as I don't know who else (customers as an example) that may rely on this value.

So, I spent time thinking about overloading create-ssl further to, if a matching listener has a protocol with SSL already, look for a protocol with a similar name. But what about delete-ssl? Looking over that code, there is no parity, feature-wise, with create-ssl, i.e., if you call deleete-sll and there is no matching listener, it will not look for a matching protocol.

It seems the proper thing to do is to add a new type to {create,delete}-ssl with protocol, though this does overlap, conceptually with the existing network-listener and http-listener types. I'm not sure we can do this in time for 3.1.2 as I believe such a change would require approval from arch.

Does this absolutely need to be resolved for 3.1.2 or can we wait?

Comment by Anissa Lam [ 08/Jan/12 08:52 PM ]

Yes, after more thought, i also think its too risky to change the protocol name now.
After thinking through more, there may be one simple way to avoid the issue of needing to create the <ssl> element by console.
How about adding an empty <ssl> in the "admin-listener" protocol ?
<protocol name="admin-listener">
<http max-connections="250" default-virtual-server="__asadmin" encoded-slash-enabled="true">
<file-cache></file-cache>
</http>
<ssl/>
</protocol>

Since there isn't any listener referencing this 'admin-listener' protocol, I hope there won't be any ill side-effect with this. Can you give this some thought ?

Comment by Ryan Lubke [ 09/Jan/12 11:03 PM ]

I did some testing with this and didn't find any side-effects so far. Even if referenced, since the protocol isn't secure, the element is ignored.

Have you tried this to make sure this doesn't cause any issues on the gui side?

Comment by Anissa Lam [ 09/Jan/12 11:41 PM ]

Yes, I have tested that gui behaves well with this empty <ssl> element.
When user goes to this SSL tab, it will show whatever the default value is set in the SSL config bean.
There is no issue on GUI's side.

Comment by Ryan Lubke [ 10/Jan/12 08:35 PM ]

Anissa,

Would you mind starting the fix request process for this issue? I think you can best describe the needs of the GUI (i.e., why you need the ssl element here, etc).

My analysis of the command is available here for review.

Comment by Anissa Lam [ 10/Jan/12 11:46 PM ]

Discussed with Joe, we have passed HCF, we will exclude this from 3.1.2.
Since this admin-listener protocol is not used by any network-listener, the error msg, although doesn't look good, we will just leave it there.
If user change the configuration and there is really a network-listener depending on it, then the error will go away.

However, I think we should add the <ssl> element to the protocol in the trunk.

Comment by Ryan Lubke [ 11/Jan/12 01:13 AM ]

I think on the Trunk we should expand the command to allow updating of a protocol directly. Will look into what's needed to get approval for that.

Comment by Anissa Lam [ 27/Mar/13 04:56 PM ]

I cannot reproduce this problem with the latest workspace.
I can create SSL for any listener in the console.
Not sure what gets fixed. I am marking this as 'cannot reproduce'.

Comment by Anissa Lam [ 29/Mar/13 07:38 AM ]

Sorry I was testing the wrong node this morning.
The bug described here still exists.
If you click on default-config -> Network Config -> Protocols -> "admin-listener" node, then go to SSL, the error comes out.

Are we going to fix this with the latest proposal, ie, add an empty <ssl> under protocol of default-config ?

This is reported as bugDB # 16572529 also.

Comment by Ryan Lubke [ 04/Apr/13 09:35 PM ]
  • What is the impact on the customer of the bug?

Unable to update protocols with SSL that aren't linked to a listener.

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

Unknown. Reported by admin team.

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

No

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

Fairly low. Update existing create/delete ssl commands to accept the token "protocol" as a valid type.
Add a new SslConfigHandler implementation for protocol targets.

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

Low impact. See https://gist.github.com/rlubke/5314519 for the diffs.

  • Is there an impact on documentation or message strings?

Yes - see the diff.

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

Admin team should be able to verify resolution. They should also be able to provide a test scenario.

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

b84.

  • 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.

No.

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

Approved for 4.0 (although it is odd considering this wasn't allowed after HCF in 3.1.2).
Please update the fixed version to the correct build rather than 4.0.1.

Comment by Ryan Lubke [ 04/Apr/13 10:24 PM ]

Just for the record, to update an existing protocol, use:

./asadmin create-ssl --type protocol --target default-config --certname c1 admin-listener

Comment by Ryan Lubke [ 04/Apr/13 10:51 PM ]

Sending nucleus/admin/util/src/main/java/com/sun/enterprise/admin/commands/CreateSsl.java
Sending nucleus/admin/util/src/main/java/com/sun/enterprise/admin/commands/DeleteSsl.java
Sending nucleus/admin/util/src/main/java/com/sun/enterprise/admin/commands/LocalStrings.properties
Adding nucleus/admin/util/src/main/java/com/sun/enterprise/admin/commands/ProtocolSslConfigHandler.java
Transmitting file data ....
Committed revision 61181.

Comment by Anissa Lam [ 09/Apr/13 10:42 PM ]

With the fix that Ryan committed above, and the fix from Jason for GLASSFISH-20215, console will need to make the change to specify the '--type protocol' to create the SSL based on protocol name.

  • What is the impact on the customer of the bug?
    user cannot go to the protocol page to create/edit SSL element.
  • How likely is it that a customer will see the bug and how serious is the bug? It is likely that they see the bug.
    User will see this if they go to protocol page instead of the Network Listener that reference this protocol to edit the SSL.
  • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    Not a regression. This bug was not fixed in previous release.
  • What CTS failures are caused by this bug?
    CTS doesn't include console
  • How risky is the fix? How much work is the fix? Is the fix complicated?
    very low risk, add the --type protocol to the payload if it is from the protocol page.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Go to default-config-> Network Config > protocol> admin-listener-1 -> SSL tab and see that the SSL can be created.
  • Which is the targeted build of 4.0 for this fix?
    84
Comment by Tom Mueller [ 10/Apr/13 02:07 AM ]

Approved for 4.0

Comment by Anissa Lam [ 10/Apr/13 05:46 AM ]

Date: 2013-04-10 05:45:22 UTC
Link:

Log Message:
------------
GLASSFISH-18111; add the type for protocol when creating ssl from protocol screen.

Revisions:
----------
61283

Modified Paths:
---------------
trunk/main/appserver/admingui/common/src/main/resources/shared/sslPrepare.inc
trunk/main/appserver/admingui/common/src/main/resources/shared/sslButtons.inc
trunk/main/appserver/admingui/web/src/main/resources/grizzly/ssl.layout

Comment by Anissa Lam [ 10/Apr/13 09:32 PM ]

Additional change made to not create the <ssl> element without user's action.

Date: 2013-04-10 21:31:05 UTC
Link:

Log Message:
------------
GLASSFISH-18111; in addition to adding the --type protocol for creating SSL under protocol, the code now don't automatically create the <ssl> when user just browse to the screen. It will be created only when user press OK button if it doesn't exist yet.
The cert name field is changed to a required field to match the CLI .

change request approved, and tested all SSL screens under admin-service, IIOP, Network Listener and Protocol.

Revisions:
----------
61356

Modified Paths:
---------------
trunk/main/appserver/admingui/common/src/main/resources/shared/sslPrepare.inc
trunk/main/appserver/admingui/common/src/main/resources/configuration/jmxSSLEdit.jsf
trunk/main/appserver/admingui/corba/src/main/resources/sslEdit.jsf
trunk/main/appserver/admingui/common/src/main/resources/shared/sslAttrs.inc
trunk/main/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/UtilHandlers.java
trunk/main/appserver/admingui/common/src/main/resources/shared/sslButtons.inc
trunk/main/appserver/admingui/web/src/main/resources/grizzly/ssl.layout





[GLASSFISH-17900] Error when a user is added to a file Realm in a cluster config. Created: 06/Dec/11  Updated: 15/Apr/13  Resolved: 15/Apr/13

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b84_RC1

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

OS : windows 2008 server
FF 8.0.1
GF nightly dated b13-12-04_2011


File Attachments: JPEG File add-user.JPG     JPEG File file-realm.JPG    
Tags: 3_1_2-exclude console
Participants: Anissa Lam, JeffTancill, kumarjayanti, shaline and srinik76

 Description   

When we add users to a fileRealm created in a cluster config, we see error that the user already exists. This issue shows up on windows systems and cluster-configs, when we specify the keyfile location for the file Realm using backward slashes. In server-configs this issue does not show up.Here are the steps to reproduce:

1) Install GF on a windows system , for Ex in a dir : C:\V3.1.2\glassfish3
2) enable secure admin and access console from remote browser, or access it locally.
3) Create a cluster with 2 instances on localhost-domain and start the cluster.
4) Under cluster-config/security/Realms, create a file realm as below:
--name : sqe-file-realm.
--Jaas context: fileRealm
--keyfile : C:\V3.1.2\glassfish3\glassfish\domains\domain1\config\keyfile

filerealm is created succesfully.

5) Open the created realm and select Manage Users button, and try adding a user Ex: admin1, with some password. Notice the error in seen in console that user exists.

"An error has occurred
An error occurred during replication FAILURE: Command create-file-user failed on server instance ins2: remote failure: Adding User admin1 to file realm sqe-file-realm failed. User admin1 already exists. User admin1 already exists. FAILURE: Command create-file-user failed on server instance ins1: remote failure: Adding User admin1 to file realm sqe-file-realm failed. User admin1 already exists. User admin1 already exists. FAILURE: Command create-file-user failed on server instance ins2: remote failure: Adding User admin1 to file realm sqe-file-realm failed. User admin1 already exists. User admin1 already exists. FAILURE: Command create-file-user failed on server instance ins1: remote failure: Adding User admin1 to file realm sqe-file-realm failed. User admin1 already exists. User admin1 already exists. "

This issue shows up only for cluster-configs, and when keyfile dir location has the backward slashes. while creating the filerealm, if we provide the keyfile dir location as "${com.sun.aas.instanceRoot}/config/keyfile". with forward slashes, then no error is seen while adding new users to the realm.

Attached the screenshots.

server.log has the same error as shown in the console.



 Comments   
Comment by Anissa Lam [ 06/Dec/11 01:22 AM ]

Can u repeat the same steps using CLI ? Does it show the same error ?

Comment by srinik76 [ 15/Dec/11 10:20 AM ]

Tried the same steps using CLI, it fails

srinivas@srinivas-laptop:~/v3/3.1.2/glassfish3/glassfish/bin$ ./asadmin create-file-user --target testcluster admin1
Authentication failed with password from login store: /home/srinivas/.asadminpass
Enter admin password for user "admin">
Enter the user password>
Enter the user password again>
remote failure: Adding User admin1 to file realm file failed.
Command create-file-user failed.
srinivas@srinivas-laptop:~/v3/3.1.2/glassfish3/glassfish/bin$

The server.log shows the following

[#|2011-12-15T15:47:28.048+0530|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.container.common|_ThreadID=46;_ThreadName=Thread-2;|User [admin] from host localhost does not have administration access|#]

[#|2011-12-15T15:47:28.064+0530|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.container.common|_ThreadID=47;_ThreadName=Thread-2;|User [admin] from host localhost does not have administration access|#]

Comment by srinik76 [ 16/Dec/11 06:45 AM ]

Shaline, i see a CLI also fails but with different error not like GUI/REST. Please confirm in your setup.

Comment by shaline [ 17/Dec/11 01:30 AM ]

I tried the above in the CLI, and was able to see the same error in CLI as in the Console.
--Created a fileRealm with backward slashes for the Keyfile location in a cluster config.
Then in CLI tried to add the user to the realm as below:

C:\SQE\glassfish\V3.1.2\glassfish3\glassfish\bin>asadmin create-file-user --authrealmname MyFileRealm --target cluster1 myadmin
Authentication failed with password from login store: C:\Users\j2eetest\.asadminpass
Enter admin password for user "admin">
Enter the user password>
Enter the user password again>
remote failure: An error occurred during replication
FAILURE: Command create-file-user failed on server instance ins2: remote failure
: Adding User myadmin to file realm MyFileRealm failed. User myadmin already exists.
User myadmin already exists.
FAILURE: Command create-file-user failed on server instance ins1: remote failure
: Adding User myadmin to file realm MyFileRealm failed. User myadmin already exists.
User myadmin already exists.
Command create-file-user failed.

Comment by Anissa Lam [ 17/Dec/11 08:08 AM ]

Thanks Shaline for the update.
Since CLI is also giving the same error, and GUI displays that error correctly, I am transferring this security for evaluation.

Comment by kumarjayanti [ 18/Jan/12 07:34 AM ]

cannot fix is 3.1.2 and is not a Stopper in that sense.

Comment by shaline [ 03/Feb/12 11:58 PM ]

I saw this issue on Solaris as well on cluster configs on GF 3.1.2 b20. When we add a user to an existing fileRealm in a cluster config, using the "manage users" button , the same above error gets displayed. but the user finally gets added and shows up in the Users table. When we try to delete the user , the below error gets displayed in the console.
An error has occurred
DELETE https://localhost:4848/management/domain/configs/config/cluster2-config/security-service/auth-realm/myFile/delete-user?target=cluster2-config&name=user1 returned a response status of 500 Internal Server Error

Comment by Anissa Lam [ 15/Apr/13 10:13 PM ]

I tested this again on the latest build, I don't see this issue any more.
I tried

  • create a cluster
  • go to the cluster's config, create a file realm, file realm created successfully.
  • edit the file realm and click the Manage User button
  • add a user, no issues.
  • delete the user, no issues
  • delete the file realm, no issues.

I tested above on both Mac and Windows, tried with both cluster running and stopped.
So, I cannot reproduce this issue in 4.0 thats reported for 3.1.2.
Marking as resolved.





[GLASSFISH-17773] Glassfish Gzip is not working fine