[GLASSFISH-19081] The admin password can be changed even the wrong original password was entered. Created: 16/Sep/12  Updated: 17/Sep/12  Resolved: 17/Sep/12

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b53
Fix Version/s: 4.0_b54

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

Windows 7, Windows XP

Attachments: Text File GLASSFISH-19081.patch    


[Bug Description]
When execute change-admin-password sub-command at the DAS was running, new password was setted
even a wrong original password entered.
It is similar to http://java.net/jira/browse/GLASSFISH-15783.
However, it can be reproduced in the latest version of GFv4.

STEP1.Start the DAS.
C:\glassfish3\glassfish\bin>asadmin start-domain

STEP2.Excute the change-admin-password sub-command to change the password.
C:\glassfish3\glassfish\bin>asadmin change-admin-password
Enter admin user name [default: admin]>admin/[Enetr Button]
Enter admin password>[Any string]
Enter new admin password>[new psw]
Enter new admin password again>[new psw]
Command change-admin-password executed successfully.

NOTE: The pwd has changed to [new psw].Use user:admin/pwd:[new psw] can login successfully.
C:\glassfish3\glassfish\bin>asadmin login
Enter admin user name [Enter to accept default]>admin
Enter admin password>[new psw]
Admin login information for host [localhost] and port [4848] is being overwritten with credentials p
rovided. This is because the --savelogin option was used during create-domain command.
Login information relevant to admin user name [admin] for host [localhost] and admin port [4848] sto
red at [C:\Documents and Settings\Administrator\.gfclient\pass] successfully.
Make sure that this file remains protected. Information stored in this file will be used by asadmin
commands to manage associated domain.
Command login executed successfully.

[affected versions]
1 4.0_b53
2 gf's trunk until 2012/09/12

Comment by zhouronghui [ 16/Sep/12 ]

I think that this BUG cause by the modify in GLASSFISH-18755. and the revision is 54235.
In revision 54235, the evaluation of password in ChangeAdminPasswordCommand.java was deleted.



I think that the evaluation of password should be reserved. I moditied the source and tested it.
I have attetched the patch for this ISSUE, Would you please check it?


Comment by Tom Mueller [ 17/Sep/12 ]

Fix on the trunk in revision 55997.

Thank you for submitting the patch.

[GLASSFISH-19070] Glassfish creates more than one http session in realm authentication Created: 11/Sep/12  Updated: 10/Oct/12  Resolved: 10/Oct/12

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b54

Type: Bug Priority: Critical
Reporter: lenz11 Assignee: Shing Wai Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: authentication, double, http, realm, sessions


When changeSessionIdOnAuthentication==true (default) and user authenticates with Realm - Glassfish calls sessions.setId(with_new_generated_id) which executes (through tellNew()): fireSessionEvent(Session.SESSION_CREATED_EVENT, null)
It is still the same session, but with new Id (no SESSION_DESTROYED_EVENT is called). This gives as a problem similar to:
http://stackoverflow.com/questions/11842343/glassfish-create-more-than-one-http-session-in-realm-authentication - and only half of sessions are being destroyed (see counter in administration panel: application monitoring/activeSessions).

This is because StandardSession.setId() calls method tellNew() even, if it is still the same session (but with new generated Id).

Now setId() method in web-core/src/main/java/org/apache/catalina/session/StandardSession.java looks like:

public void setId(String id)

{ if ((this.id != null) && (manager != null)) manager.remove(this); this.id = id; if (manager != null) manager.add(this); tellNew(); // this ALWAYS calls event: Session.SESSION_CREATED_EVENT }

but I think it should be something like this:

public void setId(String id)

{ if ((this.id != null) && (manager != null)) manager.remove(this); String old_id = this.id; this.id = id; if (manager != null) manager.add(this); if (old_id == null) tellNew(); // only call Session.SESSION_CREATED_EVENT if it is a new Session }

so the new session will be created only when old session Id is null.

Comment by Shing Wai Chan [ 10/Oct/12 ]

The fix has been checkin to GlassFish 4.0 b54 as follows:
r55887 | swchan2 | 2012-09-10 12:57:46 -0700 (Mon, 10 Sep 2012) | 2 lines

integrate javax.servlet-api 3.1-b02, implement changeSessionId


[GLASSFISH-19068] deploying hybrid osgi app with ejb bundle failed based on recent gf trunk Created: 11/Sep/12  Updated: 11/Sep/12  Resolved: 11/Sep/12

Status: Resolved
Project: glassfish
Component/s: deployment, OSGi-JavaEE
Affects Version/s: None
Fix Version/s: 4.0_b54

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

1 Windows XP
2 Maven 3.0.4
3 JDK 1.6.0_34
4 GF Trunk 2012/09/11

Attachments: Java Archive File sample.uas.api.jar     Java Archive File sample.uas.ejbservice2.jar     Java Archive File sample.uas.entities.jar     Text File server.log    


deploying hybrid osgi app with ejb bundle failed based on recent gf trunk(2012/09/11)

When using the following command to deploy a hybrid osgi app with ejb bundle, deploying failed.

> asadmin deploy --type=osgi E:\gfv4\gftrunk\fighterfish\sample\uas\ejbservice2\target\sample.uas.ejbservice2.jar

[Failed Info]
1 Cmd's Failed Info

remote failure: Error occurred during deployment: Exception while preparing the app : Unable to load the EJB module. DeploymentContext does not contain any EJB. Check the archive to ensure correct packaging for E:\gf0911\glassfish3\glassfish\domains\domain1\applications\sample.uas.ejbservice2.
If you use EJB component annotations to define the EJB, and an ejb or web deployment descriptor is also used, please make sure that the deployment descriptor references a Java EE 5 or higher version schema, and that the metadata-complete attribute is not set to true, so the component annotations can be processed as expected. Please see server.log for more details.

Command deploy failed.

2 StackTrace on server.log
Pl. see attachment(server.log)

[Deployed Bundle]
Pl. see attachment(sample.uas.ejbservice2.jar)

Comment by TangYong [ 11/Sep/12 ]

Sahoo Said:

Hi Tang,

That looks like a bug in deployment code. I know deployment team was
making some change to make deployment not about "OSGi" type deployment
and I suspect this regression has been introduced during that. Could you
kindly file a bug and assign it to deployment team?

The issue here is that an OSGi bundle containing EJBs is being deployed
with --type=osgi option, yet deployment backend is trying to deploy it
as an "ejb" archive as you can see from the exception stack.

Comment by TangYong [ 11/Sep/12 ]

Hong Said,

Sahoo: I just tried a simple EJB OSGi jar test case you gave me before
and I was able to deploy it as an OSGi bundle with --type osgi with no

Tang: If you have a reproducible test case, please file an issue and I
will take a look to see what I can find..

Comment by TangYong [ 11/Sep/12 ]

Sahoo Said,

> Sahoo: I just tried a simple EJB OSGi jar test case you gave me before
> > and I was able to deploy it as an OSGi bundle with --type osgi with no
> > issues.
Thanks much. Could you please add this to your deployment dev test suite?

Comment by TangYong [ 11/Sep/12 ]

I have reprodued the problem on my gf 09/11 built-snapshot and added the bundles resulting in the problem.

Comment by TangYong [ 11/Sep/12 ]

The complete deploying process is as following:

1 modify the property on config\osgi.properties


2 asadmin start-domain

3 asadmin start-database

4 asadmin deploy --type=osgi sample.uas.entities.jar

5 asadmin deploy --type=osgi sample.uas.api.jar

6 asadmin deploy --type=osgi sample.uas.ejbservice2.jar

The 6's deployment will failed.

Comment by TangYong [ 11/Sep/12 ]

I have investigated the problem and the results are as following:

1 sortedEngineInfos object contained Deploy Info in the following order.

1) EJB Deploy
2) OSGi Deploy

Pl. see com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:427)

So, EJB Deploying happened before OSGi Deploying.

2 tracing how to get sortedEngineInfos object

On setupContainerInfos(handler, sniffers, context), if sniffers contained EJB Sniffer, sortedEngineInfos will container EJB Deploy Info.

So, continue to trace sniffers object.

Pl. see com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:373)

3 tracing how to get sniffers object

sniffers = getSniffers(handler, sniffers, context);

So, investigated getSniffers method, and found on getSniffers method, sniffers object was get by snifferManager.getSniffers(context) method.
Pl. see
[1] com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:356)
[2] com.sun.enterprise.v3.server.ApplicationLifecycle.getSniffers(ApplicationLifecycle.java:648)

4 about snifferManager.getSniffers(context) method

the method called com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers method to get sniffers object, and because regularSniffers collection contained Connector sniffer, EJB sniffer,...OSGi sniffer,.. in such an order. And sample.uas.ejbservice2.jar has javax.ejb.Stateless annotation, so EJB sniffer can match with sniffer search rule on getApplicableSniffers method, and first added into sniffers.

Pl.see com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers(SnifferManagerImpl.java:150)

So, I think that "--type=osgi" did not take effect on getting sniffers, and wish hong and shoo confirmed what I said.

Comment by TangYong [ 11/Sep/12 ]

In addition, The problem happened on at org.glassfish.ejb.startup.EjbDeployer.prepare(EjbDeployer.java:191), and I found that when executing ApplicationLifecycle.java:828, the return value of deployer.loadMetaData(provide, context) is null, so the problem happened. However, now, I have not know the reason.

Comment by Hong Zhang [ 11/Sep/12 ]

Thanks for attaching the test case and the initial analysis!

I was able to reproduce the issue and identify the cause and I have a fix in my local workspace now.

Only OSGi sniffer should be returned back and not the ejb sniffer in sniffer retrieval. Previous changes to clean up special handling for OSGi only takes care of the cases where the Sniffer.handles method is used to retrieve sniffer, but not the part where the sniffers were retrieved through annotation scanning. Updated that code path to take the archive type into consideration as well (so any sniffer type other than OSGi will be filtered out). Will check in the change after running the usual set of the tests.

Comment by Hong Zhang [ 11/Sep/12 ]

Fix checked in, svn 55899.

[GLASSFISH-19066] A warning message is needed when error-page location file doesn't exist Created: 08/Sep/12  Updated: 07/Nov/13  Resolved: 08/Sep/12

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

Type: Improvement Priority: Major
Reporter: Amy Roh Assignee: Amy Roh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


When error-page location file doesn't exist, GF just displays a blank page without any warning message. This leads users to think that error-page mechanism is not working property when they have a typo in their web.xml.


Comment by Amy Roh [ 08/Sep/12 ]

Fixed to display a warning message when error-page location file doesn't exist. Revision 55858

Comment by alejandro88 [ 07/Nov/13 ]

Hi Amy,
I use the web.xml to map error-page to a servlet and manage all the exception through that servlet:



Now, as there is no ErrorHandlerServle page I get the warning, is there any way to avoid this warning? maybe it will be great if the validation is also at servlet scope.
Thanks for your feedback

[GLASSFISH-19050] Glassfish swallows RuntimeException thrown in SynchronizationListener.beforeCompletion Created: 04/Sep/12  Updated: 07/Sep/12  Resolved: 07/Sep/12

Status: Resolved
Project: glassfish
Component/s: jts
Affects Version/s: 3.1.2, 4.0_b53
Fix Version/s: 4.0_b54

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

Glassfish, EclipseLink 2.3.2, Oracle Database Server 10.x or 11.x

Attachments: GZip Archive demo-proxy-auth-generic.tar.gz    


I have created an example that demonstrates how to use the EclipseLink feature for
Oracle Database Server Proxy Authentication.
This feature uses database authentication and authorization to secure an application.

On Glassfish the original RuntimeException thrown in an EclipseLink exception handler is not piggybacked with the EJBException that the web client does receive from the failed session bean method call.

[#|2012-09-04T15:08:37.237+0200|WARNING|oracle-glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=39;_ThreadName=Thread-2;|javax.ejb.EJBException: Transaction aborted
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5142)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4901)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2045)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1994)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:89)
at $Proxy138.incrementAndReadValue(Unknown Source)
at oracle.support.web.BackingBean.incrementAndReadValue(BackingBean.java:46)
at org.apache.jsp.WEB_002dINF.jsp.write_jsp._jspService(write_jsp.java:97)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:809)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:671)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:505)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:476)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:355)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:305)
at oracle.support.web.ControllerServlet.doPost(ControllerServlet.java:83)
at oracle.support.web.ControllerServlet.doGet(ControllerServlet.java:38)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at oracle.support.web.AuthenticationFilter.doFilter(AuthenticationFilter.java:61)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.transaction.RollbackException
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:334)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:185)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:861)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5136)
... 54 more

The README file of the example explains how to setup the example.
The problem can be reproduced by logging in as user "proxyuser" and password "test" and then clicking on "write".
The user "proxyuser" does not have privileges to write and therefore the JDBC driver will raise an exception that indicates that the privileges are not sufficient.

On WebLogic Server the example does display the correct error message of the root cause exception on the error page.

Comment by marina vatkina [ 05/Sep/12 ]

Can you try the scroll through the causes? I think we fixed it in the transaction code, but the EJB container only reports the actual transaction failure (javax.transaction.RollbackException), which is fine.

Comment by rgirsten [ 05/Sep/12 ]

The web client error page walks down the exception chain and prints the root exception error message.
The client gets EJBException with RollbackException. The root cause exception is missing.
I have tried to setup a simpler example which is simply violating a primary key constraint (unique key violation) in a transaction. But in this case the client will receive the complete chain of exceptions including the root cause.
So, somewhat the behavior of Glassfish seems to be inconsistent.
But without having the complete exception chain available, the client cannot handle or report an application exception.
It is pretty normal for persistence frameworks to plug into JTS by using a SynchronizationListener with the beforeCompletion and afterCompletion method. Also it is normal that such persistence framework does call setRollbackOnly if the processing of the beforeCompletion and afterCompletion actions was throwing an exception.

Comment by marina vatkina [ 07/Sep/12 ]

Can you attach a simple test case? Are you using XA or non-XA resources?

Comment by marina vatkina [ 07/Sep/12 ]

I have even a junit test case that verifies that an exception from beforeCompletion is attached to the RollbackException...

Comment by rgirsten [ 07/Sep/12 ]

I have tried to simplify my example but I was not able to.
My example uses an XA data source for the transaction that throws the RuntimeException in the eclipselink exception handler when it detects the
SQLSyntaxErrorException: ORA-01031: insufficient privileges
My RuntimeException does not piggyback the SQLSyntaxErrorException. But this is not the problem.
The problem is that the RollbackException does not piggyback the root cause exception which is the RuntimeException.
If I remove the eclipselink exception handler by putting the persistence.xml property in comments then I have the problem that the SQLSyntaxErrorException is not piggybacked by the RollbackException.
There is very little Glassfish specific that eclipselink is doing.
The SunAS/Glassfish support classes do provide Glassfish specific methods to lookup the TransactionManager and to unwrap JDBC connections.

Comment by marina vatkina [ 07/Sep/12 ]

I can reproduce it with 2 XA resources, but it's not clear yet why junit test doesn't catch it

Comment by marina vatkina [ 07/Sep/12 ]

Interestingly enough the unit test calls tx.commit() and that path attaches the cause. TM.commit() doesn't

Comment by marina vatkina [ 07/Sep/12 ]

Transaction.commit was fixed by http://java.net/jira/browse/GLASSFISH-11970

Comment by marina vatkina [ 07/Sep/12 ]

Fixed on trunk with rev 55854.

To make the same change in 3.1.2x line 333 in src/main/java/com/sun/jts/jta/TransactionManagerImpl.java should be changed as follows:

  • throw new RollbackException();
    + RollbackException rbe = new RollbackException();
    + Throwable cause = ex.getCause();
    + if (cause != null) { + rbe.initCause(cause); + }

    + throw rbe;

[GLASSFISH-18900] Implement support for Java EE Connection Factory and Destination Resource Definition Created: 13/Jul/12  Updated: 07/Nov/12  Resolved: 12/Sep/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0
Fix Version/s: 4.0_b54

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7platspec, jms-2-implementation


This issue covers the implementation of the following sections of the Java EE 7 specification: EE.5.17.4 "JMS Connection Factory Resource Definition" and EE.5.17.5 "JMS Destination Definition".

For a definitive description of this requirement, see the Java EE 7 specification.

Comment by Nigel Deakin [ 23/Jul/12 ]

The annotation itself, and the standard properties that will be defined, will be defined as part of JMS 2.0. The JMS specification issues are JMS_SPEC-96 and JMS_SPEC-97.

Comment by Simon Meng [ 12/Sep/12 ]

Committed revision 55843.

Generated at Mon Mar 30 06:51:16 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.