[GLASSFISH-17289] Application scoped resources are not shown when App is deployed with Preserve Application Scoped Resources checkbox checked. Created: 12/Sep/11  Updated: 20/Jan/12  Resolved: 23/Oct/11

Status: Closed
Project: glassfish
Component/s: jca
Affects Version/s: 3.1.2_b01
Fix Version/s: 3.1.2_b06, 4.0

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

OS: Solaris Sparc
Browser : firefox 3.6.17
GF 3.1.2 b02


Tags: 3_1_2-verified

 Description   

Using GF 3.1.2 promoted b02, while deploying an application with scoped resources bundled in glassfish-resources.xml if check the checkbox "Preserve Application Scoped Resources" in the Deployment page of the Console, the application gets deployed, but the Resources tab displaying the application scoped resources does not show up, and hence one is not able to see the application scoped resources for this App.



 Comments   
Comment by sumasri [ 13/Oct/11 ]

While deploying an app, "Preserve Application Scoped Resources" check box is not required. Hence, removing it from the GUI page.
Committed the changes from GUI to both trunk(Committed revision 50222) and branch 3.1.2(Committed revision 50223).

Anyways, this issue is from the back end..Typically, it should not effect the way it is described in the issue even though we pass the property "Preserve Application Scoped Resources". Hence, transferring it to back end team to look into this.

Comment by Jagadish [ 23/Oct/11 ]

Provided a fix such that the preserveAppScopedResources flag is considered only for "redeploy" or "deploy --force" mode of deployment.

svn log -v -r 50412
branches/3.1.2/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/module/ResourcesDeployer.java

svn log -v -r 50413
trunk/main/appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/module/ResourcesDeployer.java

Comment by shaline [ 20/Jan/12 ]

Verified in GF 3.1.2 b18.





[GLASSFISH-17290] Tuned resources not preserved after redeploying application with "preserveAppScopedResources" checkbox checked. Created: 13/Sep/11  Updated: 20/Jan/12  Resolved: 13/Oct/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2_b01
Fix Version/s: 3.1.2_b06, 4.0

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

OS: Solaris Sparc 10.
Browser : FF 3.6.20
GF :3.1.2 b02


Tags: 3_1_2-verified

 Description   

The application scoped resources which are tuned should be preserved, when the application is redeployed with "preserve Application Scoped Resources" checkbox checked in the Console. But this is not happening.
Steps: deploy a application with glassfish-resources.xml bundled.
After deployment, under application name /Resources tab, select a JDBC connection Pool or a resource and edit it and save it.( Ex: max-pool-size=500)
-Redeploy the application with "preserve Application Scoped Resources" enabled.
--Notice that the updated Resource ( Conn pool) value is not preserved,and is overwritten by the new values.



 Comments   
Comment by sumasri [ 13/Oct/11 ]

Fixed the code in GUI pages to preserve the app scoped resources during redeploy.

Checked in the changes to both trunk(Committed revision 50224) and branch 3.1.2(Committed revision 50225).

Comment by shaline [ 20/Jan/12 ]

verified in GF 3.1.2 b18.





[GLASSFISH-17037] Switching log levels persistently breaks logging service Created: 13/Jul/11  Updated: 18/Jan/12  Resolved: 19/Oct/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1_b11
Fix Version/s: 3.1.2_b06, 4.0

Type: Bug Priority: Critical
Reporter: mkarg Assignee: srinik76
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 64 Bit de_DE


Issue Links:
Duplicate
is duplicated by GLASSFISH-17161 NulllPointerException in GFFileHandle... Resolved
is duplicated by GLASSFISH-18205 Changing a log level via Admin Consol... Resolved
Tags: 3_1-next_release-note-added, 3_1-next_release-notes, 3_1_1-next, 3_1_1-scrubbed

 Description   

In the admin GUI I changed some log levels from INFO to FINEST and enabled logging to console, then restarted GFv3.1.1_b11 and roated the log. Since that the server.log always is nearly empty. Even after switching everything back in the GUI and another restart, GF is no more logging into domain1\logs\server.log. The only information it puts into the log is the list of options used at server start, but nothing more.



 Comments   
Comment by donatasc [ 13/Jul/11 ]

I confirm the same.

Problem occurs also if a new logger is being added via admin console (log levels are not touched). It seems that admin GUI messes up the logging.properties file somehow.

Comment by mkarg [ 14/Jul/11 ]

I was able to workaround that by setting

com.sun.enterprise.server.logging.GFFileHandler INFO

I noticed that due to the messup that one was set to OFF

Comment by naman_mehta [ 26/Jul/11 ]

This issue is reproducible.

When you fresh install glassfish and open logging.properties file from domains/domain1/config folder you can find the following line:

com.sun.enterprise.server.logging.GFFileHandler.level=ALL

Here, com.sun.enterprise.server.logging.GFFileHandler is the FileHandler logger and having log level set as ALL by default.

Due to the log level set to ALL it allows user to write all log messages with any log levels to the server.log file. If you set log level to INFO it logs only INFO messages to server.log file.

Now when you open admin console and go to server-config and logger settings page, you can't find log level ALL there. So com.sun.enterprise.server.logging.GFFileHandler logger value is by default point to OFF in GUI. Now user make any changes to any other logger also and clicks save it sets com.sun.enterprise.server.logging.GFFileHandler logger value to OFF. So after that no data is logged under server.log file.

So remove this property from GUI so user can't allow to set the same. We need FileHandler logger should always point to ALL log level.

Comment by naman_mehta [ 26/Jul/11 ]

Assigning to admin_gui team.

Comment by Anissa Lam [ 26/Jul/11 ]

Target this for release after 3.1.1.

Comment by mkarg [ 27/Jul/11 ]

What a joke! You actually want to publish a software as "ready for production use" that will completely switch off logging as soon as one does nothing but click on "Save"? I actually don't understand your definition of "stable" obviously.

Comment by sirajg [ 27/Jul/11 ]

The console considers the following to be valid levels : "OFF", "SEVERE", "WARNING". "INFO", "CONFIG", "FINE", FINER", "FINEST". The issue is fixed by adding "ALL" to the list.

Diffs :
— src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (revision 48367)
+++ src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (working copy)
@@ -214,6 +214,7 @@
final private static List<String> levels= new ArrayList();
static{
levels.add("OFF");
+ levels.add("ALL");
levels.add("SEVERE");
levels.add("WARNING");
levels.add("INFO");

However, there should really be a way to get valid log levels from the logging backend. Putting this data in console source code is not the ideal solution.

Comment by sirajg [ 27/Jul/11 ]

Or the other solution is to just remove the property com.sun.enterprise.server.logging.GFFileHandle from console.

Comment by Anissa Lam [ 10/Aug/11 ]

request Srini to fix this in 3.1.2 and trunk.
We will want to release note this for 3.1.1 release.

Comment by Anissa Lam [ 15/Aug/11 ]

Following is added to 3.1.1 release note.

Description:

Changing log levels in the Administration Console causes logging to stop. This is because the level of the com.sun.enterprise.server.logging.GFFileHandler logger is changed to OFF.

Workaround:

Fix the com.sun.enterprise.server.logging.GFFileHandler logger level using the following command:
asadmin set-log-levels com.sun.enterprise.server.logging.GFFileHandler=ALL
Specify the --target option for a server instance other than the domain administration server (DAS).

Comment by srinik76 [ 17/Aug/11 ]

What is the fix expected,

Do I need to remove the property from admin console page or add log level "ALL" as suggested by siraj. Please suggest so that I can fix appropriately.

Comment by Anissa Lam [ 18/Aug/11 ]

I don't think ALL is a valid log-level. you may want to check with Naman.
At least in v2, ALL is not allowed.
<!ENTITY % log-level
"(FINEST | FINER | FINE | CONFIG | INFO | WARNING | SEVERE | OFF)">

Also, is com.sun.enterprise.server.logging.GFFileHandler really the name of a logger ?

It depends on the answer of the above.

  • if ALL is NOT valid log-level and GFFileHandler is NOT a logger, then remove this from the logger table. Move that to the general logger setting page and provide a dropdown with all the acceptable value for user to set this. Check with Naman what is accepted value for this.
  • if ALL is NOT valid log-level, but GFFileHandler is indeed a logger, then logging.properties is wrong out-0f-box. Naman need to fix that.
Comment by naman_mehta [ 26/Aug/11 ]

In logging the FileHanlder log level is allowed user to write logs under specified log file. Default value is ALL for the same.

http://download.oracle.com/javase/6/docs/api/java/util/logging/FileHandler.html

But in some of the case, user wants to use there custom log handler which writes logs under some different file in different format then at that time to OFF logging user has to set this log level to OFF which in turn stop logging in server.log file. I had a bug for the same in the past so to fix the same we need to allow user to set log level as OFF for the same.

ALL and OFF are also valid log levels.

http://download.oracle.com/javase/6/docs/api/java/util/logging/Level.html

Comment by srinik76 [ 29/Aug/11 ]

Fix attached

Index: src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java
===================================================================
— src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (revision 49029)
+++ src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (working copy)
@@ -221,6 +221,7 @@
levels.add("FINE");
levels.add("FINER");
levels.add("FINEST");
+ levels.add("ALL");
}
}

Waiting for review comments from Anissa.

Comment by srinik76 [ 19/Oct/11 ]

Checked in the fix in 3.1.2 branch

Sending LoggingHandlers.java
Transmitting file data .
Committed revision 50343.

Comment by srinik76 [ 19/Oct/11 ]

Checked into the trunk

Sending admingui/common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java
Transmitting file data .
Committed revision 50344.





[GLASSFISH-16995] Error on deploying JPA apps with availabilityenabled=true because of disabling them asynchronously Created: 08/Jul/11  Updated: 02/Dec/11  Resolved: 22/Jul/11

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

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

Operating System: All
Platform: All


Attachments: File cdi-jpa-resource-injection-web.war     Text File fix.patch    
Tags: 3_1_1-scrubbed

 Description   

When deploying JPA apps on DAS with availabilityenabled=true option, the asadmin command returns successfully but server.log of DAS sometimes outputs the following errors. After that JPA apps also don't work normally.

[server.log]


java.lang.RuntimeException: Exception while preparing the app
at com.sun.enterprise.v3.server.ApplicationConfigListener.enableApplication(ApplicationConfigListener.java:254)
at com.sun.enterprise.v3.server.ApplicationConfigListener.handleOtherAppConfigChanges(ApplicationConfigListener.java:199)
at com.sun.enterprise.v3.server.ApplicationConfigListener.transactionCommited(ApplicationConfigListener.java:146)
at org.jvnet.hk2.config.Transactions$TransactionListenerJob.process(Transactions.java:344)
at org.jvnet.hk2.config.Transactions$TransactionListenerJob.process(Transactions.java:335)
at org.jvnet.hk2.config.Transactions$ListenerNotifier$1.call(Transactions.java:211)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at org.jvnet.hk2.config.Transactions$Notifier$1$1.run(Transactions.java:165)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.Exception: Exception while preparing the app
at com.sun.enterprise.v3.server.ApplicationConfigListener.enableApplication(ApplicationConfigListener.java:250)
... 14 more

#]

[Reproducible Operations]
After starting DAS, execute the following command.(Note that this issue does not always happen.)
asadmin deploy --force=true --availabilityenabled=true --target server cdi-jpa-resource-injection-web.war

[Reproducible Applications]
I used dev test apps of GF as follows.
trunk/v2/appserv-tests/devtests/cdi/javaee-component-resources/jpa-resource-injection

[The reason of this issue]
As a result of investigation, I found the reason of this issue was to switch the order of enabling / disabling of apps because APPLICATION_DISABLED event is processed asynchronously.

When specifying availabilityenabled=true option, the deployment process calls ApplicationLifecycle.deploy(), ApplicationLifecycle.disable()
and ApplicationLifecycle.enable() in order.

ApplicationLifecycle.disable() registers the APPLICATION_DISABLED event and this event calls JPADeployer.closeEMFs() on another thread.
ApplicationLifecycle.enable() calls JPADeployer.createEMFs().

This issue occurs when JPADeployer.closeEMFs() is processed after JPADeployer.createEMFs(). Because the HashMap entries of EntityManagerFactoryProvider operated by JPADeployer becomes inconsistent.

[StackTrace related to this issue]
Daemon Thread [pool-77-thread-1] (Suspended (breakpoint at line 180 in PersistenceProvider))
PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) line: 180
PersistenceUnitLoader.loadPU(PersistenceUnitDescriptor) line: 205
PersistenceUnitLoader.<init>(PersistenceUnitDescriptor, ProviderContainerContractInfo) line: 119
JPADeployer$1.visitPUD(PersistenceUnitDescriptor, DeploymentContext) line: 214
JPADeployer$1(JPADeployer$PersistenceUnitDescriptorIterator).iteratePUDs(DeploymentContext) line: 483
JPADeployer.createEMFs(DeploymentContext) line: 221
JPADeployer.prepare(DeploymentContext) line: 167
ApplicationLifecycle.prepareModule(List<EngineInfo>, String, DeploymentContext, ProgressTracker) line: 873
ApplicationLifecycle.deploy(Collection<Sniffer>, ExtendedDeploymentContext) line: 410
ApplicationLifecycle.enable(String, Application, ApplicationRef, ActionReport, Logger) line: 2015
ApplicationConfigListener.enableApplication(String) line: 243
ApplicationConfigListener.handleOtherAppConfigChanges(Object, String) line: 199
ApplicationConfigListener.transactionCommited(List<PropertyChangeEvent>) line: 146
Transactions$TransactionListenerJob.process(TransactionListener) line: 344
Transactions$TransactionListenerJob.process(Object) line: 335
Transactions$ListenerNotifier$1.call() line: 211
FutureTask$Sync.innerRun() line: 303
FutureTask<V>.run() line: 138
Transactions$Notifier$1$1.run() line: 165
Executors$RunnableAdapter<T>.call() line: 441
FutureTask$Sync.innerRun() line: 303
FutureTask<V>.run() line: 138
ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
ThreadPoolExecutor$Worker.run() line: 908
Thread.run() line: 662

Daemon Thread [pool-92-thread-1] (Suspended (breakpoint at line 1796 in EntityManagerSetupImpl))
EntityManagerSetupImpl.undeploy() line: 1796
EntityManagerFactoryImpl.close() line: 214
JPADeployer.closeEMFs(ApplicationInfo) line: 405
JPADeployer.event(EventListener$Event) line: 396
EventsImpl$1.run() line: 120
Executors$RunnableAdapter<T>.call() line: 441
FutureTask$Sync.innerRun() line: 303
FutureTask<V>.run() line: 138
ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
ThreadPoolExecutor$Worker.run() line: 908
Thread.run() line: 662



 Comments   
Comment by ito_m [ 08/Jul/11 ]

This is patch for fixing this issue to change an asynchronous call into a synchronous call.

Comment by Hong Zhang [ 08/Jul/11 ]

Thanks for reporting the issue and the patch! Very good analysis. I will commit the patch to the trunk (3.2).

Comment by Hong Zhang [ 22/Jul/11 ]

applied the patch, making the event synchronous

Comment by Hong Zhang [ 17/Oct/11 ]

Port the fix to 3.1.2 branch and mark the fix versions as both 3.1.2 and trunk.

Comment by Hong Zhang [ 17/Oct/11 ]

Set the right fix version





[GLASSFISH-16399] autodeploy to instance produces incorrect log messages Created: 21/Apr/11  Updated: 02/Dec/11  Resolved: 12/May/11

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 4.0
Fix Version/s: 3.1.2_b06, 4.0_b08

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


 Description   

When a WAR file is dropped into the autodeploy directory of an instance, the instance logs some misleading messages about the deployment being successful in the instance log file. The application isn't actually deployed (as it shouldn't be because apps cannot be deployed directly to instances without a DAS). There shouldn't even be an "autodeploy" directory created for an instance since it should be used.

[#|2011-04-20T16:05:25.053-0700|INFO|glassfish3.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=24;_ThreadName=Thread-1;|[AutoDeploy] Selecting file /scratch/trm/test/glassfish3/glassfish/nodes/localhost-domain1/i1/autodeploy/helloworld.war for autodeployment.|#]

[#|2011-04-20T16:05:25.136-0700|INFO|glassfish3.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=24;_ThreadName=Thread-1;|[AutoDeploy] Successfully autodeployed : /scratch/trm/test/glassfish3/glassfish/nodes/localhost-domain1/i1/autodeploy/helloworld.war.|#]

Here are the steps to recreate the problem.

asadmin start-domain
asadmin create-cluster c1
asadmin create-local-instance --cluster c1 i1
asadmin start-instance i1

cp helloworld.war glassfish3/glassfish/nodes/localhost-domain1/i1/autodeploy



 Comments   
Comment by Hong Zhang [ 21/Apr/11 ]

assign to tim to take a look

Comment by Tim Quinn [ 21/Apr/11 ]

It should be relatively straightforward to avoid starting the autodeployer on non-DAS servers.

Comment by Tim Quinn [ 12/May/11 ]

Fix checked in.

Sending deployment/autodeploy/src/main/java/org/glassfish/deployment/autodeploy/AutoDeployService.java
Transmitting file data ...
Committed revision 46805.
Revision: 46805
Author : tjquinn
Date : May 12, 2011 9:30:27 AM

Comment by Tim Quinn [ 18/Oct/11 ]

Fix checked in for 3.1.2:

Project: glassfish
Repository: svn
Revision: 50325
Author: tjquinn
Date: 2011-10-18 20:00:36 UTC
Link:

Log Message:
------------
Fix for 16399 backported from the trunk to 3.1.2

Revisions:
----------
50325

Modified Paths:
---------------
branches/3.1.2/deployment/autodeploy/src/main/java/org/glassfish/deployment/autodeploy/AutoDeployService.java





[GLASSFISH-17481] LB : Help button throws 404 errro Created: 25/Oct/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Closed
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1.2_b01
Fix Version/s: 3.1.2_b06

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

Solaris Sparc 10


Attachments: File lb_doc_link.bmp    

 Description   

1) Login GF and click HTTP Load Balancers.
2) Click help button on top of the page
2) Right panel of the Help windows throws 404 error

-----------------------------------------------
HTTP Status 404 -

type Status report

message

descriptionThe requested resource () is not available.
GlassFish Server Open Source Edition 3.1.2
------------------------------------------------



 Comments   
Comment by kshitiz_saxena [ 04/Nov/11 ]

Assigning to admin team to take a look.

Comment by srinik76 [ 04/Nov/11 ]

Closing this bug as duplicate of 17623.

Online help for all pages are failing because of some issues. There is a bug already raised and assigned to docs team to look into this.





[GLASSFISH-16317] Some CORBA properties are ignored Created: 06/Apr/11  Updated: 31/Oct/11  Resolved: 31/Oct/11

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: v3.0.1
Fix Version/s: 3.1.2_b06

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

GlassFish Server Open Source Edition 3.0.1 (build 22)
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)


Tags: 3_1_1-exclude, 3_1_1-scrubbed, connection, jndi, orb, properties, timeout

 Description   

When specifying properties for Glassfish connection like :

org.omg.CORBA.ORBInitialHost='hostname'
org.omg.CORBA.ORBInitialPort='portnumber'

Other CORBA common properties seem to be ignored :

com.sun.corba.ee.transport.ORBWaitForResponseTimeout=5
com.sun.corba.ee.transport.ORBTCPConnectTimeouts=100:500:100:500
com.sun.corba.ee.transport.ORBTCPTimeouts=500:2000:50:1000

As you can see in this topic : http://blogs.sun.com/ejcorba/entry/client_side_transport_timeouts_and

Steps to reproduce :

  • Define the given properties in a new InitialContext
  • Start the application from Eclipse :
  • Once when Glassfish is started and the EAR deployed : everything is ok
  • Once when Glassfish is not started at all : The timeout properties are ignored ; you have to wait 1 or 2 minutes before a timeout to be thrown.


 Comments   
Comment by Cheng Fang [ 06/Apr/11 ]

re-categorize it to orb compoment.

Comment by Ken Cavanaugh [ 18/May/11 ]

No plan to fix in 3.1.1

Comment by Ken Cavanaugh [ 24/May/11 ]

Is this still a problem in 3.1.0? 3.0.1 shared a single ORB on the client side
for all naming contexts, while 3.1.0 does not. However, properties passed in
to the InitialContext are NOT passed on to the ORB. You'll need to set the
properties as system properties for the ORB to see them.

Comment by Harshad Vilekar [ 31/Oct/11 ]

Setting these properties as system properties works just fine with 3.1.2_b06 - The connection times out within 5 seconds.

Example:
java -Dcom.sun.corba.ee.transport.ORBWaitForResponseTimeout=5 -Dcom.sun.corba.ee.transport.ORBTCPConnectTimeouts=100:500:100:500 -Dcom.sun.corba.ee.transport.ORBTCPTimeouts=500:2000:50:1000 -cp .. <java client>





[GLASSFISH-17485] Apply changes button throws error message Created: 25/Oct/11  Updated: 27/Oct/11  Resolved: 27/Oct/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2_b01
Fix Version/s: 3.1.2_b06

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

Attachments: File apply_changes.bmp    

 Description   

1) Login to Glassfish Admin GUI
2) Click HTTP Load Balancers
3) Create a LB and open it
4) Click Export button
5) Click apply changes. It throws error "An error has occurred
For input string: ""For input string: ""



 Comments   
Comment by srinik76 [ 27/Oct/11 ]

Duplicate of Issue 17456

Comment by hsbhavya [ 27/Oct/11 ]

I am getting this issue for "apply button" not for "test connection button" as mentioned in issue 17456. I do not think it is a duplicate of issue 17456 . Please reopen the bug.

Comment by srinik76 [ 27/Oct/11 ]

Both test connection and apply button call the same back end call, fixing one will fix other as it calls same function.

Comment by srinik76 [ 27/Oct/11 ]

i will test it and let you know

Comment by srinik76 [ 27/Oct/11 ]

The error is because of null strings for ssl proxy host and port in domain.xml. This has been fixed by 17456. Tested with latest lb jar, it works fine.

Comment by hsbhavya [ 27/Oct/11 ]

Ok thanks .





[GLASSFISH-15717] "Very Intermittent: Drop of Planned Shutdown notification of DAS (a spectator) to one of the clustered instances". Created: 27/Jan/11  Updated: 22/Oct/11  Resolved: 21/Oct/11

Status: Closed
Project: glassfish
Component/s: group_management_service
Affects Version/s: 3.1_b38
Fix Version/s: 3.1.2_b06

Type: Bug Priority: Minor
Reporter: zorro Assignee: Joe Fialli
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux



 Description   

This is a very intermittent drop of das planned shutdown notification seen in scenarios 10 and 11.
http://aras2.us.oracle.com:8080/logs/gf31/gms/set_01_21_11_t_08_03_25/final_Fri_Jan_21_14_44_57_PST_2011.html

http://aras2.us.oracle.com:8080/logs/gf31/gms//set_01_11_11_t_13_45_23/scenario_0010_Tue_Jan_11_23_55_27_PST_2011.html

The failed constraint was the Planned Shutdown for the DAS was not received by one of the clustered instances.
(Scenario 10 explicitly stops DAS in middle of scenario to verify GroupLeadership change.)
This failure only happened in one out of 32 runs and for only one instance in the cluster. So it is definitely quite intermittent.

There is a strong possibility that this was a dropped UDP message. While I have fixed dropped UDP broadcast messages
in this release, this is unfortunately a boundary case that I can not address with current design, the rebroadcast of the missed event
can not take place since the last event the DAS broadcast was it shutdown. So when the clustered instance noticed
it missed an event, the instance it would request to rebroadcast the missed event no longer exist so it can not rebroadcast
the dropped UDP packet. So this would be nontrivial
to fix and not advised to attempt at this late stage of the release.

Luckily, the DAS is not part of replicating data so this missed PlannedShutdown of a SPECTATOR member would not impact HA.
There is no application that I am aware of that is dependent on planned shutdown notification of the SPECTATOR das. Everything else is okay in the logs.
The instance was notified of a new GroupLeader to replace the Shutdown DAS and the list of current alive and ready members is correct.
(reflects the DAS "server" is no longer part of cluster)

Extracted from http://aras2.us.oracle.com:8080/logs/gf31/gms///set_01_11_11_t_13_45_23/scenario_0010_Tue_Jan_11_23_55_27_PST_2011/easqezorro8_n1c1m7.log

[#|2011-01-12T07:56:38.260+0000|INFO|glassfish3.1|ShoalLogger|_ThreadID=16;_ThreadName=Thread-1;|GMS1093: adding GroupLeadershipNotification signal leadermember: n1c1m1 of group: clusterz1|#]

[#|2011-01-12T07:56:38.260+0000|INFO|glassfish3.1|ShoalLogger|_ThreadID=16;_ThreadName=Thread-1;|GMS1092: GMS View Change Received for group: clusterz1 : Members in view for MASTER_CHANGE_EVENT(before change analysis) are :
1: MemberId: n1c1m1, MemberType: CORE, Address: 10.133.184.208:9132:228.9.53.86:31524:clusterz1:n1c1m1
2: MemberId: n1c1m2, MemberType: CORE, Address: 10.133.184.209:9154:228.9.53.86:31524:clusterz1:n1c1m2
3: MemberId: n1c1m3, MemberType: CORE, Address: 10.133.184.211:9140:228.9.53.86:31524:clusterz1:n1c1m3
4: MemberId: n1c1m4, MemberType: CORE, Address: 10.133.184.213:9196:228.9.53.86:31524:clusterz1:n1c1m4
5: MemberId: n1c1m5, MemberType: CORE, Address: 10.133.184.214:9147:228.9.53.86:31524:clusterz1:n1c1m5
6: MemberId: n1c1m6, MemberType: CORE, Address: 10.133.184.137:9195:228.9.53.86:31524:clusterz1:n1c1m6
7: MemberId: n1c1m7, MemberType: CORE, Address: 10.133.184.138:9121:228.9.53.86:31524:clusterz1:n1c1m7
8: MemberId: n1c1m8, MemberType: CORE, Address: 10.133.184.139:9194:228.9.53.86:31524:clusterz1:n1c1m8
9: MemberId: n1c1m9, MemberType: CORE, Address: 10.133.184.140:9191:228.9.53.86:31524:clusterz1:n1c1m9

#]


 Comments   
Comment by Joe Fialli [ 27/Jan/11 ]

I confirmed that there were UDP drops on the machine that has the missing PlannedShutDown notification.

% netstat -su

Udp:
19870588 packets received
97130 packets to unknown port received.
1 packet receive errors
506777 packets sent

I checked another machine and it had two UDP receive errors.
I did verify that the /etc/sysctl.conf had appropriate settings for
receive buffer. (So the OEL OS are configured as we have requested in
past.)

This failure can only happen in either Shoal GMS QE Scenario 10 or 11
and it has only ever happened on machine running n1c1m7 (easqezorro8).

The recreation rate at the time this issue was submitted was twice in 104 runs.

It is quite possible to tune away the UDP drops by increasing the UDP receive buffer and write buffer sizes
from current size to a little bigger. If increasing these values makes the failure go away and we do not observe
udp packet receive errors in "netstat -su", then we would have confirmed the hypothesis that this drop is
due to UDP drop. As I mentioned in my previous attached email, there is a boundary condition in current design
that does not allow for rebroadcast of a a dropped planned shutdown since the rebroadcast logic is solely
in the master which has shutdown in this case.

The following document describes how to check and set udp buffer sizes for various OS.
http://www.29west.com/docs/THPM/udp-buffer-sizing.html

An unconfirmed workaround for this issue is to tune the systems current udp buffer sizing by
increasing its value. It would be helpful if we could validate with exiting GMS QE scenario 10 and
11 testing if this workaround does address the failure that has been reported.

Given that the current udp read/write buffer size is 512 * 1024, we could increase it to 756 * 1024 to see if that
causes the issue to go away on easqezorro8 machine.

Comment by Joe Fialli [ 28/Jan/11 ]

Minimally will investigate if proposed workaround mitigates this very intermittent issue.

Comment by Joe Fialli [ 21/Oct/11 ]

This failure has not been reported in recent glassfish gms qe test runs so closing with a cannot reproduce for time being.

Comment by zorro [ 22/Oct/11 ]

Confirming that this issue is not being seen in b4 and b5 of version 3.1.2





[GLASSFISH-16414] Administrator shall be able to configure a cluster to not require UDP multicast. Created: 21/Apr/11  Updated: 21/Oct/11  Resolved: 21/Oct/11

Status: Closed
Project: glassfish
Component/s: group_management_service
Affects Version/s: 3.1
Fix Version/s: 3.1.2_b06

Type: New Feature Priority: Critical
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Provide new Cluster properties to asadmin create-cluster subcommand to use group discovery rather than UDP multicast.

New cluster property is DISCOVERY_URI_LIST.
Changes checked in.

% asadmin create-cluster --properties GMS_DISCOVERY_URI_LIST=generate:GMS_LISTENER_PORT=9091 myCluster1
% asadmin create-cluster --properties GMS_DISCOVERY_URI_LIST=generate:GMS_LISTENER_PORT=9092 myCluster2



 Comments   
Comment by Joe Fialli [ 21/Oct/11 ]

Functionality checked into glassfish 3.1.2 and 4.0 workspaces.





[GLASSFISH-16417] asadmin get-health needs to work in self configuring(ad hoc clusters) cluster env Created: 21/Apr/11  Updated: 20/Oct/11  Resolved: 20/Oct/11

Status: Resolved
Project: glassfish
Component/s: group_management_service
Affects Version/s: 3.1.2_b01
Fix Version/s: 3.1.2_b06

Type: New Feature Priority: Major
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_2prd

 Description   

In GlassFish 3.1, this command only runs against the DAS and there is no DAS in self configuring cluster env.
Other commands that run against the DAS (list-instance, start-cluster) are non-requirements.
So need to evaluate if this command should be implemented for self-configuring cluster.

Health info could be stored in GMS master.
Command needs to be able to locate the master via cluster name.
(investigate means to associate clustername with configuration info such as GMS_DISCOVERY_URI_LIST)



 Comments   
Comment by Bobby Bissett [ 20/Oct/11 ]

Is in b06





[GLASSFISH-16823] No validation for installation directory when editing a node Created: 08/Jun/11  Updated: 19/Oct/11  Resolved: 19/Oct/11

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 3.1.2_b06

Type: Bug Priority: Minor
Reporter: lidiam Assignee: carlavmott
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

3.1 b43


Attachments: JPEG File asadmin-not-executable.JPG    
Tags: 3_1_1-scrubbed

 Description   

When user creates a CONFIG node and enters an invalid installation directory the following error message is displayed:

An error has occurred
Installdir value $

{com.sun.aas.productRoot}/glassfish/nodes is not a valid glassfish installation.

However, when a CONFIG node is created, e.g. without an installation directory specified, and an invalid directory is entered on Edit Node screen, the change is saved without a warning. As a result, when user later tries to create an instance under such node, the following error is displayed:

Command succeeded with Warning
Failed to execute local command: C:\as\v31\glassfish3\glassfish\nodes\glassfish\bin\asadmin.bat is not executable.

The instance appears to be created but cannot be started, since it was only created in domain.xml.

It seems that we should be validating installation directory when editing an existing node as well, and not just during the node creation. This issue is present for both SSH and CONFIG nodes - no validation is done on installation directory on Edit Node screen.

Steps to reproduce:

1. Create a config node, specifying node name and localhost for node host.
2. Go to the Edit screen for the newly created node and enter ${com.sun.aas.productRoot}

/glassfish/nodes for installation directory. Save changes.
3. Go to Create Standalone Instance screen and create a new instance on the node. Warning is displayed.



 Comments   
Comment by Anissa Lam [ 08/Jun/11 ]

Validation comes from the backend.
Transfer to Joe for evaluation.

Comment by Joe Di Pol [ 10/Jun/11 ]

I've reproduced this with a CONFIG node when editing. When you create a new node, if the node's host is the local host then the create code will validate the installdir – but edit does not do this. (If the host is not the local host then we can't validate the installdir in either case).

For an SSH node I do not see this problem. Editing an SSH node and changing installdir to an invalid path generates a validation error as expected.

I'm lowering the priority since this is not a major loss of functionality. Assigning to Carla since she did the installdir check in create-node-config.

Comment by carlavmott [ 19/Oct/11 ]

This bug was fixed in 3.1.2 workspace and also the trunk.





[GLASSFISH-16629] ./package-appclient fails with Exception Created: 13/May/11  Updated: 18/Oct/11  Resolved: 13/May/11

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: 4.0_b06
Fix Version/s: 3.1.2_b06, 4.0_b08, 4.0

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

Linux



 Description   

When running package-appclient on a brand new installation of glassfish 3.2_b06 the following happens:

debian-test:/opt/glassfish3/glassfish/bin# ./package-appclient
Creating /opt/glassfish3/glassfish/lib/appclient.jar
java.lang.IllegalArgumentException: URI is not absolute
at java.io.File.<init>(File.java:361)
at org.glassfish.appclient.client.packageappclient.PackageAppClient.addFile(PackageAppClient.java:294)
at org.glassfish.appclient.client.packageappclient.PackageAppClient.run(PackageAppClient.java:245)
at org.glassfish.appclient.client.packageappclient.PackageAppClient.main(PackageAppClient.java:171)
debian-test:/opt/glassfish3/glassfish/bin#

The resulting jar is corrupt.



 Comments   
Comment by Tim Quinn [ 13/May/11 ]

Just noticed this myself. Investigating.

Comment by Tim Quinn [ 13/May/11 ]

Fix checked in. Should be in nightly builds tonight and the next promotion build (07).

Sending v3/appclient/client/acc-standalone/src/main/java/org/glassfish/appclient/client/packageappclient/PackageAppClient.java
Transmitting file data ...
Committed revision 46823.
Revision: 46823
Author : tjquinn
Date : May 13, 2011 9:57:15 AM
Fix for 16628 and 16629 (in 3.2)

Comment by Tim Quinn [ 18/Oct/11 ]

Checked in 3.1.2 fix and updated fixed-in list.

Project: glassfish
Repository: svn
Revision: 50328
Author: tjquinn
Date: 2011-10-18 20:20:31 UTC
Link:

Log Message:
------------
Fix for 16229 backported from the trunk to 3.1.2

Revisions:
----------
50328

Modified Paths:
---------------
branches/3.1.2/appclient/client/acc-standalone/src/main/java/org/glassfish/appclient/client/packageappclient/PackageAppClient.java





[GLASSFISH-17377] enabling web cache hangs server Created: 01/Oct/11  Updated: 18/Oct/11  Resolved: 18/Oct/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2_b06

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

Attachments: Text File jstack.txt     HTML File livedump    
Tags: cache

 Description   

This deployement descriptor hangs server. After removing, glassfish works fine

  • <cache enabled="true" timeout-in-seconds="300">
  • <cache-mapping>
  • <url-pattern>*.gif</url-pattern>
  • </cache-mapping>
  • <cache-mapping>
  • <url-pattern>/favicon.ico</url-pattern>
  • </cache-mapping>
  • <cache-mapping>
  • <url-pattern>/robots.txt</url-pattern>
  • </cache-mapping>
  • <cache-mapping>
  • <url-pattern>*.gif</url-pattern>
  • </cache-mapping>
  • <cache-mapping>
  • <url-pattern>*.html</url-pattern>
  • </cache-mapping>
  • </cache>

attaching thread stack dump from locked system.



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

Can you attach a simple test case to illustrate this?
From the log, it seems the mod_jk is used. Can you provide more details on your env?

Comment by rkolar02 [ 10/Oct/11 ]

Its Apache with ajp_proxy connected to Glassfish. Application will hang after cache timeout. (it works fine for first 300 seconds, then hangs during check for changed files).

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

Can you provide a simple test war and the url requests that you have used?

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

There was a cache hang issue, http://java.net/jira/browse/GLASSFISH-12891
and has been fixed in 3.1.

I have a simple war file with the above xml configuration. It is working fine.
Please provide more information and a test war file so that we can debug further.

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

Is the same app without ajp_proxy?

Comment by rkolar02 [ 13/Oct/11 ]

i cant make application war available to public

Comment by rkolar02 [ 13/Oct/11 ]

Did you tried during your war testing to load gif file to make sure its get cached? Because it seems that glassfish hangs on cache refresh and *.gif is TWICE in cache conf. We have /something.gif located in root server directory and its loaded often.

Comment by rkolar02 [ 13/Oct/11 ]

It is the same withoyt ajp_proxy. Yes. I can reporoduce it at any time.

Comment by rkolar02 [ 13/Oct/11 ]

stack dump from hanged machine without AJP

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

Can you attach a war file to reproduce the issue?

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

I see the issue now. The issue is triggered by duplicate entry for *.gif and then accessing a gif file.
As a workaround, one can remove the extra *.gif entry in deployment descriptor.

Need more investigation on the fix.

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

fix in 3.1.2:
Sending web-glue/src/main/java/com/sun/appserv/web/cache/filter/CachingFilter.java
Transmitting file data .
Committed revision 50320.

fix in trunk:
Sending web-glue/src/main/java/com/sun/appserv/web/cache/filter/CachingFilter.java
Transmitting file data .
Committed revision 50321.





[GLASSFISH-17438] alias field names in secure Admin page should be appropriate. Created: 18/Oct/11  Updated: 18/Oct/11  Resolved: 18/Oct/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2_b01
Fix Version/s: 3.1.2_b06

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

OS: Windows 2008 server
browser : FF 3.6.23
GF 3.1.2 b05


Attachments: JPEG File secureAdminPage.jpg    

 Description   

The admin alias and instance alias field names in the secure Admin page, when Admin Console is accessed on localhost should be appropriate.
Steps:
Access console on locahost.
Select the node server(Admin server)/"Secure Administration" Button.
In the secureAdmin page notice the adminalias and the instance alias feildnames.
Screenshot attached.



 Comments   
Comment by srinik76 [ 18/Oct/11 ]

This issue is duplicate of 17274. This is because of missing l10n strings. Fixed the issue 17274. So closing as duplicate.

With the fix it will display admin alias and instance alias appropriately.





[GLASSFISH-17404] Custom classloader can't load classes from Servlet Listener using Embedded Created: 10/Oct/11  Updated: 17/Oct/11  Resolved: 17/Oct/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2_b06, 4.0

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

Attachments: Text File 17404.final.patch     File cacao_gfish_test.war     Java Source File Test_cacao.java     Java Archive File toto.jar    

 Description   

When using a custom classloader via WebContainer.createContext(File docRoot, ClassLoader classLoader), the custom classloader cannot load classes from Servlet Listener during load phase. Servlet is able to load classes previously loaded using the custom classloader after deployment but not during load (from Servlet Listener).



 Comments   
Comment by Amy Roh [ 12/Oct/11 ]

3.1.1 patch

Comment by Amy Roh [ 17/Oct/11 ]

Fixed in trunk (svn 50281) and 3.1.2 (svn 50283)





[GLASSFISH-17011] Trying to set an ejb-ref on an EJB, while the EJB does not define remote interfaces Created: 11/Jul/11  Updated: 17/Oct/11  Resolved: 21/Jul/11

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: 3.1.2_b06, 4.0

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

Win 7 Pro SP1 64 Bit de_DE


Tags: 3_1_1-scrubbed

 Description   

When deploying an EAR with lots of EJBs in it, and one or some of that EJBs has incorrect configuration, GlassFish is so smart to tell about this:

[#|2011-07-11T16:11:41.764+0200|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=56;_ThreadName=Thread-1;|Exception while deploying the app [SuperSimple]|#]

[#|2011-07-11T16:11:41.764+0200|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=56;_ThreadName=Thread-1;|Trying to set an ejb-ref on an EJB, while the EJB does not define remote interfaces
java.lang.RuntimeException: Trying to set an ejb-ref on an EJB, while the EJB does not define remote interfaces
at com.sun.enterprise.deployment.EjbReferenceDescriptor.setEjbDescriptor(EjbReferenceDescriptor.java:186)
at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:757)
at com.sun.enterprise.deployment.ApplicationClientDescriptor.visit(ApplicationClientDescriptor.java:667)
at com.sun.enterprise.deployment.Application.visit(Application.java:1794)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:799)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:277)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:170)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:826)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:768)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
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-07-11T16:11:41.774+0200|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=56;_ThreadName=Thread-1;|Exception while deploying the app [SuperSimple] : Trying to set an ejb-ref on an EJB, while the EJB does not define remote interfaces|#]

Unfortunately, it does not tell which EJB is the problem, so the deployer / administrator is blocked completely now and has to check all (possibly hundreds) EJBs in that EAR... This is everything but comfortable. GF must tell the EJB name so people know where to look at.



 Comments   
Comment by Hong Zhang [ 11/Jul/11 ]

I agree we should improve the error message to make the error message more useful. However, I don't think it's a showstopper for 3.1.1 as it's improving error message for negative case.
The fix for it is actually quite simple, I will see if I can get the approval to check in the fix to 3.1.1, if not, I will make the fix just to the trunk.

Comment by mkarg [ 12/Jul/11 ]

Ok, it is not a showstopper, but it is at least critical. The user cannot deploy to GFv3.1 unless he checked either all his EJB source codes or at least scans the complete log for any other hints. I don't think that people evaluating GFv3.1 will be convinced that this is a production use product when being stuck in this situation.

Comment by Hong Zhang [ 21/Jul/11 ]

Enhanced the error message to include the ejb name

Comment by Hong Zhang [ 17/Oct/11 ]

Port the fix to 3.1.2 branch and updated the fix versions to both 3.1.2 and trunk.





[GLASSFISH-14404] Inconsistent behavior of deployment of an EJB module with Main-Class manifest Created: 03/Nov/10  Updated: 17/Oct/11  Resolved: 25/May/11

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 3.1.2_b06, 4.0

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 14,404
Tags: 3_1-exclude

 Description   

This is an embedded test (v2/appserv-tests/devtests/ejb/ejb31/embedded/skipjar)
that currently suppresses from processing EJB modules that have Main-Class
manifest (via a property passed to createEJBContainer() call).

If I modify the test as described in [1], the deployment fails with unexpected
results.

The test builds 3 jars:
-ejb.jar
-pu.jar
-client.jar (that has all classes in the above2 and also a client class and a
manifest with Main-Class)

There is also a reporter.jar in the classpath as for all devtests (besides
static-shell.jar which we are smart to exclude).

There are 2 tests: as jars (run_se) and as unpacked dirs (run_se_unpacked).
The -client.jar is excluded from processing by the property passed to
createEJBContainer call (I added the prop after you enabled a module to be both).

I commented out the prop, to see what would happen...

For run_se, I also changed the classpath not to have -ejb.jar in it.

Both tests fail, and fail weirdly:

1) run_se fails with the output below (notice that it added everything correctly
to the ScatteredArchive):

[java] INFO: [DeploymentElement] adding EJB module to ScatteredArchive
ejb-ejb31-embedded-skipjar-client.jar
[java] Oct 29, 2010 5:46:45 PM com.sun.logging.LogDomains$1 log
[java] INFO: [DeploymentElement] adding library to ScatteredArchive
ejb-ejb31-embedded-skipjar-pu.jar
[java] Oct 29, 2010 5:46:45 PM com.sun.logging.LogDomains$1 log
[java] INFO: [DeploymentElement] adding library to ScatteredArchive reporter.jar
[java] Oct 29, 2010 5:46:45 PM com.sun.logging.LogDomains$1 log
[java] INFO: [EJBContainerImpl] Deploying app:
org.glassfish.api.embedded.ScatteredArchive@4dc4e792 located at null
[java] Oct 29, 2010 5:46:45 PM com.sun.logging.LogDomains$1 log
[java] SEVERE: Exception while deploying the app
[ejb-ejb31-embedded-skipjar-client]
[java] Oct 29, 2010 5:46:45 PM com.sun.logging.LogDomains$1 log
[java] SEVERE:
/Users/mvatkina/v3/v2/appserv-tests/devtests/ejb/ejb31/embedded/skipjar/gfembed4297581697145092559tmp/applications/reporter.jar
[java] java.io.FileNotFoundException:
/Users/mvatkina/v3/v2/appserv-tests/devtests/ejb/ejb31/embedded/skipjar/gfembed4297581697145092559tmp/applications/reporter.jar
[java] at
com.sun.enterprise.deploy.shared.ArchiveFactory.openArchive(ArchiveFactory.java:185)
[java] at
com.sun.enterprise.deploy.shared.ArchiveFactory.openArchive(ArchiveFactory.java:108)
[java] at
com.sun.enterprise.v3.server.ApplicationLifecycle.getExternalLibraries(ApplicationLifecycle.java:522)
[java] at
com.sun.enterprise.v3.server.ApplicationLifecycle.getDeployableTypes(ApplicationLifecycle.java:486)
[java] at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:342)
[java] at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:243)
[java] at
org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:193)
[java] at
org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:137)
[java] at
org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:132)

2) For run_se_unpacked I kept the classpath as-is, so it had 2 ejb modules,
-ejb.jar (with "sample" name via DD), and -client.jar (no DD, so default module
name). So global JNDI names would be different. The output is this (sorry,
deployment "eats" the actual exceptions ):
[java] INFO: [EJBContainerImpl] Deploying app:
/var/folders/IF/IFNvUBVCFPWlqMFXX-mK2++++TI/Tmp/ejb-app2505259789123896777
<...>
[java] WARNING: appclient module [ejb-ejb31-embedded-skipjar-clientdir.jar]
contains characteristics of other module type: ejb
[java] Oct 29, 2010 5:46:54 PM com.sun.logging.LogDomains$1 log
[java] WARNING: appclient module [ejb-ejb31-embedded-skipjar-clientdir.jar]
contains characteristics of other module type: ejb
[java] Oct 29, 2010 5:46:54 PM com.sun.logging.LogDomains$1 log
[java] SEVERE: Exception while invoking class
org.glassfish.appclient.server.core.AppClientDeployer prepare method
[java] Oct 29, 2010 5:46:54 PM com.sun.logging.LogDomains$1 log
[java] SEVERE: Exception while invoking class
org.glassfish.javaee.full.deployment.EarDeployer prepare method
[java] Oct 29, 2010 5:46:54 PM com.sun.logging.LogDomains$1 log

-marina

[1]

Index: build.xml
===================================================================
— build.xml (revision 42315)
+++ build.xml (working copy)
@@ -64,7 +64,7 @@
<echo message="Running with $

{embedded.classpath} in classpath"/>
<java fork="on"
failonerror="true"
-
classpath="${assemble.dir}/${appname}-client.jar:${assemble.dir}/${appname}-ejb.jar:${assemble.dir}/${appname}-pu.jar:${embedded.classpath}

:$

{env.APS_HOME}/lib/reporter.jar"
+
classpath="${assemble.dir}/${appname}-client.jar:${assemble.dir}/${appname}-xxx.jar:${assemble.dir}/${appname}-pu.jar:${embedded.classpath}:${env.APS_HOME}

/lib/reporter.jar"
classname="$

{se.client}

">
<arg line="$

{jndiroot}

"/>
</java>
Index: client/Client.java
===================================================================
— client/Client.java (revision 42315)
+++ client/Client.java (working copy)
@@ -69,7 +69,7 @@
private void test() {

Map<String, Object> p = new HashMap<String, Object>();

  • p.put("org.glassfish.ejb.embedded.skip-client-modules", "true");
    + //p.put("org.glassfish.ejb.embedded.skip-client-modules", "true");

EJBContainer c = EJBContainer.createEJBContainer(p);
// ok now let's look up the EJB...



 Comments   
Comment by Hong Zhang [ 04/Nov/10 ]

will look at this in the next release

Comment by Hong Zhang [ 06/Apr/11 ]

I have checked in the changes to handle the ejb jar with Manifest Main-Class case: the ejb jar will be processed as an ejb jar instead of appclient jar (verified with regular deployment).
Marina is in the process of switching to the new embedded api's, reassign the issue to her for her to verify with the new embedded api once she finishes.

Comment by marina vatkina [ 25/May/11 ]

I do not see any problems after switching to the new API

Comment by Hong Zhang [ 17/Oct/11 ]

Port the fix to 3.1.2 branch and marked the fix versions as both 3.1.2 and trunk.





[GLASSFISH-17413] catalina DefaultServlet path mapping different from Tomcat when servlet-mapping in subdirectory Created: 12/Oct/11  Updated: 13/Oct/11  Resolved: 13/Oct/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: v3.0.1
Fix Version/s: 3.1.2_b06

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

Windows XP, Java 1.6.0_24



 Description   

When I try the following servlet-mapping in Tomcat 6 and Glassfish 3.0.1, the behaviour is different:

<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>/static/*</url-pattern>
</servlet-mapping>

Tomcat serves a resource static/foo.js at URL static/foo.js , but in Glassfish it is served at static/static/foo.js .
According to http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/servlets/DefaultServlet.html the Glassfish behaviour is broken.



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

fix in 3.1.2:
Sending servlets/DefaultServlet.java
Transmitting file data .
Committed revision 50241.

fix in trunk:
Sending DefaultServlet.java
Transmitting file data .
Committed revision 50243.

add test case:
Sending build.xml
Adding defaultServletWithSubdirectoryMapping
Adding defaultServletWithSubdirectoryMapping/WebTest.java
Adding defaultServletWithSubdirectoryMapping/build.properties
Adding defaultServletWithSubdirectoryMapping/build.xml
Adding defaultServletWithSubdirectoryMapping/descriptor
Adding defaultServletWithSubdirectoryMapping/descriptor/web.xml
Adding defaultServletWithSubdirectoryMapping/docroot
Adding defaultServletWithSubdirectoryMapping/docroot/index.jsp
Adding defaultServletWithSubdirectoryMapping/docroot/static
Adding defaultServletWithSubdirectoryMapping/docroot/static/test.txt
Transmitting file data .......
Committed revision 50244.





Generated at Mon May 25 07:30:58 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.