[GLASSFISH-19162] Loader_<xxx> directories in generated/jsp application folders are not deleted after server shutdown Created: 16/Oct/12  Updated: 14/Mar/13  Resolved: 16/Oct/12

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b56_ms5

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

Linux


Issue Links:
Related
is related to GLASSFISH-11483 Admin GUI "Disk Space Memory Leak" (G... Resolved

 Description   

This is basically the same issue that was reported in http://java.net/jira/browse/GLASSFISH-11483. It can be duplicated using the test.war file attached in that issue. Though it was flagged as resolved but I'm seeing the same bug occurring again in the latest stable release (3.1.2.2).



 Comments   
Comment by Hong Zhang [ 16/Oct/12 ]

Yes, I was able to reproduce this issue in 3.1.2.2. This seems to be a regression in 3.1.* code base. The classloader (and related directories) was cleaned up at a later stage of the lifecycle, but that stage was not invoked as part of the server shutdown.

This issue was already fixed in GlassFish 4.0 (the classloader cleanup is now happening as part of the server shutdown).

Comment by Hong Zhang [ 16/Oct/12 ]

(Accidentally removed the affected version, put it back)

Comment by kksineric_hotmail [ 17/Oct/12 ]

Thanks for verifying the issue. Do you have an estimate on when a stable release for Glassfish 4 will be out?

Comment by Hong Zhang [ 17/Oct/12 ]

The official GlassFish 4.0 release is targeted for Q2 of 2013:
https://wikis.oracle.com/display/GlassFish/GlassFishV4Schedule

But you can get the weekly promoted builds here:
http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/

Comment by luisjotapepe [ 13/Mar/13 ]

Hello guys. I am currently using GlassFish Server Open Source Edition 3.1.2.2 (build 5). My problem is that this is already in Prod environment and we just noticed this. It is happening for domain and clusters across all nodes ie: /usr/local/glassfish3/glassfish/nodes/localhost-domain1/<clustername>/generated/jsp/

What is safe to delete from here? and what not?

Kindly appreciate your help

Comment by kksineric_hotmail [ 14/Mar/13 ]

As a workaround, we added the code below to the "asadmin" batch file, right before 'exec "$JAVA" -jar "$AS_INSTALL_LIB/admin-cli.jar" "$@"'. This will remove the generated folder upon startup.

if [ "$1" = "start-domain" ]; then
echo "Removing generated folder..."
rm -rf ../domains/domain1/generated
sleep 2
fi





[GLASSFISH-19121] NoSuchFieldError in jpa 9539 se test Created: 03/Oct/12  Updated: 03/Oct/12  Resolved: 03/Oct/12

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

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

RHL 5.0 and JDK1.7.0_03-64


Attachments: Zip Archive 9539.zip    

 Description   

NoSuchFieldError in jpa 9539 se test

glassfish-4.0-b56.zip

appserver-sqe/pe/ejb/ejb30/issue/9539
The test failed to insert data with image on se_j2db, b56
http://javaweb.us.oracle.com/net/asqe-logs/export1/4.0/Results/build56/core/das/output/ejb30_issue_se_j2db.output
[java] java.lang.NoSuchFieldError: TRACE



 Comments   
Comment by sherryshen [ 03/Oct/12 ]

Attached 9539.zip has test source.

The test is based on the issue in
http://java.net/jira/browse/GLASSFISH-9539
The test passed on b55
http://javaweb.us.oracle.com/net/asqe-logs/export1/4.0/Results/build55/core/das/output/ejb30_issue_se_j2db.output

To reproduce the issue in sqe core test env on das
$ cd appserver-sqe/pe/ejb/ejb30/issue/9539
$ ant all_se
Please reference core instruction for env
http://aseng-wiki.us.oracle.com/asengwiki/display/ASQA/4.0+Core+Test+Instructions

Comment by mtaube [ 03/Oct/12 ]

This target is picking up a log4j jar in the classpath. I don't know what's in db.root or SPS_HOME, but I suspect it is in one of those two places.

The new version of hibernate-validator requires log4j if it is present to be version 1.2.12 or newer.

<target name="run_se" depends="init-common">
<java classname="ejb30.issue.TestClient" fork="true">
<classpath>
<pathelement location="classes/META-INF"/>
<pathelement location="classes"/>
<fileset dir="$

{env.S1AS_HOME}

/modules">
<include name="*/.jar"/>
</fileset>
<fileset dir="$

{db.root}

/lib">
<include name="*/.jar"/>
</fileset>
<fileset dir="$

{env.SPS_HOME}

/lib">
<include name="*/.jar"/>
</fileset>
</classpath>
<arg value="$

{testsuite.id}

SE-J2DB:"/>
</java>
</target>

Comment by sherryshen [ 03/Oct/12 ]

Thank Mason and Mitesh for the analysis.
The offending log4j is coming from appserver-sqe/lib/jalopy/log4j-1.2.6.jar.
The test passed after build.xml is modified to exclude old version of log4j.

Index: build.xml
===================================================================
RCS file: /m/jws/appserver-sqe/pe/ejb/ejb30/issue/9539/build.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -c -r1.7 -r1.8

      • build.xml 2010/01/27 17:40:11 1.7
      • build.xml 2012/10/03 23:45:40 1.8
        ***************
      • 122,129 ****
        <fileset dir="$ {db.root}/lib">
        <include name="*/.jar"/>
        </fileset>
        ! <fileset dir="${env.SPS_HOME}/lib">
        <include name="*/.jar"/>
        </fileset>
        </classpath>
        <arg value="${testsuite.id}SE-J2DB:"/>
        — 122,132 ----
        <fileset dir="${db.root}

        /lib">
        <include name="*/.jar"/>
        </fileset>
        ! <fileset dir="$

        {env.SPS_HOME}/lib/drivers">
        <include name="*/.jar"/>
        + </fileset>
        + <fileset dir="${env.SPS_HOME}

        /lib">
        + <include name="reporter.jar"/>
        </fileset>
        </classpath>
        <arg value="$

        {testsuite.id}

        SE-J2DB:"/>





[GLASSFISH-19104] NullPointerException was thrown out when delete a nonexistent lifecycle module Created: 25/Sep/12  Updated: 25/Sep/12  Resolved: 25/Sep/12

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

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

Windows XP, Windows 7


Attachments: Text File GLASSFISH-19104.patch    
Tags: admin

 Description   

[Bug Description]
When executed "delete-lifecycle-module" command by specifing a name that does not exist, it will be failed and the NullPointerException was thrown out.

[Operations]
STEP1 Start the domain

asadmin> start-domain
Waiting for domain1 to start ..............................
Successfully started the domain : domain1
domain Location: D:\glassfish3\glassfish\domains\domain1
Log File: D:\glassfish3\glassfish\domains\domain1\logs\server.log
Admin Port: 4848
Command start-domain executed successfully.

STEP2. Execute the delete-lifecycle-module to delete a lifecycle-module that does not exist.

asadmin> delete-lifecycle-module not_exist
remote failure: User is not authorized for this command
java.lang.NullPointerException
Command delete-lifecycle-module failed.

[affected versions]
1 4.0_b54
2 Glassfish's trunk until 2012/09/25



 Comments   
Comment by zhouronghui [ 25/Sep/12 ]

The patch of GLASSFISH-19104

Comment by zhouronghui [ 25/Sep/12 ]

Dear Tom

I think it's caused by the NULL check was omitted
in DeleteLifecycleModuleCommand#getAccessChecks,
and I made a patch for this issue and attached to
the ISSUE. Would you please check it?

PS:
The NullPointerException was thrown out and
the stack trace in server.log was as follows:

 
[#|2012-09-25T15:46:58.318+0900|SEVERE|44.0|javax.enterprise.system.tools.admin.security.authorization|_ThreadID=12;_ThreadName=admin-listener(1);|org.glassfish.deployment.admin.DeleteLifecycleModuleCommand
java.lang.NullPointerException
	at java.net.URI$Parser.parse(URI.java:3004)
	at java.net.URI.<init>(URI.java:577)
	at java.net.URI.create(URI.java:839)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.resourceURIFromAccessCheck(CommandSecurityChecker.java:244)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.checkAccessRequired(CommandSecurityChecker.java:189)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.authorize(CommandSecurityChecker.java:139)
~omitted~
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
	at java.lang.Thread.run(Thread.java:662)
|#]
Comment by Hong Zhang [ 25/Sep/12 ]

As Tim helped make this part of the security changes, I will let Tim take a look to see if the attached patch is the best place to fix (or should the NPE check made in CommandSecurityChecker.resourceURIFromAccessCheck so other similar code paths are covered as well).

Comment by Tim Quinn [ 25/Sep/12 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 56123
Author: tjquinn
Date: 2012-09-25 15:54:10 UTC
Link:

Log Message:
------------
Fix for 19104.

The code which prepares the access check did not adequately protect against a null resource name being used (which happens if the specified life cycle module does not exist).

Revisions:
----------
56123

Modified Paths:
---------------
trunk/main/nucleus/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeleteLifecycleModuleCommand.java





[GLASSFISH-19093] Avoid use deprecated Habitat.getComponent API Created: 20/Sep/12  Updated: 21/Sep/12  Resolved: 21/Sep/12

Status: Resolved
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 4.0_b55
Fix Version/s: 4.0_b56_ms5

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


 Description   

There is a still a call to Habitat.getComponent in AbstractOSGiDeployer. We need to remove this.



 Comments   
Comment by Sanjeeb Sahoo [ 20/Sep/12 ]

Sending osgi-javaee-base/RELEASENOTE.txt
Sending osgi-javaee-base/src/main/java/org/glassfish/osgijavaeebase/AbstractOSGiDeployer.java
Transmitting file data ..
Committed revision 56058.

Comment by Sanjeeb Sahoo [ 21/Sep/12 ]

Integrated osgi-javaee-base:1.0.5 in svn #56068





[GLASSFISH-19092] [osgi-javaee-base] Exceptions are not always logged Created: 20/Sep/12  Updated: 21/Sep/12  Resolved: 20/Sep/12

Status: Resolved
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 4.0_b55
Fix Version/s: 4.0_b56_ms5

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


 Description   

Recently there was a NoSuchMethodError like this, but it never got logged in server.log.

java.lang.NoSuchMethodError: org.jvnet.hk2.component.Habitat.getComponent(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Object;
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.getReport(AbstractOSGiDeployer.java:146)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:119)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.OSGiContainer.redeploy(OSGiContainer.java:113)
at org.glassfish.osgijavaeebase.OSGiContainer.access$500(OSGiContainer.java:61)
at org.glassfish.osgijavaeebase.OSGiContainer$DeployerAddedThread.run(OSGiContainer.java:305)|#]



 Comments   
Comment by Sanjeeb Sahoo [ 20/Sep/12 ]

ss141213@Sahoo:~/WS/ff/trunk/module/osgi-javaee-base$ svn commit -m "GLASSFISH-19092: Exceptions are not always logged" src/main/java/org/glassfish/osgijavaeebase/JavaEEExtender.java
Sending src/main/java/org/glassfish/osgijavaeebase/JavaEEExtender.java
Transmitting file data .
Committed revision 56057.

Comment by Sanjeeb Sahoo [ 21/Sep/12 ]

Integrated osgi-javaee-base:1.0.5 in svn #56068





[GLASSFISH-19089] deploying @WebServiceProvider causes NPE in EjbSecurityComponentInvocationHandler Created: 19/Sep/12  Updated: 20/Sep/12  Resolved: 20/Sep/12

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b55
Fix Version/s: 4.0_b56_ms5

Type: Bug Priority: Major
Reporter: Lukas Jungmann Assignee: amy.yang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive ejb-npe.zip    
Issue Links:
Related
is related to GLASSFISH-19088 deployment fails for EJB based ws pro... Resolved

 Description   

-have attached ejb module containing one simple @Stateless @WebServiceProvider bean
-deploy it

=>

SEVERE: SECEJB9000: Exception while running pre-invoke
java.lang.NullPointerException
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:79)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:149)
at com.sun.ejb.containers.EjbEndpointFacadeImpl.startInvocation(EjbEndpointFacadeImpl.java:108)
at org.glassfish.webservices.EjbRuntimeEndpointInfo.prepareInvocation(EjbRuntimeEndpointInfo.java:184)
at org.glassfish.webservices.EjbRuntimeEndpointInfo.initRuntimeInfo(EjbRuntimeEndpointInfo.java:344)
at org.glassfish.webservices.WebServiceEjbEndpointRegistry.registerEndpoint(WebServiceEjbEndpointRegistry.java:127)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1173)
at com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:214)
at com.sun.ejb.containers.BaseContainerFactory.initContainer(BaseContainerFactory.java:67)
at com.sun.ejb.containers.StatelessContainerFactory.createContainer(StatelessContainerFactory.java:61)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
...

WARNING: Unexpected error in EJB WebService endpoint post processing
org.glassfish.api.invocation.InvocationException
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:83)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:149)
at com.sun.ejb.containers.EjbEndpointFacadeImpl.startInvocation(EjbEndpointFacadeImpl.java:108)
at org.glassfish.webservices.EjbRuntimeEndpointInfo.prepareInvocation(EjbRuntimeEndpointInfo.java:184)
at org.glassfish.webservices.EjbRuntimeEndpointInfo.initRuntimeInfo(EjbRuntimeEndpointInfo.java:344)
at org.glassfish.webservices.WebServiceEjbEndpointRegistry.registerEndpoint(WebServiceEjbEndpointRegistry.java:127)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1173)
at com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:214)
at com.sun.ejb.containers.BaseContainerFactory.initContainer(BaseContainerFactory.java:67)
at com.sun.ejb.containers.StatelessContainerFactory.createContainer(StatelessContainerFactory.java:61)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
...

problem seems to be that when BaseContainer.initializeHome is called, SecurityManager (EJBSecurityManager) may still be null - see BaseContainerFactory.initContainer()



 Comments   
Comment by amy.yang [ 20/Sep/12 ]

I'm running tests for the fix. Will check in when all of them passed.

Comment by amy.yang [ 20/Sep/12 ]

Project: glassfish
Repository: svn
Revision: 56044
Author: amy.yang
Date: 2012-09-20 06:22:05 UTC
Link:

Log Message:
------------
Fix for http://java.net/jira/browse/GLASSFISH-19089. call initializeHome() after EJBSecurityManager was created

Revisions:
----------
56044

Modified Paths:
---------------
trunk/main/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainerFactory.java





[GLASSFISH-18929] Executing "get-client-stubs" commands related to the applications without client files can be successful. Created: 23/Jul/12  Updated: 26/Oct/12  Resolved: 15/Oct/12

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 4.0_b45
Fix Version/s: 4.0_b56_ms5

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

Windows Xp


Attachments: Zip Archive GLASSFISH-18929_REVISED_SOURCE.zip     File Jar.ear     File War.ear    
Issue Links:
Related
is related to GLASSFISH-7948 deploy command should fail when retri... Resolved

 Description   

[Bug Description]
"get-client-stubs" command is used for getting JAR file from an application client module or an application containing the application client module to the local directory. But the result shows "Command get-client-stubs executed successfully." even the appointed application has no client module and nothing was downloaded to local. The output "Command get-client-stubs executed successfully." may cause users' misunderstanding.

[Operations]
1.Deploy two ears:Jar.ear(has client files) and War.ear(has no client files)
execute:
asadmin deploy Jar.ear
asadmin deploy War.ear

2.create "temp" folder under c:\ ,make sure c:\temp is exsts.

3.execute:
asadmin get-client-stubs --appname Jar C:┬ątemp
>Command get-client-stubs executed successfully. -->this is common

>asadmin get-client-stubs --appname War C:┬ątemp
Command get-client-stubs executed successfully. -->this is uncommon

[Modify plan]
I think if user appointed an application without client file module, executing result should be:
"remote failure: Invalid application name:

{appName}

.
Command get-client-stubs failed."

[Affected versions ]
1 4.0_b45
2 gf's trunk until 2012/07/23



 Comments   
Comment by Hong Zhang [ 10/Oct/12 ]

I don't know if it's more friendly to fail the command or continue to make the command successful for this case. But we certainly could add an additional message saying this command is not applicable for this application or there are no client stubs to retrieve for this application.

Jeremy: do you want to look into fixing this one?

Comment by Jeremy_Lv [ 10/Oct/12 ]

Hong:
yes, I have attach my revised source to the JIRA. Please check it.

Comment by Jeremy_Lv [ 10/Oct/12 ]

Some comments about my modification:
the original java resource(GetClientStubsCommand.java):

        if (matchingApp == null) {
            report.failure(logger, localStrings.getLocalString(
                getClass(),
                "get-client-stubs.noSuchApp",
                "Application {0} was not found",
                new Object[] {appname}));
            return;
        }

The code above is useless because the value of matchingApp can't be null. so I move this judgement to the method called preAuthorization in GetClientStubsCommand.java when the appname useless. what's more, I have judged if the application don't contains stub client in the methos called excute in GetClientStubsCommand.java.

Comment by Hong Zhang [ 10/Oct/12 ]

Jeremy: thanks for looking into this.

Tim would be a better person to review this change, so I am assigning this issue to him for him to take a look at the patch.

Comment by Tim Quinn [ 10/Oct/12 ]

A few comments:

1. I would suggest slightly different wording for the message:

there are no files to retrieve for application

{0}

The reason is that the downloaded files can be more than just client stubs. For a client, they can include libraries, the client JAR itself, etc. I know that the command name itself refers to client stubs, but for a long time the command has downloaded more than just client stubs. Changing the command name is difficult for reasons of backward compatibility, but let's not limit ourselves to stubs in the message.

2. I'm glad to see that the revision checks to see if there are any downloadable artifacts, rather than checking to see if the app is or contains an app client. For example, users can deploy an EJB module with stubs generation turned on and should be able to retrieve those stubs, even though the EJB module does not contain a client module.

3. Is get-client-stubs.noStubApp already defined in the strings file or do you need to add that? It was not in the patch you attached.

4. I agree with Hong's comment about reporting success rather than failure, even if there are no files to download.

5. We should do something similar with the --retrieve option on the deploy command. If the user deploys an app that creates no downloadable files but specifies --retrieve, we should include an informational message back to the user that there were no files to download for the app.

Comment by Jeremy_Lv [ 11/Oct/12 ]

1. I would suggest slightly different wording for the message:

there are no files to retrieve for application

Unknown macro: {0}

The reason is that the downloaded files can be more than just client stubs. For a client, they can include libraries, the client JAR itself, etc. I know that the command name itself refers to client stubs, but for a long time the command has downloaded more than just client stubs. Changing the command name is difficult for reasons of backward compatibility, but let's not limit ourselves to stubs in the message.

2. I'm glad to see that the revision checks to see if there are any downloadable artifacts, rather than checking to see if the app is or contains an app client. For example, users can deploy an EJB module with stubs generation turned on and should be able to retrieve those stubs, even though the EJB module does not contain a client module.

3. Is get-client-stubs.noStubApp already defined in the strings file or do you need to add that? It was not in the patch you attached.

4. I agree with Hong's comment about reporting success rather than failure, even if there are no files to download.

I have fix my source under your comments.please review them.


5. We should do something similar with the --retrieve option on the deploy command. If the user deploys an app that creates no downloadable files but specifies --retrieve, we should include an informational message back to the user that there were no files to download for the app.c

I add an INFO message to server.log if there are no files to retrieve when deploy an application but not set the message to the console. The reason is because there's only one message can be list on command.

I try to set the admin console show as
"there are no files to retrieve for this application.
Application deployed with name appname
Command deploy executed successfully."
But it is difficult for me because the method about setting the message to the admin console can be useful for the last time.
for example:The second time to set the Message can overwrite the first one.

Because of the reason above, I decided to write the message like "there are no files to retrieve for this application." in server.log

Thanks.

Comment by Jeremy_Lv [ 12/Oct/12 ]

The latest changes about this issue(update by 2012/10/12)

Comment by Jeremy_Lv [ 12/Oct/12 ]

All of the QL tests passed.

Comment by Jeremy_Lv [ 15/Oct/12 ]

All of the dev tests passed.
ready to check in:
Sending nucleus\deployment\admin\src\main\java\org\glassfish\deployment\admin\DeployCommand.java
Sending nucleus\deployment\admin\src\main\java\org\glassfish\deployment\admin\GetClientStubsCommand.java
Sending nucleus\deployment\admin\src\main\java\org\glassfish\deployment\admin\LocalStrings.properties
Transmitting file data ..
Committed revision 56466.

Comment by Jeremy_Lv [ 15/Oct/12 ]

has been implemented in the version of GF4.0_b56_ms5.





Generated at Thu May 28 15:30:26 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.