<< Back to previous view

[GLASSFISH-20907] Admin Console stops working when an application bundled with jersey-1.x.jar and classloader set to delegate false Created: 21/Nov/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui, classloader
Affects Version/s: 4.0_b89_RC5
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: iesen Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: admin-gui
Participants: Anissa Lam, iesen and Sanjeeb Sahoo

 Description   

A web application bundled with its own Jersey implementation (which is 1.x) crashes admin console after server restart. The application has glassfish-web.xml config file for classloading settings (delegate=false).

Exception is :
java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder;

Looking at the verbose classloading output (-verbose:classes), admin console application grab Jersey 1.x classes from deployed application in applications folder. Manually deleting jersey 1.x jar from application's folder solves the exception and admin console starts. But is it not possible to deploy a Jersey 1.x application to Glassfish4?



 Comments   
Comment by Anissa Lam [ 21/Nov/13 04:23 PM ]

Assign to Sahoo for initial evaluation regarding class loading. Not sure console can do much on this.





[GLASSFISH-20844] Glassfish 4 refresh taking up to 1 minute Created: 03/Oct/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b89_RC5
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: vaughnmb Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008 r2, 24 GB ram, 16 cores


Tags:
Participants: Anissa Lam and vaughnmb

 Description   

After I have deployed around 20 applications to Glassfish 4, the refresh screen time takes up to 1 minute. Glassfish 3 was around 10 seconds for 80 applications. I'm not talking about the deployment screen. I'm talking about the "white-out" screen when the page is trying to refresh.



 Comments   
Comment by vaughnmb [ 09/Oct/13 03:52 PM ]

I have performed more testing. I take a fresh install of glassfish 3.1.2.2 and glassfish 4 build 89 and autodeploy the same 80 applications to each server. Glassfish 3 can deploy the 81st application in 2-3 seconds. Glassfish 4 deploys the 81st application in 29 seconds. These applications are small CDI beans that inject an EJB. There is no database requirements or anything like that.

I will attach the files. The python file creates 80 new ear files of the same application. Just put the GlassfishTest.ear file and python file in the same folder and run the python file.

Comment by vaughnmb [ 09/Oct/13 03:53 PM ]

How do you attach files?

Comment by Anissa Lam [ 09/Oct/13 03:58 PM ]

The attachment feature has been taken away from JIRA. You can put that somewhere and give us the pointer.
Are you saying deployment is slow in the console ? What if you use CLI to deploy, do you experience the same ?

Comment by vaughnmb [ 09/Oct/13 04:20 PM ]

http://www.hvacworld.biz/downloads/GLASSFISH-20844.zip

Deployment was slow through the console, but it was fast through CLI.

Comment by vaughnmb [ 14/Oct/13 02:28 PM ]

Could you duplicate the problem? Is there anything else you need me to do?

Comment by vaughnmb [ 09/Dec/13 01:51 PM ]

I'm guessing this problem is being ignored or couldn't be duplicated? Any feedback would be nice so I can make some organizational decisions.





[GLASSFISH-20763] No confirmation message is displayed when Enable/Disable action is successfully performed Created: 15/Aug/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: xianwu Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)


Tags:
Participants: Anissa Lam and xianwu

 Description   

Reproducible operational steps:

No confirmation message is displayed at Application Targets screen for Enable/Disable action
1) Open GlassFish Admin console
2) Deploy any application (e.g. cart256)
3) Click Applications->cart256, then select Target tab
4) select all targets
5) select Enable from More Actions list
6) No confirmation message is displayed.

No confirmation message is displayed at Resource Targets screen for Enable/Disable action
1) Open GlassFish Admin console
2) Create a jdbc resource (e.g. jdbc/_TimerPool)
3) Click JDBC->JDBC Resources->jdbc/_TimerPool, then select Target tab
4) select all targets
5) click Enable button
6) No confirmation message is displayed.

However, confirmation message is displayed at JDBC Resources screen for Enable/Disable action
1) Open GlassFish Admin console
2) Create a jdbc resource (e.g. jdbc/_TimerPool)
3) Click JDBC->JDBC Resources
4) select all targets
5) click Enable button
6) Confirmation message "Selected resource(s) has been enabled" is displayed.



 Comments   
Comment by xianwu [ 15/Aug/13 06:25 AM ]

Hi Anissa

I have captured the screens (https://www.dropbox.com/s/51cjzhz8f06u1b8/Screens.xls) for your reference.

Regards, Xianwu





[GLASSFISH-20559] The drop-down list could not displayed correctly under Connectors in Windows Created: 20/May/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b88_RC4
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: Windows 2008 R2 ENT x64 zh_TW Native
Bundle: java_ee_sdk-7-web-b88-windows-ml.exe
Locale: zh_TW
JDK: 1.7.0_13 x64


File Attachments: JPEG File adminObjectResource_dropdownList.jpg     JPEG File connectorConnectionPool_dropdownList.jpg     JPEG File workSecurity_dropdownList.jpg    
Tags:
Participants: Anissa Lam and sunny-gui

 Description   

[To reproduce]
1. Install GF with bundle mentioned above.
2. In the Admin Console, go to Connectors > Work Security Maps, and click on New button.

In the New Work Security Map page, the drop-down list of Resource Adapter is not displayed correctly.

It is also reproducible in following pages.
1. Connectors > Connector Resources > New
2. Connectors > Connector Connection Pools > New
3. Connectors > Admin Object Resources > New

Attached screen shots for your reference.

I checked with 'java_ee_sdk-7-b87-jdk7-linux-x64-ml.sh' on OEL6 x64 en_US.UTF-8 & ja_JP.UTF-8, could not reproduce this issue.






[GLASSFISH-21028] CLONE -Deployment from Web Console: temporary files are not deleted Created: 02/Apr/14  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 9.1peur2
Fix Version/s: future release

Type: Bug Priority: Blocker
Reporter: T-Gergely Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,180
Tags:
Participants: Anissa Lam and T-Gergely

 Description   

When anything (war or ear) is deployed from the web console, a temporary file of
the archive is not deleted. It never happens if the same archive is deployed
with command line or remotely from NetBeans IDE.

This is quite a problem, because in this case application server must be
periodically cleaned manually, especially if deployment is very frequent and
applications are not so small.

Example:
Original file: Foo.war
Deployed on server: /tmp/Foo28436.war



 Comments   
Comment by T-Gergely [ 02/Apr/14 11:45 AM ]

The same issue is still present in GlassFish Server Open Source Edition 4.0 (build 89).





[GLASSFISH-20074] severe message about not cleaning threadlocal after accessing console and then shutdown server Created: 27/Mar/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b81
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Hong Zhang Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-20538 Stop domain throws severe message Resolved
Related
is related to GLASSFISH-20056 Failed to load admin console, when re... Resolved
Tags:
Participants: Anissa Lam, Hong Zhang and Shing Wai Chan

 Description   

Start domain, go to localhost:4848 to access console (this will trigger the console application to be loaded), stop domain, and there are following severe messages:

[2013-03-27T09:02:41.566-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.web.util] [tid: _ThreadID=132 _ThreadName=Thread-24] [timeMillis: 1364400161566] [levelValue: 1000] [[
The web application [] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@3f30c487]) and a value of type [org.glassfish.admingui.theme.AdminguiThemeContext] (value [org.glassfish.admingui.theme.AdminguiThemeContext@1ab69b7a]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.]]

[2013-03-27T09:02:41.569-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.web.util] [tid: _ThreadID=132 _ThreadName=Thread-24] [timeMillis: 1364400161569] [levelValue: 1000] [[
The web application [] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@3f30c487]) and a value of type [org.glassfish.admingui.theme.AdminguiThemeContext] (value [org.glassfish.admingui.theme.AdminguiThemeContext@1ab69b7a]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.]]

Not sure if the messages are of any significance, or if the console team should be the one to take a look. Assign to web team for initial evaluation.



 Comments   
Comment by Shing Wai Chan [ 27/Mar/13 05:10 PM ]

The above message indicates that the ThreadLocal object is not cleanup.

Comment by Anissa Lam [ 29/Mar/13 12:05 AM ]

AdminguiThemeContext is created when console launch and plugged in either the community theme or the orcale branded one.
The actual creation of ThreadLocal is in the Woodstock code.
We are not seeing any ill effect, the msg occurs during domain shutdown and since this is in woodstock code, I am deferring this to 4.0.1.





[GLASSFISH-18169] Log not displayed in Raw Log Viewer for instance on a remote config node Created: 11/Jan/12  Updated: 17/Apr/14

Status: Reopened
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2_b16
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: lidiam Assignee: andriy.zhdanov
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ogs-3.1.2-b17-01_09_2012.zip, DAS on Windows XP, config node on solaris


File Attachments: JPEG File empty-raw-log.JPG     Text File server.log.txt    
Tags: 312_gui_new 312_qa 3_1_2-exclude
Participants: andriy.zhdanov, Anissa Lam and lidiam

 Description   

Log is not displayed in Raw Log Viewer for an instance that's running on a remote CONFIG node. See attached screenshot and server.log, that contains the following exception:

[#|2012-01-10T17:23:57.281-0800|SEVERE|glassfish3.1.2|com.sun.jersey.spi.contain
er.ContainerResponse|_ThreadID=63;_ThreadName=Thread-2;|The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.NullPointerException
at com.sun.enterprise.server.logging.logviewer.backend.LogFilter.getLogF
ileForGivenTarget(LogFilter.java:320)
at org.glassfish.admin.rest.resources.custom.LogViewerResource.get(LogVi
ewerResource.java:121)
at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMe
thodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMeth
odDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchPr
ovider.java:205)

Steps to reproduce:

1. Create a CONFIG node on a remote machine in Admin Console (enter name and host only to make it easy).
2. Log in to the remote machine and create standalone instance locally via:

asadmin --host <das host> create-local-instance inty1

3. Start local instance on the remote machine via:

asadmin start-local-intsnce --host <das host> inty1

4. Go to Admin Console and navigate to the Instance General page. Click on View Raw Log - the server.log file content is not displayed.



 Comments   
Comment by Anissa Lam [ 11/Jan/12 04:43 AM ]

Assign to Andriy so he can evaluate the issue.
However, it has passed HCF, we will not be fixing this for 3.1.2. This is based on the reason that this seems to be a corner/not so common case.
The feature works on

  • instance with localhost CONFIG nodes
  • remote instance with SSH nodes
  • remote instance with DCOM nodes

The case that is not working is for case of CONFIG node on remote system, where user needs to login to the remote system to create a local instance and also start that local instance on that machine.

I am adding the exclude tag. If you think otherwise, please bring that up to Joe and the GUI team.

Andriy, if this is a backend bug, please reassign to logging. thanks

Comment by andriy.zhdanov [ 26/Jan/12 01:36 PM ]

I think this can not be supported for remote config nodes - as far as I understand, remote config nodes do not support any communication.

Comment by lidiam [ 27/Jan/12 01:53 AM ]

If we cannot display content of a log file for instances on remote, CONFIG nodes, then the View Raw Log button should not be displayed for those instances.

Comment by Anissa Lam [ 12/Feb/13 12:27 AM ]

Issues need to be addressed before 4.0 HCF (3/25)

Comment by Anissa Lam [ 15/Feb/13 05:04 PM ]

Move to 4.0.1 according to project triage guidelines.





[GLASSFISH-18281] IE9 and Google Chrome only: Export a LB config xml not working properly Created: 31/Jan/12  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2_b19
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: Jason Lee
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OEL, Google Chrome browser 16.0


Issue Links:
Duplicate
is duplicated by GLASSFISH-18282 Export Now button doesn't export load... Resolved
Tags:
Participants: Anissa Lam, arunkumar_s and Jason Lee

 Description   

This issue is browser specific(Only with google chrome browser)

Steps

1) Login Admin Console and Open a LB.
2) Go to Export Tab and click Export Now.

We can see the loadbalancer xml file is downloaded. But after that "A long-running process has been detected. Please wait..." dialog comes up and the admin console page hangs.

The dialog doesn't fade away at all. If we close it manually and try to access Export Tab in a LB , the dialog comes up again and hangs



 Comments   
Comment by Anissa Lam [ 31/Jan/12 03:16 PM ]

Jason, please take a look. You will need to install the Oracle GlassFish version to get the LB config feature.

Comment by Anissa Lam [ 31/Jan/12 10:19 PM ]

This is not a frequently used operation, and there is simple workaround: user a different browser of CLI. This is not a show stopper, exclude from 3.1.2 release.
When fixing this bug, ensure IE9 and Google Chrome works fine, although the root cause may not be the same.

We will release note this.

Comment by Anissa Lam [ 12/Feb/13 12:27 AM ]

Issues need to be addressed before 4.0 HCF (3/25)

Comment by Anissa Lam [ 20/Feb/13 09:40 AM ]

target for 4.0.1 according to guideline.





[GLASSFISH-17324] Nucleus cleanup: admin console start page Created: 20/Sep/11  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-20465 Nucleus doesn't open admin console Resolved
Tags: 3_1_x-exclude nucleus-cleanup
Participants: Anissa Lam and Tom Mueller

 Description   

When port 4848 is accessed on nucleus, the "admin console is loaded" page is shown, but then there is no admin console because nucleus doesn't have one.

After some discussion, the decision was made to keep the AdminConsoleAdapter in nucleus, but to do the following:

1. Modify the messages that are output from nucleus to indicate that there is no admin console. The "console loading" page should only been shown when there is a console that is being loaded. Or, if there is no console configured, then the AdminConsoleAdapter should not be configured at all, thereby resulting in nucleus displaying the default index.html page when http://host:484/ is accessed.

2. Modify the default configuration for nucleus so that there is no admin console configured.

3. Document the configuration data values related to the AdminConsoleAdapter. This should include information about how an admin console application can be installed and configured into nucleus. This documentation should allow a developer that is using nucleus to add a console to it.

4. Either remove the admin console upgrade code from nucleus or move it to appserver. Nucleus should not automatically configure an admin console.



 Comments   
Comment by Anissa Lam [ 11/Feb/13 11:56 PM ]

This issue involves different group, not just admin console.
I am marking this for MS6 for now. Will work with other team to get this addressed.

Comment by Anissa Lam [ 12/Feb/13 12:19 AM ]

Fix by HCF (3/25)

Comment by Anissa Lam [ 12/Feb/13 12:27 AM ]

Issues need to be addressed before 4.0 HCF (3/25)

Comment by Anissa Lam [ 12/Feb/13 07:43 PM ]

This is nucleus cleanup, defer to 4.0.1 according to the bug scrubbing guideline.





[GLASSFISH-20931] UnsupportedCharsetException is not handled properly Created: 17/Dec/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: xianwu Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

« Hide

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

GlassFish build: glassfish-4.0.1-b02-07_22_2013


Tags:
Participants: Anissa Lam and xianwu

 Description   

Reproducible operational steps:

1) set an invalid http.uri-encoding to admin-listener
asadmin set server.network-config.protocols.protocol.admin-listener.http.uri-encoding=testtest
server.network-config.protocols.protocol.admin-listener.http.uri-encoding=testtest
Command set executed successfully.

2) restart domain
asadmin restart-domain domain1
Successfully restarted the domain
Command restart-domain executed successfully.

3) access admin console (IE or FireFox)
http://localhost:4848/common/index.jsf

got page fault
HTPP Status 500-

Detailed logging from server.log

[2013-12-17T12:27:06.753+1100] [glassfish 4.0] [WARNING] [NCLS-CORE-00090] [javax.enterprise.system.core] [tid: _ThreadID=41 _ThreadName=admin-listener(3)] [timeMillis: 1387243626753] [levelValue: 900] [[
Internal Server error: /common/index.jsf
java.nio.charset.UnsupportedCharsetException: testtest
at java.nio.charset.Charset.forName(Charset.java:543)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:246)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:496)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:175)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:187)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:837)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:722)

4) similar issue if set invalid uri-encoding to http-listener-*
For example,
asadmin set server.network-config.protocols.protocol.http-listener-1.http.uri-encoding=testtest
server.network-config.protocols.protocol.http-listener-1.http.uri-encoding=testtest
Command set executed successfully.

It will cause 500 page fault to an application page with similar logging in server.log

5) Suggestion
It should handle UnsupportedCharsetException properly to avoid throwing it to the top level and create 500 page fault






[GLASSFISH-20592] Need better error msg when trying to bring up console with javaee-ri distribution, which doesn't include GUI Created: 30/May/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: pbelbin Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Tags: fishcat
Participants: Anissa Lam, pbelbin and Snjezana Sevo-Zenzerovic

 Description   

downloaded the javaee-ri (date 28May) from the release directory and tried to start it using jdk 7u21 x64 on windows 7, and, even though I had set the JAVA_HOME and updated PATH, the response on the stdout appeared to indicate glassfish had started.

however, using a browser (IE10) all it does is show the spinning thing and shows the status as the adminconsole application is loaded.

it does not progress beyond that.

the default web page at port 8080 does appear and seems normal.

just seems impossible to bring up the admin console.



 Comments   
Comment by pbelbin [ 30/May/13 02:47 AM ]

in the server.log, I do see this:

[2013-05-29T21:46:31.982-0500] [glassfish 4.0] [SEVERE] [NCLS-CORE-00043] [javax.enterprise.system.core] [tid: _ThreadID=106 _ThreadName=Thread-10] [timeMillis: 1369881991982] [levelValue: 1000] [[
Application previously deployed is not at its original location any more: file:/G:/archives/glassfish-4.0/glassfish4/glassfish//lib/install/applications/__admingui]]

I checked the location mentioned, and, indeed, there is no directory __admingui at that directory (which does exist).

Comment by Snjezana Sevo-Zenzerovic [ 30/May/13 09:45 AM ]

FWIW, RI distribution is Java EE reference implementation and and not full GlassFish distribution. As such it does not contain Admin console functionality.

Leaving the issue open to see whether we need to enhance something in the future release to get more graceful behavior since the message about admin console loading is rather misleading.

Comment by Anissa Lam [ 30/May/13 06:16 PM ]

As Snjezana pointed out, console is not include/supported for RI. It should give proper/better message so user can realize that, instead of hidden in the server.log. Don't think this should be classified as a blocker. Downgrading the priority.

This is similar to GLASSFISH-17324, where the same thing occurs when user tries to bring up the console with the nucleus distribution.
We will address both at the same time.

Comment by Anissa Lam [ 30/May/13 06:19 PM ]

edit subject to better describe the issue.





[GLASSFISH-20837] Glassfish admin listener thread failure trying to login due to NPE Created: 01/Oct/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: arie_golos Assignee: Anissa Lam
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux SUSE 11.3, JDK 1.7.0_25 64 bit, Glassfish4.0
I believe this also happened on my windows 7 machine


Tags: 4_0_1-review admin-gui
Participants: Anissa Lam and arie_golos

 Description   

[2013-10-01T11:07:19.750-0400] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=197 _ThreadName=admin-listener(16)] [timeMillis: 1380640039750] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException
at org.glassfish.admingui.common.util.GuiUtil.genId(GuiUtil.java:343)
at org.glassfish.admingui.common.handlers.UtilHandlers.encodeId(UtilHandlers.java:1011)
at sun.reflect.GeneratedMethodAccessor684.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:254)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:724)






[GLASSFISH-20658] @WebService and @Stateless not showing endpoint in GlassFish 4.0 admin console Created: 24/Jun/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Antonio Goncalves Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: admin-gui stateless webservice
Participants: Anissa Lam, Antonio Goncalves and Bruno Borges

 Description   

I wrote two very basic SOAP Web Services (https://github.com/agoncal/agoncal-sample-jaxws/tree/master/01-EndPoints) : one using a servlet endpoint and another one using an EJB endpoint :

@WebService
public class HelloServletEndpoint {

    public String saySomethingServlet(String something) {
        return "The HelloServletEndpoint is saying : " + something;
    }
}
@WebService
@Stateless
public class HelloEJBEndpoint {

    public String saySomethingEJB(String something) {
        return "The HelloEJBEndpoint is saying : " + something;
    }
}

I've packaged them in a war file and deployed the war into a GlassFish 4.0 instance (a full profile). When I check the admin console, I can view the servlet endpoint (test it and see the generated WSDL) but it does not work with the EJB endpoint (see the attached image). Both WSDLs are available though on the following URLs :

Looks like this is a bug in the UI



 Comments   
Comment by Bruno Borges [ 05/Feb/14 04:16 AM ]

Hi Antonio,

The reason to have <EJBName> as context-root for the @Stateless @WebService is for the case when they are deployed inside EJB modules in EAR files (Java EE 5), where there's no Web access (and so, no context-root).

I wonder though if there's anything in the specification of Java EE 6 that clarifies how the context-root of the EJB WebService should behave in the case it is deployed inside a single WAR instead of an EJB module.

Which specification should we be looking at? EJB or JAX-WS?





[GLASSFISH-17805] HTTP LB is broken in GUI, HTTP 500 error when a health checker and lb config is deleted in CLI and accessed in Console Created: 23/Nov/11  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1_b12
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: srinik76 Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-17673 REST endpoint gives response as FAILURE Resolved
Tags: 3_1_x-exclude
Participants: Anissa Lam and srinik76

 Description   

Steps to reproduce

1) Login Glassfish and create a new load balancer with a cluster target.
2) In CLI delete health checker of the lb cluster target using delete-http-health-checker
3) Click Edit health checker of the cluster target of LB in admin console.

Issue --> HTTP 500 error comes up.

Steps:

1) Login glassfish in admin console and create a new http load balancer
2) In CLI delete the LB config using delete-http-lb-config
3) In admin console click Http Load Balancers Tab in left pane.

Issue --> HTTP 500 error throws



 Comments   
Comment by Anissa Lam [ 23/Nov/11 04:52 PM ]

Add 3_1_x-exclude tag since this issue has been fixed in 3.1.2 branch as GLASSFISH-17770

Comment by srinik76 [ 16/Dec/11 11:37 AM ]

In trunk HTTB LB is broken because of rest point failures

Comment by Anissa Lam [ 11/Feb/13 09:53 PM ]

retarget to 4.0.1. Not required for RI release.





[GLASSFISH-20848] There is overlap between Browse button and Location field in the Deploy page Created: 10/Oct/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b89_RC5
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Windows 8 JA x64
Browser&Locale: FF24.0&fr-fr
Bundle: java_ee_sdk-7-b89b-jdk7-windows-ml.exe
JDK: jdk1.7.0_21 x86


File Attachments: JPEG File overlap_application_browseButton.jpg    
Tags:
Participants: Anissa Lam, Jeremy_Lv and sunny-gui

 Description   

To Reproduce:
1. Install & configure GF successfully.
2. Access Admin Console through access http://localhost:4848
3. Go to Application, and click on Deploy button.

Results:
There is overlap between Browse button and Location field in the Deploy page.

Attached screen shot for your reference.



 Comments   
Comment by Jeremy_Lv [ 21/Oct/13 03:41 AM ]

I think this is the Firefox's issue. the same issue can be reproduced when it comes to glassfish v3 and using the latest firefox. However, if you tried to use the IE, the same issue can't reproduced.

In my option, I don't think this is a bug to admin console as it doesn't cause any confusions or regressions for the Glassfish v4's admin console.





[GLASSFISH-20682] Custom JNDI Resources Not Saving Description Field Created: 06/Jul/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin, admin_gui
Affects Version/s: 4.0_b89_RC5
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: fishsticks87 Assignee: Chris Kasso
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Tags: jndi custom_resource description
Participants: Chris Kasso and fishsticks87

 Description   

Using GF Admin, I created a custom JNDI resource of type java.util.Properties. I can successfully add and save the name and value columns in the Additional Properties table but the description column is not retained when saving. I also tried going into the domain.xml file and adding a description attribute to the <property> tag but it just gets wiped away again when I go back into the admin area and save it again.

The description field for each property should be saved and it is not getting saved.






[GLASSFISH-5842] Lack Of JNDI Browser In Admin UI Created: 03/Sep/08  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: V3
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: abien Assignee: andriy.zhdanov
Resolution: Unresolved Votes: 22
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

Operating System: other
Platform: All


Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-17928 OLH for Jndi Browser Sub-task Open Paul Davies  
Issuezilla Id: 5,842
Tags:
Participants: abien, andriy.zhdanov, Anissa Lam, kithouna, Rebecca Parks, TangYong and Tom Mueller

 Description   

Server: GF v3 b22

GF v2 (and actually all other application servers like JBoss or WLS) come with a
visual JNDI browser. This is essential for debugging pursposes - even for
operations.

I would expect to have at least rudimentary functionality to dump the JNDI tree
from the admin UI.

Porting already existing functionality from GF v2 would be fine as well -
although it thrown from time to time exceptions .



 Comments   
Comment by Anissa Lam [ 03/Sep/08 08:59 AM ]

yes, this is on our to-do list for v3 final. Up the priority to ensure that.

Comment by Anissa Lam [ 28/Oct/09 11:18 PM ]

Sorry that even though we do have want to provide this feature for v3, we are
not able to get to this for this release.
We will look into this for v3.1.
thanks

Comment by Tom Mueller [ 27/Jul/10 12:01 PM ]
      • Issue 11793 has been marked as a duplicate of this issue. ***
Comment by Anissa Lam [ 04/Nov/11 03:49 AM ]

Suma, please give estimate of how long it will take to implement this feature. Want to see if this can be fit into 3.1.2 schedule.

Comment by Anissa Lam [ 18/Nov/11 07:42 AM ]

Requesting help from Andriy.

Comment by andriy.zhdanov [ 08/Dec/11 12:51 AM ]

Committed revision 51362 - draft

Comment by Rebecca Parks [ 12/Dec/11 06:11 PM ]

Will there be DHQA for this? Or has there already been one? Do you know which build will have this in it?

Comment by Rebecca Parks [ 13/Dec/11 08:10 PM ]

Just heard from Mike Fitch that this is deferred, changing fix version to future release.

Comment by Anissa Lam [ 14/Dec/11 03:40 AM ]

We missed this feature for 3.1.2. Target this for 4.0

Comment by Anissa Lam [ 09/Jan/13 04:42 PM ]

retarget to after 4.0

Comment by TangYong [ 23/Aug/13 07:57 AM ]

Hi Anissa,

Whether this feature has been in process?

For an ejb with multi-interfaces view, once deploying it, some portable JNDI names(not only one jndi name) will be created by container.

So, for an developer, we'd better browser these names for debugging and etc.by using admin gui.

Pl. let me know whether you are doing or we can help.

Thanks
Tang

Comment by Anissa Lam [ 23/Aug/13 05:52 PM ]

Implementing JNDI browser is not in our plan in the near feature. We may look into this in the next major release.

Comment by Rebecca Parks [ 23/Aug/13 06:09 PM ]

I've stopped watching this issue but can't figure out how to remove myself from the Participants list. If someone else knows, how, please remove me.

Comment by kithouna [ 26/Sep/13 01:10 PM ]

Implementing JNDI browser is not in our plan in the near feature. We may look into this in the next major release.

It's still targeted at 4.0.1...

Comment by Anissa Lam [ 17/Apr/14 01:38 AM ]

change fix version from 4.0.1 to future release as this is for new feature.
4.0.1 is a bug fixing release.





[GLASSFISH-20991] the target of "Selected Targets" and "Available Targets" is wrong Created: 21/Feb/14  Updated: 17/Apr/14

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

Type: Bug Priority: Minor
Reporter: lzg5039 Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux


File Attachments: PNG File targets.png    
Tags:
Participants: Anissa Lam and lzg5039

 Description   

1.create cluster(cluster1)
2."Clusters">"cluster1">"Resources"
3.choose "Admin Object Resources" from the left dropdown
4.change the dropdown of "Resource Type"
now the "Selected Targets" ought to have one target which is cluster1, but now the all targets in the "Available Targets".



 Comments   
Comment by lzg5039 [ 21/Feb/14 11:20 AM ]

Hi Anissa
My fix as follows,add the line after 87 and 124,can you give me some advices

https://svn.java.net/svn/glassfish~svn/trunk/main/appserver/admingui/jca/src/main/resources/adminObjectAttr.inc

85   setAttribute(key="click" value="$this{component}");
86   setAttribute(key="resAdapter" value="#{click.selected}");
87   setAttribute(key="reload" value="#{true}" );
+    setAttribute(key="target" value="#{pageSession.targetValue}" ); 
88   if(#{statusId}) {
89   getUIComponent(clientId="#{statusId}", component=>$attribute{statusComponent});


122  setAttribute(key="click" value="$this{component}");
123  setAttribute(key="resType" value="#{click.selected}")
124  setAttribute(key="reload" value="#{true}" );
+    setAttribute(key="target" value="#{pageSession.targetValue}" ); 
125  getUIComponent(clientId="#{resAdaptorPropId}", component=>$attribute{resAdaptorComponent});
126  getUIComponentProperty(component="$attribute{resAdaptorComponent}", name="selected", value=>$attribute{resAdapter});

Comment by Anissa Lam [ 21/Feb/14 05:41 PM ]

You mean that since you are going to the Admin Object creation screen, the selected target should be whatever you come fom, ie, cluster1.
I am using 4.0 build 89, i cannot reproduce the issue you filed here.
I have 1 instance and 1 cluster created in the domain.
The left box, available target has "server" and "instance1", and the right box, "Selected target" has cluster1.
So, cluster1 is pre-selected for you.

Comment by Anissa Lam [ 21/Feb/14 05:43 PM ]

Attached is what i am seeing. cluster1 preselected correctly,

Comment by lzg5039 [ 24/Feb/14 01:34 AM ]

sorry,the explanation of step 4 does not clear.I will explain as following
1.create cluster(cluster1)
2."Clusters">"cluster1">"Resources"
3.choose "Admin Object Resources" from the left dropdown
4.change the value of "Resource Type" from "javax.jms.Queue" to "javax.jms.Topic"
now the "Selected Targets" ought to have one target which is cluster1, but now the all targets in the "Available Targets".

Comment by Anissa Lam [ 17/Apr/14 01:37 AM ]

downgrade to P4. This is minor issue, user can easily select the target again.





[GLASSFISH-20812] java.lang.IllegalArgumentException when configurate the connector security map Created: 16/Sep/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Jeremy_Lv Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: 40-regression
Participants: Anissa Lam and Jeremy_Lv

 Description   

Here's the reproduced steps:
1). Login the admin console
2). try to access the Connector Connection pool page
3). Access the default Connector Connection pool called jms/__defaultConnectionFactory-Connection-Pool
4). Click the "Security Map" tap and create a new security map
5). Try to configurate the setting property in the security tap and save it.
6). java.lang.IllegalArgumentException will be thrown out to server.log and the property can't be saved!

Here's the stacktrace:

[2013-09-16T17:37:30.928+0800] [glassfish 4.0] [SEVERE] [NCLS-CORE-00003] [javax.enterprise.system.core] [tid: _ThreadID=201 _ThreadName=admin-listener(13)] [timeMillis: 1379324250928] [levelValue: 1000] [[
  Exception while running a command
MultiException stack 1 of 1
java.lang.IllegalArgumentException:  Invalid option: userGroupCommaStr
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.validateParameters(CommandRunnerImpl.java:1026)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1192)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
	at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:253)
	at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:231)
	at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:275)
	at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:133)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:140)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:158)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:101)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:237)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:318)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:211)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:982)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:330)
	at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:316)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:496)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:175)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:187)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:837)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
	at java.lang.Thread.run(Thread.java:722)
]]

[2013-09-16T17:37:31.021+0800] [glassfish 4.0] [SEVERE] [] [org.glassfish.admingui] [tid: _ThreadID=42 _ThreadName=admin-listener(3)] [timeMillis: 1379324251021] [levelValue: 1000] [[
  RestResponse.getResponse() gives FAILURE.  endpoint = 'http://localhost:4848/management/domain/resources/connector-connection-pool/gtrvx/security-map'; attrs = '{userGroupCommaStr=value1, userGroups=value1, poolName=gtrvx, name=aaa, mappedUserName=bbb, mappedPassword=*******}']]


 Comments   
Comment by Jeremy_Lv [ 16/Sep/13 10:45 AM ]

Hi, Anissa:
As the server.log showed, the userGroupCommaStr is a invalid options. So what do you think?





[GLASSFISH-20810] NPE will be thrown to the server.log when save the default value of Availability Service page Created: 12/Sep/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0.1
Fix Version/s: 4.0.1

Type: Bug Priority: Critical
Reporter: Jeremy_Lv Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Issue Links:
Dependency
depends on GLASSFISH-18354 Edit and delete of virtual server fai... Resolved
Tags: 40-regression admin admin-gui 4_0_1-review
Participants: Anissa Lam and Jeremy_Lv

 Description   

Here's my reproduced steps:
1). start the domain
2). login the admin console
3). Access to the Avaliable Service page under default-config.
4). Type the Web Conatiner Availability page and save the default setting
5). Error in saving the default setting
6). The NPE will be thrown to the server.log, here's the stacktrace:

[2013-09-12T16:47:17.532+0800] [glassfish 4.0] [INFO] [NCLS-REST-00003] [javax.enterprise.admin.rest] [tid: _ThreadID=124 _ThreadName=admin-listener(6)] [timeMillis: 1378975637532] [levelValue: 800] [[
  An error occurred while processing the request. Please see the server logs for details.
java.lang.NullPointerException
	at org.glassfish.admin.rest.resources.PropertiesBagResource.setParentAndTagName(PropertiesBagResource.java:265)
	at org.glassfish.admin.rest.resources.generatedASM.WebContainerAvailabilityResource.getPropertiesBagResource(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.jersey.server.internal.routing.SubResourceLocatorRouter$2.run(SubResourceLocatorRouter.java:228)
	at org.glassfish.jersey.server.internal.routing.SubResourceLocatorRouter.getResource(SubResourceLocatorRouter.java:245)
	at org.glassfish.jersey.server.internal.routing.SubResourceLocatorRouter.apply(SubResourceLocatorRouter.java:132)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:120)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:123)
	at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:104)
	at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:63)
	at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:228)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:318)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:211)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:982)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:330)
	at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:316)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:496)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:175)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:187)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:837)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
	at java.lang.Thread.run(Thread.java:722)
]]

Once the NPE was thrown out, All of the operation related to the Availability Service page are useless. So I think it is a critical issue need to be fix as soon as possible.



 Comments   
Comment by Jeremy_Lv [ 12/Sep/13 09:12 AM ]

Hi, Anissa:

I found this phenomenon can't be reproduced in the glassfish v3.1.2.2 right now, So I marked this issue as a 4.0-regression issue and need to be resolved! I will take some times to do some investigation about this failure soon.

Thanks

Comment by Jeremy_Lv [ 12/Sep/13 10:27 AM ]

After compared the PropertiesBagResource.java with glassfish v3's source, I have found the the PropertiesBagResource.setParentAndTagName has a null check there.

Here's the V3's code:

public void setParentAndTagName(Dom parent, String tagName) {
        if(parent == null) {
            return;
        }
        this.parent = parent;
        this.tagName = tagName;
        entity = parent.nodeElements(tagName);
    }

I hope anyone can help me to confirm about this.

Thanks

Comment by Jeremy_Lv [ 12/Sep/13 10:33 AM ]

this issue is similar to GLASSFISH-18354

Comment by Jeremy_Lv [ 12/Sep/13 10:40 AM ]

Although the NPE won't be thrown out after add a null check there, the property setting about the availability Service can't be saved successfully.

So the issue is still exist. Need to fix about this.

Comment by Jeremy_Lv [ 12/Sep/13 10:43 AM ]

Some of the error messages are as follows:

[2013-09-12T18:34:40.751+0800] [glassfish 4.0] [SEVERE] [] [org.glassfish.admingui] [tid: _ThreadID=43 _ThreadName=admin-listener(1)] [timeMillis: 1378982080751] [levelValue: 1000] [[
  RestResponse.getResponse() gives FAILURE.  endpoint = 'http://localhost:4848/management/domain/configs/config/default-config/availability-service/ejb-container-availability.json'; attrs = '{}']]
Comment by Anissa Lam [ 17/Apr/14 01:33 AM ]

It is not just affecting the default-config, but any config referenced by cluster.
Once the error occurs, you get the error in

web container availability tab
ejb container availability tab
jms availability.
when you just want to go to that tab. ie, the error occurs when displaying that tab.
further more, the error persist even AFTER a server restart.

We should try to fix this for 4.0.1.





[GLASSFISH-21042] Interfaces Specified by RemoteHome or LocalHome Not Resolved in SerialContext.lookup as Business Interfaces on EJB Session Beans, Resulting in NPE in JavaGlobalJndiNamingObjectProxy.create Created: 17/Apr/14  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: jonpasski Assignee: srini.gf
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: maven-glassfish-plugin embedded
Participants: jonpasski and srini.gf

 Description   

Had the following error in a JUnit test case using the embedded Glassfish 3.1.1 container:

shouldCreateABook(com.coverity.testsuite.ejb.localhome.BookLocalHomeBeanTest):
Communication exception for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory,
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl,
java.naming.factory.url.pkgs=com.sun.enterprise.naming}
BookLocalHomeBeanTest.java
package com.coverity.testsuite.ejb.localhome;

import java.io.File;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import javax.ejb.embeddable.EJBContainer;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.xml.ws.WebServiceRef;

import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;

import com.coverity.testsuite.ejb.Book;
import com.coverity.testsuite.ejb.localhome.BookLocal;

import static org.junit.Assert.*;

/**
 *
 * @author pasc
 */
public class BookLocalHomeBeanTest {

    private static EJBContainer ec=null;
    private static Context ctx=null;

    public BookLocalHomeBeanTest() {}

    @BeforeClass
    public static void initContainer() throws Exception {
        Map<String, Object> props=new HashMap<String, Object>();
        props.put(EJBContainer.MODULES, new File("target/embedded-classes"));
        props.put("org.glassfish.ejb.embedded.glassfish.instance.root","./src/test/testing-domain");
        props.put("org.glassfish.ejb.embedded.glassfish.web.http.port","");
        props.put("javax.enterprise.system.container.web", "FINE");
        ec = EJBContainer.createEJBContainer(props);
        ctx = ec.getContext();
    }

    @AfterClass
    public static void closeContainer() throws Exception {
        if(ctx!=null)
            ctx.close();
        if(ec!=null)
            ec.close();
    }

    @Test
    public void shouldCreateABook() throws Exception {
        Book book = new Book();
        book.setTitle("The Hitchhiker's Guide to the Galaxy");
        book.setPrice(12.5F);
        book.setDescription("Scifi book created by Douglas Adams");
        book.setIsbn("1-84023-742-2");
        book.setNbOfPages(354);
        book.setIllustrations(false);

        Object obj = ctx.lookup("java:global/embedded-classes/BookLocalHomeBean");
        BookLocalHome bookHome = (BookLocalHome) obj;
        BookLocal bookLocal = bookHome.createBook(book);
        book = bookLocal.findBookById(book.getId());
        assertNotNull("Book should not be null", book);
        assertNotNull("ID should not be null", book.getId());
    }
}

The application I'm using is a modified version of embedded-glassfish-example:

BookLocal.java
package com.coverity.testsuite.ejb.localhome;

import java.util.List;
import javax.ejb.EJBLocalObject;

import com.coverity.testsuite.ejb.Book;

public interface BookLocal extends EJBLocalObject {

    void deleteBook(Book book);

    Book findBookById(Long id);

    List<Book> findBooks();

    Book updateBook(Book book);
}
BookLocalHome.java
package com.coverity.testsuite.ejb.localhome;

import javax.ejb.EJBLocalHome;
import javax.ejb.CreateException;

import com.coverity.testsuite.ejb.Book;

public interface BookLocalHome extends EJBLocalHome {

    public BookLocal createBook(Book book) throws CreateException;
}
BookLocalHomeBean.java
package com.coverity.testsuite.ejb.localhome;

import java.util.List;
import javax.ejb.Stateful;
import javax.ejb.LocalHome;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.annotation.Resource;
import javax.ejb.SessionContext;

import com.coverity.testsuite.ejb.Book;

/**
 *
 * @author pasc
 */
@Stateful
@LocalHome(BookLocalHome.class)
public class BookLocalHomeBean {
    @PersistenceContext(unitName = "bookstore-ejb")
    EntityManager em;

    @Resource
    private SessionContext sessionContext;

    public List<Book> findBooks() {
        return em.createNamedQuery("Book.findAllBooks", Book.class).getResultList();
    }

    public Book findBookById(Long id) {
        return em.find(Book.class, id);
    }

    public void ejbCreateBook(Book book) {
        em.persist(book);
    }

    public void deleteBook(Book book) {
        em.remove(em.merge(book));
    }

    public Book updateBook(Book book) {
        return em.merge(book);
    }
}

The above code hasn't been validated another embedded EJB container, therefore it could be incorrect. It seems correct, based on looking at the JBoss quick start EJB test cases.

I enabled logging within Glassfish by specifying the following in a .properties file:

handlers= java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level=FINEST
com.sun.enterprise.naming.level=FINEST

com.sun.enterprise.naming is specified in LogFacade, used as SerialContext's logger. Passing it to Maven as mvn clean test -Djava.util.logging.config.file=src/test/resources/customlogging.properties results in the nice stack trace, trimmed below:

Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext <init>
FINE: SerialContext ==> SerialContext instance created : SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory,
  java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl,
  java.naming.factory.url.pkgs=com.sun.enterprise.naming}
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext <init>
FINE: Serial Context initializing with process environment org.glassfish.api.admin.ProcessEnvironment@7a341251
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE: SerialContext ==> lookup( java:global/embedded-classes/BookLocalHomeBean)
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE: SerialContext ==> lookup relative name : java:global/embedded-classes/BookLocalHomeBean
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContextProviderImpl lookup
FINE:  SerialContextProviderImpl :: lookup java:global/embedded-classes/BookLocalHomeBean
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE: enterprise_naming.serialctx_communication_exception
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE:
java.lang.NullPointerException
        at com.sun.ejb.containers.JavaGlobalJndiNamingObjectProxy.create(JavaGlobalJndiNamingObjectProxy.java:65)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)

Kicking up Eclipse and debugging the app showed the following:

com.sun.ejb.containers.JavaGlobalJndiNamingObjectProxy.create(Context)
/*    */   public Object create(Context ic) {
/* 63 */     GenericEJBLocalHome genericLocalHome = this.container.getEJBLocalBusinessHome(this.intfName);
/*    */     
/* 65 */     return genericLocalHome.create(this.intfName);
/*    */   }
  • this.intfName = com.coverity.testsuite.ejb.localhome.BookLocalHome
  • genericLocalHome = null

null is being passed into the create call, which triggers the NPE. Looking into `getEJBLocalBusinessHome`:

com.sun.ejb.containers.BaseContainer.getEJBLocalBusinessHome(String)
/*      */   public final GenericEJBLocalHome getEJBLocalBusinessHome(String clientViewClassName)
/*      */   {
/* 1016 */     return isLocalBeanClass(clientViewClassName) ? this.ejbOptionalLocalBusinessHome : this.ejbLocalBusinessHome;
/*      */   }
  • clientViewClassName = com.coverity.testsuite.ejb.localhome.BookLocalHome
  • this.ejbOptionalLocalBusinessHome = null
  • this.ejbLocalBusinessHome = null

Both are null. Let's see which one should have been picked:

com.sun.ejb.containers.BaseContainer.isLocalBeanClass(String)
/*      */   boolean isLocalBeanClass(String className)
/*      */   {
/* 1023 */     return (this.hasOptionalLocalBusinessView) && ((className.equals(this.ejbClass.getName())) || (className.equals(this.ejbGeneratedOptionalLocalBusinessIntfClass.getName())));
/*      */   }
  • this.hasOptionalLocalBusinessView = false
  • className == com.coverity.testsuite.ejb.localhome.BookLocalHome
  • this.ejbClass.getName() == com.coverity.testsuite.ejb.localhome.BookLocalHomeBean
  • this.ejbGeneratedOptionalLocalBusinessIntfClass.getName() == null

isLocalBeanClass returns false. Assuming the bug isn't lurking above, this.ejbLocalBusinessHome should not be null.

Now, BaseContainer is the abstract class. Eclipse is telling me the actual type is com.sun.ejb.containers.StatefulSessionContainer. StatefulSessionContext doesn't set the field ejbLocalBusinessHome. Grepping around ejbLocalBusinessHome is set in BaseContainer:

com.sun.ejb.containers.BaseContainer.initializeHome()
/* 1444 */       if (this.hasLocalBusinessView) {
/* 1445 */         this.ejbLocalBusinessHomeImpl = instantiateEJBLocalBusinessHomeImpl();
/*      */         
/* 1447 */         this.ejbLocalBusinessHome = ((GenericEJBLocalHome)this.ejbLocalBusinessHomeImpl.getEJBLocalHome());
/*      */

To get to that point, isLocal} needs to be true, which it is in this run. For the field to be set, {{this.hasLocalBusinessView needs to be true, which it isn't in this run. BaseContainer sets it only in one spot. (StatefulSessionContainer does reference it; it just doesn't set it.):

com.sun.ejb.containers.BaseContainer.BaseContainer(ContainerType, EjbDescriptor, ClassLoader)
/*  650 */         if (this.ejbDescriptor.isLocalBusinessInterfacesSupported()) {
/*  651 */           this.isLocal = true;
/*  652 */           this.hasLocalBusinessView = true;
  • this.ejbDescriptor = com.sun.enterprise.deployment.EjbSessionDescriptor

And digging into isLocalBusinessInterfacesSupported:

com.sun.enterprise.deployment.EjbAbstractDescriptor.isLocalBusinessInterfacesSupported()
/*     */   public boolean isLocalBusinessInterfacesSupported()
/*     */   {
/* 278 */     return this.localBusinessClassNames.size() > 0;
/*     */   }
  • this.ejbDescriptor.localBusinessClassNames == []

Well, shucks. localBusinessClassNames is set in a ctor and also com.sun.enterprise.deployment.EjbAbstractDescriptor.addLocalBusinessClassName(String):

com.sun.enterprise.deployment.EjbAbstractDescriptor.addLocalBusinessClassName(String)
/*     */   public void addLocalBusinessClassName(String className) {
/* 185 */     this.localBusinessClassNames.add(className);
/*     */   }

Eclipse is saying it's only called by org.glassfish.ejb.deployment.annotation.handlers.AbstractEjbHandler.setBusinessAndHomeInterfaces(EjbDescriptor, AnnotationInfo), whoop. Debugging that method shows this:

org.glassfish.ejb.deployment.annotation.handlers.AbstractEjbHandler.setBusinessAndHomeInterfaces(EjbDescriptor, AnnotationInfo)
...
/* 452 */     if (localBusIntfs.size() > 0) {
/* 453 */       for (Class next : localBusIntfs) {
/* 454 */         ejbDesc.addLocalBusinessClassName(next.getName());
/*     */       }
/*     */     }

And since the EJB bean doesn't have any business interfaces implemented, (as defined by JSR), localBusIntfs is null. From JSR 318:

While it is expected that the bean class will typically implement its business inter- face(s), if the bean class uses annotations or the deployment descriptor to designate its business interface(s), it is not required that the bean class also be specified as imple- menting the interface(s).

In my test case the EJB doesn't implement the interface. But the only way the logic above would not cause the NPE is if a business interface is found. To me that seems like a bug in Glassfish. I'd think the Local interface would have been returned. I dunno what the right thing is, though. Assuming the code above is valid, then yeah, it's a bug.






[GLASSFISH-20764] Remove GTE CyberTrust Solutions's expired certificate from CA DB Created: 15/Aug/13  Updated: 16/Apr/14

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

Type: Bug Priority: Blocker
Reporter: Jay Xu Assignee: michael.y.chen
Resolution: Unresolved Votes: 9
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux 3.8.0-28-generic
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.13.04.2)


Tags: 4_0_1-review
Participants: dzusik12, Jay Xu, michael.y.chen, Tim Quinn and zeto

 Description   

GTE CyberTrust Solutions's certificate expires this morning, which blocks GF's startup, pls remove it from CA DB

Exception log:

[#|2013-08-15T18:00:09.314+0800|SEVERE|oracle-glassfish3.1.2|javax.enterprise.system.ssl.security.com.sun.enterprise.security.ssl.impl|_ThreadID=5422;_ThreadName=Thread-3;|SEC5054: Certificate has expired: [
[
Version: V3
Subject: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: Sun RSA public key, 2048 bits
modulus: 23741889829347261660812437366387754385443431973861114865490414153884050331745811968523116847625570146592736935209718565296053386842135985534863157983128812774162998053673746470782252407673402238146869994438729551246768368782318393878374421033907597162218758024581735139682087126982809511479059100617027892880227587855877479432885604404402435662802390484099065871430585284534529627347717530352189612077130606642676951640071336717026459037542552927905851171460589361570392199748753414855675665635003335769915908187224347232807336022456537328962095005323382940080676931822787496212635993279098588863972868266229522169377
public exponent: 65537
Validity: [From: Fri Aug 14 22:50:00 CST 1998,
To: Thu Aug 15 07:59:00 CST 2013]
Issuer: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
SerialNumber: [ 01b6]

Certificate Extensions: 4
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:5
]

[2]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [1.2.840.113763.1.2.1.3]
[] ]
]

[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]

[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 76 0A 49 21 38 4C 9F DE F8 C4 49 C7 71 71 91 9D v.I!8L....I.qq..
]
]

]
Algorithm: [SHA1withRSA]
Signature:
0000: 41 3A D4 18 5B DA B8 DE 21 1C E1 8E 09 E5 F1 68 A:..[...!......h
0010: 34 FF DE 96 F4 07 F5 A7 3C F3 AC 4A B1 9B FA 92 4.......<..J....
0020: FA 9B ED E6 32 21 AA 4A 76 C5 DC 4F 38 E5 DF D5 ....2!.Jv..O8...
0030: 86 E4 D5 C8 76 7D 98 D7 B1 CD 8F 4D B5 91 23 6C ....v......M..#l
0040: 8B 8A EB EA 7C EF 14 94 C4 C6 F0 1F 4A 2D 32 71 ............J-2q
0050: 63 2B 63 91 26 02 09 B6 80 1D ED E2 CC B8 7F DB c+c.&...........
0060: 87 63 C8 E1 D0 6C 26 B1 35 1D 40 66 10 1B CD 95 .c...l&.5.@f....
0070: 54 18 33 61 EC 13 4F DA 13 F7 99 AF 3E D0 CF 8E T.3a..O.....>...
0080: A6 72 A2 B3 C3 05 9A C9 27 7D 92 CC 7E 52 8D B3 .r......'....R..
0090: AB 70 6D 9E 89 9F 4D EB 1A 75 C2 98 AA D5 02 16 .pm...M..u......
00A0: D7 0C 8A BF 25 E4 EB 2D BC 98 E9 58 38 19 7C B9 ....%..-...X8...
00B0: 37 FE DB E2 99 08 73 06 C7 97 83 6A 7D 10 01 2F 7.....s....j.../
00C0: 32 B9 17 05 4A 65 E6 2F CE BE 5E 53 A6 82 E9 9A 2...Je./..^S....
00D0: 53 0A 84 74 2D 83 CA C8 94 16 76 5F 94 61 28 F0 S..t-.....v_.a(.
00E0: 85 A7 39 BB D7 8B D9 A8 B2 13 1D 54 09 34 24 7D ..9........T.4$.
00F0: 20 81 7D 66 7E A2 90 74 5C 10 C6 BD EC AB 1B C2 ..f...t\.......

]|#]



 Comments   
Comment by zeto [ 28/Aug/13 09:32 AM ]

To remove the "GTE Cybertrust Solutions" certificate from cacerts.jks file of your domain you can use the keytool:
keytool -delete -alias gtecybertrust5ca -keystore cacerts.jks

See also:
http://stackoverflow.com/questions/18248020/certificate-has-expired-in-log-by-starting-glassfish-3-1-2/18249719#18249719

Comment by Tim Quinn [ 28/Aug/13 08:58 PM ]

Kyle noticed this message appearing in the CTS tests for 4.0 when running an app client. (The command line specified truststore-related properties.) The tests succeed as expected anyway, but the same message is showing up in the output.

I've updated the affected-versions list accordingly. Note that for Kyle and me both the 4.0 server started successfully.

Comment by dzusik12 [ 27/Sep/13 10:24 AM ]

Reinstall glassfish and it works then.

//edit: after some runs, it not works again.

//edit2: this is partly solution for the time, until glassfish developers will repair server
http://download.jboss.org/jbossas/7.1/jboss-as-7.1.1.Final/jboss-as-7.1.1.Final.zip





[GLASSFISH-20736] CLONE -@Singleton @Startup (EJB) , with an @Observes(notifyObserver = IF_EXISTS) wont Deploy, Created: 01/Aug/13  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: cdi, ejb_container
Affects Version/s: 3.1.2_b23
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ulrichBerl Assignee: jjsnyder83
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2. Windows 7, Java 1.6,


Tags: Singleton Startup notifyObserver
Participants: jjsnyder83 and ulrichBerl

 Description   

You get this, but i think GF eat the real weld exception somewhere. This happens only with the notifyObserver parameter, without is working fine, but i want to listen to events only when all i say so!!

I don't Implement any interface or something similar,...

@Singleton
@Startup
@TransactionManagement(TransactionManagementType.BEAN)
public class SubsystemConnectionMonitor {

// stuff
public void subsystemConnectionEventFired(
@Observes(notifyObserver = IF_EXISTS) SubsystemConnectionEvent incomingEvent) { subsystemConnectionMonitor.subsystemConnectionEventFired(incomingEvent); }

//other stuff

}

Then you get this,...
2013-03-05 16:54:41.278 SEVERE 20 Exception while loading the app (javax.enterprise.system.core.com.sun.enterprise.v3.server)
2013-03-05 16:54:42.963 SEVERE 20 Exception while shutting down application container (javax.enterprise.system.tools.admin.org.glassfish.deployment.admin)



 Comments   
Comment by jjsnyder83 [ 16/Apr/14 07:49 PM ]

Can you please test this against GF 4.0?





[GLASSFISH-20959] JMSContext injection does not work in CDI bean that is jbatch artifact. Created: 18/Jan/14  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: batch, cdi, jms
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jiggster Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS X 10.9, Ubuntu 12.04, Windows 7


Tags: 4_0_1-evangelists 4_0_1-review batch cdi jms
Participants: jiggster, jjsnyder83 and Mahesh Kannan

 Description   

The following construct does not work when used inside CDI bean that is batch artifact:

@Inject private JMSContext context;

It results in org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped when the injected context is used.



 Comments   
Comment by jiggster [ 18/Jan/14 09:23 PM ]

How can I add attachment? Would like to upload sample application that presents the issue...

Comment by jjsnyder83 [ 16/Apr/14 06:25 PM ]

Login and you should see "Attach file" under Operations on the left column.





[GLASSFISH-20996] EJB CreateException when calling a method in a retrieved local interface Created: 28/Feb/14  Updated: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: sicruise Assignee: jjsnyder83
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jdk7u51 64 bit , glassfish 4 up to glassfish-4.0.1-b04-02_26_2014, ubuntu


Tags: ejb createexception
Participants: Hong Zhang, jjsnyder83 and sicruise

 Description   

This application works perfectly in 3.1.2.2 and there has been no changes to the way beans are loaded when migrating to glassfish 4.

Application is building using jars under glassfish/modules directory, the same ones used for running.

EJB's effected so far are all marked with @Stateless annotation. The example here is the first bean that is executed on application startup.

EJB is being picked up and loaded into JNDI and when getting it from jndi it is an instance of the correct object. Just when you go to call a method in the bean it fails.

[2014-02-28T10:35:04.247+0000] [glassfish 4.0] [INFO] [AS-EJB-00054] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(3)] [timeMillis: 1393583704247] [levelValue: 800] [[
Portable JNDI names for EJB DAOStatisticBean: [java:global/merchant/webapp/DAOStatisticBean, java:global/merchant/webapp/DAOStatisticBean!com.merchant.ejb.DAOStatisticBean]]]

but then...

[2014-02-28T10:35:08.055+0000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(3)] [timeMillis: 1393583708055] [levelValue: 1000] [[
ejb.stateless_ejbcreate_exception]]

[2014-02-28T10:35:08.056+0000] [glassfish 4.0] [WARNING] [AS-EJB-00056] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(3)] [timeMillis: 1393583708056] [levelValue: 900] [[
A system exception occurred during an invocation on EJB DAOStatisticBean, method: public com.merchant.dto.DAOStatisticDTO com.merchant.ejb.DAOStatisticBean.loadTodayStatistic() throws javax.ejb.EJBException]]

Root Cause of CreateException

Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:333)
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:988)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:1185)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:185)
at org.glassfish.weld.services.JCDIServiceImpl._createJCDIInjectionContext(JCDIServiceImpl.java:198)
at org.glassfish.weld.services.JCDIServiceImpl.createJCDIInjectionContext(JCDIServiceImpl.java:179)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1696)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:456)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2579)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1971)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy338.loadTodayStatistic(Unknown Source)
at com.merchant.ejb._EJB31_GeneratedDAOStatisticBeanIntf__Bean_.loadTodayStatistic(Unknown Source)
at com.merchant.thread.DAOStatisticThread.<init>(DAOStatisticThread.java:84)
at com.merchant.thread.DAOStatisticThread.startThread(DAOStatisticThread.java:195)
at com.merchant.InitServlet.init(InitServlet.java:102)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1583)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1382)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5704)



 Comments   
Comment by Hong Zhang [ 11/Apr/14 07:45 PM ]

As stack trace is from CDI code, assign to cdi team for initial evaluation.

Comment by jjsnyder83 [ 16/Apr/14 06:17 PM ]

Can you please provide a source code example of:

  • The definition of the ejb
  • How it is injected into the servlet (I assume it is injected into a servlet based on the stack trace)
  • How it is accessed that causes the exception.




[GLASSFISH-20960] Batch job won't start when glassfish application versioning is used. Created: 19/Jan/14  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: batch
Affects Version/s: 4.0
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: jiggster Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 12.04, Mac OS X 10.9, Windows 7


Tags: 4_0_1-evangelists 4_0_1-review application-versioning batch
Participants: jiggster and Mahesh Kannan

 Description   

To reproduce the issue take the webserverlog batch application sample from the java ee 7 tutorial, add the glassfish-web.xml file and make sure it contains the version-identifier element with the value, say, 1.0. Build and deploy the applicaiton, go to http://localhost:8080/webserverlog/ (assuming your instance listens on 8080) and start the batch job. The status of the job will change to STARTING, but the job itself won't start executing.

I can upload the source code of the modified version of the webserverlog sample application, but I don't know how to add the attachments.



 Comments   
Comment by jiggster [ 21/Jan/14 03:11 PM ]

Is there any chance that this issue will be evaluated any time soon?

Regards,
Jigg

Comment by Mahesh Kannan [ 16/Apr/14 05:58 PM ]

Mark for 4.0.1





[GLASSFISH-21041] make schema/table-prefix/table-suffix configurable for batch status tables Created: 16/Apr/14  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: batch
Affects Version/s: 4.0
Fix Version/s: 4.0.1

Type: Improvement Priority: Major
Reporter: ChristianSch Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: ChristianSch and Mahesh Kannan

 Description   

currently schema is hard coded, see GLASSFISH-20886

to comply with site policies / name scheme it would be useful to be able to define not only schema, but also table-prefix and suffix, for example javax.batch.table-prefix="T_"



 Comments   
Comment by Mahesh Kannan [ 16/Apr/14 05:57 PM ]

Mar for 4.0.1





[GLASSFISH-20942] javax.batch.operations.JobStartException: java.lang.IllegalArgumentException: xJCL invalid per schema Created: 27/Dec/13  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: batch
Affects Version/s: 4.0
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: aronrodrigues Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Net Beans 4


Tags: 4_0_1-evangelists 4_0_1-review Jobs
Participants: aronrodrigues, Mahesh Kannan and reza_rahman

 Description   

When I try to debug my project, all the job fails with this error. Maybe because some jobs starts at the same time.

The strange behaviour is when I'm not debugging, I have the same error too.

SEVERE: java.lang.RuntimeException: org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
javax.batch.operations.JobStartException: java.lang.RuntimeException: org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:90)
at br.com.oscarasdati.msdcdm.core.CronJobBatchRunner.run(CronJobBatchRunner.java:99)
at br.com.oscarasdati.msdcdm.core.CronJobBatchRunner.timeout(CronJobBatchRunner.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4695)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
at sun.reflect.GeneratedMethodAccessor68.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:145)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4667)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:3993)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1199)
at com.sun.ejb.containers.EJBTimerService.access$000(EJBTimerService.java:89)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:1919)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.RuntimeException: org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
at com.ibm.jbatch.jsl.util.ValidatorHelper.getXJCLSchema(ValidatorHelper.java:42)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.unmarshalJobXML(JobModelResolverImpl.java:58)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.access$000(JobModelResolverImpl.java:45)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl$1.run(JobModelResolverImpl.java:127)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl$1.run(JobModelResolverImpl.java:125)
at java.security.AccessController.doPrivileged(Native Method)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.resolveModel(JobModelResolverImpl.java:123)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.resolveModel(JobModelResolverImpl.java:45)
at com.ibm.jbatch.container.jobinstance.JobExecutionHelper.startJob(JobExecutionHelper.java:114)
at com.ibm.jbatch.container.impl.BatchKernelImpl.startJob(BatchKernelImpl.java:123)
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.startInternal(JobOperatorImpl.java:121)
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:86)
... 39 more
Caused by: org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
at com.sun.org.apache.xerces.internal.jaxp.validation.Util.toSAXException(Util.java:65)
at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:259)
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:627)
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:659)
at com.ibm.jbatch.jsl.util.ValidatorHelper.getXJCLSchema(ValidatorHelper.java:40)
... 50 more

WARNING: JSL invalid per XSD, details:
MESSAGE: cvc-elt.1: Cannot find the declaration of element 'job'.
SEVERITY: 2
LINKED EXC: org.xml.sax.SAXParseException; lineNumber: 3; columnNumber: 21; cvc-elt.1: Cannot find the declaration of element 'job'.
LOCATOR INFO:
------------
COLUMN NUMBER: 21
LINE NUMBER: 3
OFFSET: -1
CLASS: class javax.xml.bind.helpers.ValidationEventLocatorImpl
NODE: null
OBJECT: null
URL: null



 Comments   
Comment by aronrodrigues [ 09/Jan/14 06:41 PM ]

Could you reproduce it? Can I help?

Comment by reza_rahman [ 15/Jan/14 11:40 PM ]

Could you outline the steps to reproduce?

Comment by aronrodrigues [ 16/Jan/14 12:17 AM ]

Create 2 @Startup @Singleton Beans which starts 2 differents jobs at the same time. Run sometimes...
I made an workaround making a syncronized block in the timeout method with a static variable.

Comment by Mahesh Kannan [ 16/Apr/14 05:57 PM ]

Mark for 4.0.1





[GLASSFISH-20886] jbatch reference implementation does not work with oracle database as job repository. Created: 07/Nov/13  Updated: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: jiggster Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 (though this is almost certainly platform agnostic problem).


Tags: batch
Participants: ChristianSch, jiggster and Mahesh Kannan

 Description   

Steps to reproduce the bug:

  • Have a working instance of the Oracle database with some test schema. Schema name is very important and must be other than APP or JBATCH - in my case it was simply BATCH.
  • Install GlassFish Server Open Source Edition 4.0 with the default domain1 domain.
  • Install Oracle JDBC driver for the target database, i.e. place the driver's JAR file in domain's lib directory.
  • Execute the %GLASSFISH_HOME%\glassfish\lib\install\databases\jsr352-oracle.sql script in the target database schema.
  • Create jdbc connection pool to Oracle database schema, say jdbc/pool/oracle.
asadmin create-jdbc-connection-pool -e --datasourceclassname oracle.jdbc.xa.client.OracleXADataSource --restype javax.sql.XADataSource --steadypoolsize 2 --maxpoolsize 8 --maxwait 30000 --poolresize 1 --idletimeout 300 --isconnectvalidatereq=true --isolationlevel read-committed --validationmethod table --validationtable DUAL --failconnection=true --allownoncomponentcallers=false --nontransactionalconnections=false --description "Connection pool supporting distributed transactions to BATCH schema in local Oracle database." --property "User=BATCH:Password=BATCH123:URL=jdbc\:oracle\:thin\:@localhost\:1521\:orcl:LoginTimeout=5000:DataSourceName=OracleXADataSource" jdbc/pool/batch
  • Create jdbc resource (jdbc/oracle) that wraps the jdbc/pool/oracle
asadmin create-jdbc-resource --target server --connectionpoolid jdbc/pool/oracle --enabled=true --description "Wrapper for jdbc/pool/oracle JDBC connection pool." jdbc/oracle
  • Set jdbc/oracle resource as the target data source for the batch configuration in server instance
asadmin set-batch-runtime-configuration --datasourcelookupname jdbc/oracle
  • Restart domain - not sure if it's necessary, but I think it is.
  • Deploy the webserverlog application from Java EE 7 tutorial - will try to upload app archive.
  • Go to http://localhost:8080/webserverlog/ and click the "Start Batch Job" button - it shall fail with the "java.sql.SQLSyntaxErrorException: ORA-00922: missing or invalid option".

I spent half of the day tracing the cause of this problem and it seems that the reference batch implementation that is part of the GlassFish server always sets the APP schema on the database connection before proceeding with any database operation, as can be seen in the getConnection method. I found this out by turning on the JDBC driver's logging (by adding the JVM system property -Doracle.jdbc.Trace=true) and adding new logger (logger name: oracle, level: FINEST).



 Comments   
Comment by jiggster [ 07/Nov/13 05:48 PM ]

I've just made a test and can confirm that this issue also occurs for MySQL batch job repository. This time the test was made on mac os x 10.9; MySQL version: 5.6.14 MySQL Community Server (GPL). Below is a full stack trace.

Stack Trace
[2013-11-07T18:25:43.706+0100] [glassfish 4.0] [FATAL] [] [javax.enterprise.resource.webcontainer.jsf.context] [tid: _ThreadID=20 _ThreadName=http-listener-1(3)] [timeMillis: 1383845143706] [levelValue: 1100] [[
  #{jsfBean.startBatchJob()}: javax.batch.operations.JobStartException: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQ
L server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
javax.faces.FacesException: #{jsfBean.startBatchJob()}: javax.batch.operations.JobStartException: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual tha
t corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:89)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
        at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
        at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
        at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
        at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
        at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
        at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
        at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
        at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
        at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
        at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
        at java.lang.Thread.run(Thread.java:744)
Caused by: javax.faces.FacesException: #{jsfBean.startBatchJob()}: javax.batch.operations.JobStartException: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118)
        at javax.faces.component.UICommand.broadcast(UICommand.java:315)
        at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
        at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
        at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
        ... 30 more
Caused by: javax.faces.el.EvaluationException: javax.batch.operations.JobStartException: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:101)
        at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
        ... 34 more
Caused by: javax.batch.operations.JobStartException: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:90)
        at javaeetutorial.batch.webserverlog.beans.JsfBean.startBatchJob(JsfBean.java:59)
        at org.jboss.weldeetutorial.batch.webserverlog.beans.JsfBean$Proxy$_$$_WeldClientProxy.startBatchJob(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at javax.el.ELUtil.invokeMethod(ELUtil.java:326)
        at javax.el.BeanELResolver.invoke(BeanELResolver.java:536)
        at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
        at com.sun.el.parser.AstValue.invoke(AstValue.java:269)
        at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
        at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
        at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
        at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
        at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87)
        ... 35 more
Caused by: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.createJobInstance(JDBCPersistenceManagerImpl.java:1712)
        at com.ibm.jbatch.container.jobinstance.JobExecutionHelper.getNewJobInstance(JobExecutionHelper.java:89)
        at com.ibm.jbatch.container.jobinstance.JobExecutionHelper.startJob(JobExecutionHelper.java:120)
        at com.ibm.jbatch.container.impl.BatchKernelImpl.startJob(BatchKernelImpl.java:123)
        at com.ibm.jbatch.container.api.impl.JobOperatorImpl.startInternal(JobOperatorImpl.java:121)
        at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:86)
        ... 50 more
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
        at com.mysql.jdbc.Util.getInstance(Util.java:386)
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1054)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4237)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4169)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2617)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2778)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2825)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2156)
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2459)
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2376)
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2360)
        at com.sun.gjc.spi.base.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:125)
!!!IMPORTANT PART OF THE STACK TRACE BELOW!!!
        at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.setSchemaOnConnection(JDBCPersistenceManagerImpl.java:386)
        at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.getConnection(JDBCPersistenceManagerImpl.java:323)
        at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.createJobInstance(JDBCPersistenceManagerImpl.java:1700)
        ... 55 more

I think that the key question is how does GlassFish sets the schema property of DatabaseConfigurationBean class? Can we set this property somewhere in domain.xml?

Comment by jiggster [ 08/Nov/13 03:35 PM ]

Another issue I've just found in the jbatch 1.0 reference implementation is that the createJobInstance method (and certainly some other methods also) won't work with ojdbc6 Oracle driver, because of the below code fragment, which assumes that the generated primary key is of Long data type (perfectly right assumption if the schema objects were created using the provided jsr352-oracle.sql script), but unfortunately the driver will raise the java.sql.SQLException: Invalid column type: getLong not implemented for class oracle.jdbc.driver.T4CRowidAccessor - more info here.

statement = conn.prepareStatement("INSERT INTO jobinstancedata (name, apptag) VALUES(?, ?)", Statement.RETURN_GENERATED_KEYS);
statement.setString(1, name);
statement.setString(2, apptag);
statement.executeUpdate();
rs = statement.getGeneratedKeys();
if(rs.next()) {
	long jobInstanceID = rs.getLong(1);
	jobInstance = new JobInstanceImpl(jobInstanceID, jobXml);
	jobInstance.setJobName(name);
}

I was really hoping to make use of jsr 352 API in our ongoing project, but it seems (unfortunately) that there's still no solid, cross-platform implementation...

Comment by jiggster [ 18/Nov/13 11:51 AM ]

Is there any chance that someone will evaluate this issue in the near future?

Thank you.

Comment by ChristianSch [ 27/Mar/14 07:45 AM ]

thank you for the analysis of this issue, saved me a lot of time ...

I can confirm that this issue is still present in 4.0.1 b04

as a workaround I'm using the following patch

diff JDBCPersistenceManagerImpl.java com.ibm.jbatch-runtime-all/com/ibm/jbatch/container/services/impl/JDBCPersistenceManagerImpl.java
382a383,385
>               logger.info("setSchemaOnConnection disabled!");
>               return;
> /*
390a394
> */
1673c1677
<                       statement = conn.prepareStatement("INSERT INTO jobinstancedata (name, apptag) VALUES(?, ?)", Statement.RETURN_GENERATED_KEYS);
---
>                       statement = conn.prepareStatement("INSERT INTO jobinstancedata (name, apptag) VALUES(?, ?)", new String[] {"jobinstanceid"});
1703c1707
<                       statement = conn.prepareStatement("INSERT INTO jobinstancedata (name, apptag) VALUES(?, ?)", Statement.RETURN_GENERATED_KEYS);
---
>                       statement = conn.prepareStatement("INSERT INTO jobinstancedata (name, apptag) VALUES(?, ?)", new String[] {"jobinstanceid"});
1742c1746
<                       statement = conn.prepareStatement("INSERT INTO executioninstancedata (jobinstanceid, createtime, updatetime, batchstatus, parameters) VALUES(?, ?, ?, ?, ?)", Statement.RETURN_GENERATED_KEYS);
---
>                       statement = conn.prepareStatement("INSERT INTO executioninstancedata (jobinstanceid, createtime, updatetime, batchstatus, parameters) VALUES(?, ?, ?, ?, ?)", new String[]{"jobexecid"});
1845c1849
<                       statement = conn.prepareStatement(query, Statement.RETURN_GENERATED_KEYS);
---
>                       statement = conn.prepareStatement(query, new String[] {"stepexecid"});
Comment by Mahesh Kannan [ 16/Apr/14 05:56 PM ]

Mark for 4.0.1





[GLASSFISH-20999] description attribute on Topic doesn't get set Created: 01/Mar/14  Updated: 16/Apr/14

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

Type: New Feature Priority: Major
Reporter: pranahata Assignee: David Zhao
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: amyk, David Zhao and pranahata

 Description   

When setting the description attribute of a Topic via @JMSDestinationDefinition or glassfish-resources, it doesn't show either on the client or on the server when doing a toString of the Topic object.



 Comments   
Comment by amyk [ 16/Apr/14 03:02 AM ]

Hi David, please evaluate this to see where the 'description' should be displayed for a JMSDestinationDefinition annotation as a GlassFish JMS resource. Since @JMSDestinationDefinition annotates a Java EE JMS resource, the 'description' attribute is for the Java EE JMS resource. Neither Java EE specification nor JMS specification specifies this 'description' be a description for the associated JMS provider's Destination object, further JMS API javadoc only says following for Queue.toString() and Topic.toString(), hence this is not a bug in Topic.toString()

/** Returns a string representation of this object.
 *
 * @return the provider-specific identity values for this topic
 */
Comment by David Zhao [ 16/Apr/14 08:51 AM ]

The JMS admin objects created via admin console or asadmin can take and show the description property. But the property is not included in Queue.toString() either.

Currently the JMS resources defined by annotations like @JMSDestinationDefinition are not shown in the admin gui although it is global scoped. So now the description property will not be seen anywhere in the admin gui, except it is in the codes to be as comments.

To summarize it,

1) It is same as normal JMS resources which are created traditionally that the description is not shown in the toString().
2) If it is decided that the resources defined by annotations are shown in admin gui in the funture, then the description will appear there.

Question to Amy,

Should the description go to Queue.imqDestinationDescription?

Comment by amyk [ 16/Apr/14 02:01 PM ]

>Should the description go to Queue.imqDestinationDescription?

That would be a GlassFish proprietary enhancement. Currently there is no specification (standard) govers this association.





[GLASSFISH-18536] GF callback handler blocking a JASPIC provider when Principal is unknown Created: 21/Mar/12  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: None
Fix Version/s: future release

Type: Bug Priority: Blocker
Reporter: bjb Assignee: JeffTancill
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 2008 64bits


Tags: JASPIC blocking users groups principal unknown
Participants: arjan tijms, bjb, JeffTancill and kumarjayanti

 Description   

When sending an unknown Principal (principal not valid as per a local JAAS config) but valid on a global perspective (all checks was done in the JASPIC provider), the GF CallerPrincipal handler will throw a blocking exception in the process :

com.sun.enterprise.security.auth.realm.NoSuchUserException: Cet utilisateur [USER@INTRA-DEV01.DOMAIN-DEV01.LOCAL] n'existe pas. at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:329) at com.sun.enterprise.security.auth.login.LoginContextDriver.jmacLogin(LoginContextDriver.java:566) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.processCallerPrincipal(BaseContainerCallbackHandler.java:257) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.processCallback(BaseContainerCallbackHandler.java:197) at com.sun.enterprise.security.jmac.callback.ServerContainerCallbackHandler.handleSupportedCallbacks(ServerContainerCallbackHandler.java:76) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.handle(BaseContainerCallbackHandler.java:187) at com.sun.enterprise.security.jmac.callback.ContainerCallbackHandler.handle(ContainerCallbackHandler.java:83) at net.java.spnego.PACSpnegoServerAuthModule.updateCallerPrincipal(PACSpnegoServerAuthModule.java:550) at net.java.spnego.PACSpnegoServerAuthModule.validateRequest(PACSpnegoServerAuthModule.java:354) at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:1171) at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1445) at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1323) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623) at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662)

The problem is that groups that were provided before with a call to the GF handler (Group handler) is not used but insteand GF access the default realm (file) to fetch the user's groups.

This is blocking usage of non-JAAS bridge profile JASPIC providers.

To lower the state of this issue, either fix the issue or provide a way to bypass this issue.



 Comments   
Comment by bjb [ 24/Mar/12 08:37 AM ]

Hi Kumar,

Please lower the priority level as it is actually not blocking but only misleading.

It will not block non-JAAS bridge but simply push a wrong track to people debugging.

The core issue has been logged as :
http://java.net/jira/browse/GLASSFISH-18556

When runing in JASPIC mode, such an issue should not be raised.

Rgs,
JB

Comment by kumarjayanti [ 25/Mar/12 04:21 AM ]

This issue does sound like it needs a fix. The caller principal callback is trying to do an identity assertion in this case forcing people to also configure a realm that can be used to fetch the groups of the user. This was done to meet requirements of some other usecases but now i realize this is not appropriate. Instead the Group Principal Callback should be explicitly used in this case.

I will fix this for 3.1.2 Patch releases and glassfish trunk.

Thanks for raising this issue.

Comment by arjan tijms [ 13/Apr/13 11:42 AM ]

Is this still the same issue as reported? I've done a lot of JASPIC testing with GlassFish 3.1.2.2 but never encountered this issue. There is something fishy going on though.

The caller principal callback is trying to do an identity assertion in this case

I think you mean the caller principal callback handler right? Since the caller principal callback is a very simple DTO style class that only stores the Subject and the Principal or Name.

The handler (in BaseContainerCallbackHandler.processCallerPrincipal) does a call to the LoginContextDriver, but it itself does not do any identity assertion:

if (isCertRealm) {
    if (principal  instanceof X500Principal) {
        LoginContextDriver.jmacLogin(fs, (X500Principal)principal);
    }
} else {
    if (!principal.equals(SecurityContext.getDefaultCallerPrincipal())) {
        LoginContextDriver.jmacLogin(fs, principal.getName(), realmName);
    }
}

The LoginContextDriver.jmacLogin however does attempt to do this:

public static Subject jmacLogin(Subject subject, String identityAssertion, String realm) throws LoginException {

        if (subject == null) {
            subject = new Subject();
        }
        final Subject fs = subject;
        String userName = identityAssertion;

        try {
            if (realm == null || "".equals(realm)) {
                realm = Realm.getDefaultRealm();
            }
            Realm realmInst = Realm.getInstance(realm);
            final Enumeration groups = realmInst.getGroupNames(userName);
            if (groups != null && groups.hasMoreElements()) {
                AppservAccessController.doPrivileged(new PrivilegedAction() {

                    public java.lang.Object run() {
                        while (groups.hasMoreElements()) {
                            String grp = (String) groups.nextElement();
                            fs.getPrincipals().add(new Group(grp));
                        }
                        return fs;
                    }
                });
            }
        } catch (Exception ex) {
            if (_logger.isLoggable(Level.FINE)) {
                _logger.log(Level.FINE, "Exception when trying to populate groups for CallerPrincipal " + identityAssertion, ex);
            }
        }
        return subject;
    }

When using JASPIC, the passed in realm will be "" and when that happens this method obtains the default realm ("file") and tries to get the group names from that (realmInst.getGroupNames(userName);).

If this throws an exception (in my testing a NPE is typically thrown) it is ignored by the catch, so the problem as described for this issue doesn't seem to occur anymore (that is, the exception is still thrown, but it doesn't interrupt the authentication flow).

I'm afraid though that if I happened to have this file realm defined with a user that happened to have the same name as the user I'm trying to authenticate with JASPIC, that this user would suddenly get a set of extra roles. If my application happened to have roles with the same name, then this could be a rather big problem.





[GLASSFISH-13514] app-scoped-resources lookup fails when lookup happens in a transaction in app-client Created: 17/Sep/10  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: naming
Affects Version/s: 3.1
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: lemon_zhang
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Text File console.log     Text File stmt-timeout-gf-resources-appclient.tar.gz    
Issuezilla Id: 13,514
Tags: 3_1-exclude 4_0_1-review
Participants: Cheng Fang, Jagadish, Ken Cavanaugh, lemon_zhang and marina vatkina

 Description   

Raising this issue after the discussion with Marina, Ken.

In App-Client, whenever a lookup of application-scoped-resource
(java:app prefixed resource) is made in the context of a transaction, it
fails with the following exceptions.

Sample code snippet (app-client) :
----------------------------------------------------------------------------------------------------
public void doAppClientTest() {

try { InitialContext ic = new InitialContext(); UserTransaction ut = (UserTransaction) ic.lookup( "java:comp/UserTransaction"); ut.begin(); System.out.println("** APP CLIENT LOOKUP : " + ic.lookup("java:app/jdbc/txpoolAppClient")); ut.commit(); } catch (Exception e) {
}
}
----------------------------------------------------------------------------------------------------

[1] : This happens for the first time lookup.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[echo] java.lang.IllegalStateException
[echo] at
com.sun.jts.jta.TransactionServiceProperties.startRecoveryThread(TransactionServiceProperties.java:265)
[echo] at
com.sun.jts.jta.TransactionManagerImpl.<init>(TransactionManagerImpl.java:198)
[echo] at
com.sun.jts.jta.TransactionManagerImpl.getTransactionManagerImpl(TransactionManagerImpl.java:177)
[echo] at
com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.setTransactionManager(JavaEETransactionManagerJTSDelegate.java:446)
[echo] at
com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.startJTSTx(JavaEETransactionManagerJTSDelegate.java:382)
[echo] at
com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.startJTSTx(JavaEETransactionManagerSimplified.java:394)
[echo] at
com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.checkTransactionExport(JavaEETransactionManagerSimplified.java:715)
[echo] at
com.sun.enterprise.transaction.jts.iiop.TransactionClientInterceptor.send_request(TransactionClientInterceptor.java:97)
[echo] at
com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeClientInterceptorStartingPoint(InterceptorInvoker.java:272)
[echo] at
com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeClientPIStartingPoint(PIHandlerImpl.java:385)
[echo] at
com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:301)
[echo] at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:198)
[echo] at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:365)
[echo] at
org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
[echo] at
org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.narrowProvider(SerialContext.java:435)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:407)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:334)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:527)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:474)
[echo] at
javax.naming.InitialContext.lookup(InitialContext.java:392)
[echo] at
com.sun.enterprise.container.common.impl.JavaModuleNamingProxy.getJavaModuleOrAppEJB(JavaModuleNamingProxy.java:303)
[echo] at
com.sun.enterprise.container.common.impl.JavaModuleNamingProxy.handle(JavaModuleNamingProxy.java:133)
[echo] at
com.sun.enterprise.naming.impl.NamedNamingObjectManager.tryNamedProxies(NamedNamingObjectManager.java:88)
[echo] at
com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:171)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:521)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:474)
[echo] at
javax.naming.InitialContext.lookup(InitialContext.java:392)
[echo] at
connector.sunresources.client.Client.doAppClientTest(Client.java:81)
[echo] at
connector.sunresources.client.Client.main(Client.java:64)
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[2] : This exception happens for every "application scoped" lookup ie.,
"java:app"
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[echo] SEVERE:
[echo] javax.transaction.InvalidTransactionException: CORBA
INVALID_TRANSACTION 0 No; nested exception is:
[echo] org.omg.CORBA.INVALID_TRANSACTION: vmcid: 0x0 minor
code: 0 completed: No
[echo] at
com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:296)
[echo] at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:204)
[echo] at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:151)
[echo] at
com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:229)
[echo] at
com.sun.enterprise.naming.impl._SerialContextProvider_DynamicStub.lookup(com/sun/enterprise/naming/impl/_SerialContextProvider_DynamicStub.java)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:528)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:474)
[echo] at
javax.naming.InitialContext.lookup(InitialContext.java:392)
[echo] at
com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:210)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:521)
[echo] at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:474)
[echo] at
javax.naming.InitialContext.lookup(InitialContext.java:392)
[echo] at
connector.sunresources.client.Client.doAppClientTest(Client.java:81)
[echo] at
connector.sunresources.client.Client.main(Client.java:64)
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[echo] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[echo] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[echo] at java.lang.reflect.Method.invoke(Method.java:597)
[echo] at
org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:432)
[echo] at
org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:154)
[echo] at
org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[echo] Caused by: org.omg.CORBA.INVALID_TRANSACTION: vmcid: 0x0
minor code: 0 completed: No
[echo] at
com.sun.jts.CosTransactions.CurrentTransaction.sendingRequest(CurrentTransaction.java:809)
[echo] at
com.sun.jts.CosTransactions.SenderReceiver.sending_request(SenderReceiver.java:138)
[echo] at
com.sun.jts.pi.InterceptorImpl.send_request(InterceptorImpl.java:338)
[echo] at
com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeClientInterceptorStartingPoint(InterceptorInvoker.java:272)
[echo] at
com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeClientPIStartingPoint(PIHandlerImpl.java:385)
[echo] at
com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:301)
[echo] at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:198)
[echo] at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:185)
[echo] ... 19 more
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



 Comments   
Comment by Jagadish [ 17/Sep/10 03:39 AM ]

Created an attachment (id=4911)
test-case

Comment by Jagadish [ 17/Sep/10 03:39 AM ]

Created an attachment (id=4912)
console log with exceptions

Comment by Jagadish [ 17/Sep/10 03:42 AM ]

STEPS TO REPRODUCE :
extract the attached test case to
$APS_HOME/devtests/jdbc

start GlassFish
start Derby

ant all : will fail with the exceptions reported.

Reference :
https://glassfish-svn.dev.java.net/source/browse/glassfish-svn/trunk/v2/appserv-tests/devtests/jdbc/README?view=markup

Comment by Jagadish [ 17/Sep/10 03:46 AM ]

cc->Shaline Gowda

Comment by marina vatkina [ 17/Sep/10 09:10 AM ]

Is there a single test that I run?

Comment by Jagadish [ 17/Sep/10 09:18 AM ]

yes, its a single test.

Comment by marina vatkina [ 17/Sep/10 05:20 PM ]

There are 204 of them. And all passed on the latest trunk.

Comment by Jagadish [ 18/Sep/10 03:22 AM ]

Sorry, can you run "ant all" from the extracted test
"stmt-timeout-gf-resources-appclient.tar.gz" ?
eg:
$APS_HOME/devtests/jdbc/stmt-timeout-gf-resources-appclient > ant all

Comment by marina vatkina [ 29/Sep/10 03:29 PM ]

Will wait for FOLB changes to be checked in first.

Comment by marina vatkina [ 06/Oct/10 10:16 AM ]

Connector team dependency

Comment by marina vatkina [ 08/Oct/10 04:56 PM ]

I'm fixing the warning in the output above (which was wrong but didn't affect
anything).

The actual problem is the naming exception (IDL:javax/naming/NamingEx:1.0 -
can't figure out the exact problem - it seems to be suppressed by ORB) that the
com.sun.jts.pi.InterceptorImpl.receive_exception is called with. Because of the
IT 2788 (i.e. no distinction between a lookup and a remote method call) this
results in marking a transaction for rollback.

Assigning to orb to identify the actual cause of the error.

Comment by Cheng Fang [ 11/Oct/10 11:38 AM ]

If the resource-ref is declared in deployment descriptors, for example,
java:app/env/db1, the appclient lookup works inside a transaction.

When the resource is created with glassfish-resources.xml (java:app/jdbc/db1),
the appclient failed with invalid transaction and Invalid component Id 31 in
portable interceptor:

[#|2010-10-11T14:23:34.096-0400|FINE|glassfish3.1|javax.enterprise.resource.corba.ee.S1AS-ORB.rpc.protocol|_ThreadID=16;_ThreadName=Thr
ead-1;ClassName=com.sun.corba.ee.impl.interceptors.ClientRequestInfoImpl;MethodName=get_effective_components;|"IOP00100028:
(BAD_PARAM)
Invalid component Id 31 in portable interceptor"
org.omg.CORBA.BAD_PARAM: vmcid: OMG minor code: 28 completed: No
at
com.sun.corba.ee.impl.logging.OMGSystemException.invalidComponentId(OMGSystemException.java:1610)
at
com.sun.corba.ee.impl.logging.OMGSystemException.invalidComponentId(OMGSystemException.java:1633)
at
com.sun.corba.ee.impl.interceptors.ClientRequestInfoImpl.get_effective_components(ClientRequestInfoImpl.java:441)
at
com.sun.corba.ee.impl.interceptors.ClientRequestInfoImpl.get_effective_component(ClientRequestInfoImpl.java:402)

Comment by Ken Cavanaugh [ 11/Oct/10 11:48 AM ]

Note that the BAD_PARAM exception is only logged at FINE level. This should
tell you that is is NOT an error: it is simply logged at FINE level when a
particular tagged component is not present in the IOR. This case (31)
corresponds to an OTS tagged component, used by the transaction service.

I have no idea why the transaction service is getting an IllegalStateException,
but all of the CORBA actions seem to indicate normal functioning. There is no
apparent CORBA error in the stack traces. However, it is interesting that this
is taking place in a naming lookup. Should naming lookups even participate in
transactions?

This looks most likely to be either a naming or a transactions issue, not a
CORBA issue.

Comment by marina vatkina [ 11/Oct/10 04:10 PM ]

Naming needs to sort this out: if it is supported, it should be supported. If it
is not, the appropriate error should be logged as a warning before throwing an
exception.

Comment by Cheng Fang [ 13/Oct/10 01:02 PM ]

When looking up the name "java:app/jdbc/s1qeDB" of the app-scoped-resource, the
naming code tries various variants, roughly,

java:app/jdbc/s1qeDB, failed since the resource has not been created yet;
java:global/jdbc/s1qeDB, failed due to the wrong scope;
java:global/<app-name>/jdbc/s1qeDB, failed,
internal names for java:app/jdbc/s1qeDB, which will succeed.

Step 2 is a remote invocation on SerialContextProvider. When the client got the
failed response, jts sets rollback only (TopCoordinator.rollback_only), since
currently there is no way to distinghish a remote lookup from a remote
invocation. This cause the next lookup in the current transaction fail to get
the transaction context and hence immediately failed with InvalidTransaction
(TopCoordinator.get_txcontext).

Comment by Cheng Fang [ 26/Oct/10 06:45 AM ]

exclude it from 3.1, and target it to 3.2





[GLASSFISH-17220] Remote clients cannot list global JNDI "jdbc" subcontext due to java.io.OptionalDataException Created: 22/Aug/11  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: naming
Affects Version/s: 3.1.1
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: al130959 Assignee: lemon_zhang
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude 4_0_1-review
Participants: al130959, Cheng Fang, guojun.shan, Harshad Vilekar, lemon_zhang and Shalini

 Description   

With GF 3.1.1 default setup, i.e. global JNDI "jdbc" subcontext containing the following entries:

jdbc/__TimerPool
jdbc/__default
jdbc/sample

trying to do the following from a remote client:

Context ctx = new InitialContext(env);
ctx.list("jdbc");

or

Context ctx = new InitialContext(env);
ctx.listBindings("jdbc");

produces the following fatal result:

Aug 22, 2011 7:57:12 PM com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator handleFullLogging
WARNING: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream
org.omg.CORBA.MARSHAL: WARNING: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy24.valuehandlerReadException(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1022)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:525)
at com.sun.corba.ee.impl.corba.TCUtility.unmarshalIn(TCUtility.java:289)
at com.sun.corba.ee.impl.corba.AnyImpl.read_value(AnyImpl.java:605)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_any(CDRInputStream_1_0.java:775)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_any(CDRInputObject.java:482)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.readAny(Util.java:452)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.read(DynamicMethodMarshallerImpl.java:299)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at com.sun.enterprise.naming.impl._SerialContextProvider_DynamicStub.lookup(com/sun/enterprise/naming/impl/_SerialContextProvider_DynamicStub.java)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:505)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at com.sun.enterprise.naming.impl.SerialContext.listBindings(SerialContext.java:866)
at javax.naming.InitialContext.listBindings(InitialContext.java:447)
at remotejndilookuptest.RemoteJNDILookupTest.main(RemoteJNDILookupTest.java:24)
Caused by: java.io.OptionalDataException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.impl.io.IIOPInputStream.createOptionalDataException(IIOPInputStream.java:245)
at com.sun.corba.ee.impl.io.IIOPInputStream.handleOptionalDataMarshalException(IIOPInputStream.java:944)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:393)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:344)
at java.util.HashMap.readObject(HashMap.java:1030)
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.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
... 28 more
Caused by: org.omg.CORBA.MARSHAL: FINE: IOP00800008: Not enough optional data available vmcid: SUN minor code: 8 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy27.rmiiiopOptionalDataIncompatible3(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.checkBlockLength(CDRInputStream_1_0.java:377)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInputStream_1_2.java:105)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_long(CDRInputStream_1_0.java:496)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readValueTag(CDRInputStream_1_0.java:1810)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1040)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
... 41 more
Exception in thread "main" javax.naming.CommunicationException: Communication exception for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.corba.orb=com.sun.corba.ee.impl.orb.ORBImpl@17a906e, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, com.sun.appserv.iiop.loadbalancingpolicy=ic-based, com.sun.appserv.ee.iiop.endpointslist=corbaloc:iiop:1.2@localhost:3700, com.sun.appserv.iiop.endpoints=localhost:3700} [Root exception is java.rmi.MarshalException: CORBA MARSHAL 1330446347 Maybe; nested exception is:
org.omg.CORBA.MARSHAL: WARNING: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 completed: Maybe]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:542)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at com.sun.enterprise.naming.impl.SerialContext.listBindings(SerialContext.java:866)
at javax.naming.InitialContext.listBindings(InitialContext.java:447)
at remotejndilookuptest.RemoteJNDILookupTest.main(RemoteJNDILookupTest.java:24)
Caused by: java.rmi.MarshalException: CORBA MARSHAL 1330446347 Maybe; nested exception is:
org.omg.CORBA.MARSHAL: WARNING: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 completed: Maybe
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:267)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at com.sun.enterprise.naming.impl._SerialContextProvider_DynamicStub.lookup(com/sun/enterprise/naming/impl/_SerialContextProvider_DynamicStub.java)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:505)
... 4 more
Caused by: org.omg.CORBA.MARSHAL: WARNING: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy24.valuehandlerReadException(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1022)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:525)
at com.sun.corba.ee.impl.corba.TCUtility.unmarshalIn(TCUtility.java:289)
at com.sun.corba.ee.impl.corba.AnyImpl.read_value(AnyImpl.java:605)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_any(CDRInputStream_1_0.java:775)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_any(CDRInputObject.java:482)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.readAny(Util.java:452)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.read(DynamicMethodMarshallerImpl.java:299)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
... 8 more
Caused by: java.io.OptionalDataException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.impl.io.IIOPInputStream.createOptionalDataException(IIOPInputStream.java:245)
at com.sun.corba.ee.impl.io.IIOPInputStream.handleOptionalDataMarshalException(IIOPInputStream.java:944)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:393)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:344)
at java.util.HashMap.readObject(HashMap.java:1030)
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.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
... 28 more
Caused by: org.omg.CORBA.MARSHAL: FINE: IOP00800008: Not enough optional data available vmcid: SUN minor code: 8 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy27.rmiiiopOptionalDataIncompatible3(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.checkBlockLength(CDRInputStream_1_0.java:377)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInputStream_1_2.java:105)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_long(CDRInputStream_1_0.java:496)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readValueTag(CDRInputStream_1_0.java:1810)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1040)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
... 41 more

Expected outcome: The listing of the "jdbc" subcontext should complete successfully without OptionalDataException.

Many thanks & best regards,

Andreas



 Comments   
Comment by Harshad Vilekar [ 01/Nov/11 01:17 AM ]

Assign to JDBC team for initial evaluation.

Comment by Shalini [ 14/Nov/11 09:18 AM ]

Assigning this issue to Naming module as jdbc module does not do anything special to list the jndi entries.

Comment by Cheng Fang [ 15/Nov/11 06:43 PM ]

Related issue http://java.net/jira/browse/GLASSFISH-17219 (Remote clients cannot list global JNDI root context due to non-Serializable objects in the context)

Comment by Cheng Fang [ 15/Nov/11 07:00 PM ]

The values of jndi entries are not required to be serializable. Requiring them to be so would put too much burden on the implementation. In the current implementation, when the remote client calls list or listBindings, it first tries to look up the param subcontext from remote context provider, and calls list(empty) on the subcontext. The subcontext from the first pass lookup may contain non-serializable content, hence the serialization failure.

Comment by Cheng Fang [ 12/Dec/11 07:01 PM ]

One option is to fully resolve jndi bindings (include leaf objects and all levels of subcontexts) for remote list* operations. So everything returned to the remote client is serializable. Exclude it from 3.1.2.

Comment by guojun.shan [ 29/May/13 06:50 AM ]

still exist on v4.0.
Caused by: org.omg.CORBA.BAD_PARAM: ---------BEGIN server-side stack trace---------
org.omg.CORBA.BAD_PARAM: WARNING: 00100006: Class org.glassfish.resourcebase.resources.api.ResourceProxy is not Serializable vmcid: SUN minor code: 6 completed: Maybe
at $Proxy318.notSerializable(Unknown Source)
at com.sun.corba.ee.impl.misc.ORBUtility.throwNotSerializableForCorba(ORBUtility.java:783)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_abstract_interface(CDROutputStream_1_0.java:556)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_abstract_interface(CDROutputObject.java:523)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAbstractObject(Util.java:492)
at com.sun.corba.ee.impl.io.IIOPOutputStream.writeObjectOverride(IIOPOutputStream.java:177)





[GLASSFISH-20898] Injecting @Resource(name = "jdbc/MyDB") fails with GF4 but works in GF3 Created: 13/Nov/13  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: naming
Affects Version/s: 4.0
Fix Version/s: 4.0_b90

Type: Bug Priority: Major
Reporter: lprimak Assignee: lemon_zhang
Resolution: Unresolved Votes: 4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ALL


Tags: resource injection 4_0_1-review
Participants: lemon_zhang, lprimak and tweier

 Description   

@Resource(name = "jdbc/MyDB") loads Default DataSource erroneously.
@Resource(lookup = "jdbc/MyDB") works correctly, but this is not per the spec.
name = "jdbc name" should work correctly or if data source not found, it should print an error
instead of silently default to default data source



 Comments   
Comment by tweier [ 28/Nov/13 01:08 PM ]

With the glassfish-sources from 4.0-b91 we have traced the bug into the
artifact org.glassfish.main.deployment:dol

In com.sun.enterprise.deployment.util.ComponentValidator there is a method computeRuntimeDefault() with setting the hardcoded DefaultDataSource:

com.sun.enterprise.deployment.util.ComponentValidator
964: private void computeRuntimeDefault(ResourceReferenceDescriptor resRef) {
965:  if (resRef.getType() != null && resRef.getType().equals("org.omg.CORBA.ORB")){
966:   resRef.setJndiName("java:comp/ORB");
967:  }
968:
969:  else if (resRef.getJndiName() == null ||
970:    resRef.getJndiName().length() == 0) {
971:   if (resRef.getType() != null) {
972:    if (resRef.getType().equals("javax.sql.DataSource"))
973:     resRef.setLookupName("java:comp/DefaultDataSource");
974:    else if (resRef.getType().equals("javax.jms.ConnectionFactory"))
975:     resRef.setLookupName("java:comp/DefaultJMSConnectionFactory");
976:    else
977:     resRef.setJndiName(getDefaultResourceJndiName(resRef.getName()));
978:   } else {
979:    resRef.setJndiName(getDefaultResourceJndiName(resRef.getName()));
980:   }
981:  }
982: }

From our point of view, the problem seems to be in the special handling for injected DataSources (and also for ConnectionFactories).
After commenting the lines 972 til 976 (disable the special handling), everything seems to work. We don't know, for what reason this special handling exists.

We are strongly use @Resource injection for datasources (our product has hundreds of such injections) - so this bug is a showstopper for us.





[GLASSFISH-20954] Glassfish doesn't support OpenJPA Created: 15/Jan/14  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jbreindel Assignee: ethan.wang
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8.1
Glassfish 4.0
OpenJPA 2.2.2
ClusterJPA


Tags: 4_0_1-review
Participants: ethan.wang, jbreindel and reza_rahman

 Description   

I am trying to deploy Glassfish 4.0 and OpenJPAv2.2.2 to use MySQL ClusterJPA plugin. However Whenever I try to access and entity manager I receive the following error:

Caused by: java.lang.AbstractMethodError: org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(Ljavax/persistence/SynchronizationType;Ljava/util/Map;)Ljavax/persistence/EntityManager;

I opened an issue on the OpenJPA forums where a user suggested that I have Glassfish implement the JPA 2.0 spec rather than JPA 2.1. I'm unsure how I would go about that. I can attach the full stracktrace if that would be helpful.

Here is the link to the OpenJPA issue:

https://issues.apache.org/jira/browse/OPENJPA-2471



 Comments   
Comment by reza_rahman [ 15/Jan/14 09:21 PM ]

Have you tried explicitly setting the JPA version via persistence.xml? Could you post your code?

Comment by jbreindel [ 15/Jan/14 09:30 PM ]

Do I just change the version of the persistence.xml schema to change JPA versions? And Yes I can post some of my code soon when I return home.

Comment by jbreindel [ 15/Jan/14 10:43 PM ]

Here is the relevant stack trace:

Caused by: java.lang.AbstractMethodError
at com.sun.enterprise.container.common.impl.EntityManagerWrapper._getDelegate(EntityManagerWrapper.java:197)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.createNativeQuery(EntityManagerWrapper.java:567)

I changed my persistence.xml file to use the JPA 2.0 schema as per a suggestion on the Glassfish forums. I am still confused though.

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
version="2.0">
<persistence-unit name="core" transaction-type="RESOURCE_LOCAL">
<provider>
org.apache.openjpa.persistence.PersistenceProviderImpl
</provider>
<class>...</class>
<properties>
<!-- <property name="openjpa.jdbc.SynchronizeMappings" value="add(ForeignKeys=true)"
/> -->
<property name="openjpa.ConnectionDriverName" value="com.mysql.jdbc.Driver" />
<property name="openjpa.ConnectionURL" value="jdbc:mysql://localhost:5000/core" />
<property name="openjpa.ConnectionUserName" value="***" />
<property name="openjpa.ConnectionPassword" value="***" />
<property name="openjpa.BrokerFactory" value="ndb" />
<property name="openjpa.jdbc.DBDictionary" value="TableType=ndbcluster" />
<property name="openjpa.ndb.connectString" value="localhost:1186" />
<property name="openjpa.ndb.database" value="core" />
<property name="openjpa.Log" value="DefaultLevel=INFO,SQL=TRACE" />
</properties>
</persistence-unit>
</persistence>

Comment by jbreindel [ 16/Jan/14 04:00 PM ]

It seems that Glassfish expects the JPA provider version to be 2.1. This doesn't allow for providers that are JPA 2.0 compliant.





[GLASSFISH-20913] Persisting a temporaltype.Date or temporaltype.Time object requires refresh to get the proper value Created: 04/Dec/13  Updated: 16/Apr/14

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: atrajano Assignee: Mitesh Meswani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-review
Participants: atrajano and Mitesh Meswani

 Description   

Given an entity

@Entity
public class PersistedBean { @Id @GeneratedValue private long id; @Temporal(TemporalType.DATE) private Date someDate; @Temporal(TemporalType.TIME) private Date someTime; @Temporal(TemporalType.TIMESTAMP) private Date someTimestamp; }

And an SLSB

@Stateless
// @Interceptors(LoggingInterceptor.class)
public class PersistedBeans {
@PersistenceContext
private EntityManager em;

public PersistedBean getLatest() { final PersistedBean bean = em .createQuery( "select p from PersistedBean p order by p.someDate desc, p.id desc", PersistedBean.class).setFlushMode(FlushModeType.AUTO) .getResultList().get(0); // em.refresh(bean); return bean; }

public void save(final PersistedBean bean) { em.persist(bean); }
}

performing the following call

public PersistedBean helloJpaBean() { final PersistedBean bean = new PersistedBean(); bean.setSomeDate(new Date()); bean.setSomeTime(new Date()); bean.setSomeTimestamp(new Date()); bean.setMessage("Hello JPA" + new Date()); persistedBeans.save(bean); return persistedBeans.getLatest(); }

Shows someDate and someTime with their time and date components respectively rather than the date only or time only portions.

The database stores the data correctly.

The work around at the moment is to do an em.refresh() on the retrieved result.






[GLASSFISH-16205] create-node-ssh does not create the node files in the filesystem leading to confusion. Created: 14/Mar/11  Updated: 15/Apr/14

Status: Reopened
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: easarina Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-scrubbed 3_1-next
Participants: easarina, Joe Di Pol and Tom Mueller

 Description   

Build 43. Solaris 10 Sparc.

Was used a default domain domain1. Started the domain. Then executed:

asadmin create-node-ssh --nodehost localhost --installdir /opt/glassfish3 --nodedir lena/nodes node1
Command create-node-ssh executed successfully.

Then tried to create a local instance --node was not used.

asadmin create-local-instance --nodedir /opt/glassfish3/glassfish/lena/nodes inst1
Rendezvoused with DAS on localhost:4848.
Port Assignments for server instance inst1:
JMX_SYSTEM_CONNECTOR_PORT=28686
JMS_PROVIDER_PORT=27676
HTTP_LISTENER_PORT=28080
ASADMIN_LISTENER_PORT=24848
JAVA_DEBUGGER_PORT=29009
IIOP_SSL_LISTENER_PORT=23820
IIOP_LISTENER_PORT=23700
OSGI_SHELL_TELNET_PORT=26666
HTTP_SSL_LISTENER_PORT=28181
IIOP_SSL_MUTUALAUTH_PORT=23920
Command create-local-instance executed successfully.

The directory /opt/glassfish3/glassfish/lena/nodes was created. But under this directory I saw only: localhost-domain1/ subdirectory. In this subdirectory was created inst1.

Then I've executed:

asadmin start-local-instance inst1
The instance does not exist on this machine.
Command start-local-instance failed.

asadmin start-local-instance --node node1 inst1
Server instance directory /opt/glassfish3/glassfish/nodes/node1/inst1 does not exist or is not a directory
Command start-local-instance failed.

I want to mention, that I've followed the help instruction:

--nodedir
The path to the directory that is to contain GlassFish
Server instances that are created on the node. If a
relative path is specified, the path is relative to the
as-install directory. If this option is omitted, no
directory for instances is specified for the node.



 Comments   
Comment by Tom Mueller [ 14/Mar/11 12:54 PM ]

What specifically is the incorrect behavior that you are reporting?

Everything that occurred while executing these commands is the as-designed behavior.

> asadmin create-node-ssh --nodehost localhost --installdir /opt/glassfish3 --nodedir lena/nodes node1

This command created a node with the attribute nodedir="lena/nodes". Note that in the manual page, a nodedir with a relative pathname is taken to be relative to the as-install directory.

> asadmin create-local-instance --nodedir /opt/glassfish3/glassfish/lena/nodes inst1

You reported that an instance was created /opt/glassfish3/glassfish/lena/nodes/localhost-domain1/inst1 directory. When there is no -node argument to the create-local-instance command, the default value is determined based on the contents of the nodedir. If no nodes exist, a node is made up based on the hostname of the node, and for the host where the DAS is running, this hostname is "localhost", so the instance was created in a new new "localhost<domainname>" where <domainname> is the name of the domain.

Maybe the surprising behavior here is that the instance wasn't actually created in the "node1" node. The reason it wasn't created there was because the create-node-ssh command doesn't actually modify "nodedir" directory at all. It only creates the data element in the domain.xml file. So when create-local-instance is called, the "node1" node doesn't yet exist in the lena/nodes directory.

> asadmin start-local-instance inst1

You reported that the instance failed to start. The reason for this is that the --nodedir option wasn't specified on the command line. When an instance exists in a node that is in a non-default nodedir, then the --nodedir option is required on the start-local-instance command. Without that, start-local-instance doesn't have anyway to find the instance (it can't look in domain.xml because synchronization may not have happened yet.)

> asadmin start-local-instance --node node1 inst1

Again you reported that this failed. And the reason for the failure is the same as for the previous option, not specifying the --nodedir option.

Marking this as incomplete until the incorrect behavior is specified.

Comment by easarina [ 14/Mar/11 01:24 PM ]

"Maybe the surprising behavior here is that the instance wasn't actually created in the "node1" node. The reason it wasn't created there was because the create-node-ssh command doesn't actually modify "nodedir" directory at all. It only creates the data element in the domain.xml file. So when create-local-instance is called, the "node1" node doesn't yet exist in the lena/nodes directory."

Yes, this is a surprising behavior, because a user created only one node. When he excuted
asadmin create-local-instance --nodedir /opt/glassfish3/glassfish/lena/nodes inst1. He can be absolutly sure that only one node exist, the one that he created, so this node would be used. But if there are several nodes, he will be asked what node to use. I believe the main problem there. that create-node-ssh doesn't create the node really.

Comment by Tom Mueller [ 14/Mar/11 01:41 PM ]

Joe, see the last comment for what is being identified as a bug.

Comment by Joe Di Pol [ 12/May/11 11:48 AM ]

I've changed the synopsis to reflect the root issue identified by this bug. Here is a summary of the bug:

If the user runs:

create-node-ssh --nodehost localhost --installdir /opt/glassfish3 --nodedir /tmp/mynodes node1

And then runs:

create-local-instance --nodedir /tmp/mynodes inst1

It creates a new node for inst1 in /tmp/mynodes (named localhost-domain1) instead of using "node1". This is because create-node-ssh only creates the config – it does not create any filesystem artifacts. Since nothing exists in /tmp/mynodes, create-local-instance creates a default node directory (localhost-domain1).

If create-node-ssh had actually created "/tmp/mynodes/node1" (and das.properties under there) when it was run, then create-local-instance would have used "node1" instead of creating a new one.

The work-around is to run create-local-instance like this:

create-local-instance --nodedir /tmp/mynodes --node node1 inst1

This behavior has caused confusion in general. Basically, after a user runs create-node-ssh they expect the node directory to exist. Currently that node directory is not created until the first instance is created.

Comment by Joe Di Pol [ 13/Oct/11 10:18 PM ]

This bugs has not appeared to cause much confusion for our customers so I'm lowering the priority.





[GLASSFISH-16193] Inconsistent, stopped already stopped instance, with --kill=true - failed, without - pass. Created: 10/Mar/11  Updated: 15/Apr/14

Status: Reopened
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: easarina Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-scrubbed
Participants: Byron Nevins, easarina, Joe Di Pol and Tom Mueller

 Description   

Build 43, Solaris 10 Sparc.

On the local machine I've created a cluster with one instance. The instance was stopped. Then I've executed the follow commands:

1) asadmin --passwordfile password.txt --user admin --host localhost --port 3000 stop-cluster --kill=true c1
remote failure: in1: Failed to stop instance in1 on node node1 using stop-local-instance --kill in1

Command failed on node node1 (localhost): Command stop-local-instance failed.

Can not find the process ID of the server. It is supposed to be here: /opt/glassfish3/glassfish/nodes/node1/in1/config/pid.prev. Unable to kill the process.

To complete this operation run the following command locally on host localhost from the GlassFish install location /opt/glassfish3:

stop-local-instance --kill in1

The command stop-instance failed for: in1
Command stop-cluster failed.

2) asadmin --passwordfile password.txt --user admin --host localhost --port 3000 stop-cluster c1
Command stop-cluster executed successfully.

3) asadmin --passwordfile password.txt --user admin --host localhost --port 3000 stop-instance --kill=true in1
remote failure: Failed to stop instance in1 on node node1 using stop-local-instance --kill in1

Command failed on node node1 (localhost): Command stop-local-instance failed.

Can not find the process ID of the server. It is supposed to be here: /opt/glassfish3/glassfish/nodes/node1/in1/config/pid.prev. Unable to kill the process.

To complete this operation run the following command locally on host localhost from the GlassFish install location /opt/glassfish3:

stop-local-instance --kill in1
Command stop-instance failed.

4) asadmin --passwordfile password.txt --user admin --host localhost --port 3000 stop-instance in1
The instance, in1, is stopped.
Command stop-instance executed successfully.

==========================================

So when --kill=true was used in stop-instance or stop-cluster, the correspondent stop commands - failed, without --kill=true - passed. I believe that with or without --kill=true, when an instance was stopped already, the stop commands have to create a consist result: executed successfully



 Comments   
Comment by Tom Mueller [ 11/Mar/11 06:29 AM ]

When the --kill option is specified for stop-local-instance, it appears that the command is not first checking to see if this instance is even up.

Comment by Byron Nevins [ 11/Mar/11 11:21 AM ]

"Can not find the process ID of the server. It is supposed to be here: /opt/glassfish3/glassfish/nodes/node1/in1/config/pid.prev. Unable to kill the process. "

The return is an ERROR and the message describes EXACTLY what the problem was.

You told it to kill a process that doesn't exist.

The command warned you that it can't find the PID for the server. This is a very different situation from finding a PID and not being able to kill the process.

This situation should definitely be signaled to the user as a failure – since perhaps the user deleted our magic file and the server really is still running (We have no way of knowing).

If you prefer that the message be re-worded, document here *exactly* what you want it to say and re-open and I'll change the error message.

If you want to re-open because you disagree with me then please reassign to Nazrul so he can make the call.

Comment by easarina [ 14/Mar/11 01:41 PM ]

I can imagine only one situation when pid.prev doesn't exist, but the instance is running, the user removed pid.prev manually . (We are assuming, that the creation of pid.prev works correctly). But why would a user remove pid.prev. I think it could be a very rear case. So I believe, if a user uses stop instance with --kill and pid.prev doesn't exist, then has to be created a warning, not an error. So the overall stop command should not fail.

Comment by Byron Nevins [ 23/Mar/11 01:33 PM ]

Tom -
Please reassign to the responsible engineer for stop-cluster.

stop-cluster is wasting time asking stop-local-instance to *kill* an instance that is not running.

Comment by Joe Di Pol [ 03/May/11 10:03 AM ]

Currently "stop-instance --kill" (which is called by stop-cluster) blindly calls "stop-local-instance --kill" because in the situations where a user would want to use the --kill option (if the instance is hung for example) it is unclear if the DAS can reliably determine if the instance is up or not. In fact one could argue that stop-local-instance is in a much better situation to determine if the instance is really running or not (it can get the pid from the pid file and check if the process is running).

I think the options for fixing this are:

1) Change "stop-local-instance --kill" where it is a warning (not an error) if there is no pid.prev file.

2) Change "stop-instance --kill" to only call "stop-local-instance --kill" if the DAS thinks the instance is running (this is what it does in the non kill case).

3) Change "stop-cluster --kill" to only call "stop-instance --kill" if the DAS thinks the instance is running (probably by passing an internal kill-only-if-running option to stop-instance).

At this point I'm leaning towards #1 or #3.

Comment by Joe Di Pol [ 13/Oct/11 10:20 PM ]

Not a must fix in the next update release. Lowering priority.





[GLASSFISH-15604] Allow user to clear node host field Created: 18/Jan/11  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: configuration
Affects Version/s: None
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: lidiam Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

build: b38, v3.1


File Attachments: JPEG File clearnodehosterror.JPG    
Tags: 3_1_1-scrubbed 3_1-next
Participants: Anissa Lam, Joe Di Pol and lidiam

 Description   

When creating a config node, Node Host is not a required field and node can be create without it. However, if user enters a host name and creates a node, if user then wants to clear this field, the following error is displayed on Save:

An error has occurred
javax.validation.ConstraintViolationException: Constraints for this Node configuration have been violated: on property [ nodeHost ] violation reason [ Invalid nodehost name. Name must start with a letter or number and may contain only letters, numbers, and certain other characters. ]

User should be able to clear node host field.



 Comments   
Comment by Anissa Lam [ 18/Jan/11 08:35 PM ]

The restriction comes from the backend.
Assign to Joe to evaluate.

Comment by Joe Di Pol [ 12/May/11 02:10 PM ]

This is being caused by a bean validation constraint that does not allow an empty string to be set as the host name:

@Pattern(regexp=NAME_REGEX, message="{nodehost.invalid.name}", payload=Node.class)
String getNodeHost();

where NAME_REGEX = "[A-Za-z0-9_][A-Za-z0-9\\-_\\./;#]*";

Comment by Joe Di Pol [ 13/Oct/11 10:22 PM ]

Not a must fix for the next update release. Lowering priority.





[GLASSFISH-15414] update-node-* should let you change install-dir, node-dir if no physical instances exist Created: 03/Jan/11  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_ms07
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: Joe Di Pol Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-15776 Offline configuration: user cannot mo... Closed
Tags:
Participants: carlavmott and Joe Di Pol

 Description   

Currently the update-node-* commands do not let you change install-dir or node-dir if instances exist in the configuration that reference the node. This is to prevent the user from, for example, changing the install-dir on a node which could break subsequent operations on the instances that reference the node (like start-instance).

But this impacts offline config when no physical instances exist yet. I should be able to create the node and instance configuration elements, and be free to change install-dir and node-dir. In this case no physical instances exist, so the operation should be allowed.

Also, maybe there are some valid reasons for doing this – like the install location has changed.

Some thoughts on addressing this:

Add a "-force" option to the update-node* commands which let you force the change.

Maybe keep track of when the first physical instance is created on a node and then perform the check only when that has occured. This would require a flag on a node which would be set bey create-instance and by create-local-instance when it validates the node.



 Comments   
Comment by carlavmott [ 18/Feb/11 04:27 PM ]

This is useful in the case of upgrade when we don't really know that installdir value and guess at the hostnode value. Adding --force would help. Currently the only way to change this is using the set command.

Comment by carlavmott [ 18/Feb/11 04:58 PM ]

Example of using the set command to update the installdir value for node named node1

asadmin set nodes.node.node1.install-dir=/Users/cmott/gf-v3

Comment by Joe Di Pol [ 22/Mar/11 11:01 AM ]

Adding a "--force" option would be pretty straight forward.





[GLASSFISH-15236] Move root cause of the error to the front of the message for Admin Console Created: 16/Dec/10  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b33
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: lidiam Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

build: ogs-3.1-b33-12_14_2010.zip


Tags:
Participants: Anissa Lam, Joe Di Pol and lidiam

 Description   

I've noticed when having issues with node creation that the actual root cause of an error is listed last in the error message. I personally usually do not notice it untill I read the message 2 or 3 times. Here is an example:

An error has occurred
Warning: some parameters appear to be invalid. SSH node not created. To force creation of the node with these parameters rerun the command using the --force option. Could not connect to host biffy using SSH. Could not authenticate.

The real issue here is that I entered wrong password, hence it could not authenticate. That's the piece of information that should be listed in the beginning of the error message, since user's attention is the highest then. Perhaps in CLI it makes sense to have it displayed last, but it really is pretty much lost in GUI. And when we have long error messages, the root cause is really lost then, due to the truncating issue in GUI (see related issue http://java.net/jira/browse/GLASSFISH-15221). It would be good for Admin Console users if the root cause is listed early on in error messages.

Btw, there is another, smaller issue with the message above: it says it's an error and a warning... That's confusing.



 Comments   
Comment by Anissa Lam [ 16/Dec/10 02:55 PM ]

oops, i pick the wrong one. Give this back to Joe.

Comment by Joe Di Pol [ 16/Dec/10 07:10 PM ]

While I agree the error message could be improved other bugs are taking higher priority. It is likely we will need to address this in the next release.





[GLASSFISH-13894] update-node-* lets you set a nodedir on in-use node if original node does not have one Created: 08/Oct/10  Updated: 15/Apr/14

Status: Reopened
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: lidiam Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: JPEG File node-chnodedir.JPG     JPEG File nodedir-change.JPG     JPEG File nodedir-startup-error.JPG     Text File server.log     Text File server.log    
Issuezilla Id: 13,894
Tags: 3_1_1-scrubbed
Participants: Anissa Lam, Joe Di Pol and lidiam

 Description   

build: glassfish-3.1-b23-10_07_2010.zip

Create a node on localhost specifying a node directory, e.g. mynodes and the
same install directory as localhost node. Create standalone instance using new
node. At this point directory structure is created in filesystem for node and
instance. Go to Edit Node screen, for the newly created node and modify node
directory by deleting the entry. Attempt to start instance and the following
error is printed on screen:

An error has occurred
Could not start instance sanlan1 on node lancer (localhost). Command failed on
node lancer (localhost): CLASSPATH=
/export/home/j2eetest/v3.1/glassfish3/glassfish/bin/../modules/admin-cli.jar
Commands: [start-local-instance, --node, lancer, --nodedir, , sanlan1] asadmin
extension directory: /export/home/j2eetest/v3.1/glassfish3/glassfish/lib/asadmin
Prepare Process program options Parsing program options Parse command options
params: {node: [lancer] nodedir: [] } operands: [sanlan1] Prevalidate...

Either user should be able to change node directory without further errors or
this choice should be disabled.



 Comments   
Comment by lidiam [ 08/Oct/10 04:24 PM ]

Created an attachment (id=5107)
screenshot

Comment by lidiam [ 08/Oct/10 04:25 PM ]

Created an attachment (id=5108)
server.log

Comment by Anissa Lam [ 08/Oct/10 05:49 PM ]

I think backend needs to fix this, ie to be able to handle changing of the
node-dir after the node is created.
User maybe using CLI set to modify that as well.

If this is going to cause problem, it should disallow it so user cannot use CLI
to change it, and notify GUI to make that field read-only after creation.
If user should be able to change node directory after creation, then the current
behavior is wrong.

Comment by Joe Di Pol [ 11/Oct/10 09:24 AM ]

A couple of options:

1) Don't allow changing the nodedir once a node has been created. Or

2) Don't allow changing the nodedir if there are any instances using the node.

I'm leaning towards #2. update-node-* can check if any instances are using
the node and report an error if nodedir is being changed.

Comment by Joe Di Pol [ 03/Nov/10 02:46 PM ]

The code has been changed so that if you try to change installdir or nodedir and
the node is referenced by one or more server instances then the update command
will fail with an error.

Author: jfdipol
Date: 2010-11-03 21:44:43+0000
New Revision: 42431

Modified:

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/LocalStrings.properties

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/NodeUtils.java

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/UpdateNodeCommand.java

Comment by lidiam [ 25/Feb/11 12:51 PM ]

I can still change node directory on an SSH node that has an instance underneath. Here are the steps to reproduce:

1. In Admin Console create an SSH node on localhost, filling in only node name and host.
2. Create a standalone instance under the new node with default settings.
3. Start the instance.
4. Stop the instance.
5. Go to Nodes page and type a bogus name for Node Directory field - the change is accepted. I tried it three times to make sure...
6. If you attempt to start the instance you will get the following error:

An error has occurred
Could not start instance in2 on node ln (localhost). Command failed on node ln (localhost): Command start-local-instance failed. Node directory /export/home/j2eetest/v3.1/glassfish3/glassfish/bogusDir does not exist or is not a directory To complete this operation run the following command locally on host localhost from the GlassFish install location /export/home/j2eetest/v3.1/glassfish3: asadmin start-local-instance --node ln --nodedir /export/home/j2eetest/v3.1/glassfish3/glassfish/bogusDir --sync normal in2

7. Go back to the node page and wipe out bogus node dir name - this time the change is not accepted with the expected error message of:

An error has occurred
Cannot update node ln. It is in use by a server instance and therefore attribute nodedir cannot be changed.

I'm not sure why this message does not show up the first time around...

Comment by lidiam [ 25/Feb/11 12:51 PM ]

Attaching screenshots and server.log.

Comment by Joe Di Pol [ 12/May/11 02:32 PM ]

The current code lets you update a node with new values if the attributes you are updating do not already have values, even if the node is in use by an instance. Here is the relevant comment from UpdateNodeCommand:

// If the current (config) value is null or "" then let it be changed.
// We need to do this for the offline config case where the user has
// created a config node with no values, created instances using those
// nodes, then updates the values later. This has the undersireable
// effect of letting you, for example, set a nodedir on a node
// that was created without one.
if (!StringUtils.ok(currentvalue)) { return true; }

In order to truly fix this we need to be able to tell the difference between the offline config use case (where instances exists in the config, but do not physically exist on a server yet) versus the case where the physical instances do exist.

In the former case update-node-* should allow all attributes to be changed.

In the later case update-node-* should be strict about what attributes can be changed.

This is related to bug GLASSFISH-15414.

To fix this we may need to add a "rendezvous" attribute to the server instance domain.xml element to indicate that the physical instance has been created.

Comment by Joe Di Pol [ 06/Jul/11 04:40 PM ]

Lowering priority since this is a lack of an error check and not a significant loss of functionality.





[GLASSFISH-20806] Provide embedded Glassfish as POM with dependencies as addition to or instead of the current ueber jar Created: 10/Sep/13  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: obfischer Assignee: Bhavanishankar
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Bhavanishankar and obfischer

 Description   

The embedded Glassfish is provided as huge uber jar. But wouldn't it be possible to provide it as POM with all required dependencies? This approach would allow to avoid dependency problems as I am facing them now. Sometimes the version of classes contained in embedded Glassfish differ from the dependecies required or provided by other libraries.

SLF4J, ASM, and Joda time are some examples. The POM approach would at least allow to analyse the dependencies of embedded Glassfish and to exclude some dependencies if the collide with other dependencies.






[GLASSFISH-20827] The link does not work in the Summary page during install GF Created: 27/Sep/13  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: installation
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: OEL6 x64
Locale: ko_KR.UTF-8
Bundle: java_ee_sdk-7-web-b89b-jdk7-linux-x64-ml.sh
JDK: jdk1.7.0_25 x64


File Attachments: JPEG File summary_link_noWork.jpg    
Tags:
Participants: Snjezana Sevo-Zenzerovic and sunny-gui

 Description   

To Reproduce:
1. Set JAVA_HOME=JKD7_Install_DIR
2. Run ./java_ee_sdk-7-web-b89b-jdk7-linux-x64-ml.sh
3. Click Next to go to the Summary page

Results:
The link does not work in this page. Attached screen shot for your reference.






[GLASSFISH-20855] move and mavenize major developer tests from glassfish v2 repository to trunk/appserver/tests Created: 15/Oct/13  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: build_system, test
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: 2 weeks
Time Spent: Not Specified
Original Estimate: 2 weeks
Environment:

any


Tags: test maven glassfish devtest
Participants: Romain Grécourt

 Description   
  • Current developer test suite are documented here: https://wikis.oracle.com/display/glassfish/DeveloperTestDashboard
  • Those test suites are owned by particular developer, they are responsible for monitoring the test results.
  • They can take some time to run, hence they are not required for every checkin but depending on the changes (owner will likely request it)

The codeline comes from GlassFish 2.x, the test codebase is still located in the v2 svn repository: https://svn.java.net/svn/glassfish~v2/trunk/appserv-tests/devtests/

Those tests suite are still developed, and are used to test the current GlassFish codeline.

  • They are using the infrastructure that is provided by the old workspace
  • It is based on ant and is sometime platform dependent (i.e, can't work on windows).
  • It requires shell environment configuration to run (PATH and environment variables used by the tests)

This improvement is about mavenizing some of those devtests with as few changes as possible, in order to provide the following:

  • No change in the source code
  • Only maven / jdk required, everything else is downloaded and configured on the fly via maven
  • A pom.xml wrapping the tests scenario (e.g. with profiles)
  • Test workspace nested under appserver/tests, in order to be tagged be each release

Some things nice to have:

  • Windows / UNIX profiles to help sorting the suite that supports windows or not.
  • Generation of standard junit/testng report for easier CI
  • Test coverage infra (with cobertura)

Here are the in-scope test suites:

  • deployment
  • ejb
  • security
  • admin
  • webtier

Eventually, some documentation should be written under appserver/tests to guide developers.






[GLASSFISH-20917] a wrong implementation for web-fragment.xml with <distributable/> issue Created: 06/Dec/13  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: jumperchen Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

fail with both Glassfish 3 and 4 version


Tags:
Participants: jumperchen and Shing Wai Chan

 Description   

If a web application contains with a jar (for example Spring 3.2.2 version) that enables the attribute <distributable/> in the web-fragment.xml, this setting will cause glassfish server run in cluster environment.

You may refer to this fixed in Spring's tracker - https://jira.springsource.org/browse/SPR-10219

To reproduce this issue is to save a non-serializable object to session attribute, for example

<%
   session.setAttribute( "test", new java.io.ByteArrayOutputStream(20) );
%>

Note that the web.xml doesn't specify the <distributable/>.






[GLASSFISH-20919] dontRollbackOn attribute does not seem to take subclasses into account Created: 09/Dec/13  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: svanimpe Assignee: paul_parkinson
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-evangelists 4_0_1-review
Participants: paul_parkinson and svanimpe

 Description   

The following code causes a RollbackException:

@Path("test")
@Transactional(dontRollbackOn = {WebApplicationException.class})
public class TestWAE
{
    @PersistenceContext
    private EntityManager em;
    
    @GET
    public String testWAE()
    {
        throw new BadRequestException("Some reason");
    }
}

while this works fine:

@Path("test")
@Transactional(dontRollbackOn = {BadRequestException.class})
public class TestWAE
{
    @PersistenceContext
    private EntityManager em;
    
    @GET
    public String testWAE()
    {
        throw new BadRequestException("Some reason");
    }
}

According to https://javaee-spec.java.net/nonav/javadocs/javax/transaction/Transactional.html, they should both do the same thing: "the designated behavior applies to subclasses of that class as well".

I noticed this by accident. Maybe I'm missing something, but I figured reporting it wouldn't hurt






[GLASSFISH-20956] when excutes new InitialContext(env) ,java.lang.NullPointerException is happening Created: 16/Jan/14  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: lzg5039 Assignee: guojun.shan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linuxs


Tags:
Participants: guojun.shan and lzg5039

 Description   

Instance is stopped,the address of instance is 10.124.174.204:23912.
when excutes the following code,NullPointerException is happening.

Hashtable env = new Hashtable();
env.put("com.sun.appserv.iiop.endpoints","10.124.174.204:23912");
InitialContext ic1 = new InitialContext(env);






[GLASSFISH-21032] NPE if alternatedocroot_1 has from=/* Created: 07/Apr/14  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: m.zdila Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish-4.0.1-b04-04_05_2014-ml
java version "1.7.0_51"
OpenJDK Runtime Environment (IcedTea 2.4.5) (7u51-2.4.5-2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)


Tags:
Participants: m.zdila and Shing Wai Chan

 Description   

glassfish-4.0.1-b04-04_05_2014-ml

In glassfish-web.xml I have following element:
<property name="alternatedocroot_1" value="from=/* dir=/home/martin/teris-client"/>

On deploy Glassfish throws exception:

2014-04-07T16:32:31.149+0200|SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: start:
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:744)
Caused by: org.apache.catalina.LifecycleException: start:
at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:770)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5864)
... 49 more
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(String.java:658)
at org.apache.naming.resources.WebDirContext.getAbsoluteJarResourceName(WebDirContext.java:416)
at org.apache.naming.resources.WebDirContext.lookupAllFromJars(WebDirContext.java:349)
at org.apache.naming.resources.WebDirContext.list(WebDirContext.java:214)
at org.apache.catalina.loader.WebappLoader.copyDir(WebappLoader.java:1321)
at org.apache.catalina.loader.WebappLoader.setRepositories(WebappLoader.java:1116)
at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:759)
... 50 more

In Glassfish 4.0 it works.






[GLASSFISH-20958] Autehntication not working in embedded glassfish v4 Created: 17/Jan/14  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: pranahata Assignee: Bhavanishankar
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

gfv4, ubuntu linux, jdk7


Tags:
Participants: Bhavanishankar and pranahata

 Description   

Can create an auth realm ok

runCommand("create-auth-realm", "--classname=com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm",
"--property=jaas-context=jdbcRealm:datasource-jndi=jdbc/jobtracking:user-table=USER:user-name-column=USERNAME:password-column=PASSWORD:group-table=USER_GROUP_AUTH_VW:group-table-user-name-column=USERNAME:group-name-column=GROUP_ID:digest-algorithm=none",
"jobtracking-realm");

But when trying to do programmatic login or login via http it reports

Login failed: No LoginModules configured for jdbcRealm






[GLASSFISH-20961] Closed Connection Created: 21/Jan/14  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: rkatkuri Assignee: sfelts
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008 R2 Enterprise


Tags:
Participants: rkatkuri and sfelts

 Description   

Application is crashing with out any pattern. Below is the error log

ERROR [JDBCTransaction:begin] JDBC begin failed
java.sql.SQLException: Closed Connection
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:113)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:147)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:209)
at oracle.jdbc.driver.PhysicalConnection.setAutoCommit(PhysicalConnection.java:1087)
at com.sun.gjc.spi.base.ConnectionHolder.setAutoCommit(ConnectionHolder.java:651)
at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:63)
at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1326)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:558)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:374)
at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:263)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:101)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy140.getCustomerCredentials(Unknown Source)
at iwas.service.security.UserAuthenticationService.loadUserByUsername(Unknown Source)
at org.springframework.security.providers.dao.DaoAuthenticationProvider.retrieveUser(DaoAuthenticationProvider.java:83)
at org.springframework.security.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:121)
at org.springframework.security.providers.ProviderManager.doAuthentication(ProviderManager.java:195)
at org.springframework.security.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:46)
at org.springframework.security.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:81)
at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:249)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:192)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at iwas.service.security.filter.MalicousRequestFilter.doFilter(Unknown Source)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:174)
at org.springframework.security.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:99)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:807)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:671)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:505)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:476)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:355)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:305)
at iwas.control.CustomerAuthenticationController.authentiacte(Unknown Source)
at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doInvokeMethod(HandlerMethodInvoker.java:421)
at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:136)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:326)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:313)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:359)
at org.springframework.security.concurrent.ConcurrentSessionFilter.doFilterHttp(ConcurrentSessionFilter.java:97)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:87)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:87)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:268)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at iwas.service.security.filter.MalicousRequestFilter.doFilter(Unknown Source)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:174)
at org.springframework.security.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:99)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
2014-01-21 07:54:23,742 INFO [CustomerAuthenticationController:authentiacte] Authenticating Customer
2014-01-21 07:54:23,742 DEBUG [AbstractProcessingFilter:doFilterHttp] Request is to process authentication
2014-01-21 07:54:23,742 DEBUG [UserAuthenticationService:loadUserByUsername] loadUserByUsername(1054976)
2014-01-21 07:54:23,758 ERROR [JDBCTransaction:begin] JDBC begin failed
java.sql.SQLException: Closed Connection
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:113)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:147)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:209)
at oracle.jdbc.driver.PhysicalConnection.setAutoCommit(PhysicalConnection.java:1087)
at com.sun.gjc.spi.base.ConnectionHolder.setAutoCommit(ConnectionHolder.java:651)
at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:63)
at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1326)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:558)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:374)
at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:263)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:101)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy140.getCustomerCredentials(Unknown Source)
at iwas.service.security.UserAuthenticationService.loadUserByUsername(Unknown Source)
at org.springframework.security.providers.dao.DaoAuthenticationProvider.retrieveUser(DaoAuthenticationProvider.java:83)
at org.springframework.security.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:121)
at org.springframework.security.providers.ProviderManager.doAuthentication(ProviderManager.java:195)
at org.springframework.security.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:46)
at org.springframework.security.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:81)
at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:249)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:192)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at iwas.service.security.filter.MalicousRequestFilter.doFilter(Unknown Source)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:174)
at org.springframework.security.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:99)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:807)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:671)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:505)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:476)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:355)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:305)
at iwas.control.CustomerAuthenticationController.authentiacte(Unknown Source)
at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doInvokeMethod(HandlerMethodInvoker.java:421)
at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:136)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:326)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:313)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:359)
at org.springframework.security.concurrent.ConcurrentSessionFilter.doFilterHttp(ConcurrentSessionFilter.java:97)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:87)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:87)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:268)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at iwas.service.security.filter.MalicousRequestFilter.doFilter(Unknown Source)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:174)
at org.springframework.security.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:99)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)






[GLASSFISH-20977] gf-client-module.jar is an OSGi bundle, but should not be Created: 10/Feb/14  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: build osgi 4_0_1-review
Participants: Romain Grécourt

 Description   

Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.main.appclient.gf-client-module [67]: Unable to resolve 67.0: missing requirement [67.0] osgi.wiring.package; (osgi.wiring.package=org.jboss.weld.environment.se)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2037)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:210)






[GLASSFISH-21003] start-cluster sometimes fails with: "Argument name must be defined" Created: 04/Mar/14  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: Joe Di Pol Assignee: martin.mares
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-review
Participants: Joe Di Pol and martin.mares

 Description   

Sporadically during test runs (for example the cluster admin devtests) start-cluster will fail:

cluster:
     [java] Listening for transport dt_socket at address: 9010
     [java] #####  Non-Verbose: Only Failures Are Printed #####
     [java] #########    FAILURE   #########
     [java] asadmin --host localhost --port 4848 --user admin 
--passwordfile /scratch/BUILD_AREA/workspace/gf-lw-admin-devtests-cluster/appserv-tests/config/adminpassword.txt 
--interactive=false --echo=true --terse=true 
start-cluster --verbose=false gslc1
     [java] 
     [java] Argument name must be defined

This is not consistently reproduceable, but happens periodically during the automated test runs.



 Comments   
Comment by Joe Di Pol [ 04/Mar/14 09:49 PM ]

This looks to be comming from
nucleus/admin/util/src/main/java/com/sun/enterprise/admin/event/AdminCommandEventBrokerImpl.java

    @Override
    public void fireEvent(String name, Object event) {
        if (name == null) {
            throw new IllegalArgumentException("Argument name must be defined");
        }

start-cluster uses the progress status feature – so I'm guessing this is related to that.

Comment by martin.mares [ 10/Mar/14 01:46 PM ]

I am searching for potential source of this issue.
I thing that only place in current GF where is potential source of event without name is SSE client. In case of some wrong SSE transfer it can cause this. (For example two manny EOLs in one message.

I want support my idea first. So, I change SSE client to produce runtime exception with different message. If we see "Event without name. Data: " instead of "Argument name must be defined" then we have source of the issue. Next question will be why there is broken SSE stream syntax.

SVN revision 63157





[GLASSFISH-21004] asadmin start-database does not work with JDK 1.7u51 - AccessControlException; SocketException Created: 06/Mar/14  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 4.0.1
Fix Version/s: 4.0.1

Type: Bug Priority: Critical
Reporter: Pavel Bucek Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.7u51


Tags: 4_0_1-review
Participants: Joe Di Pol, Pavel Bucek and Snjezana Sevo-Zenzerovic

 Description   
$ ./bin/asadmin start-database
Starting database in Network Server mode on host 0.0.0.0 and port 1527.
Unable to start database.  Please check log in /Users/pavel/glassfish/trunk/main/appserver/distributions/glassfish/target/stage/glassfish4/glassfish/databases/derby.log.
Command start-database failed.
Thu Mar 06 22:35:02 CET 2014 : Security manager installed using the Basic server security policy.
Thu Mar 06 22:35:02 CET 2014 : access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
Thu Mar 06 22:35:02 CET 2014 : access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
	at java.security.AccessController.checkPermission(AccessController.java:559)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.SecurityManager.checkListen(SecurityManager.java:1134)
	at java.net.ServerSocket.bind(ServerSocket.java:375)
	at java.net.ServerSocket.<init>(ServerSocket.java:237)
	at javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.createServerSocket(Unknown Source)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.access$000(Unknown Source)
	at org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown Source)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(Unknown Source)
	at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.sun.enterprise.admin.cli.optional.DerbyControl.invokeNetworkServerControl(DerbyControl.java:158)
	at com.sun.enterprise.admin.cli.optional.DerbyControl.main(DerbyControl.java:245)
java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
	at java.security.AccessController.checkPermission(AccessController.java:559)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.SecurityManager.checkListen(SecurityManager.java:1134)
	at java.net.ServerSocket.bind(ServerSocket.java:375)
	at java.net.ServerSocket.<init>(ServerSocket.java:237)
	at javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.createServerSocket(Unknown Source)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.access$000(Unknown Source)
	at org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown Source)
	at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(Unknown Source)
	at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.sun.enterprise.admin.cli.optional.DerbyControl.invokeNetworkServerControl(DerbyControl.java:158)
	at com.sun.enterprise.admin.cli.optional.DerbyControl.main(DerbyControl.java:245)

works with JDK 1.7u40.

(this also means that quicklook tests are failing when 1.7u51 us used).



 Comments   
Comment by Pavel Bucek [ 13/Mar/14 05:14 PM ]

this seems to be the cause: http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html

Area: other-libs/javadb
Synopsis: Additional permission needed to run Java DB network server

An additional permission may be needed in order to bring up the Java DB network server. 
In particular, the startup scripts in <db/bin> may fail to boot the network server. 
This is a result of the "Better applet networking" changes made by 8011787 (not public).

While attempting to boot, the network server may fail and raise the following error:

access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
java.security.AccessControlException: access denied 
("java.net.SocketPermission" "localhost:1527" "listen,resolve")

To fix this problem, you must bring up the network server with a security policy which includes 
the missing permission. Instead of booting the network server as:

java org.apache.derby.drda.NetworkServerControl start

boot the network server as follows:

java -Djava.security.manager -Djava.security.policy=${yourPolicyFile}
org.apache.derby.drda.NetworkServerControl start

where ${yourPolicyFile} is a file containing a customized version of the policy file described 
in the Java DB Admin Guide section titled Basic Network Server security policy. You must customize 
that generic policy file to fit your application. In addition, you must add the following 
permission to the permissions block granted to the ${derby.install.url}derbynet.jar codebase:

permission java.net.SocketPermission "localhost:${port}", "listen";

where ${port} should be replaced by the port number where the network server listens for incoming 
connection requests. By default, that is port 1527.

For more information on Java DB security policies, see the Java DB Admin Guide sections titled 
Network Server security and Running the Network Server under the security manager.

If you are using replication, a similar permission must be granted to the security policy for the 
slave server. Add the following permission to the ${derby.install.url}derby.jar codebase:

permission java.net.SocketPermission "localhost:${slavePort}", "listen";

where ${slavePort} should be replaced by the port number where the slave server listens for 
incoming connection requests (typically 4851). For more information on the security policy for 
the slave server, see the Java DB Admin Guide section titled Replication and security.

See 8011787 (not public).
Comment by Joe Di Pol [ 18/Mar/14 03:42 PM ]

This is being addressed in derby:

https://issues.apache.org/jira/browse/DERBY-6438

GlassFish bundles a copy of JavaDB, so we'll need to investigate picking up a newer version.





[GLASSFISH-18528] RuntimeException thown in a JASPIC swallowed and empty page returned Created: 18/Mar/12  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: bjb Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 2008, 64bits


Tags: jaspic security empty page debug maze
Participants: bjb and JeffTancill

 Description   

Any RuntimeException thrown in the JASPIC implementation will result in a empty page in GF (a valid HTML page but with no content and with host encoding as meta) and no log at all (GF security logger set to finest).

IMHO, there should be an isolation so that a RuntimeEx thrown in JASPIC should be intercepted by GF's JASPIC container and :

  • if mandatory : result in a 403
  • if not mandatory : catch & log it appropriately in the security logger and go on with the next implementation configured (as per the spec)

I do not have seen anything about RuntimeEx behavior in the JSR, but this is something that should realy be handled.

FYI, the only solution is to dig with the debugger and it result into a massive loss of time, plus an cloudy situation toward the security : a page was return without clue where it came from.

Rgs,
JB






[GLASSFISH-18556] Characters out of JASPIC GroupPrincipalCallback Created: 24/Mar/12  Updated: 15/Apr/14

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

Type: Bug Priority: Critical
Reporter: bjb Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Java Source File PolicyFileTest.java    
Tags: JASPIC group character restriction exception
Participants: bjb, JeffTancill, kumarjayanti and monzillo

 Description   

At this time, not all the characters can be used in a group set by GroupPrincipal callback.

Using thoses character will result into bad PolicyFile with non matching rule.

As a consequence, user will not be granted access as per the JACC checks.

(no exception raised, lowering the log level will result into unrelated exception beeing traced as a wrong track)

Example of such a group is :

ROLE_\01\05\00\00\00\00\00\05\15\00\00\00\8a\16\77\12\f6\70\d2\67\92\01\99\5a\b2\34\00\00

Issues here are the backslash () but I anticipate other characters could be at risks.

AFAIK, at this time there is no restricted character requirement as per JASPIC on the group.



 Comments   
Comment by kumarjayanti [ 25/Mar/12 04:27 AM ]

Will try to get comments from Ron on this.

Comment by bjb [ 26/Mar/12 08:35 AM ]

In the PolicyFile, the parseGrantEntry call

e.codeBase = match("quoted string");

But \ was configure as a quote char !

The internal java.io.StreamTokenizer indicates in line 635, that if a \ is used this is for escaping : C style or octal/hexa. But line 661+ there is no search for a second
to be reaplced by a single \ (aka '
') !

So the problem is whatever we do around \ char we will not get a bijective result (writer/parser).

But I've found reference saying that double backslash was used in PolicyFile as single backslash
http://www.eli.sdsu.edu/courses/spring99/cs696/notes/security/security.html
But I have not found that in the JDK code.

I will see to create a simple testcase for this PolicyFile corner case.
If it confirms my assumptions, I will open a JDK bug.

Until, it is fixes, the \ is a char that should be prohibited from group valid characters until we get the StreamTokenizer fixed

Anyway the domain of values for a name and the bijective nature of PolicyFile has to be confirmed from the JVM team.

Comment by bjb [ 26/Mar/12 01:37 PM ]

I've create a JUnit test case to show the JDK bug :

http://pastebin.com/HxmQJWmk

Comment by monzillo [ 26/Mar/12 02:09 PM ]

http://docs.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html

please see section entitled "Win32 Systems, File Paths, and Property Expansion"

Although I do not think what you are seeing is win32 specific, it seems that you must escape the "\" (when it occurs in your group or role names) with a preceding "\".

Comment by bjb [ 26/Mar/12 02:17 PM ]

JUnit test case to show the issue

Comment by bjb [ 26/Mar/12 02:31 PM ]

I think this has nothing to do with platformspecific as the test I have performed is "in memory" only (see version 2 attached in jira).

First the Policy Writer parser does not use double backslash for the backslash escaping while writing (cf generated policy file from GF).

Then, I can not use multiple escape as the parser (streamtokenizer from James ;P ) did not implement the double backslash escaping as usual in C :
http://en.wikipedia.org/wiki/C_syntax#Backslash_escapes

Most backslashes escapes are handled in the stream tokenizer but the escape of the backslash it self apparently.

I've submit another test case suit with triple (double 1/2) and quadruple (real double) backslash. Only the first test with single backslash (aka octet value) works.





[GLASSFISH-21030] CDI failures with 4.0.1-b05-SNAPSHOT Created: 03/Apr/14  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: jax-rs
Affects Version/s: None
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JERSEY-2461 Jersey CDI extension causes CDI deplo... Open
Tags: cdi jersey glassfish 4_0_1-review
Participants: Romain Grécourt

 Description   

Here is what the error looks like:

org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001409 Ambiguous dependencies for type [Logger] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private transient TestServlet.log]. Possible dependencies:
 - org.glassfish.jersey.gf.cdi.internal.CdiComponentProvider$Hk2Bean@2cb100f,
 - Producer Method [Logger] with qualifiers [@Any @Default] declared as [[BackedAnnotatedMethod] @Produces public TestLoggerProducer.getLogger()]

We are investigating a workaround to use before the next jersey integration. (basically bundle org.glassfish.jersey.containers.glassfish:jersey-gf-cdi-ban-custom-hk2-binding:2.7).






[GLASSFISH-18371] SSH: Do not allow running DAS on 4.0 and Remote Instances on 3.x Created: 15/Feb/12  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: distributed management
Affects Version/s: 4.0_b24
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-18366 create-dcom should detect GlassFish v... Resolved
Tags:
Participants: Byron Nevins and Joe Di Pol

 Description   

I have not checked but this is almost certainly the case. See 18366.

It is visible by nadmin not existing in a 3.x installation.
But the real problem is that we should forbid hetero-version clustering.



 Comments   
Comment by Byron Nevins [ 15/Feb/12 07:44 PM ]

the DCOM version of this issue





[GLASSFISH-20920] Glassfish Update Tool Error on OS X Created: 09/Dec/13  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: nandanito Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Custom installed Glassfish 4 on Mac OSX 10.9 on MacBook Pro Retina


Tags: updatetool
Participants: hongz1, klaraward, nandanito and Snjezana Sevo-Zenzerovic

 Description   

The following error has been caught, while using Update Tool 2.3.5. I'm using NetBeans with custom GlassFish4 installation on Mac OSX 10.9. While retrieving "Available Update", this error occurred.

Application ID: [GlassFish Update Tool 2.3.5 (Build 56.2852)]
Timestamp : [2013-12-09 18:21:24 CET(+0100)]
wx Version : [2.8.10.1]
wx Platform : [__WXMAC__]
Python Version: [2.4.6]
Platform : [Darwin-13.0.0-x86_64-i386-32bit]

Traceback (innermost last):
File "/opt/glassfish4/updatetool/vendor-packages/updatetool/common/listers.py", line 409, in run
pkg_plans = ips.get_list_of_updates(img, opname='list')
File "/opt/glassfish4/updatetool/vendor-packages/updatetool/common/ips/_init_.py", line 630, in get_list_of_updates
verbose = False)
File "/opt/glassfish4/pkg/vendor-packages/pkg/client/image.py", line 2581, in make_install_plan
self.__call_imageplan_evaluate(ip, verbose)
File "/opt/glassfish4/pkg/vendor-packages/pkg/client/image.py", line 620, in __call_imageplan_evaluate
ip.evaluate()
File "/opt/glassfish4/pkg/vendor-packages/pkg/client/imageplan.py", line 506, in evaluate
if a[1].name == "dir" and \
File "/opt/glassfish4/pkg/vendor-packages/pkg/client/imageplan.py", line 263, in get_directories
for d in m.get_directories(self.new_excludes):
File "/opt/glassfish4/pkg/vendor-packages/pkg/manifest.py", line 720, in get_directories
alist = [actions.fromstr(s.strip()) for s in f]
File "/opt/glassfish4/pkg/vendor-packages/pkg/actions/_init_.py", line 161, in fromstr
atype, ahash, attr_dict = _fromstr(string)
MalformedActionError: Malformed action at position: 45:
dir path=jdk7/lib/missioncontrol/Java Mission Control.app/Contents/Resources variant.os.bits=32
^

Regards!



 Comments   
Comment by hongz1 [ 06/Mar/14 02:44 AM ]

I also got an exact same error. (OSX 10.9.2)

Comment by klaraward [ 15/Apr/14 09:35 AM ]

My guess would be that the python script can't handle spaces in the path?
.../Java Mission Control.app/....
(I happen to be responsible for naming that path)

Comment by Snjezana Sevo-Zenzerovic [ 15/Apr/14 02:22 PM ]

Klara, you are absolutely right - that particular path was supposed to be quoted in the IPS package manifest definition since it contains space character.

That being said, I am somewhat confused since we used that same JDK IPS package to produce Java EE SDK with JDK cobundles some time ago without obvious issues but it is worth noting that we did cross-platform build on Solaris. It is possible that Solaris pkg client is more forgiving.

Immediate workaround for the problem would be to remove affected JDK IPS package from the MacOS specific UC native repository.





[GLASSFISH-20922] upgrading weld-osgi-bundle.jar into 2.1.0.Final Created: 10/Dec/13  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0
Fix Version/s: 4.0.1

Type: Task Priority: Critical
Reporter: TangYong Assignee: jjsnyder83
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: elio.alves, jjsnyder83, mauritzlovgren and TangYong

 Description   

upgrading weld-osgi-bundle.jar into 2.1.0.Final, in the version, there is the following big changes based on [1] and [2]

1. javax.inject has been removed from <_exportcontents> and javax.inject dependency has been removed

2. javax.enterprise.* has been removed from <_exportcontents> and javax.enterprise:cdi-api dependency has been removed

3. guava dependency has been removed

All is based on [3]and [4]

[1]: https://github.com/weld/core/blob/2.1/bundles/osgi/pom.xml
[2]: https://github.com/weld/core/commit/3e5cc452783161a9aae40160da1656216084bc33
[3]: https://issues.jboss.org/browse/WELD-1428
[4]: https://issues.jboss.org/browse/WELD-1477

Once upgrading 2.1.0.Final, these big changes will need GF distro to do the following:

1. javax.enterprise:cdi-api will be put into modules
2. whether current guava module in gf will meet the demand from weld-osgi-bundle. This needs to be confirm.



 Comments   
Comment by TangYong [ 10/Dec/13 02:04 PM ]

3. also confirm whether some modules which only depend on cdi api originally exported by weld-osgi-bundle, needs to be
switched into depending on javax.enterprise:cdi-api?

Comment by mauritzlovgren [ 01/Apr/14 11:01 AM ]

Might be important to inform current 4.0.0 users of the serious memory leak in the Weld version that is bundled with 4.0.0 release (Weld 2.0). Weld has released a fix for part of this memory leak that was causing big trouble in our production environment: http://weld.cdi-spec.org/news/2014/01/14/weld-212-final/. I assume that GF 4.0.1 will have a newer version of Weld, at least 2.0.5.Final or newer?).

Comment by elio.alves [ 14/Apr/14 09:20 PM ]

I fix this bug and update the weld version toweld-2.1.2.Final but I dont know how to commit.

Somebody can help-me?

Below my changes

update of lib weld-osgi-api to weld-2.1.2.Final because the atual version have a bug that mixing the sessions
update on BootstrapConfigurationImpl and ACLSingletonProvider to works with weld-2.1.2.Final. I implemented 4 methods that reuse the same old methods
I put two others bundles because the weld require it
I created another packager... but i dont know if are in the correct form, but, works fine

Comment by elio.alves [ 14/Apr/14 09:23 PM ]

How I can commit my changes?
This is my first fix in the java.net/jira

Comment by jjsnyder83 [ 15/Apr/14 01:25 PM ]

If you send me the changes I will get them committed in the next few days. There are a couple other steps that have to be done too before we can change the version.





[GLASSFISH-21037] Glassfish fails to inject javax.xml.ws.Service instance Created: 10/Apr/14  Updated: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: matthiasblaesing Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: amy.yang, Martin Grebac, matthiasblaesing and srini.gf

 Description   

I try to inject a @WebServiceClient class into a singleton ejb. This fails. I have this:

@Singleton
@Startup
public class CacheManager {
    [...]
    @WebServiceRef(ZIGeneratorService.class)
    private ZIGenerator generator;
    [...]
}

This works as expected. Now I want to change that to inject the Service, not the port, so I change the above to:

@Singleton
@Startup
public class CacheManager {
    [...]
    @WebServiceRef(ZIGeneratorService.class)
    private ZIGeneratorService generator;
    [...]
}

According to the javadoc this should be possible:

http://docs.oracle.com/javaee/6/api/javax/xml/ws/WebServiceRef.html

The WebServiceRef annotation is used to define a reference to a web service and (optionally) an injection target for it. It can be used to inject both service and proxy instances.

But I get this:

Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Env-Prop: de.persona.dev.blaesing.test.simpleznwfrontend.CacheManager/generator@Field-Injectable Resource. Class name = de.persona.dev.blaesing.test.simpleznwfrontend.CacheManager Field name=generator@javax.jws.WebServiceRef@@@ into class de.persona.dev.blaesing.test.simpleznwfrontend.CacheManager: Lookup failed for 'java:comp/env/de.persona.dev.blaesing.test.simpleznwfrontend.CacheManager/generator' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:717)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:484)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:170)
	at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:138)
	... 50 more
Caused by: javax.naming.NamingException: Lookup failed for 'java:comp/env/de.persona.dev.blaesing.test.simpleznwfrontend.CacheManager/generator' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException [Root exception is com.sun.xml.ws.model.RuntimeModelerException: Eine WebService-Annotation ist in Klasse nicht vorhanden: webservice.ZIGeneratorService]]
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
	at javax.naming.InitialContext.lookup(Unknown Source)
	at javax.naming.InitialContext.lookup(Unknown Source)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:613)
	... 53 more
Caused by: javax.naming.NamingException [Root exception is com.sun.xml.ws.model.RuntimeModelerException: Eine WebService-Annotation ist in Klasse nicht vorhanden: webservice.ZIGeneratorService]
	at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:271)
	at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:1082)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:745)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
	at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:159)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
	... 57 more
Caused by: com.sun.xml.ws.model.RuntimeModelerException: Eine WebService-Annotation ist in Klasse nicht vorhanden: webservice.ZIGeneratorService
	at com.sun.xml.ws.model.RuntimeModeler.getPortTypeName(RuntimeModeler.java:1621)
	at com.sun.xml.ws.model.RuntimeModeler.getPortTypeName(RuntimeModeler.java:1613)
	at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:453)
	at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:474)
	at javax.xml.ws.Service.getPort(Service.java:203)
	at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:231)
	... 62 more
|#]

Sorry for the german translation, but the glassfish instance ignores the locale override I set via the console... [If needed I can translate]

For reference these are the skeletons for the classes:

@WebService(name = "ZIGenerator", targetNamespace = "http://znw.blaesing.dev.persona.de/")
@XmlSeeAlso({
    ObjectFactory.class
})
public interface ZIGenerator {
 [...]
}
@WebServiceClient(name = "ZIGeneratorService", targetNamespace = "http://znw.blaesing.dev.persona.de/", wsdlLocation = "/WEB-INF/wsdl/it-u1411_8080/SimpleZNWBackend/ZIGeneratorService.wsdl")
public class ZIGeneratorService extends Service {
}

The artifacts are genereted by jaxws maven. I need the service, because according to this:

http://stackoverflow.com/questions/6627482/webservice-client-service-instantiation

I can use the service from multiple threads, while the Port objects are not safe to use that way.



 Comments   
Comment by amy.yang [ 15/Apr/14 02:24 AM ]

I don't see any EJB issue here. It might need web service team to look after





[GLASSFISH-4292] Support for idempotent methods Created: 28/Feb/08  Updated: 15/Apr/14

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

Type: New Feature Priority: Major
Reporter: Mahesh Kannan Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,292
Status Whiteboard:

v3-prd-item

Tags:
Participants: ksak, Mahesh Kannan and Tom Mueller

 Description   

This will allow ORB to retry invocations of idempotent methods



 Comments   
Comment by Mahesh Kannan [ 28/Feb/08 02:26 PM ]

Ref: EJB-07

Comment by ksak [ 28/Jan/09 10:02 AM ]

Taking ownership of Mahesh's bugs

Comment by Tom Mueller [ 06/Mar/12 09:55 PM ]

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





[GLASSFISH-20727] The value of victim-selection-policy is not output to server.log Created: 26/Jul/13  Updated: 14/Apr/14

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

Type: Bug Priority: Trivial
Reporter: tak09 Assignee: ying.x.hu
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish-4.0.1-b02-07_24_2013
Windows 7
Java 1.7.0_17


Tags:
Participants: tak09 and ying.x.hu

 Description   

The value of victim-selection-policy is not output to server.log.

In the sun-ejb-jar.xml file, you can set victim-selection-policy.
<victim-selection-policy>LRU</victim-selection-policy>

One of these can be set for victim-selection-policy.

  • An invalid value(such as hoge)
  • LRU
  • FIFO
  • NRU

The victim-selection-policy is added in the error message in server.log as shown below.
The issue is that when LRU is set, the value of victim-selection-policy is not written in server.log. In all other cases, the value of victim-selection-policy is written.

When an invalid value is set, [NRU-samples.ejb.stateful.simple.ejb.CartBean]

[2013-07-26T11:23:20.338+1000] [glassfish 4.0] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=114 _ThreadName=p: thread-pool-1; w: 2] [timeMillis: 1374801800338] [levelValue: 1000] [[
[NRU-samples.ejb.stateful.simple.ejb.CartBean]: Cannot load from BACKUPSTORE FOR Key: <[890857700a21f-18914a92-0]>]]

When FIFO is set, [FIFO-samples.ejb.stateful.simple.ejb.CartBean]

[2013-07-26T11:34:13.335+1000] [glassfish 4.0] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=114 _ThreadName=p: thread-pool-1; w: 2] [timeMillis: 1374802453335] [levelValue: 1000] [[
  [FIFO-samples.ejb.stateful.simple.ejb.CartBean]: Cannot load from  BACKUPSTORE FOR Key: <[890857700a21f-18996a3b-1]>]]

When LRU is set, [samples.ejb.stateful.simple.ejb.CartBean]. Why LRU is not displayed?

[2013-07-26T11:41:33.026+1000] [glassfish 4.0] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=117 _ThreadName=p: thread-pool-1; w: 5] [timeMillis: 1374802893026] [levelValue: 1000] [[
  [samples.ejb.stateful.simple.ejb.CartBean]: Cannot load from  BACKUPSTORE FOR Key: <[890857700a21f-18a2a469-0]>]]

When NRU is set, [NRU-samples.ejb.stateful.simple.ejb.CartBean]

[2013-07-26T11:24:49.911+1000] [glassfish 4.0] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=117 _ThreadName=p: thread-pool-1; w: 5] [timeMillis: 1374801889911] [levelValue: 1000] [[
  [NRU-samples.ejb.stateful.simple.ejb.CartBean]: Cannot load from  BACKUPSTORE FOR Key: <[890857700a21f-18914a92-1]>]]

To reproduce the issue,

1.Update stateful-simple.ear\stateful-simpleEjb.jar\META-INF\sun-ejb-jar.xml
Change <victim-selection-policy> to hoge, LRU, FIFO or NRU.

2.Deploy application.
asadmin deploy stateful-simple.ear

3.Run batch file.
run_client.bat

4.Check server.log

5. Undeploy application
asadmin undeploy stateful-simple

6. Repeat Step 1-5



 Comments   
Comment by tak09 [ 26/Jul/13 03:03 AM ]

Please download the test application here.

https://www.dropbox.com/s/q76jns25obt4s02/apps.zip

Test application stateful-simple.ear is contained in \build\assemble\ear

Thank you.





[GLASSFISH-20995] Exception in thread "connector-timer-proxy" Created: 27/Feb/14  Updated: 14/Apr/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: labkeeper Assignee: srini.gf
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Version by asadmin version --verbose is:
Version = GlassFish Server Open Source Edition 4.0 (build 89), JRE version 1.7.0_45

Installation windows, zip, full 4.0 version.

Patched: weld-osgi-bundle-2.0.5-Final.jar because leaking memory in JSF and nucleus-grizzly-all.jar because of compression error.


Tags: 4_0_1-review
Participants: labkeeper and srini.gf

 Description   

Scenario:
EJB (Timer) takes connection from pool and executes query. After execution of few queries (each query obtains new connection and releases it after query) got 1 minute timeout and then exception is thrown:

[2014-02-27T17:20:29.953+0100] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=810 _ThreadName=Thread-4] [timeMillis: 1393518029953] [levelValue: 1000] [[
Exception in thread "connector-timer-proxy"]]

[2014-02-27T17:20:29.953+0100] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=810 _ThreadName=Thread-4] [timeMillis: 1393518029953] [levelValue: 1000] [[
java.lang.IllegalArgumentException: can't parse argument number: PoolInfo : (name=java:app/sqltbstelematico)
at java.text.MessageFormat.makeFormat(MessageFormat.java:1420)
at java.text.MessageFormat.applyPattern(MessageFormat.java:479)
at java.text.MessageFormat.<init>(MessageFormat.java:363)
at com.sun.enterprise.util.i18n.StringManagerBase.getStringWithDefault(StringManagerBase.java:205)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.printConnectionLeakTrace(ConnectionLeakDetector.java:180)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.potentialConnectionLeakFound(ConnectionLeakDetector.java:160)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.access$000(ConnectionLeakDetector.java:63)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector$ConnectionLeakTask.run(ConnectionLeakDetector.java:225)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: java.lang.NumberFormatException: For input string: " PoolInfo : (name=java:app/sqltbstelematico)"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:481)
at java.lang.Integer.parseInt(Integer.java:527)
at java.text.MessageFormat.makeFormat(MessageFormat.java:1418)
... 9 more]]

Later timer is recreated and scheduled at fixed rate (see attached log).
Later have errors RAR5117 (2 times), RAR5114 (2 times) and after another minute again 4 errors.
After another minute got errors RAR5109, RAR7093, RAR8066 3 times and following queries execution continues.



 Comments   
Comment by labkeeper [ 27/Feb/14 05:18 PM ]

Cannot attach compressed log.





[GLASSFISH-21012] Can't compile JSPs when default security manager is installed Created: 20/Mar/14  Updated: 14/Apr/14

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

Type: Bug Priority: Minor
Reporter: Scott Oaks Assignee: kchung
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File server.log    
Tags: 4_0_1-review
Participants: Dhiru Pandey, kchung and Scott Oaks

 Description   

Enabled the security manager in a new domain using -Djava.security.manager -Djava.security.policy=/path_to/config/server.policy. JSPs would no longer compile due to an exception in initializer error from javac



 Comments   
Comment by Dhiru Pandey [ 20/Mar/14 06:32 PM ]

Is this a problem on JDK 7 too ?

Comment by kchung [ 24/Mar/14 06:05 PM ]

From the stack trace, it appears that the bug is in javac, during its static initializer.

[2014-03-20T10:21:46.871-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=34 _ThreadName=Thread-4] [timeMillis: 1395336106871] [levelValue: 1000] [[
  An exception has occurred in the compiler (1.8.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.]]

[2014-03-20T10:21:46.873-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=34 _ThreadName=Thread-4] [timeMillis: 1395336106873] [levelValue: 1000] [[
  java.lang.ExceptionInInitializerError]]

[2014-03-20T10:21:46.873-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=34 _ThreadName=Thread-4] [timeMillis: 1395336106873] [levelValue: 1000] [[
  at com.sun.tools.javac.code.Symtab.<init>(Symtab.java:67)]]

[2014-03-20T10:21:46.873-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=34 _ThreadName=Thread-4] [timeMillis: 1395336106873] [levelValue: 1000] [[
  at com.sun.tools.javac.code.Symtab.instance(Symtab.java:61)]]

[2014-03-20T10:21:46.873-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=34 _ThreadName=Thread-4] [timeMillis: 1395336106873] [levelValue: 1000] [[
  at com.sun.tools.javac.jvm.ClassReader.<init>(ClassReader.java:290)]]

[2014-03-20T10:21:46.873-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=34 _ThreadName=Thread-4] [timeMillis: 1395336106873] [levelValue: 1000] [[
  at com.sun.tools.javac.jvm.ClassReader.instance(ClassReader.java:253)]]

[2014-03-20T10:21:46.873-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=34 _ThreadName=Thread-4] [timeMillis: 1395336106873] [levelValue: 1000] [[
  at com.sun.tools.javac.main.JavaCompiler.<init>(JavaCompiler.java:355)]]
Comment by Scott Oaks [ 24/Mar/14 06:26 PM ]

I would say that the bug is in the default security.policy file not granting tools.jar (or wherever javac is loaded from) the appropriate permissions. If the appropriate policies are in place, then the JSP can compile (though I'm not exactly sure what the smallest set of permissions is).

This does not occur with JDK 7. But the location of Symtab.java is not changed (it is still in tools.jar), so I'm not sure exactly what the issue is. I see that before that, the server complained about a JACC Policy Porivder failed permission check; I wonder if that is related?

Comment by kchung [ 02/Apr/14 10:57 PM ]

I was able to duplicate this error just by enabling the security manager and accessing a JSP page deployed in domain1. I also verified that this is only an issues with JDK 8, and not jdk 7.

The server.policy in domain1/config has this line:

grant codeBase "file:${com.sun.aas.javaRoot}/lib/tools.jar" { permission java.security.AllPermission; };

It appears that javac is granted full permission, so it shouldn't have problem accessing the JSP page.

It also appears that the exception occurs at the constructor for javac, before the compilation of the JSP page starts.

I still think this is a javac issue, but I don't know how to reproduce the error with a standalone test.





[GLASSFISH-20295] Keep timers by default Created: 12/Apr/13  Updated: 13/Apr/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: future release
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mkarg Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1.1, JDK 1.7.0_17, Windows 7 Pro SP 1, x64


Tags:
Participants: marina vatkina, mkarg, reza_rahman and Tom Mueller

 Description   

Many business applications rely on timers. For example, it is quite typical to have a timer fire up when an insurance contract is to be renewed. Processes like these are usually modelled as MDBs reacting on Create, Update, Delete and Timout Events of the contract. Hence, these timers are business Information. If these get lost, the process is not working anymore, as no timeout is ever fired then.

It is quite typical to install new bug fixes for an application from time to time. The usual way is to do a redeploy. But: Unless "--keepstate" is used, the timers will get lost. Say that loud: Unless the Administrator takes extra care, Business Information is destroyed by GlassFish! But how should the Administrator know? The truth is: He won't. It is quite usual in large companies that a business division obtains a software package, forwards it to the admin to run it, but neither of both ever knows that timers even are used by that software package. How should they?

There are three theoretical solutions to not lose timers:
(1) GlassFish must keep timers by default but never delete them – unless it is explicitly told by a "--keepstate=false". This is true for both, redeploy AND undeploy – the the administrator might want to deploy again on a different GlassFish host accessing the same database, expecting the timers to be untouched inside of the RDBMS! Note that I do not suggest to make "true" the default of --keepstate as the Administrator typically does not want to Keep HTML sessions open but solely wants to rescue persistent timers!
(2) GlassFish team writes on the web site and on the first page of the admin docs a big fat red warning that essential business information is destroyed in the database at undeploy and redeploy, it is essential to use "--keepstate=true" always when using these commands. This is a ridiculous idea.
(3) GlassFish Team writes on the web site and on the first page of the developer docs a big fat red warning that essential Business Information is destroyed in the database at undeploy and redeploy, hence application vendors shall prints a big fat red warning on their boxes and docs, that when the application is run on GlassFish, "--keepstate=true" MUST be used ALWAYS with undeploy and redeploy to prevent data loss. This also is a ridiculous idea.

To sum up, the only real solution working in the real world outside of GlassFish development labs is to ALWAYS keep persistent timers untouched in the database, at least unless explicitly "--keepstate=false" is issued by the Administrator.



 Comments   
Comment by Tom Mueller [ 12/Apr/13 02:30 PM ]

Changing to the ejb_container component since this is related to EJB timers.

Comment by mkarg [ 10/Apr/14 02:39 PM ]

Anybody willing to at least write down an opinion of the EJB team about this proposal after one year since I proposed this feature change?

Comment by reza_rahman [ 10/Apr/14 02:52 PM ]

We are currently prioritizing bugs for the upcoming 4.x release. To tell you the truth I'm not sure we will get to feature requests like this in the near term. I hate to ask this, but would it be possible for you to contribute the feature?

Comment by mkarg [ 12/Apr/14 02:47 PM ]

Let me be frank. This is a really small change for someone who knows the source code well. We don't. For us, it is several days of work to at least be able to compile GlassFish. So we will provide a fix if it will not be in vain only. That means clearly, we need an agreement from your product lead that it is OK for him that we will change the default from "discard timers" to "keep timers". If Oracle agrees to that, we will donate that code change. But see, we will not invest any second as long as the GlassFish team later decide that it actually is UNWANTED to modify this default.

Comment by reza_rahman [ 12/Apr/14 03:12 PM ]

Excellent - this is all good. To get this process started, could you kindly make sure that this change won't be contrary to the EJB/Java EE spec? In the meanwhile, I'll follow up with the respective product/resource manager to see what they think. From our end, the only issue is really proper prioratization. As I stated the current focus is bug fixes but I'm inclined to think we could make room for integrating a good contribution.

Comment by mkarg [ 12/Apr/14 10:10 PM ]

In fact, when I first have noticed that a redeployment will delete all existing triggers at redeployment (which are a kind of business process data actually) I was shocked. For me, this actually is not a feature, but is a really heavy bug in the design of the API. Maybe this changes the product manager's view when he understands that there is no difference between an application storing "end of contract" date in a database compared to "trigger timer at end of contract" and not storing this into the database. While the first survives a redeployment, the second does not. This means, a business process might survice or not simply by going via JPA compared to persistent triggers. This is so weird, that anybody I talked to said: "This MUST be a bug."

Comment by reza_rahman [ 13/Apr/14 12:12 AM ]

The reason I am asking to check the spec is that the spec may have an opinion on what should be done at redeployment. I know you don't see it that way but erasing previous trigger data may be the most conservative approach to deal with potential changes made to triggers as a result of the deployment. This is likely the reason to explicitly make sure the user wants previous triggers preserved.

This all being said, let's see what the product managers think. In the least we could see if things need to be documented better.





[GLASSFISH-20944] @DataSourceDefinition defined data source can't be used in persistence.xml Created: 08/Jan/14  Updated: 12/Apr/14

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: arjan tijms Assignee: Mitesh Meswani
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-evangelists 4_0_1-review
Participants: arjan tijms and Mitesh Meswani

 Description   

Defining a data source from within the application using either @DataSourceDefinition on a class or the data-source element in web.xml, and then using this in persistence.xml will cause a deployment failure.

E.g.

web.xml
<data-source>
    <name>java:app/MyApp/MyDS</name>
    <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
    <url>jdbc:h2:mem:test</url>
</data-source>

and

persistence.xml
<persistence-unit name="testPU">
    <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
</persistence-unit>

will result in:

org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL:   vmcid: 0x0  minor code: 0 completed: Maybe] on Resource [rollback] operation.  vmcid: 0x0  minor code: 0  completed: No
	at com.sun.jts.CosTransactions.RegisteredResources.distributeRollback(RegisteredResources.java:1187)
	at com.sun.jts.CosTransactions.TopCoordinator.rollback(TopCoordinator.java:2291)
	at com.sun.jts.CosTransactions.CoordinatorTerm.rollback(CoordinatorTerm.java:530)
	at com.sun.jts.CosTransactions.TerminatorImpl.rollback(TerminatorImpl.java:286)
	at com.sun.jts.jta.TransactionImpl.rollback(TransactionImpl.java:162)
	... 126 more

WARNING: RAR5035:Unexpected exception while destroying resource from pool __SYSTEM/pools/__datasource_definition/5f110772-6547-4c6e-9d56-1a437f052bd8/java:app/MyApp/MyDS. Exception message: This web container has not yet been started

I provided two test cases that demonstrate the issue for the Java EE samples project: https://github.com/javaee-samples/javaee7-samples/pull/188

Running these will immediately reproduce the issue.






[GLASSFISH-20507] NullPointerException in RuntimeModelBuilder.java line 195 Created: 10/May/13  Updated: 12/Apr/14

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

Type: Bug Priority: Critical
Reporter: mkarg Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1.2.2, Win 7 Pro SP 1 (32 Bit), JDK 1.7.0_21


File Attachments: GZip Archive GF_20507.tar.gz    
Tags: incomplete
Participants: Iaroslav Savytskyi, Martin Grebac and mkarg

 Description   

Application is working well on GlassFish 3.1.1, but not on 3.1.2.2!

When deploying on GlassFish 3.1.2.2 instead (with same environmental conditions), it crashes when JAXB-unmarshalling the exact same data! Since it works in GF 3.1.1, it seems GF 3.1.2.2 replaces working parts of JAXB by failing replacements!

Simplified stack trace:

com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder$IDTransducerImpl.parse() (line 195) <--- throws NPE here
com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.parse() (line 247)
...
javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal() (line 219)
de.quipsy.util.http.HttpClient (line ...) <--- catched in my code when doing marshaller.unmarshal(InputStream).

Strange but true, this happens only with some XML content, but not with any other. And no, the InputStream is not null.

We cannot migrate from 3.1.1 to 3.1.2.2 because of this issue!



 Comments   
Comment by Martin Grebac [ 13/May/13 09:27 AM ]

Hi, thanks for submission. We can't do anything about it without the (as minimal as possible) reproducible testcase. Have you tried running your application against latest JAXB to verify if the issue is already fixed?

Comment by mkarg [ 13/May/13 05:57 PM ]

The problem is that the fault only happens in the middle of our full-size Enterprise application, which is a rather heavy sized EAR that Needs lots of resources and database tables to get to that Point that is crashing, unfortunately. I do not see any chance to provide a test case. So you need to tell me things I can trace to help you (like enabling Special logging levels). JAXB is the one contained in JRE 7u21. Is that what you mean with "latest" or how to make GlassFish use "latest"?

Comment by mkarg [ 02/Apr/14 07:50 AM ]

Bug still exists in GF 4.0 running on JDK 1.8.0!

This is a showstopper for us to migrate from 3.1.1 to 4.0 or at least 3.1.2.2.

Comment by mkarg [ 02/Apr/14 11:54 AM ]

Unfortunately I cannot test against 4.0.1-nightly-latest due to https://java.net/jira/browse/GLASSFISH-21027. As soon as GLASSFISH-21027 is fixed I will try whether the bug is possibly gone in 4.0.1 (in 4.0.0 it is still existing).

Comment by mkarg [ 03/Apr/14 07:28 AM ]

I found out that the problem can be reproduced in my EAR by the following:

  • Use @XmlID on a public String member of @XmlRootElement class Parent.
  • Use @XmlRefID on @XmlAttribute private Parent myParent within class Child.
  • Child itself is parent to another child, having @XmlID on its own so the Grand Child uses @XmlRefID again, etc.
    -> You get a chain of @XmlID parent – @XmlIDRef child – @XmlIDRef grandchild.

When unmarshalling such a JAXB tree in some cases (more often than not in my application) the failure occurs.

I can proof this by simple removing the @XmlID / @XmlIDRef annoations, which makes the unmarshalling work correctly, but certainly leading to wrong results (included copies of the parents instead of referenced singletons).

We really are stuck with this! It is a total showstopper! Please help us with a fix! If there is anything we can do to speed this up, please tell us right now!

Comment by mkarg [ 03/Apr/14 02:36 PM ]

Test project (WAR file incl. source code and Maven build script demonstrating the bug) sent directory to Iaroslav Savytskyi. The bug only happens with a class uses both, @XmlID and @XmlJavaTypeAdapter.

Comment by mkarg [ 10/Apr/14 12:19 PM ]

Provided WAR file with test code a week ago but did not even get any ack of receipt so far. Possibly you didn't get my emails or your answers are getting lost. Can you please ack here so I know that you received the test code?

Comment by Iaroslav Savytskyi [ 10/Apr/14 03:29 PM ]

User's test case.

Comment by Iaroslav Savytskyi [ 10/Apr/14 03:37 PM ]

Hi,

To be honest I can't promise any terms when we'll be able to start working on this.

Comment by mkarg [ 12/Apr/14 02:43 PM ]

Can you please provide us with a time frame when Oracle might be able to fix this critical bug? I mean, it is OK if this is not solved in the next weeks certainly, but we should have a GlassFish including a fixed JAXB within the next six months if any possible. In the end we talk about a showstopper without any existing workaround.





[GLASSFISH-21040] Update commons-fileupload Created: 11/Apr/14  Updated: 11/Apr/14

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Joe Di Pol Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-review
Participants: Joe Di Pol

 Description   

Update commons-fileupload to 1.3.1 (requires commons-io 2.2)






[GLASSFISH-21039] More details to be provided for the Password Encryption Algorithm parameter while creating JDBCRealm Created: 11/Apr/14  Updated: 11/Apr/14

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

Type: Improvement Priority: Minor
Reporter: Nithya Ramakrishnan Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Anissa Lam and Nithya Ramakrishnan

 Description   

The Password Encryption Algorithm parameter is shown as mandatory in the form page for creation of a JDBCRealm. It is required only in case of JDBC Digest Realm and not JDBC Realm . Since both these share the common realm classname (with only their login modules being different) its good to remove the mandatory field for the paramters since it is confusing in case of plain JDBCRealm.

Also, it would be good to add more text for the paramter, since there have been many questions regarding this:

" It denotes the algorithm for storing the passwords in the database in an encrypted form for JDBC Digest Realms. The key for decryption is the master password."






[GLASSFISH-20992] Clustered deployment sometimes fails with error "Command disable failed on server instance xxx: remote failure: Application not registered Command deploy failed." Created: 21/Feb/14  Updated: 11/Apr/14

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

Type: Bug Priority: Critical
Reporter: electricsam Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, JDK 1.7.0_45


Tags:
Participants: electricsam and Hong Zhang

 Description   

Sometimes when redeploying an application, the deploy fails with the following error:

Failure: Command disable failed on server instance xxxxxx: remote failure: Application not registered Command deploy failed.

Repeated attempts always fail. After the error appears once it seems like nothing can be deployed.

Sometimes the error is:

Error occurred during deployment: Keys cannot be duplicate. Old value of this key property, nullwill be retained. 

Here is the command:

asadmin deploy --force=true --deploymentorder 300 --target yyyyy 

Sometimes by trial and error I can get the deploy to work. Here is what I've tried:

1. Stop the domain then remove the "generated" and "osgi-cache" and re-start the domain
2. Stop the cluster and the domain then remove the "generated" and "osgi-cache" from the domain and the nodes and re-start the domain and cluster
3. Undeploy the problem app, then redeploy it. However, sometimes the app is listed as having been un-deployed already and this fails
4. Undeploy everything that can be undeployed. Manually delete the applications that could not be undeployed via asadmin from the applications folder and manually edit the domain.xml to remove references to those apps.



 Comments   
Comment by Hong Zhang [ 11/Apr/14 08:24 PM ]

Can you provide the test application and the set of steps for us to reproduce from our side?





[GLASSFISH-21038] domain.xml application context race condition Created: 11/Apr/14  Updated: 11/Apr/14

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

Type: Bug Priority: Major
Reporter: Jovok Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

Windows 7 OS


Tags:
Participants: Hong Zhang, Jovok and Martin Grebac

 Description   

My team is experiencing an issue with deploying a war file containing web services. When the war is generated and then deployed, the following line is sometimes missing from the domain.xml file under domains/domain1/config:

<engine sniffer="webservices"></engine>

Other facts:
-Attempting to access any web service then results in an error involving the javax.servlet.jar, for reasons unknown.
-Nothing in our project ever modifies the domain.xml file
-Using the /exact/ same war file, un-deploying and then re-deploying randomly results in the <engine sniffer="webservices"></engine> line being present or missing. The war file is not regenerated, we just have to undeploy and redeploy.
-Adding the <engine sniffer="webservices"></engine> manually to the domain.xml file, stopping the server, and restarting the server fixes the issue, and the inverse is also true.
-There are other <engine sniffer=".*"></engine> lines that are always present.



 Comments   
Comment by Hong Zhang [ 11/Apr/14 08:21 PM ]

Can you attach a reproducible test case for us to reproduce and look from our side?

Assign to web services team for initial evaluation.





[GLASSFISH-21036] List not found via expression: '$attribute{_children}'. Created: 09/Apr/14  Updated: 09/Apr/14

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

Type: Bug Priority: Major
Reporter: trukhinyuri Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jelastic | CentOS 6


Tags:
Participants: Ed Burns and trukhinyuri

 Description   

[#|2014-04-08T18:36:41.298+0000|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web.vs._asadmin|_ThreadID=100;_ThreadName=Thread-46;|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException: List not found via expression: '$attribute{_children}'.
at com.sun.jsftemplating.layout.descriptors.LayoutForEach.getList(LayoutForEach.java:113)
at com.sun.jsftemplating.layout.descriptors.LayoutForEach.encode(LayoutForEach.java:167)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutDefinition.encode(LayoutDefinition.java:250)
at com.sun.jsftemplating.renderer.TemplateRenderer.encodeEnd(TemplateRenderer.java:139)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encodeChild(LayoutElementBase.java:558)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.encode(LayoutComponent.java:243)
at com.sun.jsftemplating.layout.descriptors.LayoutComposition.encodeThis(LayoutComposition.java:161)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:330)
at com.sun.jsftemplating.layout.descriptors.LayoutComposition.encodeThis(LayoutComposition.java:161)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:330)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutDefinition.encode(LayoutDefinition.java:246)
at com.sun.jsftemplating.layout.LayoutViewHandler.renderView(LayoutViewHandler.java:683)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:744)

#]


 Comments   
Comment by trukhinyuri [ 09/Apr/14 01:20 PM ]

reproduced only in HA mode





[GLASSFISH-21035] FileRealm.getGroupNames throws NPE when user does not exist. Created: 09/Apr/14  Updated: 09/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 3.1.2_b23, 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: sjdavies Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.6.0_45 on Windows and RHEL.


Tags:
Participants: JeffTancill and sjdavies

 Description   

Regarding com.sun.enterprise.security.auth.realm.file.FileRealm implementation.

The following code fragment will result in a NullPointerException being thrown from a servlet's service method when user "FOO" does not exist:

FileRealm realm = new FileRealm("keyfile");
realm.getGroupNames("FOO");

Method signature for getGroupNames indicates it throws NoSuchUserException but this is not the case.

The sequence:

FileRealm realm = new FileRealm("keyfile");
realm.getUser("FOO");

does throw NoSuchUserException.






[GLASSFISH-21034] Glassfish randomly swaps queues Created: 08/Apr/14  Updated: 09/Apr/14

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: enschedem Assignee: David Zhao
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MacOS


Tags:
Participants: David Zhao and enschedem

 Description   

I the following example I using 2 JMS queues in Glassfish 4.0. The first class sends a message to queue 1, this is picked up by a second bean which forwards the message to a next queue. From there it is picked up to the last bean. Schematically:

Creator -> jms/q1 -> QueueBean1 -> jms/q2 -> QueueBean2.

Problem is that QueueBean1 and QueueBean2 are receiving messages randomly from q1 and q2. It seems to me that q1 and q2 are just one queue and the MessageBeans a looking to that queue.



 Comments   
Comment by David Zhao [ 09/Apr/14 05:48 AM ]

How did you create jms/q1 and jms/q2? Please check if they are pointing to the same physical destination in MQ. If true, then the 2 MDBs are listening to the same Queue actually.





[GLASSFISH-19686] Java EE security classes are part of nucleus Created: 18/Feb/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: JeffTancill and Sanjeeb Sahoo

 Description   

Classes like J2EESecurityManager JavaEESecurityLifecycle are part of nucleus when they should not be.






[GLASSFISH-19790] configure-ldap-for-admin should be investigated such that the default security service configuration is updated when switching admin realm to LDAP. Created: 07/Mar/13  Updated: 07/Apr/14

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

Type: Bug Priority: Minor
Reporter: JeffTancill Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: JeffTancill

 Description   

configure-ldap-for-admin should be investigated such that the default security service configuration is updated when switching admin realm to LDAP.






[GLASSFISH-20063] GUI cannot handle mulitbyte char in the login page Created: 26/Mar/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: console
Participants: Anissa Lam, Jason Lee and JeffTancill

 Description   

I am able to create an admin user with multibyte char, eg 中文 through console or CLI.
In console u can create this user by:
Config -> server-config -> Security -> Realms -> admin-realm , manage User button, select and add user.

The admin-keyfile in domain1/config directory is updated correctly.

If i use CLI with this user name, and enter password, it works fine. so, it shows multibyte char is supported.
eg.
%asadmin --user 中文 create-jdbc-resources --connectionpoolid DerbyPool myJDBC

But i cannot login to console using this user name.
Also, I cannot delete this user when i go to
Config -> server-config -> Security -> Realms -> admin-realm , manage User button, select and delete it.



 Comments   
Comment by Jason Lee [ 26/Mar/13 07:10 PM ]

The Console login screen POSTs to j_security_check for the credential validation and does no actual user/pass handling at this point in the user experience. This seems to be an issue in the security layer, so I'm reassigning to that team for evaluation.





[GLASSFISH-20336] ejb.security_preinvoke_exception for security devtests Created: 17/Apr/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk


Tags:
Participants: bebbo, Craig Perez and JeffTancill

 Description   

The security devtests mdb and timerStandalone have been disabled from the set of tests. These tests both fail for the same root cause:

java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)



 Comments   
Comment by Craig Perez [ 17/Apr/13 06:45 PM ]

mdb test:

[2013-04-17T11:25:00.018-0700] [glassfish 4.0] [SEVERE] [ejb.security_preinvoke_exception] [javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application] [tid: _ThreadID=33 _ThreadName=admin-listener(2)] [timeMillis: 1366223100018] [levelValue: 1000] [[
SECEJB9000: Exception while running pre-invoke
java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)
at org.glassfish.ejb.mdb.MessageBeanContainer.<init>(MessageBeanContainer.java:248)
at org.glassfish.ejb.mdb.MessageBeanContainerFactory.createContainer(MessageBeanContainerFactory.java:63)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]

Comment by Craig Perez [ 17/Apr/13 06:46 PM ]

timeStandalone test:

[2013-04-17T11:29:06.808-0700] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=98 _ThreadName=Thread-3] [timeMillis: 1366223346808] [levelValue: 800] [[
In SfulEJB:hello()]]

[2013-04-17T11:29:06.819-0700] [glassfish 4.0] [SEVERE] [ejb.security_preinvoke_exception] [javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application] [tid: _ThreadID=98 _ThreadName=p: thread-pool-1; w: 2] [timeMillis: 1366223346819] [levelValue: 1000] [[
SECEJB9000: Exception while running pre-invoke
java.lang.NullPointerException
at java.util.Arrays$ArrayList.<init>(Arrays.java:2842)
at java.util.Arrays.asList(Arrays.java:2828)
at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:299)
at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:295)
at org.glassfish.ejb.security.application.EJBSecurityManager$2.run(EJBSecurityManager.java:857)
at com.sun.enterprise.security.common.AppservAccessController.doPrivileged(AppservAccessController.java:61)
at org.glassfish.ejb.security.application.EJBSecurityManager.loginForRunAs(EJBSecurityManager.java:855)
at org.glassfish.ejb.security.application.EJBSecurityManager.preInvoke(EJBSecurityManager.java:824)
at org.glassfish.ejb.security.application.EjbSecurityComponentInvocationHandler$1.beforePreInvoke(EjbSecurityComponentInvocationHandler.java:76)
at org.glassfish.api.invocation.InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:180)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1628)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:456)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:97)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:698)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:246)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:430)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2516)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1906)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:204)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy267.hello(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:143)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:173)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatchToServant(ServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatch(ServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequestRequest(MessageMediatorImpl.java:1549)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:1425)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleInput(MessageMediatorImpl.java:930)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:213)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:694)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.dispatch(MessageMediatorImpl.java:496)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.doWork(MessageMediatorImpl.java:2222)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
]]

Comment by bebbo [ 29/Jul/13 11:15 AM ]

suggested fix: add a null check and create an empty array if null.

if (groups == null)
  groups = new String[0];
return Collections.enumeration(Arrays.asList(groups));




[GLASSFISH-20337] security devtests jmac failure Created: 17/Apr/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk


Tags:
Participants: Craig Perez and JeffTancill

 Description   

The security-jmac-httpservlet test in the jmac security devtests suite is failing and has been disabled.

The expected output includes an adjusted PrintWriter count that is not matching the golden files output.

Otherwise the general behavior and functional output looks correct.



 Comments   
Comment by Craig Perez [ 17/Apr/13 07:04 PM ]

From examining the test case, the MyHttpServletResponseWrapper.java only overrides the method write(char[] cbuf, int off, int len) and the test currently outputs a count of 0 vs 218 along with the blank lines that are not lining up 1-1 as previously.

Functionally the SAM is working but either the MyPrintWriter needs changes or the goldenfiles could be updated since the test will validate basic ServerAuthModule wrappering.

[webtest] Expected Output ****************************************
[webtest] Hello World from 196 HttpServlet AuthModule Test!
[webtest] <hr>
[webtest] Hello, shingwai123 from com.sun.s1asdev.security.jmac.httpservlet.HttpServletTestAuthModule
[webtest] PC = security-jmac-httpservlet-web/security-jmac-httpservlet-web
[webtest]
[webtest]
[webtest] <hr>
[webtest] Adjusted count: 218
[webtest]
[webtest] ********************************************************
[webtest] Actual Output ##########################################
[webtest] Hello World from 196 HttpServlet AuthModule Test!
[webtest] <hr>
[webtest] Hello, shingwai123 from com.sun.s1asdev.security.jmac.httpservlet.HttpServletTestAuthModule
[webtest] PC = security-jmac-httpservlet-web/security-jmac-httpservlet-web
[webtest]
[webtest] <hr>
[webtest]
[webtest] Adjusted count: 0





[GLASSFISH-20338] security devtests ciphertest failures Created: 17/Apr/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk


Tags:
Participants: Craig Perez and JeffTancill

 Description   

Disabled tests for ciphers:

  • SSL_RSA_WITH_DES_CBC_SHA
  • SSL_RSA_EXPORT_WITH_RC4_40_MD5

Use of -Dsun.security.ssl.allowUnsafeRenegotiation=true no impact both server and client side






[GLASSFISH-20339] security devtests wss roles failures Created: 17/Apr/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk


Tags:
Participants: Craig Perez and JeffTancill

 Description   

Disabled the roles tests for security devtests wss suite.

[exec] Apr 12, 2013 4:41:47 PM org.glassfish.appclient.client.acc.AppclientCommandArguments warnAboutPasswordUsage
[exec] WARNING: ACC013: The -password option is deprecated and will likely be removed in a future release. Please use -passwordfile or let the app client container prompt for the username and/or password if they are needed to access a remote resource.
[exec] com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: java.lang.Exception: Client not authorized for invocation of public java.lang.String com.sun.s1asdev.security.wss.roles.ejbws.HelloEjb.hello(java.lang.String) Please see the server log to find more detail regarding exact cause of the failure.



 Comments   
Comment by Craig Perez [ 17/Apr/13 07:30 PM ]

Additionally the roles2, ssl & sslclientcert where previously disabled

  • roles2 has same/similar test failure
  • ssl and sslclientcert have build failures on wsimport looking for WSDL at HTTPS URL




[GLASSFISH-20363] security devtests cert-realm-custom-loginmodule failure Created: 19/Apr/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

security-devtests-trunk


Tags:
Participants: Craig Perez and JeffTancill

 Description   

The cert-realm-custom-loginmodule security devtest is failing and has been disabled.

The client is being denied access to the test application that us using <CLIENT-CERT> authentication method.

Debug of the client SSL handshake looks fine but there is no information in the server log so further debug is needed.



 Comments   
Comment by Craig Perez [ 19/Apr/13 11:04 PM ]

Server log entries:

[2013-04-19T15:15:31.082-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=34 _ThreadName=admin-listener(3)] [timeMillis: 1366409731082] [levelValue: 800] [[
cert-realm-custom-loginmodule-web was successfully deployed in 3,797 milliseconds.]]

[2013-04-19T15:15:35.145-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=100 _ThreadName=Thread-16] [timeMillis: 1366409735145] [levelValue: 800] [[
Server shutdown initiated]]





[GLASSFISH-20377] Unable to create file users after changing key file of the file realm Created: 23/Apr/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: winston_jack Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: JeffTancill and winston_jack

 Description   

This is GlassFish 3.1.2.2 and GlassFish 4 issue.

After changing the key file of file realm of cluster,
I could not create file users.

ex)

asadmin create-auth-realm --classname com.sun.enterprise.security.auth.realm.file.FileRealm --property jaas-context=fileRealm:file=${com.sun.aas.instanceRoot}/config/keyfile1 test
asadmin set cluster.security-service.auth-realm.test.property.file=${com.sun.aas.instanceRoot}/config/keyfile2
asadmin stop-cluster cluster
asadmin start-cluster cluster
asadmin create-file-user --target cluster --authrealmname test user1

This error happened when executing asadmin create-file-user command.

The specified physical file C:\gf4b82\glassfish4\glassfish\domains\domain1/config/keyfile2 associated with the file realm test does not exist.

Likewise, if I set the key file to the other directory of glassfish (such as C:\work\keyfile),
asadmin create-file-user shows this error.
However, file users were created in the key file.

An error occurred during replication Failure: Command create-file-user failed on server instance instance: remote failure: Adding User user1 to file realm test failed. User user1 already exists.

If I tried GlassFish 2.1.1, these problem did not occur.






[GLASSFISH-20485] appclient -user xxx option is ignored unless -passwordfile is given Created: 08/May/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: mkarg Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1.1, Win 7 Pro SP 1 (64 Bit), JDK 1.7.0_21


Tags:
Participants: JeffTancill, mkarg and Tim Quinn

 Description   

Steps to reproduce:

  • appclient -name myname -client MyClient.jar

Expected result:

  • Login dialog should default user name to "myname".

Actual result:

  • Login dialog defaults user name to Windows Account.


 Comments   
Comment by Tim Quinn [ 08/May/13 11:19 AM ]

Updated title and component; this applies to the appclient utility

Comment by Tim Quinn [ 08/May/13 11:39 AM ]

The "-name" option on the appclient command specifies the name of the app client to be executed (especially if there are multiple app clients in the EAR), not to tell what username to use for authentication.

The "-user" option is used for specifying the username on the command line.

Markus, can you please confirm whether you are actually using "-name" or "-user" in your example?

Comment by mkarg [ 10/May/13 06:58 AM ]

Sorry for the typos, I was in a hurry.

Actually I typed:

appclient -user myname -Client MyClient.jar

And the ACC's login dialog Shows the user Name field defautled to the value "MARKUS KARG" (which seems to be taken from active directory), but not "myname".

Comment by Tim Quinn [ 24/May/13 03:52 PM ]

I am reassigning this to the security team.

The app client container invokes AppClientSecurityInfoImpl's constructor, passing the username (if the user provided one on the command line, null otherwise).

I looked around a little and it seems that ClientPasswordLoginModule interrogates the UsernamePasswordStore to retrieve a user-provided username and/or password but the code seems not to use those values (I concentrated on the username) in setting the default value in the callback.





[GLASSFISH-20588] Principal Classes have serious problems Created: 29/May/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Craig Perez
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Byron Nevins and Craig Perez

 Description   

Ref: Joshua Bloch, Effective Java, 2nd edition, item #8
Mr. Bloch does an excellent job of describing precisely the problem in these classes:
(all in common-util)
common/common-util/src/main/java/org/glassfish/security/common/Role.java
common/common-util/src/main/java/org/glassfish/security/common/Group.java
common/common-util/src/main/java/org/glassfish/security/common/Principal.java
3 problems:
(1) These problems are the only low level FindBugs issues in all of common-util.
(2) The equals/hash methods are a mess. Look at the FB results for common-utils. Especially look at the way the base class equals() method chedcks to see if the other object is a Group. Note how it doesn't check if it is a Role (why?). This is quite brittle. The base class ought to know nothing about subclasses!
(3) Even though all three classes implement the Principal interface, the outside calling code does NOT use it. Instead, it uses PrincipalImpl. Why bother with an interface if it isn't used ? Should either use them as a class hierarchy OR as references to interfaces.
I attempted to fix this using Bloch's recommendation which is to use composition instead of inheritance. I.e. I made all three implement the interface directly. Then Role and Group stopped being subclasses. This failed because outside code is looking for PrincipalImpl objects - not Principal objects.
PrincipalImpl pi = new PrincipalImpl("foo");
Group g = new Group("foo");
Role r = new Role("foo");
pi.equals(r) --> true
r.equals(pi) --> false






[GLASSFISH-21010] Under normal traffic, Glassfish crashes after disconnecting the network connection from client PC Created: 19/Mar/14  Updated: 07/Apr/14

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

Type: Bug Priority: Critical
Reporter: khanhdo Assignee: oleksiys
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish (version 4.0.1-b04-03_13_2014) installed in Windows 7.
A WebSocket application is deployed.


Issue Links:
Dependency
depends on GRIZZLY-1670 No event is called on HttpHandler's W... Resolved
Tags:
Participants: khanhdo, oleksiys and Pavel Bucek

 Description   

While Glassfish server working in normal traffic environment (throughput = 80 kbps), try to disconnect the network cable from a client. From then, Glassfish server works unstable and shortly after Glassfish server does not response to any request from other clients session.

Step to reproduct the issue:
Test PC A-------> Glassfish Server <---------Test PC B
(Ethernet network: 1 Gbps)

1. From a test PC A and B, open web browser sessions to connect to the testing site.
2. From these test PC, do some actions to acquire the data from server until the traffic throughput at server reaches and remains always nearly 80 kbps.
3. Disconnect network cable at the test PC A .
4. Monitor the reaction from the browser sessions from PC A, B and also from the server.

Actual result:
1. The site is loaded successfully at both test PC A and B. Browser sessions are connected to the WebSocket server endpoint and can send/receive WebSocket data.
2. The traffic throghput reaches nearly 80 kps at the server, no problem occurs.
3. - No data is transmitted to PC A because the cable is disconnected.

  • PC B still received the data in short time (10 seconds), then receives no more data
  • Glassfish server does not throw any log exception. In next 1-2 minutes, the Glassfish still accepts http connection, but later on, it does not response to any http request. It seems Glassfish crashed (ping to server is still ok).

Note:
1. This issue does not occur when closing the browser session. It only occurs when disconnect the physical cable or disable network adapter from the test PC.
2. Under low traffic (< 80 kps), this issue also not occurs.



 Comments   
Comment by oleksiys [ 20/Mar/14 05:44 AM ]

It would be great if you can take a thread dump snapshot, when GF stops responding (using jstack for example).

Can you please create a testcase for us (maven project)?

thank you!

Comment by khanhdo [ 20/Mar/14 04:02 PM ]

Hello Oleksiys,

Thanks for your comment.

Enclosed is the thread dump by jstack and also the exceptions output. The testcase in maven project will be provided soon later.

Best Regards,
Khanh Do

------------
1. Thread dump link to download:

https://docs.google.com/file/d/0B3mBNH6XLa-PMWlDMjVpWHdfelU/edit?pli=1

------------
2. Exceptions:

WARNING: WriteListener.onError
java.io.IOException: Connection closed
at org.glassfish.grizzly.asyncqueue.TaskQueue.onClose(TaskQueue.java:291)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.onClose(AbstractNIOAsyncQueueWriter.java:576)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.closeConnection(TCPNIOTransport.java:400)
at org.glassfish.grizzly.nio.NIOConnection$3.run(NIOConnection.java:485)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.execute(DefaultSelectorHandler.java:234)
at org.glassfish.grizzly.nio.NIOConnection.close0(NIOConnection.java:479)
at org.glassfish.grizzly.nio.transport.TCPNIOConnection.close0(TCPNIOConnection.java:292)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.writeCompositeRecord(TCPNIOAsyncQueueWriter.java:169)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:87)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.processAsync(AbstractNIOAsyncQueueWriter.java:423)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.executeIoEvent(WorkerThreadIOStrategy.java:103)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89)
at org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:412)
at org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:381)
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:345)
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:276)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.io.IOException: An established connection was aborted by the software in your host machine
at sun.nio.ch.SocketDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.flushByteBuffer(TCPNIOUtils.java:149)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.writeCompositeRecord(TCPNIOAsyncQueueWriter.java:158)
------------

Comment by oleksiys [ 20/Mar/14 07:35 PM ]

Hi,

thank you for the info.
The exception and the thread dump look fine, I can't see any sign of the problem.

Is it possible for you to create a testcase for us (maven based would be great)?

Thank you!

Comment by khanhdo [ 20/Mar/14 10:02 PM ]

Hi Oleksiys,

Thanks for your information.

Regarding to the maven testcase, I just created a WebSocket program to reproduce this issue, which can be cloned at the following Git link:

https://github.com/khanhdoth/GLASSFISH-21010

Best Regards,
Khanh Do

Comment by oleksiys [ 20/Mar/14 11:25 PM ]

perfect, thank you very much!
I'll let you know once I have more info.

Comment by oleksiys [ 27/Mar/14 01:21 AM ]

Hi,

unfortunately I can't reproduce the problem.
Can you pls. give me more details, when you say "but later on, it does not response to any http request", do you mean simple "http://localhost:8080" won't work?
Can you pls. try to connect to:

1) http://localhost:4848
2) telnet localhost 8080

Thank you!

Comment by khanhdo [ 03/Apr/14 08:02 PM ]

Hi Oleksiys,

Sorry for late reply. Yes, I mean only http and websocket services at http://localhost:8080 won't work; and 4848 is still ok.

In my orginal Websocket application, the root cause is that for every WebSocket message, I calls a thread to send it (in order to send the message as fast as possible without blocking the IO). Normally, a thread is fired and finished shortly when the sending is successfully. But when the network cable is disconnected, Glassfish still keep the session open for a long time. As a result, the sending threads still remain during this time. The situation becomes worse when there are more threads created to send other on-going messages.

Here, the problem I mentioned ("but later on, it does not response to any http request") occurs. Since there are too many threads are created more and more, this may exceed the capacity of the Glassfish server.

The small provided test application does not cover exactly what happens in my WebSocket application, sorry . It only shows that the sending thread is blocked when the network cable is disconnected. It causes the WebSocket Endpoint server is blocked and unable to send the message. Somehow it's similar to the situation I meet in my app.

So I don't know whether the root cause "the sending thread is blocked when the network cable is disconnected" is a bug or only a normal situation.

What is your idea?

Currently I use ThreadPoolExecutor to send the message. It helps to control the maximum of threads can be used to send the message, in order to prevent the problem.

Thanks & Best Regards,
Khanh Do

Comment by Pavel Bucek [ 03/Apr/14 08:13 PM ]

Hi khando,

can you please try to replace

session.getBasicRemote().sendText(msg);
with
session.getAsyncRemote().sendText(msg);
?

It returns Future instance, but if you won't call Future#get() on that, your thread should not remain blocked after disconnect happens.

Comment by khanhdo [ 04/Apr/14 11:37 AM ]

Hi Pavel,

Thanks for your suggestion. And here's the results after the cable disconnection:

1. session.getBasicRemote().sendText(msg) -> thread is blocked
2. session.getAsyncRemote().sendText(msg) -> thread is not blocked
3. session.getBasicRemote().sendObject(msg) -> thread is blocked
4. session.getAsyncRemote().sendObject(msg) -> thread is blocked

It's very strange for me that in case 4, thread is blocked. Is this a bug?

Unfortunately, I'm using sendObject() instead of sendText() to send the data... therefore, the threads are still blocked after disconnection.

Comment by Pavel Bucek [ 04/Apr/14 02:22 PM ]

ad case 4 - can you please post stacktrace of blocked thread(s)? (I don't see any reason why it should be blocked from the code perspective..)





[GLASSFISH-20589] AzResource URI Path encoding problems Created: 29/May/13  Updated: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: Craig Perez Assignee: Tim Quinn
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Nucleus


Tags:
Participants: Craig Perez and Tim Quinn

 Description   

The CommandSecurityChecker is creating AzResource URI by URL encoding the URI Path with the following logical operation:

new URI(ADMIN_RESOURCE_SCHEME, URLEncoder.encode(resourceName, RESOURCE_NAME_URL_ENCODING), null)

As an example, when using input resourceName as "/users/user/admin" this approach results in the following output from the constructed URI object:

URI.toString() 'admin:%252Fusers%252Fuser%252Fadmin'
URI.toASCIIString() 'admin:%252Fusers%252Fuser%252Fadmin'
uri.getAuthority() 'null'
uri.getPath() 'null'

thus yielding the AzResource based on the URI object unable to obtain proper the proper Path information.



 Comments   
Comment by Craig Perez