[GLASSFISH-19733] OLH empty index.xml in console-concurrent-plugin-help.zip causes OLH broken Created: 27/Feb/13  Updated: 04/Mar/13  Resolved: 04/Mar/13

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b77
Fix Version/s: 3.1.2_b08

Type: Bug Priority: Critical
Reporter: Anissa Lam Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the latest nightly build, console OLH is broken.
This is due to an empty index.xml file in the console concurrent help doc set. Patching the jar with an non-empty index.xml shows thats indeed the issue.



 Comments   
Comment by Anissa Lam [ 04/Mar/13 ]

Checked in the pom.xml that uses 4.0-b21.

Log Message:
------------
GLASSFISH-19733. OLH for concurrent console plugin index.xml should not be null.

Revisions:
----------
60018

Modified Paths:
---------------
trunk/main/nucleus/pom.xml





[GLASSFISH-17577] [IBM JDK7]All the appclient related test cases failed on AIX against IBM JDK1.7 Created: 02/Nov/11  Updated: 26/Aug/13  Resolved: 26/Aug/13

Status: Resolved
Project: glassfish
Component/s: naming
Affects Version/s: 3.1.2_b07
Fix Version/s: 3.1.2_b08

Type: Bug Priority: Critical
Reporter: sonialiu Assignee: Harshad Vilekar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

AIX
IBM JDK1.7
java version "1.7.0"
Java(TM) SE Runtime Environment (build pap3270-20110827_01)
IBM J9 VM (build 2.6, JRE 1.7.0 AIX ppc-32 20110810_88604 (JIT enabled, AOT enabled)
J9VM - R26_Java726_GA_20110810_1208_B88592
JIT - r11_20110810_20466
GC - R26_Java726_GA_20110810_1208_B88592
J9CL - 20110810_88604)
JCL - 20110809_01 based on Oracle 7b147


Attachments: Zip Archive patch-GLASSFISH-17577.zip     Text File server.log    
Tags: 3_1_2-review, blocking

 Description   

build: GF 3.1.2 b07
OS: AIX
jdk: IBM JDK1.7

SQE appclient related test cases passed on AIX against IBM JDK1.6, but all failed against IBM JDK1.7.

Steps to reproduce the bug:
1.Checkout SQE workspace:
cvs co appserver-sqe/bootstrap.xml
(CVSROOT=:pserver:cvsguest@sunsw.us.oracle.com:/m/jws)
cd appserver-sqe
ant -f bootstrap.xml co-smoke-test
2. install GF V3.1.2 on AIX, start domain domain1
3. Set the following env. variables
S1AS_HOME <GF installation dir> (example: /export/hudson/workspace/glassfishv3/glassfish
SPS_HOME <workspace dir> (example: /export/hudson/workspace/appserver-sqe)
ANT_HOME <ant 1.7.1 dir>
JAVA_HOME <java dir point to IBM jdk1.7>
> 4. cd appserver-sqe/pe/ejb/mdb/basic, run "ant all", the test failed and the following exceptions displayed:
runclient-common:
[echo] Executing appclient at /export/hudson/workspace/alex-aix-smoke/appserver-sqe/pe/ejb/mdb/basic
[echo] Nov 02, 2011 9:05:45 AM org.glassfish.appclient.client.acc.AppclientCommandArguments warnAboutPasswordUsage
[echo] WARNING: ACC013: The -password option is deprecated and will likely be removed in a future release. Please use -passwordfile or let the app client container prompt for the username and/or password if they are needed to access a remote resource.
[echo] WS HOME appserver-sqe
[echo] In main before calling init
[echo] basicJMS2EJB initTopic failed: unexpected NamingException
[echo] javax.naming.NamingException: Lookup failed for 'java:comp/env/jms/basicTopic' in SerialContext[myEnv=

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

[Root exception is javax.naming.CommunicationException: Communication exception for SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, com.sun.enterprise.naming.logicalName=java:comp/env/jms/basicTopic}

[Root exception is java.rmi.RemoteException: CORBA UNKNOWN 1330446338 Maybe; nested exception is:
[echo] org.omg.CORBA.UNKNOWN: ---------BEGIN server-side stack trace---------
[echo] org.omg.CORBA.UNKNOWN: WARNING: IOP00010002: Unknown user exception thrown by the server - exception: java.lang.IllegalArgumentException; message: null vmcid: OMG minor code: 2 completed: Maybe
[echo] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[echo] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:80)
[echo] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
[echo] at java.lang.reflect.Constructor.newInstance(Constructor.java:539)
[echo] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
[echo] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
[echo] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
[echo] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
[echo] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
[echo] at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
[echo] at $Proxy184.runtimeexception(Unknown Source)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.convertThrowableToSystemException(CorbaMessageMediatorImpl.java:1843)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1793)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1758)
[echo] at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:255)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
[echo] at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
[echo] at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
[echo] at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
[echo] Caused by: java.lang.IllegalArgumentException
[echo] at java.nio.Buffer.position(Buffer.java:247)
[echo] at sun.nio.cs.UTF16_Decoder.decodeLoop(UTF16_Decoder.java:186)
[echo] at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:561)
[echo] at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:783)
[echo] at com.sun.corba.ee.impl.encoding.CodeSetConversion$JavaBTCConverter.getChars(CodeSetConversion.java:413)
[echo] at com.sun.corba.ee.impl.encoding.CodeSetConversion$UTF16BTCConverter.getChars(CodeSetConversion.java:559)
[echo] at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.getConvertedChars(CDRInputStream_1_0.java:2325)
[echo] at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.read_wstring(CDRInputStream_1_2.java:171)
[echo] at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1082)
[echo] at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
[echo] at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$14.read(DynamicMethodMarshallerImpl.java:384)
[echo] at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readArguments(DynamicMethodMarshallerImpl.java:451)
[echo] at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:172)
[echo] at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
[echo] at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
[echo] ... 9 more
[echo]
[echo] ---------END server-side stack trace--------- vmcid: OMG minor code: 2 completed: Maybe]]
[echo] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
[echo] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
[echo] at javax.naming.InitialContext.lookup(InitialContext.java:422)
[echo] at com.sun.s1peqe.ejb.mdb.basic.BasicJMS2EJBClient.initTopic(BasicJMS2EJBClient.java:63)
[echo] at com.sun.s1peqe.ejb.mdb.basic.BasicJMS2EJBClient.init(BasicJMS2EJBClient.java:52)
[echo] at com.sun.s1peqe.ejb.mdb.basic.BasicJMS2EJBClient.main(BasicJMS2EJBClient.java:315)
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
[echo] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
[echo] at java.lang.reflect.Method.invoke(Method.java:613)
[echo] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:438)
[echo] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
[echo] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[echo] Caused by: javax.naming.CommunicationException: Communication exception for SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, com.sun.enterprise.naming.logicalName=java:comp/env/jms/basicTopic}

[Root exception is java.rmi.RemoteException: CORBA UNKNOWN 1330446338 Maybe; nested exception is:
[echo] org.omg.CORBA.UNKNOWN: ---------BEGIN server-side stack trace---------
[echo] org.omg.CORBA.UNKNOWN: WARNING: IOP00010002: Unknown user exception thrown by the server - exception: java.lang.IllegalArgumentException; message: null vmcid: OMG minor code: 2 completed: Maybe
[echo] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[echo] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:80)
[echo] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
[echo] at java.lang.reflect.Constructor.newInstance(Constructor.java:539)
[echo] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
[echo] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
[echo] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
[echo] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
[echo] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
[echo] at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
[echo] at $Proxy184.runtimeexception(Unknown Source)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.convertThrowableToSystemException(CorbaMessageMediatorImpl.java:1843)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1793)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1758)
[echo] at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:255)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
[echo] at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
[echo] at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
[echo] at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
[echo] at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
[echo] Caused by: java.lang.IllegalArgumentException
[echo] at java.nio.Buffer.position(Buffer.java:247)
[echo] at sun.nio.cs.UTF16_Decoder.decodeLoop(UTF16_Decoder.java:186)
[echo] at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:561)
[echo] at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:783)
[echo] at com.sun.corba.ee.impl.encoding.CodeSetConversion$JavaBTCConverter.getChars(CodeSetConversion.java:413)
[echo] at com.sun.corba.ee.impl.encoding.CodeSetConversion$UTF16BTCConverter.getChars(CodeSetConversion.java:559)
[echo] at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.getConvertedChars(CDRInputStream_1_0.java:2325)
[echo] at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.read_wstring(CDRInputStream_1_2.java:171)
[echo] at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1082)
[echo] at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
[echo] at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$14.read(DynamicMethodMarshallerImpl.java:384)
[echo] at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readArguments(DynamicMethodMarshallerImpl.java:451)
[echo] at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:172)
[echo] at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
[echo] at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
[echo] ... 9 more
[echo]

There are some exceptions in the server.log, please see attached server.log for more details.



 Comments   
Comment by sonialiu [ 02/Nov/11 ]

The problem happened for both 32 and 64 bit JDK.

Comment by Cheng Fang [ 18/Nov/11 ]

Related to GLASSFISH-16882

GlassFishNamingBuilder need to be updated to reflect changes in IBM JDK 1.7 (the field name has changed from icfb to initctx_factory_builder)

Assign to Sahoo for further evaluation.

Comment by Sanjeeb Sahoo [ 01/Dec/11 ]

Cheng,

I think we can apply the following patch. Would you mind taking care of this bug?

diff --git a/nucleus/common/glassfish-naming/src/main/java/com/sun/enterprise/naming/GlassFishNamingBuilder.java b/nucleus/common/glassfish-naming/src/main/java/com/sun/enterpri
index 1283fe2..32369fb 100644
— a/nucleus/common/glassfish-naming/src/main/java/com/sun/enterprise/naming/GlassFishNamingBuilder.java
+++ b/nucleus/common/glassfish-naming/src/main/java/com/sun/enterprise/naming/GlassFishNamingBuilder.java
@@ -211,7 +211,7 @@ public class GlassFishNamingBuilder implements InitialContextFactoryBuilder, Sta
{
try

{ - final String fieldName = ifIbmJava() ? "icfb" : "initctx_factory_builder"; + final String fieldName = ifIbmJava6() ? "icfb" : "initctx_factory_builder"; Field f = NamingManager.class.getDeclaredField(fieldName); f.setAccessible(true); f.set(null, null); @@ -226,8 +226,8 @@ public class GlassFishNamingBuilder implements InitialContextFactoryBuilder, Sta }

}

  • private boolean ifIbmJava() {
  • return System.getProperty("java.vendor", "").equals("IBM Corporation");
    + private boolean ifIbmJava6() { + return System.getProperty("java.vendor", "").equals("IBM Corporation") && System.getProperty("java.version").equals("1.6.0"); }

/**

Comment by Sanjeeb Sahoo [ 01/Dec/11 ]

Taking ownership and fixing it as well.
trunk:
Committed r51227
M nucleus/common/glassfish-naming/src/main/java/com/sun/enterprise/naming/GlassFishNamingBuilder.java

3.1.2:
Committed revision 51228.

Comment by Alex Pineda [ 15/Feb/13 ]

Just tried on the lastest version of Glassfish, 3.2.1.2 and I'm seeing the same appclient problem as originally reported. Re-opening the issue as a customer is requesting for IBM JDK7 support and it appears to be a problem.

Comment by Sanjeeb Sahoo [ 18/Feb/13 ]

I am pretty sure this bug was fixed in 3.1.2 otherwise we would not have been able to certify 3.1.2 on Aix. So, I am not sure what has changed since then. Pl open a new bug. If you want me to investigate this bug, please prove that it was not fixed in 3.1.2. Use the AIX version that's certified to be used with 3.1.2.

Comment by Sanjeeb Sahoo [ 12/Mar/13 ]

I could not use appserver-sqe test suite. cvs checkout is still running for last 2+ hours. So, I went ahead and wrote my own appclient->remoteEjb test case. I confirm that a simple appclient->remoteEjb scenario is NOT working using glassfish-3.1.2-aix.zip as I downloaded from glassfish.org download page. I am getting the exact same error reported by the submitter. I am using the same version of IBM JDK used by the submitter of this bug, except that I am using on Linux, but that does not matter. I get the same error as reported by the submitter.

Where is the confusion and what have we so far fixed then? Actually, there was another naming bug that needed cropped up when we used IBM JDK 7. The attached server.log had the following exception and that made Cheng assign the issue to me as you can see from his earlier comment [1]. He did that because I had once fixed GLASSFISH-16882 to address a similar stack trace:

[#|2011-11-02T09:07:09.460-0700|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=117;_ThreadName=Thread-10;|Caused by: |#]

[#|2011-11-02T09:07:09.461-0700|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=117;_ThreadName=Thread-10;|java.lang.NoSuchFieldException: icfb|#]

[#|2011-11-02T09:07:09.462-0700|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=117;_ThreadName=Thread-10;| at java.lang.Class.getDeclaredFieldImpl(Native Method)|#]

[#|2011-11-02T09:07:09.463-0700|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=117;_ThreadName=Thread-10;| at java.lang.Class.getDeclaredField(Class.java:533)|#]

[#|2011-11-02T09:07:09.464-0700|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=117;_ThreadName=Thread-10;| at com.sun.enterprise.naming.GlassFishNamingBuilder.resetInitialContextFactoryBuilder(GlassFishNamingBuilder.java:215)|#]

[#|2011-11-02T09:07:09.464-0700|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=117;_ThreadName=Thread-10;| ... 12 more|#]

It was a valid issue and has been fixed by me and forward ported to trunk as well. But, unfortunately, that does not address everything that's reported here. The remaining issue has to be investigated by a COSNaming engineer (Harsad Vilekar may be?). All in all, we have work to do make things work on IBM JDK 7. What was not told to us that GF 3.1.2 was not certified on IBM-JDK7; it was only certified on IBM-JDK6.

[1] http://java.net/jira/browse/GLASSFISH-17577?focusedCommentId=324750&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_324750

Comment by guojun.shan [ 21/Mar/13 ]

we need help from CORBA team. re-assign to Harshad.

Comment by Harshad Vilekar [ 15/Aug/13 ]

I could duplicate the exception using a very simple HelloWorld remote EJB test, with IBM AIX JDK7. The part of the stack trace of interest is:
================================================
[echo] Caused by: java.lang.IllegalArgumentException
[echo] at java.nio.Buffer.position(Buffer.java:247)
[echo] at sun.nio.cs.UTF16_Decoder.decodeLoop(UTF16_Decoder.java:186)
[echo] at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:561)
[echo] at
java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:783)
[echo] at
com.sun.corba.ee.impl.encoding.CodeSetConversion$JavaBTCConverter.getChars(Cod
eSetConversion.java:413)
================================================

Note the part of the JDK code in the stack trace. Exact same test works fine with IBM AIX JDK6. This looks like a regression in IBM AIX JDK7.

The issue is worked around in the Corba code by reconstructing the ByteBuffer, and then passing it to the JDK CharsetDecoder.

Requesting QA review of the fix.
The Corba patch is attached. To apply the patch:
--------------------
Install GlassFish 3.1.2 update 6

cd $GF_INSTALL_DIR/glassfish3/glassfish/modules
jar xvf patch-GLASSFISH-17577.zip
jar uvf glassfish-corba-orb.jar com/sun/corba/ee/impl/encoding
\rm -rf com/sun/corba/

Restart GlassFish
--------------------
Please test the attached patch and update the bug report with the results.

Comment by Harshad Vilekar [ 26/Aug/13 ]

Fixed committed. GlassFish 3.1.2 svn revision 14819.

glassfish-corba source gf-corba-v3-mirror~gfv31-master, hg revision 708, build 3.1.2-b001.

Please regression test all remote EJB related functionality with IBM AIX JDK7.





[GLASSFISH-17539] Timeout field under Protocol -> Http tab should allow negative number. Created: 31/Oct/11  Updated: 17/Nov/11  Resolved: 31/Oct/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2_b08, 3.1.2, 4.0

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

Issue Links:
Duplicate
is duplicated by GLASSFISH-17540 Can't set -1 to http.request-timeout-... Resolved

 Description   

request-timeout-seconds attribute for <http> allows -1 , but GUI is enforcing that to be a positive number in the client validation.
This should be fixed so user can input -1 which means disabling it.

In the forum discussion:
http://forums.java.net/node/855551?force=732

@laptop:~/apps/glassfish/0000/glassfish3/bin$ ./asadmin set
configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.request-timeout-seconds=-1
configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.request-timeout-seconds=-1
Command set executed successfully.



 Comments   
Comment by Anissa Lam [ 31/Oct/11 ]

While looking into this, sounds like the following fields also allows -1 to indicate disabling it.

request-timeout-seconds
timeout-seconds
connection-upload-timeout-millis

Will request oleksiys to confirm and will change the validation for those fields also.

Comment by oleksiys [ 31/Oct/11 ]

you're right Anissa.
-1 should work similar way for other timeout attributes.

Comment by Anissa Lam [ 31/Oct/11 ]

Fixed in both trunk (4.0) and 3.1.2. Should be available in 3.1.2 promoted build 08.

Trunk:
50594 31.10.2011 18:29:58, by anilam
GLASSFISH-17539. Allows 1 for the following timeout attributes: request-timeout-seconds, timeout-seconds and connection-upload-timeout-millis in protocol>http tab.

3.1.2 branch:
50592 31.10.2011 18:20:06, by anilam
GLASSFISH-17539. Allows 1 for the following timeout attributes: request-timeout-seconds, timeout-seconds and connection-upload-timeout-millis in protocol>http tab.
M /branches/3.1.2/admingui/common/src/main/resources/js/adminjsf.js
M /branches/3.1.2/admingui/web/src/main/resources/grizzly/httpAttr.inc
M /branches/3.1.2/admingui/web/src/main/resources/org/glassfish/web/admingui/Strings.properties

mark resolved.

Comment by tmpsa [ 01/Nov/11 ]

Glad to be of help to finding this issue.

As I said in the forum, please also update the built-in help (both on the form page and the help page); -1 is a magical value with special meaning.

I also suggested that there should be a NEW SEPARATE timeout for uploads. Perhaps downloads as well... These can run for quite some time; for example when transferring a huge file. As long as there's reasonable traffic (i.e. above a certain number of bytes per seconds during the last y seconds) the request should not time out, no matter how long it has been running.

In other words, the ordinary Request Timeout should not apply at all to such operations, only when no traffic has occured.

Perhaps this should be made into a different issue?

Comment by Anissa Lam [ 01/Nov/11 ]

Yes, the inline help for those 3 attributes has been modified, spell out that -1 means disabling it. Thats part of the checkin for this bug.

There is also a doc bug filed for enhancement for http://java.net/jira/browse/GLASSFISH-17480

As for adding another 'NEW SEPARATE timeout for uploads' attribute, please find another issues against grizzly. Once the backend has added that, we will add that to the console screen.
thanks.

Comment by tmpsa [ 17/Nov/11 ]

Anissa, I have now filed a new issue against Grizzly, as you suggest. See http://java.net/jira/browse/GRIZZLY-1121 .





[GLASSFISH-17512] enable-secure-admin should fail if the admin password is null Created: 27/Oct/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.1, 4.0
Fix Version/s: 3.1.2_b08, 4.0

Type: Bug Priority: Major
Reporter: Joe Di Pol Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-17510 Be more rigorous about requiring user... Resolved
Tags: 3_1_2-review

 Description   

If the user runs enable-secure-admin, but the admin password is null (no password) for any admin user then it should fail and tell the user they need to set a password with change-admin-password before enabling secure admin.

See issue GLASSFISH-17510 for more information.



 Comments   
Comment by Tim Quinn [ 04/Nov/11 ]

Fix checked in for 3.1.2.

Project: glassfish
Repository: svn
Revision: 50672
Author: tjquinn
Date: 2011-11-04 15:28:51 UTC
Link:

Log Message:
------------
Fix for 17512 - enable-secure-admin should fail if the admin password is null

These changes enhance enable-secure-admin so that the command fails if any admin user has an empty password.

Tests: QL, admin devtests

Revisions:
----------
50672

Modified Paths:
---------------
branches/3.1.2/security/core/src/main/java/com/sun/enterprise/security/admin/cli/EnableSecureAdminCommand.java
branches/3.1.2/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminConfigUpgrade.java
branches/3.1.2/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/SecureAdminHelper.java
branches/3.1.2/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminHelperImpl.java
branches/3.1.2/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminCommand.java
branches/3.1.2/security/core/src/main/resources/com/sun/enterprise/security/admin/cli/LocalStrings.properties

Comment by Tim Quinn [ 04/Nov/11 ]

Fix for the trunk checked in

Project: glassfish
Repository: svn
Revision: 50681
Author: tjquinn
Date: 2011-11-04 21:13:22 UTC
Link:

Log Message:
------------
Fix for 17512 - enable-secure-admin should fail if the admin password is null

These changes enhance enable-secure-admin so that the command fails if any admin user has an empty password.

Revisions:
----------
50681

Modified Paths:
---------------
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminCommand.java
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminConfigUpgrade.java
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminHelperImpl.java
trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/EnableSecureAdminCommand.java
trunk/main/nucleus/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/SecureAdminHelper.java
trunk/main/nucleus/security/core/src/main/resources/com/sun/enterprise/security/admin/cli/LocalStrings.properties





[GLASSFISH-17503] Should throw exception rather than log a warning for incorrect configuration of security filters Created: 27/Oct/11  Updated: 27/Oct/11  Resolved: 27/Oct/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 3.1.2_b08

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


 Description   

One should port of the Apache fix to GlassFish:
http://svn.apache.org/viewvc?rev=1189258&view=rev



 Comments   
Comment by Shing Wai Chan [ 27/Oct/11 ]

fix in 3.1.2:
Sending web-core/src/main/java/org/apache/catalina/filters/CsrfPreventionFilter.java
Sending web-core/src/main/java/org/apache/catalina/filters/FilterBase.java
Transmitting file data ..
Committed revision 50536.

fix in trunk:
Sending web-core/src/main/java/org/apache/catalina/filters/CsrfPreventionFilter.java
Sending web-core/src/main/java/org/apache/catalina/filters/FilterBase.java
Transmitting file data ..
Committed revision 50537.





[GLASSFISH-17499] Uncaught NullPointerException during http.ProcessorTask.doProcess can break postProcess buffer cleanup Created: 27/Oct/11  Updated: 28/Nov/11  Resolved: 28/Oct/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.1_b12
Fix Version/s: 3.1.2_b08, 4.0

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


 Description   

We are running the GlassFish Server version 3.1.1 build 12 plus patches loaded from the private Oracle repository on 8/16/2011.
During testing we noted that the following pair of errors occurred following a very large (over 8192 byte) URI sent to the server. Thereafter, each time that the thread was reused, it generated the same pair of errors, most likely because the second error was not caught and caused the thread to be released without the postProcess buffer cleanup 'recycle()'. With just a few retries of the long URI, we managed to disable all of the domain's request processing threads.

The error was triggered by the buffer overflow and then the unhandled null pointer error in the ErrorHandler caused the rest - the stack traces are shown below.

The actual error appears to be in the ErrorHandler property of the associated thread; however the grizzly http.ProcessorTask.doProcess probably should protect itself.

[#|2011-10-06T17:13:28.188-0400|SEVERE|oracle-glassfish3.1.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=28;_ThreadName=Thread-3;|GRIZZLY0039: Request URI is too large.
java.nio.BufferOverflowException
at com.sun.grizzly.tcp.http11.InternalInputBuffer.fill(InternalInputBuffer.java:765)
at com.sun.grizzly.tcp.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:402)
at com.sun.grizzly.http.ProcessorTask.parseRequest(ProcessorTask.java:861)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:692)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
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:662)

#]

[#|2011-10-06T17:13:28.188-0400|SEVERE|oracle-glassfish3.1.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=28;_ThreadName=Thread-3;|GRIZZLY0051: ProcessorTask exception.
java.lang.NullPointerException
at java.nio.CharBuffer.put(CharBuffer.java:896)
at com.sun.enterprise.web.accesslog.DefaultAccessLogFormatterImpl.appendRequestInfo(DefaultAccessLogFormatterImpl.java:494)
at com.sun.enterprise.web.accesslog.DefaultAccessLogFormatterImpl.appendLogEntry(DefaultAccessLogFormatterImpl.java:264)
at com.sun.enterprise.web.PEAccessLogValve.postInvoke(PEAccessLogValve.java:592)
at com.sun.enterprise.web.VirtualServer$2.onParsingError(VirtualServer.java:1698)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:709)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
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:662)

#]


 Comments   
Comment by oleksiys [ 27/Oct/11 ]

reassign to webcontainer to fix NPE.

Comment by Shing Wai Chan [ 27/Oct/11 ]

The NPE is due to the fact that hreq.getRequestURI() is null.
The URI is null because of the buffer overflow.

Assign to Amy to investigate what should be done in this case.
Note that one need to be able to identify this from the log later.

Comment by Amy Roh [ 28/Oct/11 ]

Fixed in svn 50549 & 50551.

Comment by gpambrozio [ 28/Nov/11 ]

Is there a workaround for this issue? Maybe adding a filter to every request? I started seeing this error today on my servers and I'm worried it might be some kind of DOS or that it might become one...





[GLASSFISH-17419] lib/applibs not created automatically for instances Created: 13/Oct/11  Updated: 02/Nov/11  Resolved: 02/Nov/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2_b08, 4.0

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


 Description   

The "lib/applibs" directory is not created automatically when an instance is created, even though the directory exists in the DAS.

This is important for supporting config-specific libraries. The --libraries option of the deploy command accepts a relative pathname that is interpreted relative to the lib/applibs directory. When specifying a config-specific library using ../../config/named-config/lib/somesuch.jar, the reference fails if the lib/applibs directory does not exist.

The fix for this issue should cause the lib/applibs directory to show up in an instance even if there are no files in it.



 Comments   
Comment by Tom Mueller [ 17/Oct/11 ]

Target for 3.1.2 and the trunk.

Comment by Tom Mueller [ 02/Nov/11 ]

Fixed in revision 50622 on the trunk.
Fixed in revision 50623 on the 3.1.2 branch.





[GLASSFISH-17367] Default JMS host ist set to "localhost", which cannot be resolved by appclient Created: 28/Sep/11  Updated: 22/Nov/11  Resolved: 21/Nov/11

Status: Closed
Project: glassfish
Component/s: jms
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2_b08

Type: Bug Priority: Critical
Reporter: mkarg Assignee: Satish Kumar
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 64 Bit



 Description   

glassfish-3.1.1-windows creates a default domain (domain1), which contains the following line:

<jms-host name="default_JMS_host" host="localhost" port="7676" admin-user-name="admin" admin-password="admin" lazy-init="true"/>

The problem is the word "localhost", as it gets transferred to remote appclients in an unchanged way. As soon as a client program running in ACC tries to start a JMS connection, it will fail as it tries to reach "localhost".

Obviously, the ACC should get provided the JMS server's real hostname by the server instead of "localhost", or even better, the actual IP address to which the JMS port is currently bound.



 Comments   
Comment by scatari [ 13/Oct/11 ]

We could document this, given that the none of the configuration exists for "zip" based installer. I am transferring to admin backend team to see if they can replace "localhost" with the IP address.

Comment by scatari [ 13/Oct/11 ]

Snjezana, Please work with admin team to identify the owner for this issue.

Comment by Snjezana Sevo-Zenzerovic [ 18/Nov/11 ]

Assigning to Tom and cc-ing Tim to get further input. While "localhost" needs to remain in the initial default domain shipped in zip distribution in order to make the configuration portable, maybe it would be possible to replace it with fully qualified hostname prior to the point where configuration gets used by remote appclient.

Comment by Tom Mueller [ 19/Nov/11 ]

This looks like something that the ACC needs to handle.

Comment by Tim Quinn [ 19/Nov/11 ]

I disagree that this is the responsibility of the ACC.

[The rest of this notes is IIRC - I am not very familiar with what happens internally in this process... ] One of the first steps a JMS client performs is to obtain a ConnectionFactory, either by explicit look-up using JNDI calls or by injection which itself will use JNDI look-up. The factory object will have been set up to refer to whatever host is specified in the jms-host setting. If that is localhost, then that is how the factory object will be set up, and that is what the client will get.

I think the documentation refers, at least briefly, to the need to configure the jms host's address to refer to the host's actual address if it will be used remotely. But I'm not sure about that.

I'm transferring this to the queuing folks, not because I think there is a bug in JMS or MQ that needs fixing but for them to comment on this.

One other note - Aren't there potential problems if somehow GlassFish did automatically place the system's real name into this configuration setting and then the user tries to run disconnected from the network? I think the attempt to resolve the configured, non-"localhost" name will fail because the system cannot reach a DNS server.

Comment by Satish Kumar [ 21/Nov/11 ]

The value of jms-host.host is defaulted to localhost so that it can work with the zip installer. Automatically setting this to the actual hostname is not recommended as Tim has also pointed out. A note to the effect that the user will need to manually configure this if required, is mentioned in the documentation.

Comment by mkarg [ 22/Nov/11 ]

I have to object. This issue is not talking about ZIP bundles but about solely the Windows Installer bundle. In the Windows world, people are used to get jumpstart defaults instead of reading docs since the installer is an active software that can use the complete Windows API - including the functions for checking hostnames and changing XML files. Please forget (just for one minute) all your technical constraints and watch the scene from the administrator's view. After having run the windows installer, you force him to fiddle with the JMS settings to manually provide the host name - yes, of exactly that host that just did run the installer. And, EVERYONE does that in THE EXACTLY SAME WAY. My goodness, why shall it be so impossible for the installer to just do that automatically? I mean, is it so unbelievable hard to change the installer code in a way that just replaces localhost by %HOSTNAME%? Sorry, but this is just ridiculous. I do not see anything "invalid" in this bug report and expect a solution in the next release to stop all the GF competitors out there from loughing out loudly!





[GLASSFISH-16627] delete-log-level command to be implemented and rest api access required Created: 13/May/11  Updated: 14/Mar/12  Resolved: 19/Oct/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 4.0
Fix Version/s: 3.1.2_b08

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

Issue Links:
Dependency
blocks GLASSFISH-16190 Logger Level screen cannot specify cu... Resolved

 Description   

delete-log-levels cli command implementation required and also rest api implementation for console access is required.

After implementing the cli command the bug needs to be transferred to rest_interface team.



 Comments   
Comment by srinik76 [ 13/May/11 ]

Admin console require option to delete loggers and add custom loggers

Comment by naman_mehta [ 18/May/11 ]

This one is duplicate of 16337. Closed 16337.

delete-log-levels commands are available from logging side. Made required check-ins for the same.
trunk/v3/core/logging/src/main/java/com/sun/enterprise/server/logging/commands/DeleteLogLevel.java

Added bug 16395 for REST provisioning.

Comment by naman_mehta [ 19/Oct/11 ]

Reopen this issue for 3.1.2 fix...

Comment by naman_mehta [ 19/Oct/11 ]

Already made check-ins for 3.1.2 so closing with fix version 3.1.2_b08.





[GLASSFISH-16582] GFLauncher is not fomatting record properly same as other log records Created: 09/May/11  Updated: 19/Oct/11  Resolved: 19/Oct/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.2_b08

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


 Description   

I noticed in server.log some messages (the ones logged by
GFLauncherLogger) have a different format:

[#|2011-04-29T12:38:53.104+1000|INFO|glassfish3.2|org.jvnet.hk2.osgiadap
ter|_ThreadID=17;_ThreadName=Thread-1;|Stopping
com.sun.enterprise.v3.server.AppServerStartup@691ccf|#]

29/04/2011 12:38:53 PM
com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:

GFLauncherLogger's messages have different separators ([#| at the
beginning, | between files and enclosing |#] and the date format is
different.



 Comments   
Comment by naman_mehta [ 09/May/11 ]

Set formatter in GFLauncherLogger.

Sending admin/launcher/pom.xml
Sending admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncherLogger.java
Sending core/logging/src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java
Transmitting file data ...
Committed revision 46749.

Comment by naman_mehta [ 19/Oct/11 ]

Opening for 3.1.2 fix...

Comment by naman_mehta [ 19/Oct/11 ]

Already made check-ins for 3.1.2 so closing with fix version 3.1.2_b08.





[GLASSFISH-16566] rotate-log is failing when user deletes log file by mistake Created: 05/May/11  Updated: 19/Oct/11  Resolved: 19/Oct/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.2_b08

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


 Description   

It's original bug from sustaining for previous release. Need to do similar fix on existing workspace.

https://bug.oraclecorp.com/pls/bug/webbug_print.showbug?c_rptno=12310360

User will delete log file by mistake while glassfish is running and now user tries to rotate log and fails there.



 Comments   
Comment by naman_mehta [ 05/May/11 ]

Committed revision 46717.

Comment by naman_mehta [ 19/Oct/11 ]

Reopening for 3.1.2

Comment by naman_mehta [ 19/Oct/11 ]

Already made check-ins for 3.1.2 so closing with fix version 3.1.2_b08.





Generated at Fri Sep 04 22:22:05 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.