[GLASSFISH-11088] [embedded] Stopping GFv3 leaves several daemon threads running Created: 18/Nov/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: bavik78 Assignee: sakshi.jain
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: Java Source File GlassFish11088.java     HTML File jstack    
Issue Links:
Dependency
depends on GLASSFISH-16873 The transaction-manager timer thread ... Resolved
Issuezilla Id: 11,088
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude, 3_1-next_release-note-added, 3_1-next_release-notes, 3_1_1-next, 3_1_1-scrubbed

 Description   

After stopping the server there is a bunch of daemon threads:
transaction-manager, AutoDeployer, DynamicReloader, pool-X-thread-Y.

Most of these threads (all except of some instances of pool-X-thread-Y) are
never finished until VM exit.
In the use case, when embedded GF is restarted many times during main
application session this can cause "Out-Of-Memory" problem and other side effects.



 Comments   
Comment by bavik78 [ 18/Nov/09 ]

2 CC added

Comment by dochez [ 18/Nov/09 ]

not a showstopper, few deamon threads hanging around after server.close()

Comment by kumara [ 07/Dec/09 ]

Setting target release for unresolved issues submitted on v3 release to the next release. Not changing
issues submitted on v2.x release because they might not apply to v3.next release.

Comment by sirajg [ 08/Jul/10 ]

transfer

Comment by sirajg [ 09/Jul/10 ]

After a start, deploy, stop, I see these threads (Thread.getAllStackTraces) :
Keep-Alive-Timer
Reference Handler
pool-8-thread-1
pool-1-thread-1
pool-6-thread-1
pool-7-thread-1
pool-4-thread-1
DynamicReloader
pool-2-thread-1
transaction-manager
AutoDeployer
Signal Dispatcher
pool-10-thread-1
pool-9-thread-1
pool-5-thread-1
pool-3-thread-1

Comment by Bhavanishankar [ 10/Oct/10 ]

This issue is reproducible in v3.1 as well.

This is a core issue in glassfish, not particularly an embedded issue. But the
embedded users will have the impact. Bunch of threads belonging to different
modules remain even after GlassFishRuntime.shutdown(), so we need to go through
each of them and see why they remain.

May not be able to fix this for v3.1, hence updating the keyword.

Comment by Bhavanishankar [ 01/Jun/11 ]

Simple testcase.

Instructions to run the test case:

1. Compile it:

javac -g -cp $S1AS_HOME/lib/embedded/glassfish-embedded-static-shell.jar GlassFish11088.java

2. Run it

java -cp $S1AS_HOME/lib/embedded/glassfish-embedded-static-shell.jar:. GlassFish11088

3. When it prompts "GlassFish has been stopped and disposed. After taking jstack, press any key to quit this program", please take the jstack.

In the jstack you will see number of glassfish threads still running. (I have attached the jstack output that I got with this testcase)

Once this issue is fixed, there should not be any running glassfish threads in the jstack.

Comment by brdjcx [ 07/Jun/11 ]

Bug two years old and "No work has yet been logged on this issue."?

May be tolerable on Unix/Mac but a stopper on Windows. Those stray processes hold files open that IDEs/maven want to delete (mvn clean). The workaround on Windows goes like this: stop GF, stop Netbeans, kill the strays with TaskManager, and start everything back up and wait, wait, wait. Dozens of times per hour. NOT good.

Comment by Tim Quinn [ 08/Jun/11 ]

partial fix checked into the 3.1.1 branch and the trunk. The rev for the 3.1.1 branch is

Project: glassfish
Repository: svn
Revision: 47365
Author: tjquinn
Date: 2011-06-08 16:02:35 UTC
Link:

Here is the full check-in log for the trunk check-in. The files changes and the diffs are the same for both check-ins.

Project: glassfish
Repository: svn
Revision: 47366
Author: tjquinn
Date: 2011-06-08 16:06:58 UTC
Link:

Log Message:
------------
Partial fix for 11088

The dynamic reloader and auto-deployer daemon threads were not stopped as part of shutdown. This caused problems during embedded use.

These changes correct where the "cancel requested" indicator is cleared.

Tests: autodeploy and "touch .reload" manual tests

Revisions:
----------
47366

Modified Paths:
---------------
trunk/v3/deployment/autodeploy/src/main/java/org/glassfish/deployment/autodeploy/AutoDeployService.java
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/server/DynamicReloadService.java
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/server/DynamicReloader.java
trunk/v3/deployment/autodeploy/src/main/java/org/glassfish/deployment/autodeploy/AutoDeployer.java

Comment by Bhavanishankar [ 14/Jun/11 ]

Apart from the simple start/stop of embedded GlassFish, we will also have to check which threads keep running in the start/deploy/undeploy/stop scenario.

To do that, the existing devtest can be used like this:

1. cd v3/tests/embedded/cdi_ejb_jpa (in your 3.1.1 workspace).

2. Modify the test a bit so that it gives a chance to take the jstack/jmap before it exits, like this:


--- src/test/java/org/glassfish/tests/embedded/cdi_ejb_jpa/BasicCDITest.java    (revision 47440)
+++ src/test/java/org/glassfish/tests/embedded/cdi_ejb_jpa/BasicCDITest.java    (working copy)
@@ -105,6 +105,11 @@
 
         glassfish.dispose();
 
+               System.out.println("GlassFish has been stopped and disposed. " +
+                                   "After taking jstack, press any key to quit this program");
+
+                       new BufferedReader(new InputStreamReader(System.in)).readLine();
+
     }   
 
     private void get(String urlStr, String result) throws Exception {

3. Set S1AS_HOME to your 3.1.1 glassfish image (eg., /space/image/glassfish3/glassfish)

4. Execute the test : mvn -P run-with-static-shell clean verify

5. Once the test finishes and prompts "GlassFish has been stopped and disposed. After taking jstack, press any key to quit this program", please take the jstack/jmap of the "SurefireBooter" process.

Comment by Satish Kumar [ 20/Jun/11 ]

Out of the threads mentioned in the jstack, the following have been resolved-

DynamicReloader
AutoDeployer

The following threads are started by the event notification framework (EventsImpl) and return eventually after notifying the event listeners. This is taking a bit of time 30-60 secs before they return. But these are not long running threads.

pool-2-thread-1
pool-3-thread-1
pool-4-thread-1
pool-5-thread-1

transaction-manager:
The jta module starts a timer service from JavaEETransactionManagerSimplified which is not stopped during appserver shutdown. I have created a separate issue to track this - 16873.

Comment by Satish Kumar [ 21/Jun/11 ]

Linking this issue to GF 16873...

Comment by scatari [ 25/Jun/11 ]

Pre-approving for 3.1.1 as this is needed for embedded.

Comment by Satish Kumar [ 06/Jul/11 ]

marking this for the next release since this issue is still waiting for 16873 which is unlikely to get fixed for 3.1.1

Comment by Bhavanishankar [ 01/Dec/11 ]

.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-17179] Security configuration files are not copied when embedded container is started using EJBContainer#createEJBContainer Created: 10/Aug/11  Updated: 01/Dec/11

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: atomicknight Assignee: sakshi.jain
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 6u26, Windows 7 Professional 64-bit, glassfish-embedded-all 3.1.1 Maven artifact


Tags: 3_1_2-exclude, ejb, embedded

 Description   

When the embedded container is started using javax.ejb.embeddable.EJBContainer#createEJBContainer, security files like the keystores (e.g. cacerts.jks) are not being copied. This appears to be a regression from 3.1, as these files are copied correctly by the 3.1 version of the glassfish-embedded-all artifact.

The problem seems to be caused by revision 47307, which introduced the use of com.sun.enterprise.security.EmbeddedSecurity when determining whether to copy the files. The root cause of the problem is that the org.glassfish.server.ServerEnvironmentImpl that is constructed and checked by com.sun.enterprise.security.embedded.EmbeddedSecurityUtil has a RuntimeType of "DAS" rather than "EMBEDDED."

In my particular case, there is an additional CA certificate that needs to be added to the CA certificate keystore. Attempting to override the javax.net.ssl.trustStore property from outside the container (whether setting it as a JVM property or passing it as an entry in the Properties object passed to createEJBContainer) doesn't work because the property is being set programmatically from within the embedded container runtime.

I'm starting the container with the following properties set:

org.glassfish.ejb.embedded.glassfish.installation.root=/path/to/install/root
org.glassfish.ejb.embedded.glassfish.instance.root=/path/to/install/root/domains/domain1
org.glassfish.ejb.embedded.glassfish.configuration.file=/path/to/install/root/domains/domain1/config/domain.xml
org.glassfish.ejb.embedded.glassfish.keep-temporary-files=true

My modified version of cacerts.jks lives in /path/to/install/root/domains/domain1/config/. However, the version of cacerts.jks actually being used (i.e. in the temporary folder) is the version included with the glassfish-embedded-all artifact.



 Comments   
Comment by Cheng Fang [ 10/Aug/11 ]

assign to security team to check why EmbeddedSecurityUtil has a RuntimeType of "DAS" rather than "EMBEDDED."

Comment by Nithya Ramakrishnan [ 24/Aug/11 ]

This seems to happen because type argument is not being passed as an argument when the Embedded EJB container is created. In ServerEnvironmentImpl, the serverType seems to default to DAS, since the typeString argument is null. Transferring this issue to the Embedded team for fixing this.

Comment by Bhavanishankar [ 14/Nov/11 ]

It is the correct behaviour of embedded GlassFish to return the serverType as DAS. Internal code should never depend on whether the server is running in EMBEDDED mode or standalone mode.

Comment by Bhavanishankar [ 01/Dec/11 ]

assigning.





[GLASSFISH-17154] Unable to access role-protected remote bean using maven-embedded-glassfish-plugin Created: 05/Aug/11  Updated: 08/Mar/12

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ljnelson Assignee: sakshi.jain
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive remote-authentication.zip    
Tags: 3_1_2-exclude, community, embedded, security

 Description   

I'm using the maven-embedded-glassfish-plugin to do some integration testing.

I have an .ear file with an ejb.jar file in it. The ejb.jar file contains a single, remote, role-protected EJB in it. This .ear file deploys fine to embedded Glassfish v3.1.1.

Prior to deployment, I use the plugin to set up a user named "scott" with a password "tiger" and assign him to the group "superuser". I get the password in there by using the (recently added, as of Glassfish embedded 3.1.1) --passwordfile option (see http://java.net/jira/browse/GLASSFISH-16277). It is my understanding from looking at the domain.xml that ships as part of embedded-all that default Principal-to-role mapping is turned on. These setup commands, using the AdminMojo, complete normally with an odd-to-decipher but presumably OK SUCCESS message.

In my .ear file Maven project, I have a single unit test that attempts to look up this bean from an embedded Glassfish instance that has been started by the maven-embedded-glassfish-plugin. This lookup fails. The lookup string is correct, as the lookup succeeds if I unprotect the bean by removing the @RolesAllowed annotation.

To perform the lookup, I first do a ProgrammaticLogin. I take care to make sure that the login configuration file is passed as a system property, containing the proper configuration for the default realm. The ProgrammaticLogin of course doesn't actually log anyone in at this point; it just stashes the credentials. This completes normally.

But the lookup fails with a CORBA NO_PERMISSION error.

I'm going to attach a Maven project that demonstrates the issue.



 Comments   
Comment by Bhavanishankar [ 08/Mar/12 ]

assigning to Sakshi.





[GLASSFISH-16916] Unable to restart embedded GlassFish instance once the remoteejb is deployed. Created: 27/Jun/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.1, 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bhavanishankar Assignee: sakshi.jain
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any


Attachments: Text File exception.txt     Java Source File Test.java     Java Source File Test2.java    
Tags: 3_1-next, 3_1-next_release-note-added, 3_1-next_release-notes, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

I have a program which embeds GlassFish like this:

        BootstrapProperties bootstrapProperties = new BootstrapProperties();
        bootstrapProperties.setInstallRoot(System.getenv("S1AS_HOME"));
        GlassFishRuntime glassFishRuntime = GlassFishRuntime.bootstrap(bootstrapProperties);

        GlassFishProperties glassFishProperties = new GlassFishProperties();
        glassFishProperties.setInstanceRoot(System.getenv("S1AS_HOME") + "/domains/domain1");
        GlassFish glassfish = glassFishRuntime.newGlassFish(glassFishProperties);

        glassfish.start();
        String appName = glassfish.getDeployer().deploy(new File("remoteejb.jar"));
        System.out.println("GlassFish started [ " + glassfish + "]");

        glassfish.getDeployer().undeploy(appName);
        glassfish.stop();
        System.out.println("GlassFish stopped");

        glassfish.start();
        appName = glassfish.getDeployer().deploy(new File("remoteejb.jar"));
        System.out.println("GlassFish started [ " + glassfish + "]");

        glassfish.getDeployer().undeploy(appName);
        glassfish.dispose();
        System.out.println("GlassFish disposed");

The above code starts glassfish embedded, deploys a remoteejb application, undeploys the application, stops the server and tries to restart.

But the restart fails with exception in ORB and EJB container, as attached in the exception.txt

To reproduce:

1. Install latest 3.1.1 GlassFish, set S1AS_HOME to this installation.
2. Download remoteejb.jar from GLASSFISH-16546 issue and keep it under /tmp/
3. Download Test.java attachment of this issue (has the same code as I shown above) and keep it under /tmp/
4. Compile and run the test program:

javac -cp $S1AS_HOME/lib/embedded/glassfish-embedded-static-shell.jar Test.java
java -cp $S1AS_HOME/lib/embedded/glassfish-embedded-static-shell.jar:. Test


 Comments   
Comment by Harshad Vilekar [ 30/Jun/11 ]

We are currently reviewing this issue. Restart is not supported in the current ORB implementation. The code doesn't cleanly handle the operation sequence of destroy and then reinitialize. It is going to take us some time for further investigation.

Comment by Harshad Vilekar [ 05/Jul/11 ]

There are issues with cleanup after orb destroy operation. After destroying the old ORB, and creating the new ORB instance, references to older ORB are still lingering around, resulting in the reported exception. For example: com.sun.enterprise.iiop.security.SecIORInterceptor is still holding reference to the old orb. This is going to need more analysis.

As a workaround - If we create a complete new reference to glassFish, then the ORB restart exception is not seen at all. Please see the attached Test2.java.

Note: The test still throws an error: "Exception while loading the app : EJB Timer Service is not available.". That a different issue, not related to orb.

Comment by Bhavanishankar [ 06/Jul/11 ]

Further to the EJB timer issue you have mentioned, there is one more error from EJB container

 "java.lang.RuntimeException: EJB Container initialization error" 

caused due to

 java.lang.RuntimeException: Error while binding JNDI name org.glassfish.tests.embedded.ejb.remoteejb.RemoteEJBInf__3_x_Internal_RemoteBusinessHome__ for EJB : RemoteEJB 

This happens if we stop the first instance without undeploying, like this:


....
        //glassfish.getDeployer().undeploy(appName);
        glassfish.stop();

        glassfish = glassFishRuntime.newGlassFish(glassFishProperties);
        glassfish.start();
        appName = glassfish.getDeployer().deploy(new File("remoteejb.jar"));
...

Comment by Harshad Vilekar [ 08/Jul/11 ]

In the attached test case (Test2.java), we replace stop() by dispose(), and then create a new instance of glassfish. Additional cleanup done by these steps seem to help, and no ORB exception is seen. Changing the category to embedded - Please evaluate the feasibility of implementing the generic cleanup in embedded mode restart sequence.

Related EJB timer issue is tracked in - GLASSFISH-16230. That is not going to be addressed in 3.1.1, adding scrubbed tag to this issue also.

Comment by Bhavanishankar [ 01/Dec/11 ]

assigning.





[GLASSFISH-18585] embedded glassfish: jersey-test does not honor @Singleton and @ManagedBean Created: 20/Aug/11  Updated: 01/Apr/12

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jst Assignee: sakshi.jain
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux + Glassfish.


Attachments: Text File embedded_log.txt     File UsingEmbeddedGlassfish.diff     File UsingExternalGlassfish.diff    

 Description   

I am trying to switch my project to run in Glassfish. The application seems to work, but I have problems with tests. They all seem to fail, as my class, annoted as

import javax.annotation.ManagedBean;
import javax.inject.Singleton;

@Path("/")
@Singleton
@ManagedBean
public class Quoridor {
}

is instantiate more than one per each test run. Could the Jersey framework honor the @Singleton + @ManagedBean annotation as glassfish does?



 Comments   
Comment by jst [ 20/Aug/11 ]

Steps to reproduce:

$ hg clone http://source.apidesign.org/hg/quoridor/
$ cd quoridor/
$ hg up -C accdcc2ab312
$ mvn install

The build fails with: Tests run: 13, Failures: 2, Errors: 6, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Quoridor related projects ......................... SUCCESS [0.265s]
[INFO] Quoridor Library .................................. SUCCESS [1.752s]
[INFO] Quoridor Visual Board ............................. SUCCESS [0.794s]
[INFO] wsdor ............................................. SUCCESS [0.410s]
[INFO] webidor server .................................... FAILURE [49.682s]

Now you can open the quoridor/webidor project in NetBeans place a breakpoint into constructor of Quoridor class and debug for example ChatTest. You should see that the instances of Quoridor class are created multiple times, in spite it is a singleton.

Comment by jst [ 20/Aug/11 ]

Update Please "hg up -C 92bd2090dd5f" as I found out that with compile on save the debugging is broken. I had to disable it completely. With 92bd2090dd5f debugging part of my report works.

Comment by Pavel Bucek [ 23/Aug/11 ]

just my $0.02:

@Singleton and @ManagedBean (and others) should work as expected. I haven't seen your testcase, but Mu guess is that you are trying to access your singleton instance from various tests (@Test annotated methods), which should return (by definition) different instances. Why? Each test currently "restarts" Jersey, reloads all resource methods, providers, etc..

What you could do is try to access your @Singleton annotated class twice from one test method, that should work as you expect.

Comment by jst [ 23/Aug/11 ]

Should you check my usecase you'd find out that there is only single test method in
http://source.apidesign.org/hg/quoridor/file/92bd2090dd5f/webidor/src/test/java/cz/xelfi/quoridor/webidor/resources/ChatTest.java
Still multiple instances are created.

Comment by jbenoit [ 04/Sep/11 ]

I've reproduced your original reported error. To help confirm if problem using embedded glassfish, can you please try using external Glassfish instead of embedded glassfish? I've done so, but I encounter 403 & 404 errors whilest trying to confirm behavior.

Comment by jst [ 05/Sep/11 ]

Good to know the problem has been reproduced. I'll be happy to change my project testing code anyway you suggest. However I am don't have that much experience with application servers, so I don't know how to eliminate embedded glassfish properly.

Comment by jbenoit [ 05/Sep/11 ]

See http://jersey.java.net/nonav/documentation/latest/test-framework.html#d4e1275

I did this:

  • added this <dependency> to quoridor/webidor/pom.xml, at line 57:

<dependency>
<groupId>com.sun.jersey.jersey-test-framework</groupId>
<artifactId>jersey-test-framework-external</artifactId>
<version>$

{jerseyVersion}</version>
<scope>test</scope>
</dependency>

the above <dependency> was added right before:
<dependency>
<groupId>com.sun.jersey.jersey-test-framework</groupId>
<artifactId>jersey-test-framework-embedded-glassfish</artifactId>
<version>${jerseyVersion}

</version>
<scope>test</scope>
</dependency>

then i built and deployed quoridor\webidor\target\webidor-1.19.war to external Glassfish, i.e.

// build webidor-1.19.war
C:\a\fresh\jersey-757\quoridor\webidor>mvn package -Dmaven.repo.local=C:\a\fresh\jersey-757\quoridor\repo -DargLine="-Dhttp.proxyHost=yourProxyHostNameGoesHere" -Dmaven.test.skip=true

// start external Glassfish, already installed into C:\a\fresh\1.8testing dir
// downloaded from http://download.java.net/glassfish/3.1.1/release/glassfish-3.1.1.zip
C:\a\fresh\jersey-757\quoridor>set AS_HOME=C:\a\fresh\1.8testing\glassfish3\glassfish

C:\a\fresh\jersey-757\quoridor>echo %AS_HOME%
C:\a\fresh\1.8testing\glassfish3\glassfish

C:\a\fresh\jersey-757\quoridor>set PATH=%AS_HOME%\bin;%PATH%

C:\a\fresh\jersey-757\quoridor>which asadmin
C:/a/fresh/1.8testing/glassfish3/glassfish/bin/asadmin.bat

// start the domain
C:\a\fresh\jersey-757\quoridor> asadmin start-domain domain1

// deploy webidor-1.19.war
C:\a\fresh\jersey-757\quoridor\webidor> asadmin deploy target\webidor-1.19.war

//run, using proxy behind company firewall:
C:\a\fresh\jersey-757\quoridor>mvn install -Dmaven.repo.local=C:\a\fresh\jersey-757\quoridor\repo -DargLine="-Dhttp.proxyHost=yourProxyHostNameGoesHere" -Djersey.test.containerFactory=com.sun.jersey.test.framework.spi.container.external.ExternalTestContainerFactory -Djersey.test.port=8080

[snip]

-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running cz.xelfi.quoridor.webidor.AllGamesTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.532 sec <<< FAILURE!
Running cz.xelfi.quoridor.webidor.FinishedGameTest
Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.969 sec <<< FAILURE!
Running cz.xelfi.quoridor.webidor.GamesTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.328 sec
Running cz.xelfi.quoridor.webidor.QuoridorTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.641 sec <<< FAILURE!
Running cz.xelfi.quoridor.webidor.resources.ChatTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.515 sec <<< FAILURE!
Running cz.xelfi.quoridor.webidor.UsersTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.547 sec <<< FAILURE!

Results :

Tests in error:
testListGames(cz.xelfi.quoridor.webidor.AllGamesTest): PUT http://localhost:80
80/allgamess/login?name=Jarda&password=heslo returned a response status of 403
testNotLoggedIn(cz.xelfi.quoridor.webidor.FinishedGameTest): GET http://localh
ost:8080/finishedGame/login?id=not-logged-in returned a response status of 404
testCreateAGame(cz.xelfi.quoridor.webidor.FinishedGameTest): PUT http://localh
ost:8080/finishedGame/login?name=Jarda&password=heslo returned a response status
of 403
testResignAGame(cz.xelfi.quoridor.webidor.FinishedGameTest): PUT http://localh
ost:8080/finishedGame/login?name=Jarda&password=heslo returned a response status
of 403
testResignBGame(cz.xelfi.quoridor.webidor.FinishedGameTest): PUT http://localh
ost:8080/finishedGame/login?name=Jarda&password=heslo returned a response status
of 403
testResignForeignGame(cz.xelfi.quoridor.webidor.FinishedGameTest): PUT http://
localhost:8080/finishedGame/login?name=Jarda&password=heslo returned a response
status of 403
testApplicationWadl(cz.xelfi.quoridor.webidor.QuoridorTest): GET http://localh
ost:8080/quoTest/application.wadl returned a response status of 404
testCreateAGame(cz.xelfi.quoridor.webidor.QuoridorTest): PUT http://localhost:
8080/quoTest/login?name=Jarda&password=heslo returned a response status of 403
testCreateAGame(cz.xelfi.quoridor.webidor.resources.ChatTest): PUT http://loca
lhost:8080/context/login?name=Jarda&password=heslo returned a response status of
403
testListUsers(cz.xelfi.quoridor.webidor.UsersTest): PUT http://localhost:8080/
userstest/login?name=Jarda&password=heslo returned a response status of 403

Tests run: 13, Failures: 0, Errors: 10, Skipped: 0

I added webidor/src/main/webapp/WEB-INF/sun-web.xml containing <context-root>, rebuilt and redeployed .war:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">
<sun-web-app error-url="">
<context-root>/webidor-1.19</context-root>
<class-loader delegate="false"/>
<jsp-config>
<property name="classdebuginfo" value="true">
<description>Enable debug info compilation in the generated servlet class</description>
</property>
<property name="mappedfile" value="true">
<description>Maintain a one-to-one correspondence between static content and the generated servlet class' java code</description>
</property>
</jsp-config>
</sun-web-app>

This is where I'd like you to see if you can get your project to work with external Glassfish, such that it avoids these 403/404 errors.

Comment by jst [ 06/Sep/11 ]

I have modified the sources, removed all but one test and I could successfully run the test against externally running glassfish.

Just

$ hg up -C 92bd2090dd5f
$ patch -p1 <UsingExternalGlassfish.diff

and follow the tests described above. The test succeeds.

Comment by jst [ 06/Sep/11 ]

Here is another patch to show that embedded glassfish does not honor @Singleton. You can try:

$ hg up -C 92bd2090dd5f
$ patch -p1 <UsingEmbeddedGlassfish.diff
$ cd webidor
$ mvn install

The test fails with assert in the constructor of the Quoridor class.

Comment by jbenoit [ 26/Sep/11 ]

Regarding your comments:

I have modified the sources, removed all but one test and I could successfully run the test against externally running glassfish.

Just

$ hg up -C 92bd2090dd5f
$ patch -p1 <UsingExternalGlassfish.diff

I don't have "UsingExternalGlassfish.diff" file, here is what i see:

C:\a\fresh\jersey-757>hg up -C 92bd2090dd5f
abort: no repository found in 'C:\a\fresh\jersey-757' (.hg not found)!

C:\a\fresh\jersey-757>cd quoridor

C:\a\fresh\jersey-757\quoridor>hg up -C 92bd2090dd5f
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

C:\a\fresh\jersey-757\quoridor>patch -p1 <UsingExternalGlassfish.diff
The system cannot find the file specified.

C:\a\fresh\jersey-757\quoridor>find . | grep -i UsingExternalGlassfish.diff

Comment by jbenoit [ 30/Sep/11 ]

I see attachments:
UsingEmbeddedGlassfish.diff
UsingExternalGlassfish.diff
but when I execute command it shows error:

C:\a\fresh\jersey-757\2\quoridor>patch -p1 <UsingEmbeddedGlassfish.diff
Hmm... I can't seem to find a patch in there anywhere.

C:\a\fresh\jersey-757\2\quoridor>patch -p1 <UsingExternalGlassfish.diff
Hmm... I can't seem to find a patch in there anywhere.

Comment by jst [ 30/Sep/11 ]

I don't know what can be wrong. Maybe patch does not work well on windows? Try:

$ hg up -C 92bd2090dd5f
$ wget http://java.net/jira/secure/attachment/47163/UsingExternalGlassfish.diff
$ hg import --no-commit UsingExternalGlassfish.diff

These three commands just did the trick for me (on Linux).

Comment by sakshi.jain [ 07/Dec/11 ]

I have been able to run the webidor test using external glassfish.Hence the issue does lie with embedded.
As you said the class annotated as Singleton is instantiated more than once.This is because it is bootstrapping embedded glassfish twice.
Attached herewith is the log which I obtain on running the webidor test.

Comment by sakshi.jain [ 27/Dec/11 ]

Since embedded glassfish was being bootstrapped twice, I declared the Glassfish instance as static so it will bootstrap only once.So after the first test, embedded glassfish would merely stop instead of shutting down, and for the second test it will start again.However, another issue is encountered here which looks like a design issue & we are looking into that.

Comment by Michal Gajdos [ 01/Apr/12 ]

is there any progress on this issue?





[GLASSFISH-18386] Unable to specify absolute path as glassfish.embedded.tmpdir in maven plugin configuration Created: 21/Feb/12  Updated: 08/Mar/12

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.2, 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bhavanishankar Assignee: sakshi.jain
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows



 Description   

In org.glassfish:maven-embedded-glassfish-plugin configuration, if the glassfish.embedded.tmpdir system property is specified like this:

<systemProperties>
    <property>glassfish.embedded.tmpdir=${project.build.directory}/glassfish</property>
</systemProperties>

then all the "\" characters in the absolute path are replaced with EMPTY characters.

Due to this the embedded GlassFish fails to bootstrap.

This happens only on Windows platform.

Community thread : http://java.net/projects/glassfish/lists/users/archive/2012-02/message/382



 Comments   
Comment by Bhavanishankar [ 08/Mar/12 ]

Assigning to Sakshi





[GLASSFISH-18500] embedded GF cannot run two CDI-enabled JSF apps (Exception: Must call associate() before calling activate()) Created: 13/Mar/12  Updated: 15/Mar/12

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1, 3.1.1, 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dansg Assignee: sakshi.jain
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive EmbeddedGf-Jsf-Cdi-broken.zip     Zip Archive EmbeddedGf-Jsf-Cdi-broken.zip    

 Description   

when running two CDI-enabled JSF apps on embedded glassfish and the first app gets called before the second app is deployed, the first app crashes after the second is deployed.

Please see attached project to reproduce this error.

WARNUNG: StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.IllegalStateException: Must call associate() before calling activate()
	at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:200)
	at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:108)
	at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:85)
	at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
	at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
	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:849)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
	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(Unknown Source)
public class EGFTest {
	public static void main(String[] args) throws Exception {
		GlassFishProperties props = new GlassFishProperties(); 
		props.setPort("http-listener", 8080);
		GlassFishRuntime gfruntime =GlassFishRuntime.bootstrap();
		GlassFish gf =  gfruntime.newGlassFish(props);
		gf.start();
		Deployer deployer = gf.getDeployer();
		ScatteredArchive archive = new ScatteredArchive("jsf", ScatteredArchive.Type.WAR,new File("WebContent/"));
		
		deployer.deploy(archive.toURI(),"--name", "jsf", "--contextroot=app1");
		
		String urlApp1 = "http://localhost:8080/app1/faces/index.xhtml";
		String urlApp2 = "http://localhost:8080/app2/faces/index.xhtml";

		// comment this out to get both apps working  
		printPage(urlApp1);
		try {
			System.out.println(urlApp1+" will stop working in 15 seconds");
			Thread.sleep(15000);			
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		deployer.deploy(archive.toURI(),"--name", "jsf2", "--contextroot=app2");
		// app1 is damaged
		printPage(urlApp1);
		//app2 still working
		printPage(urlApp2);
	}

	private static void printPage(String urlStr) throws Exception{
			URL url = new URL(urlStr);
			URLConnection conn = url.openConnection();
			String line;
			BufferedReader reader =new BufferedReader(new InputStreamReader(conn.getInputStream())); 
			 while ((line = reader.readLine()) != null) {
			    System.out.println(line);
			 }
			 reader.close();
	}
}
WebContent/index.xhtml
<!DOCTYPE html>
<html lang="en"
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:ui="http://java.sun.com/jsf/facelets">
    <h:head>
        <title>XHTML page</title>
    </h:head>
    <h:body>
    	<h:outputText value="hello world"/>
     </h:body>  
</html>


 Comments   
Comment by dansg [ 13/Mar/12 ]

seems there is more messed up with WELD in embedded glassfish. I have an EJB-App wich works allone in embedded GF but is broken when deployed with other CDI-enabled apps. No Problems in normal GF.

13.03.2012 10:44:57 com.sun.xml.ws.server.sei.TieHandler createResponse
SCHWERWIEGEND: null
javax.ejb.EJBException
	at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5215)
	at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5113)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4901)
	at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:204)
	at $Proxy199.getReportDescription(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.glassfish.webservices.InvokerImpl.invoke(InvokerImpl.java:82)
	at org.glassfish.webservices.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
	at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:149)
	at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:94)
	at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:961)
	at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:910)
	at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:873)
	at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:775)
	at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
	at org.glassfish.webservices.MonitoringPipe.process(MonitoringPipe.java:142)
	at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
	at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:961)
	at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:910)
	at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:873)
	at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:775)
	at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
	at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:212)
	at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:144)
	at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
	at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:961)
	at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:910)
	at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:873)
	at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:775)
	at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:386)
	at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:640)
	at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:263)
	at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:163)
	at org.glassfish.webservices.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:120)
	at org.glassfish.webservices.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:91)
	at org.glassfish.webservices.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:200)
	at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:131)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
	at com.sun.grizzly.http.servlet.ServletAdapter$FilterChainImpl.doFilter(ServletAdapter.java:1059)
	at com.sun.grizzly.http.servlet.ServletAdapter$FilterChainImpl.invokeFilterChain(ServletAdapter.java:999)
	at com.sun.grizzly.http.servlet.ServletAdapter.doService(ServletAdapter.java:434)
	at com.sun.grizzly.http.servlet.ServletAdapter.service(ServletAdapter.java:384)
	at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
	at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
	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)
Caused by: org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [interface org.jboss.weld.context.ejb.EjbRequestContext]; Bindings: [@javax.enterprise.inject.Any(), @javax.enterprise.inject.Default()]
	at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:707)
	at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:96)
	at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:44)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
	at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
	at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360)
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
	at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:192)
	... 59 more
Comment by Bhavanishankar [ 14/Mar/12 ]

Assigning to Sakshi

Comment by sakshi.jain [ 15/Mar/12 ]

How are you running this test case? I see an ivy.xml, so ant is needed to build it.But build.xml is not present.

Comment by dansg [ 15/Mar/12 ]

added build xml to project. To run unpack, change to dir, type ant





[GLASSFISH-17145] Cannot use deploymentParams to specify application name as documentation suggests Created: 03/Aug/11  Updated: 08/Mar/12

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: ljnelson Assignee: sakshi.jain
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: community, embedded

 Description   

The maven-embedded-glassfish-plugin documentation clearly prefers we use <deploymentParams> wherever possible.

One cannot supply an application name in this manner, however:

<deploymentParams>
<param>--name=foo</param>
</deploymentParams>

This is because the Maven plugin property "name" has a default value. The result is that if you omit it, "myapp" is used instead, and (in the example above) both "foo" and "myapp" are passed as name values to the deployment. This is of course an error and you get a nasty message that says that repeated parameter values (in this case it's probably --name) are not allowed.

The workaround is to simply use the <name> property and to not use a deployment param for this case.



 Comments   
Comment by Bhavanishankar [ 08/Mar/12 ]

Similar to the 'name', the 'context root' can also be specified exclusively using <contextRoot> element of the deploy goal. The exclusive elements should take precedence over what is specified in the <deploymentParams> for backward compatibility reasons.

As a fix, while processing <deployParams> values, the above precedence should be taken care of.

Assigning to Sakshi.

Comment by Bhavanishankar [ 08/Mar/12 ]

assigning to Sakshi





Generated at Fri Jul 03 17:44:12 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.