[GLASSFISH-16704] FileNotFoundException passing password to asadmin through std in Created: 23/May/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1.1, 4.0_b03
Fix Version/s: 3.1.1_b01

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

Tags: 3_1_1-upgrade

 Description   

In 3.1, the upgrade tool could pass the master password into asadmin by using the -passwordfile option with the value "". This told asadmin to accept the password on standard in so we could avoid writing the password out in plain text to a file. In the 3.1.1 branch, this is now causing a file not found exception. Easy to reproduce on command line:

In 3.1:
hostname% ./target/glassfish3/glassfish/bin/asadmin --passwordfile - start-domain
[asadmin waits on std in]

In 3.1.1:
./branch/glassfish3/glassfish/bin/asadmin --passwordfile - start-domain
java.io.FileNotFoundException: /Users/bobby/eraseme/- (No such file or directory)
Command start-domain failed.

This will block using the upgrade tool for any source domain that has a non-default master password.



 Comments   
Comment by Tom Mueller [ 23/May/11 ]

This problem shows up on the trunk as well.

Comment by Tom Mueller [ 23/May/11 ]

The root cause of this problem is due to a change in revision 45444 made for issue GLASSFISH-16150. That change introduced a call to SmartFile.sanitize in the ProgramOptions.getPasswordFile method. This results in the return value being an absolute pathname rather than the "" that CLIUtil.readPasswordFileOptions checks for later. The fix for issue GLASSFISH-16150 will need to be changed so that passing in "" for the passwordfile option still works.

Revision 45444 was made on March 8, so this is why the problem shows up in 3.1.1 and on the trunk. It needs to be fixed in both places.

Comment by Byron Nevins [ 23/May/11 ]

Trivial.

D:\3.1.1\admin\cli>svn commit
Sending cli\src\main\java\com\sun\enterprise\admin\cli\ProgramOptions.java
Transmitting file data .
Committed revision 47042.

D:\gf\v3\admin\cli>svn commit
Sending cli\src\main\java\com\sun\enterprise\admin\cli\ProgramOptions.java
Transmitting file data .
Committed revision 47043.

Comment by Bobby Bissett [ 24/May/11 ]

And verified.





[GLASSFISH-16499] Virtual Server not working Created: 29/Apr/11  Updated: 03/May/11  Resolved: 03/May/11

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Blocker
Reporter: bjornstenfeldt Assignee: Shing Wai Chan
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 pro & Windows 2008. Both 64-bit.


Tags: server, virtual

 Description   

We're trying to deploy a few EAR projects on GF3.1 and need to use virtual servers. Our setup works in GF3.0, which we're forced to use instead. It's rather troublesome though, as NetBeans 7 is bundled with GF3.1 and we need to install 3.0 to use it. Furthermore, when we use GF3.0, we must replace the JSF version every time we install it, due to a bug with PhaseListeners and virtual machines in GF3.0.

Here's what we do:

1) Install our project, tracker-ear.ear.
2) Create a new virtual server called tracker.
3) Set the default web module on our virtual server to tracker-ear#tracker-web.war.
4) Test if it's working. It's not. HTTP-error 500.
5) Restart GF.
6) Test if it's working. It's not. HTTP-error 500.
7) Look in the log file. It contains the following exception.

[#|2011-04-29T09:39:27.193+0200|SEVERE|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=83;_ThreadName=Thread-1;|WEB0149: Unable to set default-web-module [/tracker-web] for virtual server [tracker]
org.apache.catalina.LifecycleException: java.lang.Exception: No context matching /tracker-web deployed on virtual server tracker
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2034)
at com.sun.enterprise.web.WebContainer.loadDefaultWebModulesAfterAllAppsProcessed(WebContainer.java:1451)
at com.sun.enterprise.web.WebContainer.event(WebContainer.java:599)
at org.glassfish.kernel.event.EventsImpl$1.run(EventsImpl.java:120)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.Exception: No context matching /tracker-web deployed on virtual server tracker
at com.sun.grizzly.util.http.mapper.Mapper.addDefaultContext(Mapper.java:795)
at com.sun.grizzly.util.http.mapper.Mapper.setDefaultContextPath(Mapper.java:759)
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2026)
... 9 more

#]


 Comments   
Comment by Shing Wai Chan [ 29/Apr/11 ]

According to the above log message, the corresponding web app is not deployed to the virtual server 'tracker'.
One has to associate the application to the virtual server 'tracker' before setting the default-web-module of the virtual server.
This can be achieved through Admin Console: Applications > tracker-ear > Virtual Servers

Note that one has to set the http-listeners in a given virtual servers.
Now, you can set the default web module of the given virtual server.
If we do this, then there is no need to restart the server.

I have verified that it is working fine.

Comment by bjornstenfeldt [ 02/May/11 ]

Ok, it seems to be working now, but not quite as easy as you describe it. Here is what we did:

1) Deploy tracker-ear.ear.
2) Create a new virtual server called tracker on http-listener-1. (No default-web-module)
3) Update Applications > tracker-ear > Virtual Servers and select tracker. This fails and tracker isn't selected. Furthermore, tracker-ear is now disabled.
4) Edit domain.xml and force tracker-ear to use tracker virtual server.
5) Restart GF.
6) Enable tracker-ear. It will throw an exception, but is still enabled. See the exception below.
7) Select a default-web-module for tracker virtual server.
8) Test it. It works.

[#|2011-05-02T09:23:41.377+0200|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=40;_ThreadName=Thread-1;|Initializing Mojarra 2.1.0 (FCS 2.1.0-b11) for context '/tracker-web'|#]

[#|2011-05-02T09:23:42.424+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=130;_ThreadName=Thread-1;|WEB0671: Loading application tracker-ear#tracker-web.war at [tracker-web]|#]

[#|2011-05-02T09:23:42.429+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=185;_ThreadName=Thread-1;|CORE10010: Loading application tracker-ear done in 0 ms|#]

[#|2011-05-02T09:23:42.535+0200|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=40;_ThreadName=Thread-1;|Exception in prepareAlert():null|#]

[#|2011-05-02T09:23:42.540+0200|WARNING|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=40;_ThreadName=Thread-1;|java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
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:215)
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.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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.reflect.InvocationTargetException
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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.layout.LayoutViewHandler.getResourcePath(LayoutViewHandler.java:425)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:137)
at com.sun.jsftemplating.handlers.NavigationHandlers.navigate(NavigationHandlers.java:162)
at org.glassfish.admingui.common.handlers.CommonHandlers.navigate(CommonHandlers.java:577)
... 49 more

#]

[#|2011-05-02T09:23:42.547+0200|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=130;_ThreadName=Thread-1;|javax.faces.FacesException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
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:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
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:215)
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.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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
... 33 more
Caused by: java.lang.reflect.InvocationTargetException
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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.layout.LayoutViewHandler.getResourcePath(LayoutViewHandler.java:425)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:137)
at com.sun.jsftemplating.handlers.NavigationHandlers.navigate(NavigationHandlers.java:162)
at org.glassfish.admingui.common.handlers.CommonHandlers.navigate(CommonHandlers.java:577)
... 49 more

#]
Comment by Anissa Lam [ 02/May/11 ]

Looking at Step #3 and Step #4

>> 3) Update Applications > tracker-ear > Virtual Servers and select tracker. This fails and tracker isn't selected. Furthermore, tracker-ear is now disabled.
>> 4) Edit domain.xml and force tracker-ear to use tracker virtual server.

You are hitting GLASSFISH-16048.
You need to use CLI to set the virtual server, and if you do a SAVE on that screen, ensure that the enabled checkbox is checked.

Comment by Shing Wai Chan [ 02/May/11 ]

Can you try 3.1.1 promoted build to see whether the jsftemplating exception is resolved?

Comment by Shing Wai Chan [ 02/May/11 ]

One more remark, both virtual servers `tracker' and `server' has http-listener-1. We should not do this.

Comment by bjornstenfeldt [ 03/May/11 ]

Thanks, I'll see if we can find time to do a 3.1.1 deployment, but we really need to get moving with our projects. I think this work-around can get us by until next GF is release.

Comment by Shing Wai Chan [ 03/May/11 ]

Duplicate of http://java.net/jira/browse/GLASSFISH-16048





[GLASSFISH-16335] Windows is still the Red-Haired StepChild of GlassFish Created: 11/Apr/11  Updated: 06/Jun/11  Resolved: 06/Jun/11

Status: Closed
Project: glassfish
Component/s: build_system
Affects Version/s: None
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Critical
Reporter: Byron Nevins Assignee: janey
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-16331 stop/start/restart domain local comma... Resolved

 Description   

Right now GlassFish 3.2 on Windows is fairly hosed because of 16331.

What happens is that you can not successfully stop or restart a server using asadmin. Probably a bunch of other commands would fail as well – I didn't try.

So right now restart-domain and restart-local-instance WILL NOT WORK at all.

Quick Look tests will not pass on Windows now. The tests are doing exactly what they are supposed to do – loudly screaming a warning that something broke. But we would never know this because we have no Hudson build on Windows that also runs the QL tests on Windows (I think).

Luckily I run on Windows and I noticed the problem 2 days after it occurred.

My Recommendation: Have the Windows trunk build also run the QL tests as part of every build.



 Comments   
Comment by Byron Nevins [ 11/Apr/11 ]

It "blocks" because there is no "official" way to check if Windows-only bugs are fixed – like we do with the regular hudson jobs for regular bug fixes.

Comment by scatari [ 02/Jun/11 ]

The related bug http://java.net/jira/browse/GLASSFISH-16335 is resolved.

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.





[GLASSFISH-16331] stop/start/restart domain local commands are yet not perfect Created: 10/Apr/11  Updated: 02/Dec/11  Resolved: 11/Apr/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 3.1.1_b01, 4.0

Type: Bug Priority: Critical
Reporter: Byron Nevins Assignee: Bill Shannon
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-16335 Windows is still the Red-Haired StepC... Closed

 Description   

On (my) Windows QuickLook fails 100% of the time with one failure [1].

Here is what is happening:

(0) There is an empty (zero-byte) local-password file in the domain's config directory and the domain is definitely running.
(1) restart-domain is a subclass of StopDomain. StopDomain.executeCommand() sees that there is no valid local-password
(2) by DEFINITION, (1) means that the domain is NOT running.
(3) So now asadmin thinks that there is no DAS running – so it tries the improvement that was added --> start the domain
(4) (3) is done inside RestartDomain's dasNotRunning() method. It calls start-domain
(5) start-domain detects that its admin port is in use – and fails because of that.

Result – impossible to restart the running DAS without a forcible OS-level kill. It can not be restarted locally. It can not be stopped locally the normal way.

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

Question: What happened to the local-password file? Unknown. I didn't look into that. QL tests are hostile to debugging – it takes forever.

==============================
But this is a good bug that QL uncovered. This behavior is bad. It is fragile (brittle?). stopdomain shouldn't merely look for the magic file. It ought to also check and see if the admin port is in use. If so – it can call the _localdirectories(sp?) command on that port and see if it REALLY is the domain. Then emit a severe/warning message about the weird empty local password file.

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

Another EASY way to reproduce this bug –
1) start a domain
2) edit the local-password file. Make it empty and save it
3) restart-domain

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

Also –
restart-domain --kill is NOT working:

D:\glassfish3\glassfish\domains\domain1\config>asadmin restart-domain --kill
Server is not running, will attempt to start it...
There is a process already using the admin port 4848 – it probably is another instance of a GlassFish server.

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

[1]
test.admincli.RestartDomainTests:restartDomainTest

Restart domain failed. expected:<true> but was:<false>
org.testng.Assert.fail(Assert.java:84)
at org.testng.Assert.failNotEquals(Assert.java:438)
at org.testng.Assert.assertEquals(Assert.java:108)
at org.testng.Assert.assertEquals(Assert.java:239)
at test.admincli.RestartDomainTests.parseTestResults(RestartDomainTests.java:90)
at test.admincli.RestartDomainTests.restartDomainTest(RestartDomainTests.java:62)
23 lines not shown



 Comments   
Comment by Byron Nevins [ 10/Apr/11 ]

Wait a minute. Not so fast. I just ran

stop-domain --kill
start-domain

And there is a zero-byte local-password file! Maybe this was caused by Tim's recent changes?

Comment by Tim Quinn [ 10/Apr/11 ]

I am continuing this discussion in e-mail with Byron. Someone will post the net result here.

Comment by Byron Nevins [ 10/Apr/11 ]

LocalPasswordImpl runs before the logging service starts.
LocalPasswordImpl makes logging calls. These messages disappear into thin air.

This is what happens on my computer (Windows 7)

if (!(
localPasswordFile.setWritable(false, false) && // take from all
localPasswordFile.setWritable(true, true) && // owner only
localPasswordFile.setReadable(false, false) && // take from all
localPasswordFile.setReadable(true, true)
))

{ // owner only logger.log(Level.WARNING, "localpassword.cantchmod", localPasswordFile.toString()); // if we can't protect it, don't write it return; }

The if fires - a log message is written to thin air and it returns without writing the file.
The file will never fix itself – this will continue to fail forever - until the user deletes it, I suppose.

Catastrophic! I recommend deleting it in ALL cases – if possible. Then log to EarlyLogger with a *severe* message.

Even more curious is that the code above the chunk I pasted calls delete() on the file and true is returned but the file was NOT deleted.

Comment by Byron Nevins [ 10/Apr/11 ]

46057 is the culprit.

The security checks always fail on Windows.

Raising the priority for now. It is catastrophic for asadmin on windows

Comment by Bill Shannon [ 11/Apr/11 ]

Went back to ignoring the return values from these filesystem operations.
Fixed in trunk and 3.1.1 branch.





[GLASSFISH-16330] sqlserver datasource class does not mention the ones documented on MS's homepage Created: 08/Apr/11  Updated: 10/Apr/11  Resolved: 10/Apr/11

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Minor
Reporter: Dies Koper Assignee: Shalini
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I think we could be using an old driver class name for SQLServer.

GlassFish has the following entry (in cpds.properties):

MICROSOFTSQLSERVER=com.microsoft.sqlserver.jdbc.ConnectionPoolSQLServerDataSource

According to the following article from Microsoft (on SQLServer 2008 R2) it's another class:

http://msdn.microsoft.com/en-us/library/ms378484.aspx

com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource
or
com.microsoft.sqlserver.jdbc.SQLServerXADataSource



 Comments   
Comment by Shalini [ 10/Apr/11 ]

Fixing this issue.

Sending jdbc/templates/src/main/resources/glassfish/lib/install/databases/dbvendormapping/cpds.properties
Transmitting file data .
Committed revision 46074.





[GLASSFISH-16327] com.sun.aas.instanceName in log configuration not used initially Created: 07/Apr/11  Updated: 17/Apr/11  Resolved: 17/Apr/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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

Glassfish 3.1, Tested on Windows XP, Redhat 5.6



 Description   

I'm using Glassfish 3.1 and was attempting to set the log file to a common location for my server instances by using the "/logs/$

{com.sun.aas.instanceName}/${com.sun.aas.instanceName}

.log" set on the logging configuration page or "com.sun.enterprise.server.logging.GFFileHandler.file" setting with asadmin for the server-config

This results in the first set of log statements are being written to a file literally called "/logs/$

{com.sun.aas.instanceName}/${com.sun.aas.instanceName}

.log". After the start-up args are logged the logs start flowing to "/logs/server/server.log" as expected.



 Comments   
Comment by naman_mehta [ 17/Apr/11 ]

Made required changes and closed the same.

Comment by naman_mehta [ 17/Apr/11 ]

Re-Open to changed fixed version...





[GLASSFISH-16306] appclient throws NPE when passwordfile is not proper Created: 02/Apr/11  Updated: 03/Apr/11  Resolved: 03/Apr/11

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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

WinXP



 Description   

I noticed this when I accidentally picked another file than my password file:
If you specify a file that does not contain property "PASSWORD" you get a NPE, instead of a friendly warning or error message:

D:\GFv3.1\glassfish-3.1\glassfish3\glassfish>bin\appclient -passwordfile ..\..\..\..\TestDBModAsCase.java
java.lang.NullPointerException
at org.glassfish.appclient.client.acc.AppclientCommandArguments.loadPasswordFromFile(AppclientCommandArguments.java:343)
at org.glassfish.appclient.client.acc.AppclientCommandArguments.processPasswordFile(AppclientCommandArguments.java:325)
at org.glassfish.appclient.client.acc.AppclientCommandArguments.processAppclientArgs(AppclientCommandArguments.java:295)

The responsible code is like this:

Properties props = new Properties();
props.load(inputStream);
return props.getProperty("PASSWORD").toCharArray();

It needs a null check before toChaArray() is called.



 Comments   
Comment by Dies Koper [ 02/Apr/11 ]

I just noticed that although this option is included in the syntax in the GFv3.1 Reference Manual (found at the url below), there is no description on it at all.

http://download.oracle.com/docs/cd/E18930_01/html/821-2433/appclient-1m.html

In particular, it doesn't explain the format of the file, and the property name to use.
That makes the option unusable for people who don't look it up in the GF code.
Updating the priority accordingly.

Comment by Tim Quinn [ 03/Apr/11 ]

The doc omission should be reported in a separate issue. I've opened Issue 16309 to record it.

Comment by Tim Quinn [ 03/Apr/11 ]

Fix checked in.

Repository: svn
Revision: 45876
Author: tjquinn
Date: 2011-04-03 20:45:50 UTC
Link:

Log Message:
------------
Fix for 16306

The appclient command accepts the -passwordfile option which should point to to a file containing a line such as

PASSWORD=client-password

If the file exists but contains no such line the ACC would fail with a NPE.

With these changes the ACC displays a clearer UserError instead.

Tests: deployment devtests, added JUnit tests

Revisions:
----------
45876

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/test/java/org/glassfish/appclient/client/acc/AppclientCommandArgumentsTest.java
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/acc/AppclientCommandArguments.java
trunk/v3/appclient/client/acc/src/main/resources/org/glassfish/appclient/client/acc/LocalStrings.properties





[GLASSFISH-16301] jsessionID drop after form-submit & redirect cycle Created: 01/Apr/11  Updated: 13/Apr/11  Resolved: 12/Apr/11

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: V3, v3.0.1, 3.1
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Critical
Reporter: KBachl Assignee: Shing Wai Chan
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All 3.0.0; 3.0.1; 3.1;



 Description   

This problem takes place when using wicket; It's depending on glassfish 3.0/ 3.0.1/ 3.1 as JBOSS 6; TOMCAT 6; 7; JETTY; are all not showing this behaviour;

My idea is that an access to root path of a webapp is not considered necessary of jsessionId en/decoding;

To reproduce just get a Wicket-App like the BrixDemo (https://github.com/brix-cms/brix-cms) and run it, then do following steps:

-> Page with Tile holding stateful Form (stateless is also not working but less dramatic): accessing it via disables cookies
-> url e.g.: /brixdemo/demos/stockquote.html;jsessionid=1F89CE840F7281BA2A92F2272CD74A60 then send form
-> url: /brixdemo/;jsessionid=1F89CE840F7281BA2A92F2272CD74A60?wicket:interface=:2:brix-tile-8:form::IFormSubmitListener::

then one is immeadiatly redirected to the mapped path at "/" with a clean, new session! - in case the session would still be existing, then the request would be handled differend;

This can be reproduced by starting brix-demo on Glassfish 3 and 3.1 and going to the Stockquote forms with cookies disabled;

I originally thought this was a BrixCMS bug, but it turned out that only glassfish is affected, therefore this bug report;



 Comments   
Comment by Shing Wai Chan [ 08/Apr/11 ]

Can you provide a unit test for the scenario?

Comment by KBachl [ 10/Apr/11 ]

Hello Shing Wai,

apologise for my late answer. At the moment I can't provde a unit-test, however, the reproduction is quite simple as stated above. Just get the project above and do a mvn clean install, afterwards drop in the brix-demo.war (or alternatively use this one: http://code.google.com/p/brix-cms/downloads/detail?name=brix-demo-1.1.0.war ) into GF 3 and follow the steps above and you see the loss of session.

go to $

{applicationPath}

/demos/stockquote with a browser that has disabled cookies, then send the form at the bottom (it has stateful written over it) and you see that you end having a brand new jsession; compare this to a deploy at e.g: jetty or tomcat where you won't loose the session;

I hope this helps, if you have any questions left please do not hesitate to contact me,

Best,

KBachl

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

I don't see the issue in trunk.
This looks like the issue specified in
http://java.net/jira/browse/GLASSFISH-13129

You may like to download 3.1.1 build or 3.2 build from trunk.

Comment by KBachl [ 13/Apr/11 ]

Hello Shing Wai,

I can confirm that the issue is fixed in 3.1.1-continous build from today; Seems it was the Issue you mentioned; Any ETA on 3.1.1 final release?

Thank you and Best Regards





[GLASSFISH-16300] Resync not working for library files for specific cluster instance Created: 01/Apr/11  Updated: 05/May/11  Resolved: 04/Apr/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

Linux/debian


Issue Links:
Duplicate
is duplicated by GLASSFISH-16559 Manual per-node intervention required... Resolved

 Description   

I'm establishing two clusters on two nodes with 2 instances each. One cluster is for production use, the other is for deployment of new release versions so I can change software versions without loss of availability. I don't need session persistence so session replication to the new cluster is not necessary. Environment: Linux/GF 3.1 b43

However, I've got a problem with synchronization between the DAS and the instances. Because the two clusters are running in the same domain, I use different configurations, one for each cluster. Now, the High Availability Administration Guide (HAAG) tells me, to put all cluster specific libraries in <domain-dir>/config/<config-name>/lib directory. Again, the HAAG tells me to trigger a resync on instance restart by 'touch'-ing a top-level file in the directory mentioned above. After restarting the instance(s) the timestamp on the library directory in the config/<config-name> directory changed, but the contents of the directory is not synced.

After trying for half a day I did an export-sync-bundle call and looked into the generated sync-zip-file. What I saw was, that the library directory appears in the file, but - again - the contents of the directory does not appear in the zip-file. I've already double checked the locations and existence of the file in the DAS. It's all there.

According to tmueller: In the ServerSynchronizer.synchronizeConfigSpecificDir method, the call to getFileName passes in SyncLevel.DIRECTORY rather than SyncLevel.RECURSIVE, which means that only the files at the top level of the config specific directory are synchronized rather than all files under the directory.

See: http://www.java.net/forum/topic/glassfish/glassfish/resync-not-working-library-files-specific-cluster-instance



 Comments   
Comment by Tom Mueller [ 01/Apr/11 ]

Bill, here is the bug that we were discussing over email.

Comment by Bill Shannon [ 04/Apr/11 ]

Yes, it needed to tell the Payload to replace the entire directory contents
if the config-specific lib directory (for instance) changed.

Comment by Tim Quinn [ 11/Apr/11 ]

I've just checked in partial changes for this to the 3.1.1 branch.

Project: glassfish
Repository: svn
Revision: 46086
Author: tjquinn
Date: 2011-04-11 20:48:59 UTC
Link:

Log Message:
------------
Partial fix for 16300 (already checked into trunk)

Payload handling when a directory file is attached to the payload was not correct. Also fixed an unrelated logging error.

Approval: Jane
Tests: QL

Revisions:
----------
46086

Modified Paths:
---------------
branches/3.1.1/common/common-util/src/main/java/org/glassfish/admin/payload/LocalStrings.properties
branches/3.1.1/common/common-util/src/main/java/org/glassfish/admin/payload/PayloadFilesManager.java
branches/3.1.1/admin/cli/src/main/java/com/sun/enterprise/admin/cli/AsadminMain.java
branches/3.1.1/common/common-util/src/main/java/org/glassfish/admin/payload/PayloadImpl.java

Added Paths:
------------
branches/3.1.1/common/common-util/src/test/java/org/glassfish/admin/payload/PayloadImplTest.java





[GLASSFISH-16298] ServletContext.addFilter should throw IllegalStateException if it is invoked after context initialization Created: 31/Mar/11  Updated: 07/Apr/11  Resolved: 01/Apr/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 3.1.1_b01

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


 Description   

ServletContext.addFilter should throw IllegalStateException if it is invoked after context initialization.
The same need to be fixed for addServlet, setInitParameter and declareRoles.



 Comments   
Comment by Shing Wai Chan [ 01/Apr/11 ]

Sending web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Transmitting file data .
Committed revision 45836.





[GLASSFISH-16286] IllegalArgumentException: port out of range:-1 after config upgrades unit test Created: 30/Mar/11  Updated: 02/Dec/11  Resolved: 30/Mar/11

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 4.0
Fix Version/s: 3.1.1_b01

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


 Description   

[java] [#|2011-03-30T09:39:34.635-0700|SEVERE|glassfish3.2|com.sun.pkg.client.SystemInfo|_ThreadID=10;_ThreadName=main;|badproxy|#]
[java]
[java] [#|2011-03-30T09:39:34.639-0700|SEVERE|glassfish3.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=10;_ThreadName=main;|java.lang.IllegalArgumentException: port out of range:-1
[java] at java.net.InetSocketAddress.<init>(InetSocketAddress.java:118)
[java] at com.sun.pkg.client.AuthProxy.newProxy(AuthProxy.java:105)
[java] at com.sun.pkg.client.SystemInfo.loadProxyInfo(SystemInfo.java:201)
[java] at com.sun.pkg.client.SystemInfo.getProxySelector(SystemInfo.java:168)
[java] at com.sun.pkg.client.Image.<init>(Image.java:965)
[java] at com.sun.pkg.client.Image.<init>(Image.java:983)
[java] at com.sun.enterprise.registration.glassfish.RegistrationUtil.getUpdateCenterImage(RegistrationUtil.java:180)
[java] at com.sun.enterprise.registration.glassfish.RegistrationUtil.setUpdateCenterUUID(RegistrationUtil.java:187)
[java] at com.sun.enterprise.registration.glassfish.RegistrationUtil.synchUUID(RegistrationUtil.java:174)
[java] at com.sun.enterprise.registration.glassfish.PingService.postConstruct(PingService.java:92)
[java] at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
[java] at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
[java] at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
[java] at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
[java] at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
[java] at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
[java] at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:326)
[java] at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
[java] at com.sun.enterprise.v3.server.UpgradeStartup.start(UpgradeStartup.java:170)
[java] at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
[java] at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:597)
[java] at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
[java] at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
[java] |#]
[java]
[java] [#|2011-03-30T09:39:34.686-0700|INFO|glassfish3.2|null|_ThreadID=10;_ThreadName=main;|Exiting after upgrade|#]



 Comments   
Comment by Justin Lee [ 30/Mar/11 ]

these tests weren't exactly correct and are handled elsewhere so I just removed them.





[GLASSFISH-16276] get-health reports incorrect status using jdk7 b136 after cluster is stopped Created: 28/Mar/11  Updated: 14/Mar/12  Resolved: 16/Apr/11

Status: Resolved
Project: glassfish
Component/s: group_management_service
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01, 4.0_b37

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

10-machine cluster setup on linux 64bit



 Description   

used jdk7_b136 on b43 and get-health reported incorrect status after a successful cluster shutdown.
However, after stopping the cluster I get:
n1c1m1 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m2 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m3 stopped since Mon Mar 28 02:32:16 UTC 2011
n1c1m4 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m5 failed since Mon Mar 28 02:32:26 UTC 2011
n1c1m6 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m7 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m8 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m9 failed since Mon Mar 28 02:32:24 UTC 2011
Command get-health executed successfully.

http://aras2.us.oracle.com:8080/logs/gf31/gms//set_03_27_11_t_19_33_25/scenario_installonecluster_Sun_Mar_27_19_33_48_PDT_2011.html



 Comments   
Comment by Joe Fialli [ 28/Mar/11 ]

The instances are being stopped by stop-cluster. All instances are stopped in their server.log

>[#|2011-03-28T02:32:16.172+0000|INFO|glassfish3.1|ShoalLogger|_ThreadID=18;_ThreadName=Thread-1;|
> GMS1015: Received Group Shutting down message from member: server of group: clusterz1|#]
>
>[#|2011-03-28T02:32:16.315+0000|INFO|glassfish3.1|
>javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=115;_ThreadName=Thread-1;|
>Server shutdown initiated|#]
>
>[#|2011-03-28T02:32:16.322+0000|INFO|glassfish3.1|ShoalLogger|_ThreadID=115;_ThreadName=Thread-1;|
>GMS1096: member: n1c1m1 is leaving group: clusterz1|#]

The UDP notification message from the stopped instance to the DAS is being lost for 8 out of the 9
instances. The planned shutdown notification for n1c1m3 is received in DAS.

Could the test be rerun with following log-level set to FINEST to help track what is going wrong.

% asadmin set-log-level --target clusterz1 ShoalLogger=FINEST // enable FINEST ShoalLogger in clustered instances
% asadmin set-log-level ShoalLogger=FINEST // enable ShoalLogger in DAS server.log

Comment by Joe Fialli [ 30/Mar/11 ]

recreated failure and verified fix.

fix integrated into glassfish 3 trunk. should be in next build.

Comment by Joe Fialli [ 16/Apr/11 ]

fix integrated into 3.1.1 branch.





[GLASSFISH-16265] 'invalid option : id" is given when specifying "name" in the payload to deploy an app Created: 24/Mar/11  Updated: 07/Apr/11  Resolved: 25/Mar/11

Status: Resolved
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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

Attachments: File test.jsf    
Tags: 3_1-next

 Description   

If i include "name" in the payload when trying to post to the endpoint : "http://localhost:4848/management/domain/applications/application", I always get an error.

The responseMap gives:
"data =>

{message= Invalid option: id, exit_code=FAILURE}

"

Here is the info:

endpoint = "http://localhost:4848/management/domain/applications/application"

payloads =

{availabilityEnabled=false, id=/Users/anilam/DeployApp/hello.war, enabled=true, precompilejsp=false, contextroot=hello, verify=false, name=myHello}

Takes me a long time to realize that its the 'name' option that causes the problem



 Comments   
Comment by Jason Lee [ 25/Mar/11 ]

I can't reproduce this error. Here's my test:

curl -X POST -F availabilityEnabled=false -F id=@path/to/my.war -F enabled=true -F precompilejsp=false -F contextroot=hello -F verify=false -F name=myHello -F force=true http://localhost:4848/management/domain/applications/application

which returns a success message. Can you enable REST logging (asadmin _set-rest-admin-config --loginput=true --logoutput=true) and retry your deploy?

Comment by Anissa Lam [ 25/Mar/11 ]

I have attached test.jsf, just put this under __admingui/ and try that out.

If you uncomment the line
//mapPut(map="#

{requestScope.attrsMap}

" key="name" value="myHello");

you will see the error.
of course, make sure 'id' is pointing to your copy of hello.war

Comment by Jason Lee [ 25/Mar/11 ]

I think you're using the endpoint incorrectly. The value of ID should be the contents of a file, not the path to it. That it works without the 'name' parameter is a quirk of the underlying CLI.

For an example, see admin/rest/src/test/java/org/glassfish/admin/rest/ApplicationTest.java

Comment by Anissa Lam [ 25/Mar/11 ]

The file is on DAS machine, no upload is needed. Just like the deploy command, i should be able to just specify a local path to the war and get that deployed. Why do i need to provide the content of the file if the war is local ?
If 'id' is only for 'content of file', then maybe you need to provide a way to specify the local path to the war.

The deploy command has an option to specify uplaod, [--upload[=<upload(default:false)>]] , i can specify that to false in the payload if needed, but 'upload' is not recognized by REST now.

This 'invalid Id' error depends on whether some other option is specified is very misleading and confusing.

I talked to Ludo, he believes this is a REST bug, one should be able to specify a local path for deployment.

Comment by Jason Lee [ 25/Mar/11 ]

Found the problem. There was a bug in the parameter handling causing the wrong thing to be passed to the CLI.

Fix committed (r45746)





[GLASSFISH-16262] deleting instance leaves lifecycle module around that cannot be deleted Created: 24/Mar/11  Updated: 07/Apr/11  Resolved: 25/Mar/11

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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


 Description   

Consider the following sequence of commands:

asadmin start-domain
asadmin create-local-instance i1
asadmin create-lifecycle-module --target i1 --classname foo.Bar --failurefatal=true abc
asadmin delete-local-instance i1

asadmin create-lifecycle-module --classname foo.Bar --failurefatal=true abc
remote failure: Lifecycle module with name [abc] already exists
Command create-lifecycle-module failed.

asadmin delete-lifecycle-module abc
remote failure: Lifecycle module abc is not deployed on this target [server]
Command delete-lifecycle-module failed.

When the instance was deleted, the reference to the "abc" lifecycle module was deleted, but the <application> element for that lifecycle module is still in the domain.xml. This is why the attempt to create it on the DAS fails. The delete fails because it isn't deployed on the DAS, but the problem at this point is that it isn't deployed anywhere because the instance has been deleted.

So we are left in the state where we have this "abc" lifecycle module hanging around in the domain.xml, but we can't get rid of it.

To workaround this problem, one can do this:

asadmin create-application-ref abc
asadmin delete-lifecycle-module abc

Not exactly an obvious workaround, especially since list-applications doesn't list lifecycle modules.

Either the system should make sure that when the last instance that references a lifecycle module is deleted, then the lifecycle module is deleted too automatically, or, the delete-lifecycle-module command should allow for deleting a lifecycle module that isn't referenced by any target.



 Comments   
Comment by Hong Zhang [ 24/Mar/11 ]

Tom, this seems pretty similar to issue http://java.net/jira/browse/GLASSFISH-13979 where a regular application was left deployed in the domain after the instance was deleted and a subsequent deployment was attempted.

I fixed that issue to have similar behavior as v2, where the failure message will tell user that the application was already deployed to domain and a create-application-ref command should be used to deploy to subsequent targets. This is consistent with how we handled the scenario where the application was deployed to a target ABC, and then need to be deployed to subsequent target XYZ (you cannot use deploy command here and have to use create-application-ref), only the target ABC here is the special target "domain".

I plan to fix this issue the similar way. The error message for regular application is like this:
Application foo is already deployed in this domain. Please use create-application-ref command to create application reference on target XYZ.

The error message I plan to have for lifecycle module case will be something like this:
Lifecycle module foo is already created in this domain. Please use create-application-ref command to create application reference on target XYZ.

BTW: The list-lifecycle-modules command takes special target "domain" which shows all the created lifecycle modules in this domain. So the module should be in the list when you do "asadmin list-lifecycle-modules domain"
after the instance is deleted.

Comment by Tom Mueller [ 24/Mar/11 ]

Should there be a "create-lifecycle-module-ref" command? Is it commonly understand that a lifecycle module is actually an application?

Thank you for the tip about using "domain" as the target for list-lifecycle-modules.

It turns out that this also works for delete-lifecycle-module, i.e., if there is an unreferenced lifecycle-module, it can be deleted with:

asadmin delete-lifecycle-module --target domain abc

So the bug as reported doesn't actually exist.

Comment by Hong Zhang [ 24/Mar/11 ]

It's probably more consistent to have a create-lifecycle-module-ref command as we have a separate create-lifecycle-module command, but as this is the syntax since 8.* and lifecycle module is kind of deprecating, I am relucant to add a new command for this now.

Right, the domain is a supported target for delete-lifecycle-module as well so we can delete the lifecycle module in this case. I will still enhance the error message for the create-lifecycle-module so user has some clue what they need to do to have this module created on the specified target.

Comment by Hong Zhang [ 25/Mar/11 ]

enhanced the error message in this case to give user more clue how to proceed





[GLASSFISH-16261] PreDestroy method in app client is not invoked Created: 24/Mar/11  Updated: 07/Apr/11  Resolved: 24/Mar/11

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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


 Description   

Neither annotating a method with @PreDestroy or identifying it in application-client.xml causes the method to execute. At least this is true with a command-line, non-GUI app client.

A PostConstruct is invoked correctly, using either approach.



 Comments   
Comment by Tim Quinn [ 24/Mar/11 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 45720
Author: tjquinn
Date: 2011-03-24 23:41:24 UTC
Link:

Log Message:
------------
Fix for 16261

The @PreDestroy method on an app client class (whether specified using annotations or in the descriptor) was not called.

The clean-up logic in the ACC was correctly written to invoke this but the injection manager in the clean-up objects was never set to the injection manager for the main class, so the clean-up logic could not invoke the pre-destroy method in the app client.

These changes store the injection manager with the clean-up information so the clean-up logic can invoke the method.

Tests: QL, deployment dev tests

Revisions:
----------
45720

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/acc/AppClientContainer.java





[GLASSFISH-16260] npe in REST init when a cli used in the rest metadata is not present in the runtime Created: 24/Mar/11  Updated: 07/Apr/11  Resolved: 24/Mar/11

Status: Resolved
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-next

 Description   

we have a npe in REST init when a cli used in the rest metadata is not present in the runtime.
REST should continue working and not expose the resource for this missing cli. (maybe adding a warning in the log)






[GLASSFISH-16251] Include the deployment exception when using REST to deploy Created: 23/Mar/11  Updated: 07/Apr/11  Resolved: 23/Mar/11

Status: Resolved
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

Type: New Feature Priority: Major
Reporter: lightguard Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: File org.jboss.seam.solder.test.serviceHandler.ServiceHandlerTest_test.war    
Tags: 3_1-next

 Description   

When you deploy via the rest interface the exception causing the deployment to fail is not in the payload. This makes it very difficult to report problems if they occur.

To recreate:

clone Seam Solder at https://github.com/seam/solder
cd impl
mvn integration-test -Dincontainer-glassfish-rest -Dtest=ServiceHandlerTest

Or use the attached war via curl:

curl -s -S -H 'Accept: application/xml' -X POST -F id=@org.jboss.seam.solder.test.serviceHandler.ServiceHandlerTest_test.war -F force=true http://localhost:4848/management/domain/applications/application



 Comments   
Comment by Jason Lee [ 23/Mar/11 ]

Fix committed (r45695). We were missing a 'return' keyword, which caused execution to go passed where it should, resulting in an incorrect error message and code being returned to the user.





[GLASSFISH-16232] If an instance was stopped, restart-instance doesn't start it. Created: 17/Mar/11  Updated: 06/Jun/11  Resolved: 19/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-next

 Description   

Latest continuous build.

Executed the follow commands:
Started domain1, created a local instance using localhost-domain1 node, started an instance, then stopped the instance. Then executed
==============================================================
asadmin restart-instance in1
remote failure: Error trying to restart the instance named in1 : Remote server does not listen for requests on [localhost:24848]. Is the server up?
Command restart-instance failed.
------------------------------------------------------------------------------
asadmin restart-local-instance --nodedir=$S1AS_HOME/nodes --node localhost-domain1 --debug=true --force=true --kill=true in1
Server is not running, will attempt to start it...
CLI801 Instance is already synchronized
Waiting for in1 to start ................
Successfully started the instance: in1
instance Location: /opt/glassfish3/glassfish/nodes/localhost-domain1/in1
Log File: /opt/glassfish3/glassfish/nodes/localhost-domain1/in1/logs/server.log
Admin Port: 24848
Command restart-local-instance executed successfully.
=====================================================

Then stopped an instance and domain and executed:
=======================================================================
asadmin restart-domain --debug=true --domaindir=$S1AS_HOME/domains --force=true --kill=true domain1
Server is not running, will attempt to start it...
Waiting for domain1 to start .......
Successfully started the domain : domain1
================================================================

Then I've created ssh node and created an instance for that node using create-instance, then run start-instance, stop-instance

After that executed restart-instance against that instance:

asadmin restart-instance in2
remote failure: Error trying to restart the instance named in2 : Remote server does not listen for requests on [localhost:24849]. Is the server up?
Command restart-instance failed.
jed-asqe-7#/opt/appserver-sqe/ee/adm_cli] asadmin list-instances
in1 running
in2 not running
Command list-instances executed successfully.
asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
in1 localhost 24848 2813 — running
in2 localhost 24849 -1 — not running
Command list-instances executed successfully.
asadmin list-nodes --long
NODE NAME TYPE NODE HOST INSTALL DIRECTORY REFERENCED BY
localhost-domain1 CONFIG localhost /opt/glassfish3 in1
node2 SSH localhost /opt/glassfish3 in2
Command list-nodes executed successfully.

I.e. if instance/domain were stopped, restart-local-instance and restart-domain start the correspondent server, but restart-instance - not. First this is an inconsistent behavior, I believe all restart commands have the same behavior.

Second, I think that restart-instance have to have the same behavior , as start-instance if it would be executed against an instance that was stopped.



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

restart-instance should be like restart-domain and restart-local-instance in that if the instance isn't up, it should at least try to start it.

Comment by Tom Mueller [ 18/Mar/11 ]

Carla, Byron requested that you take a look at this.

Comment by Byron Nevins [ 18/Mar/11 ]

I think this should not be "fixed".

I think it was a BIG mistake when restart-server commands were changed to start the server if they are not running.

It is illogical. It is over-engineering. I said RESTART – not START!

This opens a HUGE can of expensive worms and it is already guaranteed to be IMPOSSIBLE to implement correctly in all cases. A very common case is that the instance is not running on a remote machine and there is no SSH connection. That means it is impossible to start it.

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

If you decide to go ahead anyways this should go to Joe to do this:
--> if the instance is NOT running AND the instance is on a remote machine AND SSH is setup –
then call start-local-instance for it via SSH
Otherwise if the instance is co-located with DAS – call start-instance
====================================================
The Final case is when the instance lives on a different machine and there is no SSH in case we need to emit a new complicated message explaining it
====================================================
When that's all done Doc needs to be updated to explain this complicated behavior

Comment by Tom Mueller [ 18/Mar/11 ]

As Elena pointed out in the issuee, all of the restart-* command should behave the same. restart-domain and restart-local-instance already do a start if the server isn't running. Restart-instance should at least try to do the start if it can.

Comment by Byron Nevins [ 18/Mar/11 ]

Assigned to Tom to think it over.
Maybe we should discuss at next Admin iTeam?

Comment by Byron Nevins [ 19/Mar/11 ]

D:\gf\v3\cluster>svn commit
Sending cluster\admin\src\main\java\com\sun\enterprise\v3\admin\cluster\LocalStrings.properties
Sending cluster\admin\src\main\java\com\sun\enterprise\v3\admin\cluster\RestartInstanceCommand.java
Sending cluster\admin\src\main\java\com\sun\enterprise\v3\admin\cluster\StartInstanceCommand.java
Transmitting file data ...
Committed revision 45632.

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

Now restart-instance calls start-instance (with default args) if the instance isn't already running.

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.





[GLASSFISH-16223] admin_gui gets undeployed after my application redeploy Created: 16/Mar/11  Updated: 15/Jun/11  Resolved: 11/Apr/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01, 4.0_b01

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

Attachments: Text File fullstacktrace.txt     PNG File Екран.png    

 Description   

After i redeploy my app on server - admin gui shows this error and gets undeployed. Application is redeployed fine but after this i can't access admin_gui anymore: instead of it Server is running page showed.

See text error below and in attachment

HTTP Status 500 -

type Exception report

message

descriptionThe server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory

root cause

java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory

note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 3.1 logs.
GlassFish Server Open Source Edition 3.1



 Comments   
Comment by mariohmol [ 26/Mar/11 ]

Same here! Every time i redeploy i have to restart the glassfish.

Version: GlassFish Server Open Source Edition 3.1 (build 43).

Full stack trace attached here!

Regards,

Comment by Anissa Lam [ 29/Mar/11 ]

I don't know if you redeploy your app using CLI or GUI, but i assume both results the same.
If you undeploy instead of redeploy, you are seeing the same thing also ?

mariohomol/illia , please provide a test app that i can use to reproduce the problem. Not much i can do without a test app to reproduce the problem. Really appreciate your help here.

Comment by mariohmol [ 29/Mar/11 ]

HY, I'm using reeploy from GUI.

About the apps, rigth now i'm using 4 projects in early stages. All was created as a Enterprise Application on Netbeans (EAR-EJB-WAR), all using JEE6.

In this server i'm monitoring and at all times ther is 2.5gb free ram memory and processor dont get up to 50%.

Doing undeploy I get same error, i didnt have the chance to deploy again. So maybe the problem is related to undeploy.

Try to create a new EAR on Netbeans and using GF, if you do not get the error, say to me that i can try to get on of this projects, clean it and try to reproduce the error.

Regards,

Comment by Anissa Lam [ 29/Mar/11 ]

Can you try using CLI to undeploy ? Does this bring down the GUI as well ?
This will tell me if this is due to the fact that the deploy/undeploy of app is running in the same thread as the GUI, as reported in GLASSFISH-15905.
I am currently working on fixing GLASSFISH-15905.
Still requesting you to attach your app thats created from netbeans. thanks a lot.

Comment by mariohmol [ 29/Mar/11 ]

Hy,

could you please show me how to do it using CLI?

I made some tests here and you are ritgh, i simple EAR project on Netbeans works. I will see if it is possible to clean some classes on a project and send to you.

Regards,

Comment by Anissa Lam [ 29/Mar/11 ]

Hi, here is the instruction using CLI, assuming you did not deploy the app to other cluster or instances.

%cd <glassfish3>/glassfish/bin

%asadmin list-applications <== this should give you the list of applications you have deployed.

%asadmin undeploy hello <== assuming hello is on the list returned from above cmd.

You can then try go to the console, click on the applications node. IF everything works, the undeployed application should not list here. (of course, if GUI is working).

thanks for trying to get me the test app.

Comment by mariohmol [ 29/Mar/11 ]

Hy,

same error using CLI.

If you send me your email and promise to no publish the ear on web, i can send to help you on testing.

Regards,

Comment by Anissa Lam [ 31/Mar/11 ]

mariohmol, i have sent the private email to you 2 days ago. waiting for your reply.

Comment by Illia Romanenko [ 31/Mar/11 ]

Please contact me off the list i will send you war file with the same promise

Comment by mariohmol [ 03/Apr/11 ]

Hy guys,

with the nightly build works partially.
http://dlc.sun.com.edgesuite.net/glassfish/3.2/nightly/glassfish-3.2-b01-04_02_2011.zip

I have 2 applications in two differentes virtual servers. When I redeploy Application 2 it shows me a error about context of Application 1.

Exception while loading the app : java.lang.Exception: WEB0113: Virtual server [server] already has a web module [App1-war.war] loaded at [/]; therefore web module App2#App2-war.war cannot be loaded at this context path on this virtual server.

If I Undeploy and Afterwards Deploy, works.

So the Redploy still not working.

Regards,

Comment by Anissa Lam [ 07/Apr/11 ]

mariohmol,
what you described above about 2 app not working properly with re-deploy seems to be a different bug than what is reported here.
Please open up another bug, maybe filed against deployment.

What is reported here is about the console no longer works after undeploy or redeploy an existing app.
I can no longer reproduce that with 3.2 build 01

Please confirm that with 3.2 build 01, admin console works properly after you undeploy/redeploy your application.

Comment by Anissa Lam [ 07/Apr/11 ]

Illia, thanks for the app.
I have verified that with the changes from DF to using REST API, I no longer see the problem.

I have tried the following sequence using CLI: deploy, undeploy, deploy, deploy with --force=true, undeploy
and also with GUI:

  • deploy, undeploy, deploy with force checkbox, undeploy, deploy, redeploy, undeploy

Admin console works perfectly after each request.
And your application works fine too.

Please try that with b01 (you can download that from http://dlc.sun.com.edgesuite.net/glassfish/3.2/promoted/) and let me know if you see any issue.

Comment by mariohmol [ 10/Apr/11 ]

Hy,

you are right, the admin console still workign after redeploy, what does not work is the redeploy itself.

Anyway, to me is ok right now because i can undeploy and then deploy afterwards.

Good work!

Regards,

Comment by Anissa Lam [ 11/Apr/11 ]

I am marking this bug resolved.
The fix is checked in before the 3.1.1 branch created, so I the fix is in both 3.1.1 b01 and 3.2 b01/MS1.

mariohmol, if i understand it right, there is issue with your app if you 'redeploy' it, but 'undeploy' follow by 'deploy' again works fine. Maybe you should open up a bug against deployment.

Comment by Illia Romanenko [ 12/Apr/11 ]

Sorry for delay - i can confirm now that it works but still my app not being reinitialized after redeploy... But if i'm doing undeploy and then deploy - it works fine

Comment by Illia Romanenko [ 12/Apr/11 ]

Thanks Anissa

Comment by Anissa Lam [ 15/May/11 ]

The fix for GLASSFISH-15905 by using REST API instead of Deployment Facility API for application deployment also fixes this issue.
The fix is checked in before the 3.1.1 branch created, so I the fix is in since 3.1.1 b01 and 3.2 b01/MS1.

Comment by rdelaplante [ 26/May/11 ]

FYI the root cause of this bug may be related to a bug in JSF that was recently fixed: JAVASERVERFACES-1542

Comment by Illia Romanenko [ 26/May/11 ]

rdelaplante, not sure about this - because it works fine on prev versions of glassfish

Comment by rdelaplante [ 26/May/11 ]

We've been running on GlassFish since 2.0 and the bug in JAVASERVERFACES-1542 didn't affect us until we upgraded to GlassFish 3.1. I'm not sure why it just started happening, but that's why I thought it could be related to this ticket. When the problem happens to us, we get the same error except it complains about RenderKitFactory instead of ApplicationFactory. The ticket says all factories are affected.

Comment by rdelaplante [ 15/Jun/11 ]

Earlier I thought that JAVASERVERFACES-1542 was the cause of this bug. JSF 2.1.2 has since been released, and I tried replacing jsf-impl.jar in glassfish/modules to see if it solves this ticket's problem. It does not. I have not yet tried GlassFish 3.1.1.

Comment by Anissa Lam [ 15/Jun/11 ]

I am getting confused. Are you saying the issue comes back ?
Lets start from the beginning.

1. If you deploy your app, does Admin Console still work correctly ?

2. If you undeploy your app, does Admin Console still work correctly ?

3. If you do deploy then undeploy then deploy again, does Admin Console still work correctly ?

4. If you deploy, then do "deploy --force=true" , does Admin Console still work correctly ?

If the answer is No to any of the above, please attach a sample app, reopen the bug so I can look into this again.

You mentioned "I have not yet tried GlassFish 3.1.1.". Please try the above step using latest promoted build available on http://dlc.sun.com.edgesuite.net/glassfish/3.1.1/promoted/

Comment by rdelaplante [ 15/Jun/11 ]

I was only following up on my own hypothesis from May 26 in case anyone is interested. I suggested that the fix in this ticket may have been unnecessary because the root cause of the problem might be a bug in JSF which is now fixed. Knowing that your fix is in GlassFish 3.1.1 and not 3.1.0, I decided to test my hypothesis by replacing jsf-impl.jar in GlassFish 3.1.0 with a newer version that contains the fix I am talking about. That did not solve the problem, and therefore I was wrong. The bug in JSF is not related to this ticket.

Comment by Anissa Lam [ 15/Jun/11 ]

I see. Thanks for clarifying this.





[GLASSFISH-16216] annotation scanning was not done for library jars in directory format Created: 15/Mar/11  Updated: 07/Apr/11  Resolved: 15/Mar/11

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: None
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-next

 Description   

This is a related glassfish side issue for this Eclipse plug in issue:

http://java.net/jira/browse/GLASSFISHPLUGINS-324

This is to address the deployment problem when an EJB jar is inside the WEB-INF/lib directory and in exploded format.

The cause has been identified and a fix will be checked in soon.

There are parts in the glassfish annotation processing code that assumes the library jars are always in file format and we need to update them to include the directory format as well to support the Eclipse plug in.



 Comments   
Comment by Hong Zhang [ 15/Mar/11 ]

Checked in the fix. Have verified the changes (with simulated directory structure) for the test case (Fred) attached in the plug in issue. Ludo will verify the changes with the Eclipse plugin.





[GLASSFISH-16213] cleanup in security code for AIX port. Created: 15/Mar/11  Updated: 07/Apr/11  Resolved: 15/Mar/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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


 Description   

The class PolicyConfigurationImpl uses the JDK internal PolicyParser even though a PolicyParser (copied) exists in the security module. Also there is a copy of sun.security.provider.PolicyFile which is now unused in GlassFish (left over for V2.X), this needs to be cleaned up.



 Comments   
Comment by kumarjayanti [ 15/Mar/11 ]

fixed in latest V3.2 (trunk)





[GLASSFISH-16212] some dtds and schemas don't have the CDDL+GPL license header Created: 15/Mar/11  Updated: 07/Apr/11  Resolved: 16/Mar/11

Status: Resolved
Project: glassfish
Component/s: other
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-next

 Description   

I am working on packaging some j2ee bundles for eclipse orbit and noticed that some headers of the dtd and xsd files distributed with glassfish carry no license, a sun license or a proprietary license.

This is preventing us from adopting the java EE jars at eclipse.
We could re-use the apache ones but would favor the ones provided by gl;assfish as it is the reference implementation for java EE.

I apologize for this very unexciting and tedious request: is it possible to fix those headers or clarify under which license those files are distributed?

In case this helps here is the list. We don't need all of those at this point.

http://java.net/projects/glassfish/sources/svn/show/trunk/v3/deployment/schemas/src/main/resources/glassfish/lib/schemas?rev=45563
XMLSchema.dtd
no license

application-client_1_4.xsd
Sun's proprietary license 2002

application-client_5.xsd
Sun's proprietary license 2003

application-client_6.xsd
CDDL+GPL

application_1_4.xsd
Sun's proprietary license 2003

application_5.xsd
Sun's proprietary license 2003

application_6.xsd
CDDL+GPL

beans_1_0.xsd
JBoss copyright, ASL-20

datatypes.dtd
no license

ejb-jar_2_1.xsd
Sun's proprietary license 2003

ejb-jar_3_0.xsd
Sun's proprietary license 2003

ejb-jar_3_1.xsd
Sun's proprietary license 2003

j2ee_1_4.xsd
Sun's proprietary license 2003

j2ee_jaxrpc_mapping_1_1.xsd
Sun's proprietary license 2003

j2ee_web_services_1_1.xsd
Sun's proprietary license 2003

j2ee_web_services_client_1_1.xsd
Sun's proprietary license 2003

javaee_5.xsd
Sun's proprietary license 2003

javaee_6.xsd
CDDL+GPL

javaee_web_services_1_2.xsd
Sun's proprietary license 2003

javaee_web_services_1_3.xsd
CDDL+GPL

javaee_web_services_client_1_2.xsd
Sun's proprietary license 2003

javaee_web_services_client_1_3.xsd
CDDL+GPL

jax-rpc-ri-config.xsd
no license

jdbc-data-source.xsd
no license

jsp_2_0.xsd
CDDL+GPL

jsp_2_1.xsd
CDDL+GPL

jsp_2_2.xsd
CDDL+GPL

orm_1_0.xsd
no license

persistence_1_0.xsd
no license

web-app_*.xsd
web-common_3_0.xsd
web-facelettaglibrary_2_0.xsd
web-facesconfig_1_2.xsd
web-facesconfig_2_0.xsd
web-fragment_3_0.xsd
CDDL+GPL

web-jsptaglibrary_2_0.xsd
web-jsptaglibrary_2_1.xsd
Sun's proprietary license 2003

weblogic-application-client.xsd
weblogic-application.xsd
weblogic-connector.xsd
weblogic-ejb-jar.xsd
weblogic-javaee.xsd
weblogic-jms.xsd
weblogic-web-app.xsd
weblogic-webservices.xsd
no license

xml.xsd
no license

And for the dtd folder:
http://java.net/projects/glassfish/sources/svn/show/trunk/v3/deployment/dtds/src/main/resources/glassfish/lib/dtds?rev=45563
application-client_1_2.dtd
Sun's proprietary license 1999

application-client_1_3.dtd
Sun's proprietary license 2000

application_1_2.dtd
Sun's proprietary license 1999

application_1_3.dtd
Sun's proprietary license 2000

ejb-jar_1_1.dtd
Sun's proprietary license 1999

ejb-jar_2_0.dtd
Sun's proprietary license 2000

glassfish-*
CDDL+GPL

sun-application-*.dtd
sun-cmp-*.dtd
no license

sun-domain-1_0.dtd
CDDL
sun-domain-1_1.dtd
no license
sun-domain-1_2.dtd
sun-domain-1_3.dtd
CDDL

sun-ejb-jar_3_1-0.dtd
no license

sun-loadbalancer_*.dtd
CDDL

sun-server_1_0.dtd
no license

sun-web-app_*.dtd
no license

web-app_2_2.dtd
Sun's proprietary license 1999

web-app_2_3.dtd
Sun's proprietary license 2000

web-jsptaglibrary_1_1.dtd
Sun's proprietary license 1999

web-jsptaglibrary_1_2.dtd
no license



 Comments   
Comment by hmalphettes [ 15/Mar/11 ]

Here are the alternative sources with CDDL-GPL headers I have found for the xsds and dtds necessary for servlet-api:
http://java.sun.com/xml/ns/javaee/application-client_5.xsd
http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd
http://java.sun.com/xml/ns/javaee/javaee_5.xsd
http://java.sun.com/xml/ns/javaee/javaee_web_services_1_2.xsd
http://java.sun.com/xml/ns/javaee/javaee_web_services_client_1_2.xsd

This should confirm that the corresponding files packaged with glassfish are not up to date.

I was able to find
j2ee_web_services_1_1.xsd and j2ee_web_services_client_1_1.xsd
in glassfish-v2 (appserver-common/schema) with CDDL+GPL

That is enough to complete servlet-api-3.0 with CDDL+GPL.

Comment by Hong Zhang [ 16/Mar/11 ]

Thanks for catching this! We forgot to update the old schemas/dtds when the license header was updated. I am working on them right now and should be able to check in the changes into the v3 trunk workspace today.

Comment by Hong Zhang [ 16/Mar/11 ]

I am having some discussions with Bill (EE spec lead) on what license header we should have and he was wondering if Eclipse were using these files before, and if so, what has changed recently to prompt this request? Thanks.

Comment by hmalphettes [ 16/Mar/11 ]

Thanks for your attention.

Those older files were distributed with the servlet-api-2.5 bundle; in the javax.servlet.resources package and in the jsp-api-2.1 bundle in the javax.servlet.jsp.resources package.

  • servlet-api-2.5 was coming from apache and all files contain the ASl-2.0 header.
  • jsp-api-2.1 was coming from java.net/jsp. We had the same issue with missing license headers; reported it to Sun (kchung) at the time. Gave more work to the lawyers who review the pedigree of the files and were able to put that bundle together.

The jetty core developers want to stick to the reference implementation for the providers of servlet-api-3.0 and all other java-ee bundles.
So they got the servlet-api-3.0 and jsp-api-2.1 approved by the IP review at eclipse.
We found out once the review was approved that those jars don't package javax.servlet.resources and javax.servlet.jsp.resources

For the IP review the lawyers favor that all files are found in a single location.
In glassfish v2, all jars have the CDDL+GPL header.
In glassfish v3 which is still distributed as a whole as CDDL+GPL, some files have the wrong header.
On the http://java.sun.com/xml/ns urls all the files have the CDDL+GPL header.
In fact if we were to copy and override the files from v2 into v3 we would have the expected headers everywhere.

Strictly speaking we don't need at the moment all those files.
However it seems that glassfish license distribution is not consistent with the license of the files that it contains. And that is why I listed all the files.

Comment by Hong Zhang [ 16/Mar/11 ]

Thanks for the clarifications. Yes, for some reason some of the files in the v3 workspace were out of synch from the ones posted on the java.sun.com. I have updated the license headers of the schemas/dtds that are owned by Sun/Oracle now. For the ones that we don't own, we should not change. You can get from them (W3C, JBoss etc) if needed. Please let me know if I missed anything in the schemas/dtds that owned by Sun/Oracle.
The changes were checked into v3 trunk:
https://svn.java.net/svn/glassfish~svn/trunk/v3

Comment by hmalphettes [ 16/Mar/11 ]

Thanks a lot!
Sorry about listing the jboss and w3c files in there: it is clear that they should remain the way they were at jboss and w3c.





[GLASSFISH-16211] restart required not shown after calling set-log-attributes Created: 14/Mar/11  Updated: 10/Apr/11  Resolved: 10/Apr/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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


 Description   

The following is in recent email discussion from Naman

"As per the logging side, if user changes any attributes needs restart of the server as it's picked by the start up code. Any change in the log level doesn't need restart. I already sent this comment when I reviewed logging documentation and man pages.

So if you use the logging command like set-log-levels or rotate-log, restart is not required. If you use set-log-attributes command needs restart of the server.

Regards,
Naman
"
However using the CLI set-log-attributes command, or changing log attributes in the GUI (GUI code eventually calls set-log-attributes), I don't see the server status change to restart required. This needs to be fixed by the logging component.



 Comments   
Comment by Scott Fordin [ 18/Mar/11 ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by naman_mehta [ 21/Mar/11 ]

Fixed the same. It shows restart required when user changes and attributes from logger settings page.





[GLASSFISH-16201] non-existent web fragment referenced by ordering clause should be ignored Created: 13/Mar/11  Updated: 07/Apr/11  Resolved: 14/Mar/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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


 Description   

Application deployment should not fail if a web-fragment.xml references another web fragment by name that isn't part of the deployment. IMO, that defeats the main point of the relative ordering in the web-fragment.xml.

For example, library A may need to be ordered after library B, but before all others. So we define an ordering clause in A's web-fragment.xml as follows:

<ordering>
<after>
<name>B</name>
</after>
<before>
<others/>
</before>
</ordering>

However, we can't guarantee that library B will be used. In that case, GlassFish should just ignore the reference (after all, if it isn't there, the relative ordering of the two libraries isn't a concern).

Here's the error that's appearing in the log:

SEVERE: Exception while deploying the app [myapp_war]
SEVERE: The log message is null.
java.lang.NullPointerException
at com.sun.enterprise.deployment.OrderingDescriptor$Node.access$300(OrderingDescriptor.java:434)
at com.sun.enterprise.deployment.OrderingDescriptor.sort(OrderingDescriptor.java:169)
at com.sun.enterprise.deployment.archivist.WebArchivist.readStandardFragments(WebArchivist.java:438)
at com.sun.enterprise.deployment.archivist.WebArchivist.postAnnotationProcess(WebArchivist.java:350)
at com.sun.enterprise.deployment.archivist.WebArchivist.postAnnotationProcess(WebArchivist.java:89)
at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:409)
at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:383)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:246)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:255)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:216)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:180)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:826)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:768)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:636)

SEVERE: Exception while deploying the app [myapp_war]



 Comments   
Comment by Shing Wai Chan [ 14/Mar/11 ]

fix in dol: AbsoluteOrderingDescriptor.java, OrderingDescriptor.java, LocalStrings.properties

svn commit 45556





[GLASSFISH-16195] Web Services that declare exception cause class load failure with Java Web Start Created: 11/Mar/11  Updated: 07/Apr/11  Resolved: 31/Mar/11

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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

linux, gf 3.1, java se 6u24


Attachments: Zip Archive JAXWS_JMS_JWS_Tester.zip    

 Description   

I have created a sample project to demonstrate the issue.

Basically if a web service method declares a throws clause (say that its going to throw a custom exception), the generated web service client code fails to run from java web start.

Steps to reproduce:
1) create a simple ee project (ear, ejb, app client).
2) Create a simple @WebSerbice @Stateless @Webmethod class and deploy
3) generate the web service client code in the app client project using wsimport from java se 6 (or from glassfish, but that's a whole different problem)
4) create the main class to call the web service method.
5) deploy again
6) javaws http://localhost:8080/Tester-ear-1.0.0-SNAPSHOT/Tester-client-jaxws

Crash when trying to create port. The project has steps 1-4 already done. It is a maven project. Should be able to just:

  1. mvn clean install
  2. asadmin deploy Tester-ear/target/Tester-ear-1.0.0-SNAPSHOT.ear
  3. javaws http://localhost:8080/Tester-ear-1.0.0-SNAPSHOT/Tester-client-jaxws

The web service client works fine if you run it run it as an appclient

  1. appclient -client Tester-client-jaxws/target/Tester-client-jaxws-1.0.0-SNAPSHOT.jar

The web service client works fine if the web service end point doesn't have any methods that declare a throw.

Note the project also has the JMS client also, you can just ignore that client.

Let me know if I can be of any further help.

-Geoff



 Comments   
Comment by Tim Quinn [ 18/Mar/11 ]

Using a very simple example app with a web service (with a method that throws a user exception) and an app client I can reproduce the problem.

The ACC, when run under Java Web Start, takes steps to make sure that classes and resources provided by the endorsed GlassFish JARs are resolved from those JARs instead of the system JARs. This is particularly important for JAX-WS items because GlassFish usually ships with later versions of those than are in the standard Java SE runtime.

Unfortunately, the ACC is not doing this correctly and certain classes that should come from GlassFish JARs are instead being loaded from the Java SE system JARs.

I am testing a fix, but it will take some time to make sure it induces no bad side effects.

Comment by Tim Quinn [ 31/Mar/11 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 45806
Author: tjquinn
Date: 2011-03-31 07:38:42 UTC
Link:

Log Message:
------------
Fix for 16195

The Java Web Start-aware app client container must make sure that certain classes which are present in both the Java SE installation and in a GlassFish-provided JAR are loaded from the GlassFish JAR. This behavior was not working correctly because the Java Web Start-aware ACC used the MaskingClassLoader from the core/bootstrap module. That implementation did not do what the ACC needs.

This change uses a fine-tuned masking class loader which works as the ACC needs in this scenario.

Tests: app client launches via Java Web Start of an app containing a web service method which throws a user exception (the user-provided scenario which triggered the error)

Revisions:
----------
45806

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/JWSAppClientContainerMain.java

Added Paths:
------------
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/JWSACCMaskingClassLoader.java





[GLASSFISH-16191] application name resulted from deployment shouldn't default to some random name Created: 10/Mar/11  Updated: 07/Apr/11  Resolved: 10/Mar/11

Status: Resolved
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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

Tags: 3-1_next

 Description   

If i deploy hello.war through CLI, without specifying the default application name, it will use the prefix of the file.
eg. if i deploy hello.war, the name will default to 'hello'.

However, if i use REST to do the deployment, the resulting application name will be something like "hello3693413819820575515"

GUI is planning to move to REST for application deployment, and the app name is optional. If user doesn't specify that, the resulting name is 'hello' when using Deployment Facility, which matches CLI.

So, i need REST to fix this default to match CLI or DF.



 Comments   
Comment by Jason Lee [ 10/Mar/11 ]

Fix committed (r45480).





[GLASSFISH-16179] Issues with discovery of RuntimeBuilder when using GFR.bootstrap in OSGi environment Created: 08/Mar/11  Updated: 07/Apr/11  Resolved: 08/Mar/11

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-next

 Description   

While trying out various scenarios of embedding GlassFish in OSGi environment, I stumbled upon this issue. When the launcher classloader has simple-glassfish-api.jar and osgi framework is configured with same properties as regular glassfish, then I found that GlassFishRuntime.bootstrap() fails to find RuntimeBuilders. It happens because we don't configure system package to export org.glassfish.embeddable.spi package. Similarly, glassfish.jar bundle does not import this spi package as well.

This needs to be fixed in 3.1 branch if that branch opens.



 Comments   
Comment by Sanjeeb Sahoo [ 08/Mar/11 ]

Sending core/bootstrap/osgi.bundle
Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini
Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties
Transmitting file data ...
Committed revision 45446.





[GLASSFISH-16175] When a domain was down, restart-domain did not start it, but created a wrong error message. Created: 08/Mar/11  Updated: 07/Apr/11  Resolved: 16/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 3.1.1_b01

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


 Description   

Build 43, Solaris 10 Sparc. Created a domain, started domain and stopped domain, then tried to execute:
==================================================================
asadmin restart-domain --debug=true --domaindir=/opt/glassfish3/glassfish/domains --force=false --kill=true domain2

Invalid option: --force=false
Usage: asadmin [asadmin-utility-options] restart-domain
[-debug[=<debug(default:false)>]] [-force[=<force(default:true)>]]
[--kill[=<kill(default:false)>]] [--domaindir <domaindir>]
[?|-help[=<help(default:false)>]] [domain_name]
Server is not running, will attempt to start it...
Command restart-domain failed.

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

If to remove from the commnd line --force=false it start to comlain about --kill and so on.

I believe that when domain is down the restart-domain command has to start it. And in any case should not create a wrong error message like: "Invalid option: --force=false"



 Comments   
Comment by Byron Nevins [ 09/Mar/11 ]

THe problem is in this method in RestartDomainCommand:

@Override
protected int dasNotRunning(boolean local) throws CommandException

{ if (!local) throw new CommandException( Strings.get("restart.dasNotRunningNoRestart")); logger.warning(strings.get("restart.dasNotRunning")); CLICommand cmd = habitat.getComponent(CLICommand.class, "start-domain"); // XXX - assume start-domain accepts all the same options return cmd.execute(argv); }

}

See the "XXX" comment? The comment's hopes are dashed. They do indeed have different options.

Comment by Bill Shannon [ 10/Mar/11 ]

When --force and --kill were added to restart-domain, it broke
the assumption that all arguments to restart-domain were valid
arguments to start-domain.

Rather than passing all the original arguments through, restart-domain
needs to pass through only the options that are valid for start-domain.

The same problem exists with restart-local-instance/start-local-instance.
I fixed both.

Comment by easarina [ 16/Mar/11 ]

Was used latest continuous build. The problem still is not fixed there. Were seen such messages during restarting of domain and local instance, that were not running.

asadmin restart-domain --debug=true --domaindir=$S1AS_HOME/domains --force=true --kill=true domain4
Server is not running, will attempt to start it...
Command start-domain only accepts one operand
Usage: asadmin [asadmin-utility-options] restart-domain
[-debug[=<debug(default:false)>]] [-force[=<force(default:true)>]]
[--kill[=<kill(default:false)>]] [--domaindir <domaindir>]
[?|-help[=<help(default:false)>]] [domain_name]
Command restart-domain failed.

asadmin restart-local-instance --nodedir=$S1AS_HOME/nodes --node localhost-domain4 --debug=true --force=true --kill=true in42
Server is not running, will attempt to start it...
Command start-local-instance only accepts one operand
Usage: asadmin [asadmin-utility-options] restart-local-instance
[-debug[=<debug(default:false)>]] [-force[=<force(default:true)>]]
[--kill[=<kill(default:false)>]] [--nodedir <nodedir>] [--node <node>]
[?|-help[=<help(default:false)>]] [instance_name]
Command restart-local-instance failed.

Comment by Bill Shannon [ 16/Mar/11 ]

Oops. Forgot to add the command name to the argv passed to the start
command.





[GLASSFISH-16172] [packaging] Don't package dome/docs/javadoc for javadb artifact Created: 08/Mar/11  Updated: 07/Apr/11  Resolved: 08/Mar/11

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

Type: Improvement Priority: Major
Reporter: ancoron Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

v3 trunk


Attachments: Text File external-javadb-pom.patch    

 Description   

I always wondered why my local distribution builds where larger by approx. 5-7 MiB compared to the released bits of yours.

Now I got some time to get into it at least a bit.

The first thing I made was a diff of the zip contents and there I noticed that my local distribution build contains all those nasty javadb/demo, javadb/docs and javadb/javadoc files which make up about 5 MiB of space.

So I stepped backwards through the build process and finally saw this:

packager/external/javadb/pom.xml:

<unzip src="$

{javadb.zip}

"
dest="target/classes/glassfish/javadb">
<patternset>
<exclude name="javadb/demo/**"/>
<exclude name="javadb/docs/**"/>
<exclude name="javadb/javadoc/**"/>
</patternset>
</unzip>

...well, this simply cannot work and looking at the file revision history it never did work as expected.

So, do you post-process the zip before upload to the server?

However, I've made a simple patch for this ready for inclusion.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 08/Mar/11 ]

Thanks for catching this and providing the patch. This is actually a regression compared to 3.0.1 release and it was introduced during the integration of JavaDB 10.6.2.1 since JavaDB 10.6.2.1 zip artifact had different file layout compared to previous one. Exclude pattern did work as expected before that time...

This does not happen in "official" IPS enabled GlassFish distributions since those are assembled using JavaDB IPS packages and not zip artifact.

I'll integrate the fix shortly.

Comment by ancoron [ 08/Mar/11 ]

Ah, yes, I see. Thanx for the explanation.

Comment by Snjezana Sevo-Zenzerovic [ 08/Mar/11 ]

Fix checked into trunk as SVN revision 45440.





[GLASSFISH-16162] Cannot start standalone instance Created: 04/Mar/11  Updated: 09/Jan/13  Resolved: 10/Apr/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

solaris sparc


Attachments: HTML File 8691     HTML File 8743     File server.log.started-notrunning    

 Description   

I'm trying to start a standalone instance but the action hangs from both Admin Console and CLI. After trying with --verbose, with Joe's advice, here is what I see:

tuppy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish# a start-local-instance --verbose in1
CLI801 Instance is already synchronized
Mar 4, 2011 5:52:23 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
/export/home/j2eetest/jdk/bin/java
-cp
/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/glassfish.jar
-XX:+UnlockDiagnosticVMOptions
-XX:MaxPermSize=192m
-XX:NewRatio=2
-Xmx512m
-javaagent:/export/home/j2eetest/v3.1/glassfish3/glassfish/lib/monitor/btrace-agent.jar=unsafe=true,noServer=true
-server
-Dosgi.shell.telnet.maxconn=1
-Dfelix.fileinstall.disableConfigSave=false
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Dfelix.fileinstall.dir=/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/autostart/
-Djavax.net.ssl.keyStore=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/keystore.jks
-Dosgi.shell.telnet.port=26666
-Djava.security.policy=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/server.policy
-Dfelix.fileinstall.log.level=3
-Dfelix.fileinstall.poll=5000
-Dcom.sun.aas.instanceRoot=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1
-Dosgi.shell.telnet.ip=127.0.0.1
-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory
-Djava.endorsed.dirs=/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/endorsed:/export/home/j2eetest/v3.1/glassfish3/glassfish/lib/endorsed
-Dcom.sun.aas.installRoot=/export/home/j2eetest/v3.1/glassfish3/glassfish
-Dfelix.fileinstall.bundles.startTransient=true
-Djava.ext.dirs=/export/home/j2eetest/jdk/lib/ext:/export/home/j2eetest/jdk/jre/lib/ext:/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/lib/ext
-Dfelix.fileinstall.bundles.new.start=true
-Djavax.net.ssl.trustStore=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/cacerts.jks
-Dorg.glassfish.additionalOSGiBundlesToStart=org.apache.felix.shell,org.apache.felix.gogo.runtime,org.apache.felix.gogo.shell,org.apache.felix.gogo.command
-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
-Djava.security.auth.login.config=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/login.conf
-DANTLR_USE_DIRECT_CLASS_LOADING=true
Dgosh.args=-noshutdown -c noop=true
-Djava.library.path=/export/home/j2eetest/v3.1/glassfish3/glassfish/lib:/export/home/j2eetest/jdk/jre/lib/sparc/server:/export/home/j2eetest/jdk/jre/lib/sparc:/export/home/j2eetest/jdk/lib/sparc:/usr/jdk/packages/lib/sparc:/lib:/usr/lib
com.sun.enterprise.glassfish.bootstrap.ASMain
-asadmin-args
-host,,,localhost,,,port,,,4848,,,secure=false,,,terse=false,,,echo=false,,,interactive=false,,,start-local-instance,,,verbose=true,,,-debug=false,,,in1
-instancename
in1
-verbose
true
-debug
false
-asadmin-classpath
/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/admin-cli.jar
-asadmin-classname
com.sun.enterprise.admin.cli.AsadminMain
-upgrade
false
-type
INSTANCE
-instancedir
/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1
-read-stdin
true
Mar 4, 2011 5:52:23 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: Successfully launched in 100 msec.
Launching GlassFish on Felix platform
Exception in thread "main" java.lang.reflect.InvocationTargetException
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.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.server.logging.SyslogHandler.postConstruct(SyslogHandler.java:88)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.jvnet.hk2.component.Habitat$5.get(Habitat.java:701)
at java.util.AbstractList$Itr.next(AbstractList.java:345)
at com.sun.enterprise.server.logging.LogManagerService.postConstruct(LogManagerService.java:263)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:219)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
... 6 more

The exception seems to come from logging, hence I'm logging this bug under this module.

A little background: I've been using this solaris system for verifying 3.1 bugs for the past week or so. I encountered this issue yesterday. The last thing I did was undeploy a hello.war application from this instance while it was stopped (didn't actually mean to do this). When I went to the standalone instance's page and clicked on Start button. The "processing, please wait" message was displayed and never went away. I checked CLI and it reported this instance as stopped but with odd status:

tuppy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains/domain1/logs# a list-instances
in1 not running [pending config changes are: _get-runtime-info; _get-runtime-info; ]
c1in1 running
in2 not running
Command list-instances executed successfully.

After reloading Admin Console, the instance was reported as stopped there too.

I checked jps -v and it looked like there were two in1 processes running:

tuppy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains/domain1/logs# jps -v
8743 ASMain -XX:+UnlockDiagnosticVMOptions -XX:MaxPermSize=192m -XX:NewRatio=2 -Xmx512m -javaagent:/export/home/j2eetest/v3.1/glassfish3/glassfish/lib/monitor/btrace-agent.jar=unsafe=true,noServer=true -Dosgi.shell.telnet.maxconn=1 -Dfelix.fileinstall.disableConfigSave=false -Djdbc.drivers=org.apache.derby.jdbc.ClientDriver -Dfelix.fileinstall.dir=/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/autostart/ -Djavax.net.ssl.keyStore=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/keystore.jks -Dosgi.shell.telnet.port=26666 -Djava.security.policy=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/server.policy -Dfelix.fileinstall.log.level=3 -Dfelix.fileinstall.poll=5000 -Dcom.sun.aas.instanceRoot=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1 -Dosgi.shell.telnet.ip=127.0.0.1 -Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory -Djava.endorsed.
...
8691 ASMain -XX:+UnlockDiagnosticVMOptions -XX:MaxPermSize=192m -XX:NewRatio=2 -Xmx512m -javaagent:/export/home/j2eetest/v3.1/glassfish3/glassfish/lib/monitor/btrace-agent.jar=unsafe=true,noServer=true -Dosgi.shell.telnet.maxconn=1 -Dfelix.fileinstall.disableConfigSave=false -Djdbc.drivers=org.apache.derby.jdbc.ClientDriver -Dfelix.fileinstall.dir=/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/autostart/ -Djavax.net.ssl.keyStore=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/keystore.jks -Dosgi.shell.telnet.port=26666 -Djava.security.policy=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/server.policy -Dfelix.fileinstall.log.level=3 -Dfelix.fileinstall.poll=5000 -Dcom.sun.aas.instanceRoot=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1 -Dosgi.shell.telnet.ip=127.0.0.1 -Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory -Djava.endorsed.

At this point I asked Joe for help and he confirmed that indeed there were two in1 processes on the system. I'm attaching thread dump for both of them. I also checked instance's server.log and it looks like the shutdown from that day was not clean. Here is the output of the shutdown from a couple days earlier on the same instance that completed:

[#|2011-02-23T19:04:20.327-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.tools.admin.org.glassfish.server|_ThreadID=79;_ThreadName=Thread-2;|JMXStartupS
ervice: Stopped JMXConnectorServer: null|#]

[#|2011-02-23T19:04:20.329-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.tools.admin.org.glassfish.server|_ThreadID=79;_ThreadName=Thread-2;|JMXStartupS
ervice and JMXConnectors have been shut down.|#]

[#|2011-02-23T19:04:20.330-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.core.com.sun.enterprise.v3.server|_ThreadID=79;_ThreadName=Thread-2;|Shutdown p
rocedure finished|#]

Feb 25, 2011 12:13:58 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
/export/home/j2eetest/jdk/bin/java

While the latest shutdown is missing the "Shutdown procedure finished" line:

[#|2011-03-03T15:49:31.811-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.tools.admin.org.glassfish.server|_ThreadID=1120;_ThreadName=Thread-2;|JMXStartu
pService: Stopped JMXConnectorServer: null|#]

[#|2011-03-03T15:49:31.813-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.tools.admin.org.glassfish.server|_ThreadID=1120;_ThreadName=Thread-2;|JMXStartu
pService and JMXConnectors have been shut down.|#]

Mar 3, 2011 3:51:25 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
/export/home/j2eetest/jdk/bin/java

At this point, I killed both processes and tried to start the instance again - it would still hang and the output of the verbose option is listed at the top (hence we came the full circle). I'm attaching server.log from the start of testing till the initial startup hang and thread dumps of both processes that belonged to the instance. The machine is still available for debugging.



 Comments   
Comment by naman_mehta [ 07/Mar/11 ]

Don't able to reproduce the same. Please provide me the exact steps to reproduce.

Looks like it's machine specific issue.

Comment by naman_mehta [ 21/Mar/11 ]

hi lidia,

Wouldn't able to reproduce the same. Assigning this issue in your name. If still reproducible by you then give me exact steps and machine details.

Comment by lidiam [ 22/Mar/11 ]

It is not an issue that can be easily reproduced. I do not know what caused it in the first place, however, since the outcome was quite severe, I was asked to log an issue. You can close it if you want. If anybody encounters it in the future, we can reopen.

Comment by lidiam [ 22/Mar/11 ]

One more note, Joe Di Pol was helping debug this issue and this is how far we got. I kept the machine intact for a couple of days for debugging, but Glassfish has been reinstalled since. Glassfish worked flawlessly on this machine for months, so it's not necessarily a machine specific issue. After reinstall everything is working fine again. Series of many steps got Glassfish in this situation and unfortunately can't be reproduced.

Comment by naman_mehta [ 22/Mar/11 ]

As per the comments by lidia this issue is not reproducible.

But to avoid NPE in the code made some changes to catch the same. Committed revision 45678.

Comment by Matthias Wimmer [ 14/Apr/11 ]

Same problem existed here today. I found the reason for this to be some configuration properties missing in the file logging.properties in the config directory within the domain.
The first missing properties, causing this exception was "com.sun.enterprise.server.logging.SyslogHandler.useSystemLogging". After I have added this property, glassfish did not catch a NullPointerException in line 88 of SyslogHandler.java. But I got the next exception for the property "com.sun.enterprise.server.logging.GFFileHandler.file", which was missing as well.
As I expected even more properties would miss, I then copied a logging.properties file from a working domain on an other server. With the new logging.properties glassfish did start again.

Probably the broken logging.properties file was produced by editing a log level setting using the web interface by one of my coleagues last night.

The broken logging.properties file produced by the web interface we had, solely contains the following content:

#GlassFish logging.properties list
#Wed Apr 13 22:02:29 UTC 2011
javax.enterprise.system.tools.admin.level=INFO
javax.enterprise.system.ssl.security.level=OFF
org.apache.jasper.level=INFO
javax.enterprise.system.tools.backup.level=INFO
javax.enterprise.resource.corba.level=INFO
javax.enterprise.resource.webcontainer.jsf.resource.level=INFO
javax.enterprise.system.core.classloading.level=INFO
javax.enterprise.resource.jta.level=INFO
java.util.logging.ConsoleHandler.level=FINEST
javax.enterprise.system.webservices.saaj.level=INFO
javax.enterprise.system.tools.deployment.level=INFO
javax.enterprise.system.container.ejb.level=INFO
javax.enterprise.system.core.transaction.level=INFO
org.apache.catalina.level=INFO
javax.enterprise.resource.webcontainer.jsf.lifecycle.level=INFO
javax.enterprise.resource.webcontainer.jsf.config.level=INFO
javax.enterprise.system.container.ejb.mdb.level=INFO
javax.enterprise.resource.webcontainer.jsf.timing.level=INFO
javax.enterprise.system.core.level=INFO
org.apache.coyote.level=INFO
javax.level=INFO
javax.enterprise.resource.webcontainer.jsf.taglib.level=INFO
com.nicbase.server.infra.keyvalue.level=FINEST
javax.enterprise.resource.javamail.level=INFO
javax.enterprise.system.webservices.rpc.level=INFO
javax.enterprise.system.container.web.level=INFO
javax.enterprise.system.util.level=INFO
javax.enterprise.resource.webcontainer.jsf.facelets.level=INFO
javax.enterprise.resource.resourceadapter.level=INFO
javax.org.glassfish.persistence.level=INFO
javax.enterprise.resource.webcontainer.jsf.context.level=INFO
javax.enterprise.resource.webcontainer.jsf.application.level=INFO
javax.enterprise.resource.jms.level=INFO
javax.enterprise.system.core.config.level=INFO
org.jvnet.hk2.osgiadapter.level=INFO
javax.enterprise.system.level=INFO
javax.enterprise.system.core.security.level=INFO
javax.enterprise.resource.sqltrace.level=FINE
javax.enterprise.resource.webcontainer.jsf.renderkit.level=INFO
javax.enterprise.system.webservices.registry.level=INFO
javax.enterprise.system.core.selfmanagement.level=INFO
javax.enterprise.resource.webcontainer.jsf.managedbean.level=INFO
org.glassfish.admingui.level=INFO
javax.enterprise.resource.jdo.level=INFO
javax.enterprise.system.core.naming.level=INFO

Comment by naman_mehta [ 14/Apr/11 ]

We added code for checking that properties is present or not so NPE is avoided now.

Tried to made changes under Logger Settings page from admin GUI but couldn't reproduce broken logging.properties file. So question is how to reproduce broken logging.properties file from web interface. Let me know if it's reproducible.

Comment by juergenschmied [ 22/Feb/12 ]

Same problem. Rebuilding logging.properties helped.

Comment by roinou [ 06/Apr/12 ]

Same problem here.

It happened in our PRODUCTION environment this morning. After a routine restart, it was no longer possible to restart the server. Thanks to this issue, we reconstructed the "logging.properties" from our ACCEPTANCE and it fixed the problem.

The question is, HOW did this file get corrupted? last modification date stated 2012/03/29, today is 2012/04/06. This is a serious issue, we lost 3 hours of working time this morning.

Comment by cobre420 [ 09/Jan/13 ]

Same trouble today (9.1.2013) with glassfish 3.1.2.2. end of stacktrace
at com.sun.enterprise.server.logging.SyslogHandler.postConstruct(SyslogHandler.java:86)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at org.jvnet.hk2.component.Habitat$5.get(Habitat.java:703)
at java.util.AbstractList$Itr.next(AbstractList.java:345)
at com.sun.enterprise.server.logging.LogManagerService.postConstruct(LogManagerService.java:374)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:229)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)

Replacing the logging.properties helped.. Any advice or help, how to prevent from this behavior?





[GLASSFISH-16159] asupgrade fails without internet connection Created: 04/Mar/11  Updated: 14/Mar/12  Resolved: 04/Mar/11

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01, 4.0_b37

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

Attachments: File gf-16159.diff    
Tags: 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1-upgrade

 Description   

Without an internet connection, the upgrade tool fails while trying to parse the version out of the source domain.xml. The failure is here in UpgradeUtils.java:

/*

  • We don't need to validate the xml document now as that is the
  • job of the upgrade code in the application server. We're only
  • interested in the version information here, and if that is
  • somehow wrong then the upgrade process will fail downstream
  • as the document is parsed into serverbeans objects.
    */
    public Document getDomainDocumentElement(String domainFileName) {
    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
    factory.setNamespaceAware(true);
    Document resultDoc = null;
    try { DocumentBuilder builder = factory.newDocumentBuilder(); resultDoc = builder.parse(new File(domainFileName)); }

    catch (Exception ex)

    Unknown macro: { logger.log(Level.WARNING, stringManager.getString("upgrade.common.could_not_create_doc", new Object [] {domainFileName, ex.toString()})); }

    return resultDoc;
    }

Example error:

Could not create xml document object from file name /home/oracle/SUNWappserver/domains/domain1/config/domain.xml due to: java.net.UnknownHostException: www.sun.com

The fix for this is simple – what's bad is that this code hasn't changed since the initial commit in the v3 workspace, and no one has reported it till now (though GLASSFISH-14951 came close). We should fix this for any 3.1.next release.



 Comments   
Comment by Bobby Bissett [ 04/Mar/11 ]

The workaround is easy:

1. Copy source domain to the target domains directory (first rename the 3.1 domain if it has the same name as the one to be upgraded).
2. "asadmin start-domain --upgrade <domainname>"

Comment by Bobby Bissett [ 04/Mar/11 ]

Patch, take 1.

Comment by Bobby Bissett [ 04/Mar/11 ]

This is fixed in revision 45411.

Comment by Scott Fordin [ 15/Mar/11 ]

Does this still need to be included in the 3.1 Release Notes?

Comment by Bobby Bissett [ 15/Mar/11 ]

Thanks for checking. I guess it probably should include that you can run into this when using the upgrade tool with a 2.x domain and no internet connection. Let me know if you want me to file a separate issue or something.

Comment by Scott Fordin [ 15/Mar/11 ]

Ah, I can see where this could start to get messy. Two questions: 1) Should this information be included in the Upgrade Guide proper rather than the Release Notes? For example, it go in the Correcting Potential Upgrade Problems section (http://download.oracle.com/docs/cd/E18930_01/html/821-2437/gkrfh.html) 2) More messy, does this issue not have implications for performing closed network upgrades, as described in http://download.oracle.com/docs/cd/E18930_01/html/821-2416/gjcya.html?

I suppose I can just add the topic to Release Notes, but the closed network upgrade bit concerns me. Is there something I'm missing that makes this issue moot in closed network upgrade context? I mean, a user could copy the source domain to the target domain, as you state in the workaround, but would this workaround be necessary when the repositories are configured to be local?

Comment by Snjezana Sevo-Zenzerovic [ 15/Mar/11 ]

As far as I can tell we are OK when it comes to closed network upgrade section since there we tell user to run 'asadmin start-domain --upgrade' command which is not affected by this...

This affects only the scenario where user has side-by-side installations and runs 'upgradetool' to upgrade domain config. So, closed network updates (and regular updates) which upgrade the domain config "in place" using asadmin flag should be fine. It doesn't matter if repositories are local or remote.

Comment by Bobby Bissett [ 16/Mar/11 ]

Thanks Snjezana – I didn't get to this yesterday. I agree that we're ok on the closed-network upgrade/update. In fact, we're fine on any update since this only affects the case of upgrading from a 2.X domain. Only 2.X domains have a schema in them, and the stupid stupid stupid code in the upgrade tool tries to check that schema when it parses the domain (and it's only parsing it in order to check a version, nothing else).

So this only affects the internal version checking code in the tool, and doesn't apply to an actual upgrade at all. The "asadmin start-domain --upgrade" workaround is unaffected. To answer Scott's big question, this should probably be in the "correcting potential..." section, as it may be fairly common. (This isn't technically an upgrade problem, but that's irrelevant.) There could be a lot of people doing an upgrade from 2.X internally, and it would be good if they don't have to hunt for this info. Scott, let me know if there's something else you'd like me to do on this.

I will be so happy if/when we drop the upgrade tool for 3.2.

Comment by Scott Fordin [ 08/Apr/11 ]

Added topic to 3.1 Upgrade Guide.

Comment by Scott Fordin [ 13/Apr/11 ]

Also added issue to 3.1 Release Notes.





[GLASSFISH-16153] Admin GUI hangs on first access after installation on some Solaris Server Hardware. Created: 04/Mar/11  Updated: 07/Apr/11  Resolved: 04/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

Attachments: HTML File prtfru    
Tags: 3_1-next, 3_1-release-note-added, 3_1-release-notes

 Description   

This has been logged twice internally by the support organization in different Geos after performing installations of GF 3.1 on Solaris servers (i.e. bigger than your under-the-desk workstation).

Please refer to defects 7023434 and 7023307 for additional detail.

The problem is that during the generation of the registration page, if the SolarisSystemEnvironment.getSNViaPrtfruX() method is called, then if the output from the prtfru -x command is significant (a good sized server could output over 3000 lines/150Kbytes) then the page generation will hang.

The problem is the SystemEnvironment.getCommandOutput() implementation. This simply forks a process and waits for it to complete, without considering that the command might produce enough output to fill its standard out / standard error buffers, which would lead to the command being blocked until the buffers are drained:

ProcessBuilder pb = new ProcessBuilder(command);
p = pb.start();
p.waitFor();

This is not good. What the end user sees is the initial "Admin Console" loading screen, which is then replaced will a blank white screen and the browser hangs indefinitely. The only way to continue is to kill the prtfru command that is hung.

The solution is already available in the code base, and would be to reuse the com.sun.enterprise.universal.process.ProcessStreamDrainer:

ProcessBuilder pb = new ProcessBuilder(command);
p = pb.start();
psd = ProcessStreamDrainer.save("RegEnvCommandProcess", p);
return psd.getOutString();



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

sounds like we are generating the registration.jsf during console initialization, maybe we should move the code to till user press the 'GlassFish Registration' button in the common task page.
Siraj, do we have workaround for this ? maybe a way to stop this generation from happening ?

Comment by sirajg [ 04/Mar/11 ]

A fix has been checked into the trunk, so that the registration html generation happens when the user presses the register button. There are three work arounds :

Workaround 1 :

kill the process running prtfru, for example:

  1. ptree `cat /path/to/install-dir/glassfish/domains/your-domain-name/config/pid`
    20365 /usr/jdk/jdk1.6.0_23/bin/java -cp /path/to/install-dir/glassfish/modules/glass
    20385 /usr/sbin/prtfru
  2. kill -9 20385

Workaround 2:
Prior to logging into the DAS for the first time run:

Make the directory <install-dir>/glassfish/lib/registration/ read-only - i.e. chmod -w <install-dir>/glassfish/lib/registration/
This will result in the registration file not being generated. Registration option will not be displayed.

Workaround 3:

Prior to logging into the DAS for the first time run:

touch <install-dir>/glassfish/lib/registration/registration.html

The downside to approach (2) and (3) is that registering the product is not possible.

Comment by tecknobabble [ 04/Mar/11 ]

Okay, you are deferring the generation of the registration page But are you changing the code that will still hang when you press the "Register" button?

The crux of this is the SystemEnvironment.getCommandOutput() doesn't drain the command's output as it runs, and hence if the command produces enough output to fill its output buffers any further output will block waiting for the buffers to be read. Since the getCommandOutput() just does a p.waitFor() it will sit forever until someone goes and kills the forked process.

Comment by tecknobabble [ 04/Mar/11 ]

This is a shell script that can be used to simulate the problem seen on larger servers.

Rename your existing /usr/sbin/prtfru and replace it with this copy. Make sure it has execute privileges on it.

Comment by Scott Fordin [ 04/Mar/11 ]

Added issue to 3.1 Release Notes.

Comment by sirajg [ 04/Mar/11 ]

A fix has also been checked in to ensure that the command output is drained. This was the underlying issue. So the fix consists of two parts :

1) Delay registration file generation till it is needed.
2) Drain command output in SystemEnvironment.getCommandOutput().

Comment by Anissa Lam [ 04/Mar/11 ]

change fix version to 3.1_b01 since this is fixed in the trunk.
add 3_1-next tag as requested by Chris.





[GLASSFISH-16151] enable-secure-admin fails badly if user specifies non-existent aliases Created: 03/Mar/11  Updated: 07/Apr/11  Resolved: 04/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 3.1.1_b01

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


 Description   

Build 43, Sparc machine. Executed the follow steps:
1) Created a new domain:
asadmin --passwordfile ./password.txt --user admin create-domain --domaindir /opt/glassfish3/glassfish/domains --adminport 12345 --instanceport 9876 --savemasterpassword=true --usemasterpassword=true --savelogin=false --checkports=true --nopassword=false domain13
Using port 12345 for Admin.
Using port 9876 for HTTP Instance.
Default port 7676 for JMS is in use. Using 48200
Default port 3700 for IIOP is in use. Using 48201
Default port 8181 for HTTP_SSL is in use. Using 48202
Using default port 3820 for IIOP_SSL.
Using default port 3920 for IIOP_MUTUALAUTH.
Default port 8686 for JMX_ADMIN is in use. Using 48203
Using default port 6666 for OSGI_SHELL.
Using default port 9009 for JAVA_DEBUGGER.
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=jed-asqe-7,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US]
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=jed-asqe-7-instance,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US]
No domain initializers found, bypassing customization step
Domain domain13 created.
Domain domain13 admin port is 12345.
Domain domain13 admin user is "admin".
Command create-domain executed successfully.

2) Started the domain
3) Created a cluster: asadmin --passwordfile ./password.txt --user admin --port 12345 --host localhost create-cluster c1
Command create-cluster executed successfully.
4)Created an instance: asadmin --passwordfile ./password.txt --user admin --port 12345 --host localhost create-instance --cluster c1 --node localhost-domain13 in1

Command _create-instance-filesystem executed successfully.
Port Assignments for server instance in1:
JMX_SYSTEM_CONNECTOR_PORT=28691
JMS_PROVIDER_PORT=27681
HTTP_LISTENER_PORT=28085
ASADMIN_LISTENER_PORT=24853
JAVA_DEBUGGER_PORT=29009
IIOP_SSL_LISTENER_PORT=23820
IIOP_LISTENER_PORT=23700
OSGI_SHELL_TELNET_PORT=26666
HTTP_SSL_LISTENER_PORT=28186
IIOP_SSL_MUTUALAUTH_PORT=23920
The instance, in1, was created on host localhost
Command create-instance executed successfully.
5) Started an instance:
asadmin --passwordfile ./password.txt --user admin --port 12345 --host localhost start-local-instance --node localhost-domain13 in1
Waiting for in1 to start ..............................
Successfully started the instance: in1
instance Location: /opt/glassfish3/glassfish/nodes/localhost-domain13/in1
Log File: /opt/glassfish3/glassfish/nodes/localhost-domain13/in1/logs/server.log
Admin Port: 24853
Command start-local-instance executed successfully.
6) Stopped the instance:
asadmin --passwordfile ./password.txt --user admin --port 12345 --host localhost stop-instance in1
The instance, in1, is stopped.
Command stop-instance executed successfully.
7) Executed enable-secure-admin: asadmin --passwordfile ./password.txt --user admin --port 12345 --host localhost enable-secure-admin --adminalias adtest --instancealias intest
WARNING: Instance in1 seems to be offline; command enable-secure-admin was not replicated to that instance
Command enable-secure-admin completed with warnings.
8) Started an instance:
jed-asqe-7#/export/home] asadmin --passwordfile ./password.txt --user admin --port 12345 --host localhost start-local-instance --node localhost-domain13 in1
Waiting for in1 to start ....................
Successfully started the instance: in1
instance Location: /opt/glassfish3/glassfish/nodes/localhost-domain13/in1
Log File: /opt/glassfish3/glassfish/nodes/localhost-domain13/in1/logs/server.log
Admin Port: 24853
Command start-local-instance executed successfully.
9) Tried to execute enable-secure-admin again:
asadmin --passwordfile ./password.txt --user admin --port 12345 --host localhost enable-secure-admin --adminalias adtest --instancealias intest
remote failure: An error occurred during replication
FAILURE: Command enable-secure-admin failed on server instance in1: java.net.SocketException: Unexpected end of file from server
Command enable-secure-admin failed.

In the instance in1 server.log during step 9 were created such messages:
=============================================================================
[#|2011-03-03T16:27:24.721-0800|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=19;_ThreadName=Thread-1;|GRIZZLY0007: SSL support could not be configured!
java.io.IOException: SSL configuration is invalid due to No available certificate or key corresponds to the SSL cipher suites which are enabled.
at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:455)
at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:183)
at com.sun.grizzly.config.SSLConfigHolder.initializeSSL(SSLConfigHolder.java:361)
at com.sun.grizzly.config.SSLConfigHolder.configureSSL(SSLConfigHolder.java:237)
at com.sun.grizzly.config.GrizzlyEmbeddedHttps$LazySSLInitializationFilter.execute(GrizzlyEmbeddedHttps.java:202)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:310)
at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:255)
at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:451)
... 14 more

#]

[#|2011-03-03T16:27:24.748-0800|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=19;_ThreadName=Thread-1;|GRIZZLY0007: SSL support could not be configured!
java.io.IOException: SSL configuration is invalid due to No available certificate or key corresponds to the SSL cipher suites which are enabled.
at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:455)
at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:183)
at com.sun.grizzly.config.SSLConfigHolder.initializeSSL(SSLConfigHolder.java:361)
at com.sun.grizzly.config.SSLConfigHolder.configureSSL(SSLConfigHolder.java:237)
at com.sun.grizzly.config.HttpProtocolFinder.find(HttpProtocolFinder.java:109)
at com.sun.grizzly.config.ConfigProtocolFinderWrapper.find(ConfigProtocolFinderWrapper.java:72)
at com.sun.grizzly.portunif.PUReadFilter.findProtocol(PUReadFilter.java:512)
at com.sun.grizzly.portunif.PUReadFilter.execute(PUReadFilter.java:188)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:310)
at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:255)
at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.checkConfig(JSSE14SocketFactory.java:451)
... 17 more

#]

[#|2011-03-03T16:27:24.763-0800|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=19;_ThreadName=Thread-1;|GRIZZLY0059: PortUnification exception.
java.lang.NullPointerException
at com.sun.grizzly.config.SSLConfigHolder.createSSLEngine(SSLConfigHolder.java:205)
at com.sun.grizzly.config.HttpProtocolFinder.find(HttpProtocolFinder.java:116)
at com.sun.grizzly.config.ConfigProtocolFinderWrapper.find(ConfigProtocolFinderWrapper.java:72)
at com.sun.grizzly.portunif.PUReadFilter.findProtocol(PUReadFilter.java:512)
at com.sun.grizzly.portunif.PUReadFilter.execute(PUReadFilter.java:188)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2011-03-03T16:27:24.772-0800|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=20;_ThreadName=Thread-1;|GRIZZLY0059: PortUnification exception.
java.lang.NullPointerException
at com.sun.grizzly.config.SSLConfigHolder.createSSLEngine(SSLConfigHolder.java:205)
at com.sun.grizzly.config.HttpProtocolFinder.find(HttpProtocolFinder.java:116)
at com.sun.grizzly.config.ConfigProtocolFinderWrapper.find(ConfigProtocolFinderWrapper.java:72)
at com.sun.grizzly.portunif.PUReadFilter.findProtocol(PUReadFilter.java:512)
at com.sun.grizzly.portunif.PUReadFilter.execute(PUReadFilter.java:188)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2011-03-03T16:27:24.783-0800|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=21;_ThreadName=Thread-1;|GRIZZLY0059: PortUnification exception.
java.lang.NullPointerException
at com.sun.grizzly.config.SSLConfigHolder.createSSLEngine(SSLConfigHolder.java:205)
at com.sun.grizzly.config.HttpProtocolFinder.find(HttpProtocolFinder.java:116)
at com.sun.grizzly.config.ConfigProtocolFinderWrapper.find(ConfigProtocolFinderWrapper.java:72)
at com.sun.grizzly.portunif.PUReadFilter.findProtocol(PUReadFilter.java:512)
at com.sun.grizzly.portunif.PUReadFilter.execute(PUReadFilter.java:188)
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)

#]
=======================================================================

I believe in any case such error messages should not be created.



 Comments   
Comment by easarina [ 03/Mar/11 ]

I believe this issue happened because were used not existent aliases.
I've created a new domain. started a domain, then executed:
enable-secure-admin --adminalias adtest --instancealias intest

After that tried to execute restart-domain. The restart-domain never returned a prompt. Based on the domain server.log, the domain was stopped, but it was not started, in sever.log appeared countless number of the same messages:

;|GRIZZLY0059: PortUnification exception.
java.lang.NullPointerException
at com.sun.grizzly.config.SSLConfigHolder.createSSLEngine(SSLConfigHolder.java:205)
at com.sun.grizzly.config.HttpProtocolFinder.find(HttpProtocolFinder.java:116)
at com.sun.grizzly.config.ConfigProtocolFinderWrapper.find(ConfigProtocolFinderWrapper.java:72)
at com.sun.grizzly.portunif.PUReadFilter.findProtocol(PUReadFilter.java:512)
at com.sun.grizzly.portunif.PUReadFilter.execute(PUReadFilter.java:188)
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)

Comment by Tom Mueller [ 04/Mar/11 ]

The user error here appears to be that the domain was not restarted after running enable-secure-admin. We already have an issue open for having the command output a warning that the domain needs to be restarted after any command that triggers a required restart (issue GLASSFISH-14925). Maybe this is a duplicate of that issue.

Comment by Tim Quinn [ 04/Mar/11 ]

Tom is correct; the initial error was because the domain was not restarted before further commands were issued.

My hope is that in a future release of GlassFish that Grizzly can handle the config changes for secure admin without requiring a restart, but unless and until that happens the restart will remain required.

Separately from that, Elena has identified a bug in that the enable-secure-admin command does not valid the alias names if the user specifies them. I am going to change the summary line of this issue to reflect that defect and will work with the security team to find out the best way to validate alias names.

Comment by Tim Quinn [ 04/Mar/11 ]

Changing the summary to reflect that the alias names are not validated, and that seems to lead to spectacular errors.

Comment by easarina [ 04/Mar/11 ]

If a user mistakenly would use a wrong alias name and then stop domain, it would be impossible to start domain after that.

Comment by Tim Quinn [ 04/Mar/11 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 45408
Author: tjquinn
Date: 2011-03-04 20:02:10 UTC
Link:

Log Message:
------------
Fix for 16151

The enable-secure-admin command lets users specify the DAS alias, the instance alias, or both (or neither). The code did not validate the alias, and specifying an alias not present in the keystore caused numerous error messages.

These changes validate the alias names (if specified) and report problems in the action report.

Revisions:
----------
45408

Modified Paths:
---------------
trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/EnableSecureAdminCommand.java
trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/SecureAdminConfigUpgrade.java
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/SecureAdminCommand.java





[GLASSFISH-16150] Created a domain with master password, restart-instance - failed. Created: 03/Mar/11  Updated: 06/Jun/11  Resolved: 08/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 3.1.1_b01

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

Issue Links:
Dependency
blocks GLASSFISH-16146 Umbrella bug. Created a domain with ... Open
Tags: 3_1-next

 Description   

Executed steps that were described in the umbrella bug 16146.

Then executed restart-instance:
=======================================================
asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin restart-instance in9
No response from Domain Admin Server after 600 seconds.
The command is either taking too long to complete or the server has failed.
Please see the server log files for command status.
Command restart-instance failed.
====================================================
According to the messages in the server.log the instance was stopped. After the mesages regarding the stopping of the instance, no other correspondent messages were seen.

The password.txt file had such content:

AS_ADMIN_PASSWORD=adminadmin
AS_ADMIN_MASTERPASSWORD=admin123



 Comments   
Comment by Byron Nevins [ 07/Mar/11 ]

This is user error.

restart-domain is clearly documented as stopping the server followed by starting it up EXACTLY the same way as it was originally started. You did not originally start it with a password file.

For a fair test – you need to call start-domain (not restart) with the arguments documented in this issue. After that a restart-domain ought to work. If it doesn't please document all of your steps and reopen.

Comment by easarina [ 07/Mar/11 ]

This bug talks about restart-instance, not restart-domain. The steps are3 listed in the bug.

Comment by Byron Nevins [ 07/Mar/11 ]

Reassigning to Elena.

restart-domain, restart-instance. My previous comment applies to both.

Go to the machine with the instance on it and start it (not restart it) with the password file. Then you can restart it.

You can reassign to me if the above fails – else close it.

Comment by easarina [ 07/Mar/11 ]

Please see all previous steps in the umbrella bug:

http://java.net/jira/browse/GLASSFISH-16146

The instance was started with passwordfile. Then I've tried to restart instance with and without step 6 from 16146, stop-local-instance. In both cases restart-instance created timeout.

Comment by Byron Nevins [ 08/Mar/11 ]

Confirmed! Nice job Elena.

Here is my Windows script for reproducing:

rem ===== 16150.bat =====================

call asadmin --passwordfile ./password.txt --user admin create-domain --domaindir /glassfish3/glassfish/domains --adminport 9999 --instanceport 4444 --savemasterpassword=true --usemasterpassword=true --savelogin=false --checkports=true --nopassword=false domain12
pause

call asadmin start-domain domain12
pause

call asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin create-cluster c1
pause

call asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin create-local-instance --cluster c1 --node localhost-domain12 in9
pause

call asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin start-local-instance --node localhost-domain12 in9
pause

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

The I tried to restart like this:

call asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin restart-instance in9

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

result – server stopped but never restarted.

Comment by Byron Nevins [ 08/Mar/11 ]

Here is the problem – which is trivial to fix.

(1) GlassFish servers always always always have the current working directory set to their config directory
(2) You gave a RELATIVE path to the password file.

So – the running server had NO WAY of knowing what directory you originally ran the command from. So the running server created a JVM and then told asadmin to use a password file that is located in the config directory! At that point it "hung". But not really. Your client asadmin called restart-instance and then waited for it to restart. It has NO WAY of knowing that it failed to restart. Meantime the running server was killed, and the new JVM ran asadmin which resulted in EXACTLY what would happen if you ran this command:

asadmin --passwordfile /i_dont_exist --port 9999 --host localhost --user admin start-local-instance --node localhost-domain12 in9

I.e. asadmin printed an error into space and exited. And you waited for a pointless 10 minutes.

Note: If you ran with verbose mode – you would have seen no problem at all. Try it! This would have been a VERY useful clue.

WORK-AROUND FOR END-USER:

(1) copy the password.txt to the config dir – which is where it ought to be anyways!
==or==
(2) give the full path for the password file

FIX FOR GF CODE:

(1) asadmin itself should see that the value of --passwordfile is a file – and automatically change ALL such options to the full path using SmartFile.sanitize()

Comment by Byron Nevins [ 08/Mar/11 ]

D:\gf\v3\admin\cli>svn commit
Sending cli\src\main\java\com\sun\enterprise\admin\cli\ProgramOptions.java
Transmitting file data .
Committed revision 45444.

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.





[GLASSFISH-16139] add ShoalLogger.level=CONFIG to glassfish/lib/templates/logging.properties Created: 03/Mar/11  Updated: 10/Apr/11  Resolved: 10/Apr/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

Issue Links:
Duplicate
is duplicated by GLASSFISH-14674 Log Level setting not honored Closed
Tags: 3_1-next

 Description   

ShoalLogger is not showing up by default in asadmin GUI Configurations => cluster-config => Logger Settings => LogLevels => Logger Name.

Workaround is to explicitly set ShoalLogger using following cli command.

% asadmin set-log-levels ShoalLogger=CONFIG
% asadmin set-log-levels --target <clustername>-config ShoalLogger=CONFIG

I noticed if I manually added ShoalLogger to glassfish/lib/templates/logging.properties,
that this addresses the issue.



 Comments   
Comment by Joe Fialli [ 03/Mar/11 ]

Glassfish issue 14674 was incorrectly reopened due to this issue.

Comment by naman_mehta [ 20/Mar/11 ]

Made changes in logging.properties template for the same.





[GLASSFISH-16136] For WARs in EARs web sessions are not retained after redeploy Created: 03/Mar/11  Updated: 07/Apr/11  Resolved: 07/Mar/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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

Windows XP


Attachments: File TestEAR.ear     File TestWeb.war    
Tags: http_sessions, keep_state, sessions, web_sessions

 Description   

If an EAR application, containing a WAR module is deployed and then the same EAR is redeployed the web sessions are lost although the option "Keep state" was checked in admin GUI before redeployment.

I am attaching a simple WAR and EAR to demonstrate the issue. The EAR is nothing more but a container for the same WAR.
Steps to reproduce.
1. Deploy TestEAR.ear
2. Open the TestWeb index page in a web browser ( http://localhost:8080/TestWeb/ ). You will see a webpage with a simple "Counter: 0"
3. Refresh the page a couple of times. You will see the counter increasing.
4. Redeploy the application from GUI with "Keep state" on. (I also tested with asadmin keepSessions=true with the same result)
5. Refresh the page in the browser again. You will see that the counter is reset to 0.

If you go through the above steps with the WAR file ( TestWeb.war ) instead of the EAR you should see that the counter is not reset in step 5. The problem I describe is for version 3.1, it does not seem to occur for v3-final even with the EAR redeployment.



 Comments   
Comment by Shing Wai Chan [ 07/Mar/11 ]

Sending web-glue/src/main/java/com/sun/enterprise/web/WebApplication.java
Transmitting file data .
Committed revision 45422.





[GLASSFISH-16132] Bug in create-http-lb command with --lbenableallapplications=true when the application is already availability enabled. Created: 02/Mar/11  Updated: 08/Apr/11  Resolved: 05/Apr/11

Status: Resolved
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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


 Description   

I deployed a Web Application to a GF Cluster cluster1 with availability enabled.

Now When I try to create http load balancer config for all applications deployed on that cluster, I get the following error.

./asadmin create-http-lb --devicehost retriever --deviceport 8989 --target cluster1 --lbenableallinstances=true --lbenableallapplications=true my-http-lb
remote failure: Application [WebApplication] is already enabled for [cluster1].
Command create-http-lb failed.

If the app is already availability enabled, it should just continue and not throw an error.
One more interesting thing, though it says the command failed, it did create the http-lb-config as shown below.

[rama@shepherd]$ ./asadmin list-http-lb-configs
my-http-lb_LB_CONFIG
Command list-http-lb-configs executed successfully.



 Comments   
Comment by Yamini K B [ 05/Apr/11 ]

Sending src/main/java/org/glassfish/loadbalancer/admin/cli/CreateHTTPHealthCheckerCommand.java
Sending src/main/java/org/glassfish/loadbalancer/admin/cli/DisableHTTPLBApplicationCommand.java
Sending src/main/java/org/glassfish/loadbalancer/admin/cli/DisableHTTPLBServerCommand.java
Sending src/main/java/org/glassfish/loadbalancer/admin/cli/EnableHTTPLBApplicationCommand.java
Sending src/main/java/org/glassfish/loadbalancer/admin/cli/EnableHTTPLBServerCommand.java
Transmitting file data .....
Committed revision 45929.





[GLASSFISH-16112] Admin GUI fails with NPE when attempting to undeploy an application, and redeploy also fails - must manually clean domain Created: 01/Mar/11  Updated: 11/Apr/11  Resolved: 11/Apr/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01, 4.0_b01

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

Ubuntu Linux 10.04 x86, Sun JVM 1.6.0_24-b07, Mozilla Firefox 3.6.13


Attachments: GZip Archive deploy-undeploy-logs.tar.gz     XML File domain.xml     File hello.war     File stateless-simple.ear    

 Description   

When attempting to undeploy an application, even if undeploy is successful, the UI shows the "Long operation detected" mini-dialog, only to fail with an NPE moments later. Afterwards, the Admin UI is no longer accessible and Glassfish displays the "default welcome" page where the UI should be.

Inspecting the domain.xml, it appears that the undeployment is successful (no further reference of the application is visible).

Stack trace from GUI undeploy failure:

INFO: JSF1027: [null] The ELResolvers for JSF were not registered with the JSP container.
INFO: file:/opt/gf3.1/glassfish/domains/domain1/applications/teos-1.0.7-r2712/WEB-INF/lib/teos-core-1.0.7.jar_TEOS Core logout successful
INFO: No timers to be deleted for id: 85130494774476800
INFO: Admin Console: Initializing Session Attributes...
WARNING: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button1'.
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
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:215)
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.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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.reflect.InvocationTargetException
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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.IllegalStateException: REST Server Name not set!
at org.glassfish.admingui.common.util.GuiUtil.initSessionAttributes(GuiUtil.java:158)
at org.glassfish.admingui.common.util.GuiUtil.getSessionValue(GuiUtil.java:241)
at org.glassfish.admingui.common.handlers.DeploymentHandler.removeFromDefaultWebModule(DeploymentHandler.java:335)
at org.glassfish.admingui.common.handlers.DeploymentHandler.undeploy(DeploymentHandler.java:318)
... 49 more

SEVERE: javax.faces.FacesException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button1'.
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:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
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:215)
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.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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
... 33 more
Caused by: java.lang.reflect.InvocationTargetException
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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.IllegalStateException: REST Server Name not set!
at org.glassfish.admingui.common.util.GuiUtil.initSessionAttributes(GuiUtil.java:158)
at org.glassfish.admingui.common.util.GuiUtil.getSessionValue(GuiUtil.java:241)
at org.glassfish.admingui.common.handlers.DeploymentHandler.removeFromDefaultWebModule(DeploymentHandler.java:335)
at org.glassfish.admingui.common.handlers.DeploymentHandler.undeploy(DeploymentHandler.java:318)
... 49 more

WARNING: StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
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:215)
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.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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)



 Comments   
Comment by drivera [ 01/Mar/11 ]

I made a mistake above - the environment is Ubuntu 10.10, not 10.04. Sorry about that - should be "same difference", though.

Comment by Anissa Lam [ 01/Mar/11 ]

Looking at the stack trace,

Caused by: java.lang.IllegalStateException: REST Server Name not set!
at org.glassfish.admingui.common.util.GuiUtil.initSessionAttributes(GuiUtil.java:158)
at org.glassfish.admingui.common.util.GuiUtil.getSessionValue(GuiUtil.java:241)
at org.glassfish.admingui.common.handlers.DeploymentHandler.removeFromDefaultWebModule(DeploymentHandler.java:335)
at org.glassfish.admingui.common.handlers.DeploymentHandler.undeploy(DeploymentHandler.java:318)

GUI has lost its session information and needs to initialize it again, yet doesn't have enough info.
I am not sure what is causing it as it is in the middle of undeployment and shouldn't caused by session timeout.
Please let me know the following:

  • Do you see this consistently and always reproducible ?
  • If you use the same browser, open up another browser window and launch GUI from there, will that work ?
  • If the above doesn't, can you try a different browser and will GUI come up then ?
  • Is this the same app that is causing the problem in GLASSFISH-16113 or GLASSFISH-16114 ?
  • Will it be possible attach the war for me to reproduce the issue ?

thanks.

Comment by drivera [ 01/Mar/11 ]

Yes, 100% reproducible.

Same browser, new browser window ineffectual - UI is gone as in no longer in Kansas
Different browser - same effect, UI is gone.

Yes, it's the same app as for those two issues, but those other two issues happen with all apps. The application itself does no "black magic" - no funky threading, no runtime manipulation, no advanced reflection, no runtime instrumentation, etc.

I'm afraid I can't provide the WAR due to licensing constraints. In addition, there would be substantial setup to be made to prepare a "test" environment (databases, paths, etc).

Comment by drivera [ 01/Mar/11 ]

But, if you like, I can make some time available and help you in your research - perhaps even provide you remote access to the testing instance so you can latch on a debugger? E-mail me privately and we can coordinate.

Comment by Anissa Lam [ 01/Mar/11 ]

Thanks for the offer
You mentioned this is an app that does no "black magic", but the issue is 100% reproducible.
Can you try with a simple hello.war to see if you run into this same problem ? I want to isolate if this issue only occurs for this particular app or this is an environment issue.
I have attached both hello.war and another .ear file, please deploy and undeploy that to see what happens. thanks

Comment by drivera [ 01/Mar/11 ]

Both deployed and undeployed fine. I can't think of why the app would work on 3.0.1 but not 3.1 - if there were something glaringly broken, then I'd expect either:

1) the app to not work with 3.0.1
2) plenty of errors pointing out the actual API/model usage problems (in 3.1)

Would you agree?

Granted, this is the real world...

Let me know how else I can help you. I'm hoping to succeed with deploying on 3.1 because we're being afflicted by a memory leak that I believe is due to the well-known CDI memory issues in 3.0.1. I just need to confirm it.

However, with these issues, it'll be a tough sell even if we succeed...

Comment by drivera [ 01/Mar/11 ]

Sorry - my previous comment may be misleading. The app DOES deploy and work in 3.1 - but it causes the aforementioned undeployment problems when undeploying via the UI. Undeploy via command line works.

Furthermore, the app is afflicted with the issue described in GLASSFISH-16115, which is the only part we've been unable to test (for obvious reasons).

Comment by Anissa Lam [ 01/Mar/11 ]

As you said the 2 attached app doesn't have issue, yet undeploying your app shows the issue 100% of time, there must be something related to your app that triggers the problem.
If you do the following:

  • launch GUI
  • deploy the app (using GUI or CLI, whatever you have been using before)
  • undeploy the app using CLI

Does GUI work after the undeployment using CLI ?

Does the app deploy to "server" (DAS), or cluster ?
What virtual server does this app deploy to ?
Is there any other config change you made, eg, create new VS and deploy to this new VS etc ?
Will it be possible for you to attach domain.xml after the app is deployed, but BEFORE undeploy ?

  • one more thing, once you see this problem, even using another browser cannot bring up GUI. How about restarting the server ? Can you launch GUI after restarting server ?
Comment by drivera [ 01/Mar/11 ]

Domain XML attached, as requested.

Your answers:

  • KEY POINT: After CLI undeploy, the Admin UI also goes offline.

This was the procedure followed:

1) Start the server
2) Deploy the app
3) bring up the Admin UI
4) Go to Apps page, to see the app listed
5) hit the app main page, login, make sure it's up, etc
6) undeploy via CLI
7) Navigate to the "Lifecycle Modules" entry on the navigation panel

  • UI now returns either 404 (not found), or if a reload to the base URL (http://localhost:4848) it shows the "placeholder" page.
  • IMPORTANT: There are NO exceptions in the log, whatsoever.

More info...

  • The app deploys to "whatever the default deployment target is from asadmin deploy", which I expect is server since I've not configured it to anything else.
  • No clustering is in use
  • No VS or additional server configuration (except the requisite DataSources) has been created
  • Some JVM flags have been added (noted in the attached domain.xml)
  • Admin UI works fine upon a server reboot
Comment by drivera [ 01/Mar/11 ]

More info

  • KEY POINT: After CLI undeploy, the Admin UI was accessible.

This was the procedure followed:

1) Start the server
2) Deploy the app
3) hit the app main page, login, make sure it's up, etc
4) undeploy via CLI
5) bring up the Admin UI (which starts up fine)
6) Admin UI seems to be fine

So the problem seems to be (in this particular case, obviously): when an undeploy is executed while the Admin UI is up, the undeploy drags the Admin UI with it...

Is there a command I could re-run afterwards to re-deploy the admin UI and see if that works in bringing it back online? At least that would tell us if that's what's happening.

Keep in mind the last two are wild, shot-from-the-hip guesses...

Comment by Anissa Lam [ 04/Mar/11 ]

>> Is there a command I could re-run afterwards to re-deploy the admin UI and see if that works in bringing it back online?
If you start up GUI with a new browser, GUI initialize for that session.
One thing we can try is to set the logger level to FINEST for all, restart the domain and repeat the steps. Hopefully, it will give us more information.
To do that, go to Configuration -> server-config -> Logger Settings and then the Log Levels tab. change the level and save.

Can you tell us more on what kind of app this is ? Will you be able to scale down your app and provide us a copy of your app with 'sensitive info' removed so we can reproduce the case ? It is really hard to know what is going on without any knowledge of your app.

Since there is workaround and you can undeploy the app with CLI and then bring up the console, i am downgrading this to P3.

Comment by drivera [ 04/Mar/11 ]

I'm not sure I agree with the priority drop, since this is a pretty glaring defect in a part of the UI where one as an administrator would least expect it to fail.

Having said that, yes - I'll get you this information as soon as I can. Also, the workaround is limited since if I re-deploy, and then undeploy after the UI is 'initialized', then clearly we're back in the same hole.

I'll get you the info tomorrow during my next "playtime" session.

Cheers.

Comment by drivera [ 05/Mar/11 ]

Requested log files attached. Logs are split into two files: one file is the log from the deployment of the application, the other is the log from the undeployment of the application.

Hopefully, this will shed more light. I'm working on permission to give you a copy of the app so you may reproduce, but I'm not hopeful. Also, the setup is somewhat complex so that might be another barrier.

Let me know if there's anything else I can help you with in the meantime.

Comment by Anissa Lam [ 23/Mar/11 ]

If it is not feasible for you to provide a stripped down application for us to reproduce the problem, please provide more info about your app.
Actually you can remove all your business logic, and i don't care about setting up the database etc. either since i just want to deploy and undeploy to reproduce the issue. I really don't need the app to run successfully.

What library is packaged with it ?
Can you give the directory structure of your app ?

Comment by scott6666 [ 29/Mar/11 ]

Looks like I just ran into the same issue.

War file runs fine. Redeploy killed the gui. Restarted gui and app was not enabled. Restarted server and came up ok.

Same basic app ran fine under 3.0.1. Had been developed a bit since then but no changes in technology stack or components used.

[#|2011-03-29T17:01:39.346+0000|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=99;_ThreadName=Thread-1;|javax.faces.FacesException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'reloadLink'.
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:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
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:215)
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.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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'reloadLink'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at com.sun.webui.jsf.component.TableRowGroup.broadcast(TableRowGroup.java:1989)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
... 33 more
Caused by: java.lang.reflect.InvocationTargetException
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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: java.lang.IllegalStateException: REST Server Name not set!
at org.glassfish.admingui.common.util.GuiUtil.initSessionAttributes(GuiUtil.java:158)
at org.glassfish.admingui.common.util.GuiUtil.getSessionValue(GuiUtil.java:241)
at org.glassfish.admingui.common.util.GuiUtil.getDeploymentFacility(GuiUtil.java:251)
at org.glassfish.admingui.common.util.DeployUtil.enableApp(DeployUtil.java:169)
at org.glassfish.admingui.common.util.DeployUtil.reloadApplication(DeployUtil.java:156)
at org.glassfish.admingui.common.handlers.ApplicationHandlers.reloadApplication(ApplicationHandlers.java:483)
... 50 more

#]

[#|2011-03-29T17:01:39.350+0000|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=99;_ThreadName=Thread-1;|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
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:215)
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.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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]
Comment by Anissa Lam [ 07/Apr/11 ]

I have requested several times for a test app, or at least the list of contents of your app, but i never get any answer.

GLASSFISH-16223 is reporting the same issue, that the console is not available after undeployment of their app.
The deployment code in the console has been changed to use REST API, and with the application provided by the submitter in GLASSFISH-16223, I can no longer reproduce the problem.

So, Please try 3.2 b01 that is available from http://dlc.sun.com.edgesuite.net/glassfish/3.2/promoted/
Hopefully that fix your problem as well.

Comment by Anissa Lam [ 11/Apr/11 ]

I am marking this bug resolved as his is reporting the same problem as in GLASSFISH-16223.
Using the application given to me by the submitter of GLASSFISH-16223, I verified that the issue is fixed after I convert the code to use REST for application deployment.

This is fixed in both 3.1.1 b01 and 3.2 b01 as fix checked in before the 3.1.1 branch get created.





[GLASSFISH-16109] get-health command not showing rejoins Created: 28/Feb/11  Updated: 14/Mar/12  Resolved: 29/Mar/11

Status: Resolved
Project: glassfish
Component/s: group_management_service
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01, 4.0_b37

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

Issue Links:
Dependency
depends on SHOAL-116 rejoin subevent is null in JoinedAndR... Closed
Tags: 3_1-next

 Description   

When a rejoin event happens (an instance fails and restarts before GF knows it has failed), the status for it in 'asadmin get-health' shows started instead of rejoined. This is happening because the rejoin subevent is null in the JoinedAndReadyNotificationSignal. Am filing this for GF integration and will file a more technical one against Shoal to get the fix in.

This is a minor issue now because instances probably won't restart this quickly. But it would be good to get the fix in. To cause this, here's a snippet of domain.xml that leads to an absurdly long time to kill/restart an instance:

<group-management-service>
<failure-detection
heartbeat-frequency-in-millis="1800000"
max-missed-heartbeats="30"></failure-detection>
</group-management-service>



 Comments   
Comment by Bobby Bissett [ 28/Feb/11 ]

Adding dependency.

Comment by Bobby Bissett [ 02/Mar/11 ]

This has been fixed in the shoal workspace and will be in the next integration of shoal into glassfish.

Comment by Bobby Bissett [ 29/Mar/11 ]

Fixed in revision 45770.





[GLASSFISH-16108] validate-multicast tool can give duplicate results Created: 28/Feb/11  Updated: 14/Mar/12  Resolved: 29/Mar/11

Status: Resolved
Project: glassfish
Component/s: group_management_service
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01, 4.0_b37

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

Issue Links:
Dependency
depends on SHOAL-115 MultiCastReceiverThread is not cleari... Resolved
Tags: 3_1-next

 Description   

When running the "asadmin validate-multicast" command, there can be duplicate entries shown so that a host shows up more than once. For instance:

Received data from myhost (loopback)
Received data from someotherhost
Received data from myhost

'myhost' appears twice, when it should only be there once. This is a minor issue, and is due to a bug in the gms code that does not clear out the data buffer between receive() calls on the socket. If you run the tool with the --verbose option, you can see the full messages that are being received that cause the duplicate entries.

What's important is that the host name shows up at all, not how many times it shows up. But this could cause confusion with users (it confused me).



 Comments   
Comment by Bobby Bissett [ 28/Feb/11 ]

Adding a dependency to the Shoal issue. Will fix in trunk there and integrate into GF with another Shoal promotion.

Comment by Bobby Bissett [ 03/Mar/11 ]

This is now fixed in the Shoal workspace and will be in the next Shoal integration into GlassFish.

Comment by Bobby Bissett [ 29/Mar/11 ]

Fixed in revision 45770.





[GLASSFISH-16103] GMS fails to start on IPv6 only system Created: 25/Feb/11  Updated: 14/Mar/12  Resolved: 20/Apr/11

Status: Resolved
Project: glassfish
Component/s: group_management_service
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01, 4.0_b37

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

Oracle Enterprise Linux 5, with an IPv6-only stack. The ifconfig output is below. Note that
the eth0 interface is down but it is the first one listed.

  1. ifconfig -a
    eth0 Link encap:Ethernet HWaddr 00:09:3D:10:CF:C8
    BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
    Interrupt:185 Memory:fe810000-fe820000

eth1 Link encap:Ethernet HWaddr 00:09:3D:10:CF:C9
inet6 addr: fe80::209:3dff:fe10:cfc9/64 Scope:Link
inet6 addr: fc01::25/96 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:293292 errors:0 dropped:0 overruns:0 frame:0
TX packets:347212 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:228022244 (217.4 MiB) TX bytes:378699726 (361.1 MiB)
Interrupt:193 Memory:fe830000-fe840000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6863 errors:0 dropped:0 overruns:0 frame:0
TX packets:6863 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6932837 (6.6 MiB) TX bytes:6932837 (6.6 MiB)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)


Attachments: Java Archive File shoal-gms-impl.jar     File shoal.dif    
Tags: 3_1-exclude, 3_1-next

 Description   

To recreate the problem, create a cluster on an IPv6-only system with a single instance on another node. The cluster has to be created with the multicast address set as follows:

asadmin create-cluster --multicastaddress ff02::1 c1

Then restart the domain. The log will contain the following exception message:

[#|2011-02-24T22:43:19.510+0100|SEVERE|glassfish3.2|javax.org.glassfish.gms.org.glassfish.gms|_ThreadID=1;_ThreadName=Thread-1;|GMSAD1017: GMS failed to start. See stack trace for additional information.
com.sun.enterprise.ee.cms.core.GMSException: failed to join group c1
at com.sun.enterprise.ee.cms.impl.base.GMSContextImpl.join(GMSContextImpl.java:182)
at com.sun.enterprise.ee.cms.impl.common.GroupManagementServiceImpl.join(GroupManagementServiceImpl.java:381)
at org.glassfish.gms.GMSAdapterImpl.initializeGMS(GMSAdapterImpl.java:573)
at org.glassfish.gms.GMSAdapterImpl.initialize(GMSAdapterImpl.java:199)
at org.glassfish.gms.bootstrap.GMSAdapterService.loadModule(GMSAdapterService.java:218)
at org.glassfish.gms.bootstrap.GMSAdapterService.checkCluster(GMSAdapterService.java:192)
at org.glassfish.gms.bootstrap.GMSAdapterService.checkAllClusters(GMSAdapterService.java:180)
at org.glassfish.gms.bootstrap.GMSAdapterService.postConstruct(GMSAdapterService.java:132)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:243)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
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.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: com.sun.enterprise.ee.cms.core.GMSException: initialization failure
at com.sun.enterprise.mgmt.ClusterManager.<init>(ClusterManager.java:142)
at com.sun.enterprise.ee.cms.impl.base.GroupCommunicationProviderImpl.initializeGroupCommunicationProvider(GroupCommunicationProviderImpl.java:164)
at com.sun.enterprise.ee.cms.impl.base.GMSContextImpl.join(GMSContextImpl.java:176)
... 23 more
Caused by: java.net.SocketException: Cannot assign requested address
at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:506)
at com.sun.enterprise.mgmt.transport.BlockingIOMulticastSender.start(BlockingIOMulticastSender.java:165)
at com.sun.enterprise.mgmt.transport.grizzly.GrizzlyNetworkManager.start(GrizzlyNetworkManager.java:434)
at com.sun.enterprise.mgmt.ClusterManager.<init>(ClusterManager.java:140)
... 25 more

#]

The exception message persists even if the bind address is set to variables different values: the IPv6 site scope address, the IPv6 link scope address.

A shoal-gms-impl.jar file that fixes the problem, with the diffs is attached. Just put this JAR file into the glassfish/modules directory and GMS works fine on an IPv6-only system.

It is still unknown as to whether the existence of the eth0 that is disabled or the sit0 interfaces have anything to do with this problem, or whether there is some other IPv6 configuration change that could be made to workaround this problem. The problem does not show up on a dual stack system that uses both IPv4 and IPv6.

There are several Java problems related to multicast sockets and IPv6 reported in the past. The one that seems most relevant to this issue is:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6262075

The enclosed patch works around the issue by calling MulticastSocket.setInterface() instead of
setNetworkInteface and we are explicitly checking if network interface is considered UP before using it.



 Comments   
Comment by Joe Fialli [ 25/Feb/11 ]

Checked fix into shoal trunk.

Still needs to be integrated into glassfish 3.1.

Comment by Bobby Bissett [ 20/Apr/11 ]

This was integrated into GF in revision 45770 (before 3.1.1 branch created).





[GLASSFISH-16099] [patch] NPE in UniformLogFormatter when trying to log collections/maps with null values/keys Created: 24/Feb/11  Updated: 10/Apr/11  Resolved: 10/Apr/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

Attachments: Text File UniformLogFormatter-null.patch    
Tags: 3_1-next

 Description   

When trying to log some message with parameters which in turn contain null values/keys the UniformLogFormatter class throws a NPE because it doesn't handle such situations:

java.lang.NullPointerException
at com.sun.enterprise.server.logging.UniformLogFormatter.getNameValuePairs(UniformLogFormatter.java:208)
at com.sun.enterprise.server.logging.UniformLogFormatter.uniformLogFormat(UniformLogFormatter.java:276)
at com.sun.enterprise.server.logging.UniformLogFormatter.format(UniformLogFormatter.java:161)
at java.util.logging.StreamHandler.publish(StreamHandler.java:179)
at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)
at java.util.logging.Logger.log(Logger.java:458)

The attached patch (against SVN rev. 45202) fixes this problem.



 Comments   
Comment by naman_mehta [ 24/Feb/11 ]

I will verify and plan to check-in the same.

Comment by chaoslayer [ 25/Feb/11 ]

So, this will not make it into 3.1?

Comment by naman_mehta [ 25/Feb/11 ]

Right now 3.1 branch is closed so we can make it patch for 3.1. But it will be check-in in the 3.2 by monday.

Comment by chaoslayer [ 25/Feb/11 ]

OK, so how do we get those patches if we want to use a version build from upstream (=you)?

Or is this then scheduled for inclusion to a patch release?

Comment by naman_mehta [ 27/Feb/11 ]

It would be added in next patch.

Comment by naman_mehta [ 24/Mar/11 ]

Made changes required for the same. Bug is fixed now.

Comment by ancoron [ 25/Mar/11 ]

Which revision?

Comment by naman_mehta [ 25/Mar/11 ]

Right now you can find in latest nightly build and soon it will be part of 3.1 next release.





[GLASSFISH-16098] Incorrect assignment of orderingList in WebModule Created: 24/Feb/11  Updated: 07/Apr/11  Resolved: 24/Feb/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 3.1.1_b01

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


 Description   

In web/web-glue/src/main/java/com/sun/enterprise/web/WebModule.java, we have
List<String> orderingList = null;
....
AbsoluteOrderingDescriptor aod =
webBundleDescriptor.getAbsoluteOrderingDescriptor();
if (aod != null) {
orderingList = aod.getOrdering();

Note that aod.getOrdering() is a list may contain Object.



 Comments   
Comment by Shing Wai Chan [ 24/Feb/11 ]

Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/AbsoluteOrderingDescriptor.java
Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/node/web/AbsoluteOrderingNode.java
Sending web/war-util/src/main/java/org/glassfish/web/loader/ServletContainerInitializerUtil.java
Sending web/web-core/src/main/java/org/apache/catalina/Context.java
Sending web/web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/TomcatDeploymentConfig.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebModule.java
Transmitting file data .......
Committed revision 45250.





[GLASSFISH-16087] console login fails with ConnectException if admin-listener is bound to a specific address Created: 23/Feb/11  Updated: 16/Jul/11  Resolved: 23/Feb/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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


 Description   

If the admin-listener network listener address is changed to point to a specific IP address, then one can no longer use the admin console (it freezes on the console loading page), and the exception shown below is output to the log. Here is an example admin-listener network listener element in the domain.xml file:

<network-listener port="4848" protocol="admin-listener" address="adc2180966.us.oracle.com" transport="tcp" name="admin-listener" thread-pool="admin-thread-pool"></network-listener>

To recreate the problem:

1. edit the domain.xml to have a specific address
2. start the domain
3. access port 4848 (the console)

At this point, the browser will just stay on the console loading page, and the exception can be found in the log.

Adding an additional listener that listens on localhost:4848 changes the behavior. Instead of freezing, you get the login page, but you cannot login, and there are no exceptions. So it seems that something is trying to connect to localhost.

[#|2011-02-23T12:45:50.889-0800|WARNING|glassfish3.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=91;_ThreadName=Thread-1;|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw exception
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
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.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:244)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:204)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:1171)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1328)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1206)
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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.reflect.InvocationTargetException
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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:459)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:659)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java:184)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(RestApiHandlers.java:210)
... 50 more
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:233)
at sun.net.www.http.HttpClient.New(HttpClient.java:306)
at sun.net.www.http.HttpClient.New(HttpClient.java:323)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:975)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:916)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
... 57 more

#]


 Comments   
Comment by Anissa Lam [ 23/Feb/11 ]

When i add the address attribute, I can't get to the loading page or the login page. The browser can't establish a connection.
I can't get to REST either.
Can you access REST after adding the address attribute ?

Comment by Tom Mueller [ 23/Feb/11 ]

Yes, the REST interface works fine. What address did you use? You should use the address that you normally use to login to the system.

Comment by Jason Lee [ 23/Feb/11 ]

I can confirm that REST works, but I never get the console login screen.

Comment by Anissa Lam [ 23/Feb/11 ]

I WFH today, and connect using VPN, my hostname becomes something like "dhcp-whq-twvpn-.......oracle.com" and thats what i put in the address field. I am not getting anywhere with this specified.

Comment by Jason Lee [ 23/Feb/11 ]

I think the culprit is this line in domain.xml:

<property name="restAuthURL" value="http://localhost:$

{ADMIN_LISTENER_PORT}/management/sessions"></property>

You can work around this for now by issuing this command:

asadmin --host $NEWHOST set configs.config.server-config.security-service.message-security-config.HttpServlet.provider-config.GFConsoleAuthModule.property.restAuthURL="http://$NEWHOST:\${ADMIN_LISTENER_PORT}

/management/sessions"

I'll see if I can find a better to handle that.

Comment by Tom Mueller [ 23/Feb/11 ]

Confirmed that when I replace "localhost" with the same name as is used with the admin-listener, then the admin console comes up fine.

Comment by Jason Lee [ 23/Feb/11 ]

I just committed a fix to trunk (r45246) that should address this issue without the property change workaround. My tests locally showed the issue is resolved.

Comment by walec51 [ 16/Jul/11 ]

Reopen this bug.

Got the exact same error with glassfish-3.1.1-b11

I using Debian 64 git and OpenJDK:

OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-2~lenny1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

I remember that 3.0.1 had problems this JSF under OpenJDK too.

Comment by walec51 [ 16/Jul/11 ]

PS. I can't login even if the address attribute is set or not

Comment by walec51 [ 16/Jul/11 ]

However my stack trace is a little different:

[#|2011-07-16T17:07:55.400+0200|WARNING|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=24;_ThreadName=Thread-2;|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw exception
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
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.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:247)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:231)
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 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:636)
Caused by: java.lang.reflect.InvocationTargetException
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:616)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: java.lang.UnsupportedOperationException: Cannot create XMLStreamReader or XMLEventReader from a javax.xml.transform.stream.StreamSource
at com.sun.xml.internal.stream.XMLInputFactoryImpl.jaxpSourcetoXMLInputSource(XMLInputFactoryImpl.java:283)
at com.sun.xml.internal.stream.XMLInputFactoryImpl.createXMLStreamReader(XMLInputFactoryImpl.java:143)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:115)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:110)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:106)
at org.glassfish.admingui.plugin.ConsolePluginService.init(ConsolePluginService.java:126)
at org.glassfish.admingui.plugin.ConsolePluginService.getIntegrationPoints(ConsolePluginService.java:428)
at org.glassfish.admingui.common.handlers.PluginHandlers.getIntegrationPoints(PluginHandlers.java:164)
at org.glassfish.admingui.handlers.ThemeHandlers.getThemeFromIntegrationPoints(ThemeHandlers.java:102)
... 50 more

Comment by walec51 [ 16/Jul/11 ]

A workaround is to install Sun's JVM and JDK:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)

I would really hope the Glassfish team would test on OpenJDK.
We should move to OpenJDK after the acquisition of Sun right ?
Is OpenJDK on the focus of Oracle or will it keep releasing SunJDK ?





[GLASSFISH-16081] [patch] Make system property 'com.sun.aas.instanceRoot' work Created: 23/Feb/11  Updated: 07/Apr/11  Resolved: 23/Feb/11

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

Attachments: Text File domain-dir.patch    
Tags: 3_1-next

 Description   

When starting GlassFish inside some existing OSGi environment using the main bundle "glassfish.jar" the system property "com.sun.aas.instanceRoot" is not being picked up.

The attached patch (against SVN rev. 45202) does fix this problem.



 Comments   
Comment by Sanjeeb Sahoo [ 23/Feb/11 ]

Committed to trunk:
Sending core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/GlassFishMainActivator.java
Transmitting file data .
Committed revision 45232.

It seems if we tag the bug with 3_1-next, we will be reminded about backporting in 3.1 maintenance branch. I have done so.

Comment by ancoron [ 23/Feb/11 ]

Thanx a lot.





[GLASSFISH-16073] GMS1077 gms total message size is too big (default max is 4MB) is repeated in server log Created: 22/Feb/11  Updated: 14/Mar/12  Resolved: 20/Apr/11

Status: Resolved
Project: glassfish
Component/s: group_management_service
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01, 4.0_b37

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

Tags: 3-1_exclude, 3_1-next

 Description   

An attempt to send a message larger than GMS max message size results in repeated reporting of the WARNING
in server.log.

Here is sample message:
[#|2011-02-22T17:06:00.412-0500|WARNING|glassfish3.1|ShoalLogger|_ThreadID=24;_ThreadName=Thread-1;|GMS1077: total message size is too big: size = 12,584,300, max size = 4,196,352|#]

[#|2011-02-22T17:06:00.548-0500|WARNING|glassfish3.1|ShoalLogger|_ThreadID=32;_ThreadName=Thread-1;|GMS1077: total message size is too big: size = 12,584,366, max size = 4,196,352|#]

************************************

WORKAROUND:

A workaround exists if the default max gms message size is too small.
To create a cluster with a larger max message size, use the following command:

% asadmin create-cluster --properties "GMS_MAX_MESSAGE_LENGTH=8200000" theClusterName

****

To increase the max message size for an already created cluster, use the following command with cluster running.

$ asadmin set clusters.cluster.myCluster.property.GMS_MAX_MESSAGE_LENGTH=8200000
clusters.cluster.myCluster.property.GMS_MAX_MESSAGE_LENGTH=81200000
Command set executed successfully.

After setting the value, stop the cluster and DAS domain, then restart the DAS and the cluster with the new settings.



 Comments   
Comment by Joe Fialli [ 22/Feb/11 ]

Fix is already known for this issue and is checked into shoal gms trunk.

Comment by Bobby Bissett [ 20/Apr/11 ]

This was integrated into GF in rev 45770 (before 3.1.1 branch was created).





[GLASSFISH-16059] failure while processing resource-type of a resource-ref in an application that uses a resource-adapter artifact on non-DAS target Created: 21/Feb/11  Updated: 02/Dec/11  Resolved: 03/Mar/11

Status: Resolved
Project: glassfish
Component/s: naming
Affects Version/s: 4.0
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-exclude

 Description   

1) Deploy the resource-adapter to the instance
2) Create pool and resource with "target" as the instance
3) Deploy the application that uses the resources of the
resource-adapter to the instance.
[This will fail in DAS as there seem to be some processing happening in
DAS though the target is "instance"]

Exact failure is due to EjbBundleValidator making sure that the
resource-type of the resource-ref specified is valid.
[Refer EJBBundleValidator calling "resRef.checkType()" in the method
"accept()" ]

Above check will fail in DAS as the resource-adapter is not enabled (and
hence not available for the classloader hierarchy).

Workaround would be to deploy the resource-adapter and the application that uses the resource-adapter in DAS and then create application-ref in appropriate targets.



 Comments   
Comment by Hong Zhang [ 28/Feb/11 ]

This is related to my fix to
http://java.net/jira/browse/GLASSFISH-15058

Seems we should invoke the validation in the naming code like in v2 where the resource is actually being used (looked up).

Assign to Cheng to take a look.

Comment by Cheng Fang [ 03/Mar/11 ]

Sending common/container-common/src/main/java/com/sun/enterprise/container/common/impl/ComponentEnvManagerImpl.java
Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/EnvironmentProperty.java
Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/JmsDestinationReferenceDescriptor.java
Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/util/EjbBundleValidator.java
Committed revision 45383.

I've moved the checkType from EjbBundleValidator to ComponentEnvManagerImpl,
which is roughly the equivalent as in v2.
I also added the same checkType for res-env-ref to be consistent with resource-ref.

I tested with invalid res-ref-type and res-env-ref-type (as in issue 15058), and either one will cause the deployment to fail with the correct exception and error message.

Jagadish tested with the resource adapter (thanks!) with the following comments:
<quote>
I tried with the resource-adapter that I was using before. It works fine
now. ie., even though the RAR (and the resource) are not available in DAS,
deployment works fine with your fix.
If I dont have the RAR available in the instance and try to deploy
the .ear that uses the resource of RAR, it fails as expected.
</quote>





[GLASSFISH-16058] Deviation from servlet3 spec in ServletContext implementation (getResourcePaths()) Created: 21/Feb/11  Updated: 07/Apr/11  Resolved: 08/Mar/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: v3.0.1
Fix Version/s: 3.1.1_b01

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

ubuntu 10


Attachments: Zip Archive servlet3-web-fragment-static-resources-bugreport-src.zip    

 Description   

Hi!

I'm writing you from ZeroTurnaround and we are currently building JRebel
integration with new containers aiming to implement the servlet3 standard. I've
stumbled on a bug in your implementation that is actually at the very core of
the servlet standard and thus quite important, and actually a major issue for
our integration.

(FYI: I already made this same report for Tomcat7.. I'm not sure if Tomcat7 and Glassfish 3 containers share some base libraries for this functionality, but mentioning it just in case. Anyway, Tomcat7 guys told me that they had fixed this issue in tomcat trunk and it will be ok in next release.)

Namely, i'm copy-pasting you a fragment of the reference javadoc of the
servlet3 spec for the method ServletContext#getResourcePaths():

============= SPEC START =================

For example, for a web application containing:

/welcome.html
/catalog/index.html
/catalog/products.html
/catalog/offers/books.html
/catalog/offers/music.html
/customer/login.jsp
/WEB-INF/web.xml
/WEB-INF/classes/com.acme.OrderServlet.class
/WEB-INF/lib/catalog.jar!/META-INF/resources/catalog/moreOffers/books.html

getResourcePaths("/") would return

{"/welcome.html", "/catalog/", "/customer/", "/WEB-INF/"}

, and getResourcePaths("/catalog/") would return

{"/catalog/index.html", "/catalog/products.html", "/catalog/offers/", "/catalog/moreOffers/"}

.

============= SPEC END =================

Now run my attached test-application, you'll discover immediately that Glassfish3.0.1 doesn't
respect that standard. getResourcesPath("/catalog") would not return
"/catalog/moreOffers" if there were 2 embedded jars containing web-fragments.
And even more importantly, had there been a new folder coming solely from a
jar's META-INF/resources, this wouldn't get listed with getResourcePaths("/").

Please note that these are important issues! Many frameworks rely on various
scanning techniques for recursive resource lookup, and so forth. This bug basically
breaks any resource lookup using recursive calls to getResourcesPath()..
not good at all (

I've tested this thing with Glassfishv3.0.1. Not sure if it might be fixed already in the trunk.

Thanks a lot if you can have a look at this!



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

assign to shingwai for evaluation

Comment by Shing Wai Chan [ 22/Feb/11 ]

If we create the war file structure as described in spec (and quote above), then we have the following in 3.1:

getResourcePaths("/") : //catalog/, /welcome.html, /catalog/, /WEB-INF/, /customer/
getResourcePaths("/catalog/") : /catalog/offers/, /catalog/products.html, /catalog//moreOffers/, /catalog/index.html
getResourcePaths("/catalog") : /catalog/offers/, /catalog/moreOffers/, /catalog/products.html, /catalog/index.html

So, we do have /catalog/moreOffers there.
But there are issues as we have extra "/" in "//catalog/" and "/catalog//moreOffers/".

Comment by Shing Wai Chan [ 22/Feb/11 ]

I have a local fix for extra "/" issue.
But there is an additional issue as follows:
Suppose we have /catalog/bookcatalog.html in one of the web-fragment jar, then it is not visible through getResourcePaths("/catalog") now. Need further investigation.

Comment by Shing Wai Chan [ 22/Feb/11 ]

The fix for extra "/" has been committed as follows:

Sending src/main/java/org/apache/catalina/core/StandardContext.java
Transmitting file data .
Committed revision 45217.

Comment by Shing Wai Chan [ 08/Mar/11 ]

Sending web/war-util/src/main/java/org/glassfish/web/loader/WebappClassLoader.java
Sending web/web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Transmitting file data ..
Committed revision 45436.

Comment by Shing Wai Chan [ 08/Mar/11 ]

add test case
Adding multiWebFragmentsResources
Adding multiWebFragmentsResources/WebTest.java
Adding multiWebFragmentsResources/build.properties
Adding multiWebFragmentsResources/build.xml
Adding multiWebFragmentsResources/descriptor
Adding multiWebFragmentsResources/descriptor/web-fragment.xml
Adding multiWebFragmentsResources/docroot
Adding multiWebFragmentsResources/docroot/catalog
Adding multiWebFragmentsResources/docroot/catalog/index.html
Adding multiWebFragmentsResources/docroot/catalog/offers
Adding multiWebFragmentsResources/docroot/catalog/offers/books.html
Adding multiWebFragmentsResources/docroot/catalog/offers/music.html
Adding multiWebFragmentsResources/docroot/catalog/products.html
Adding multiWebFragmentsResources/docroot/customer
Adding multiWebFragmentsResources/docroot/customer/login.jsp
Adding multiWebFragmentsResources/docroot/index.jsp
Adding multiWebFragmentsResources/resources
Adding multiWebFragmentsResources/resources/for_fr2_jar
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources/catalog
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources/catalog/another.html
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources/catalog/moreOffers
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources/catalog/moreOffers/books.html
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources/catalog/moreOffers/music.html
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources/catalog/moreOffers2
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources/catalog/moreOffers2/cars.html
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources/catalog2
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources/catalog2/moreOffers
Adding multiWebFragmentsResources/resources/for_fr2_jar/META-INF/resources/catalog2/moreOffers/books.html
Adding multiWebFragmentsResources/resources/for_fr_jar
Adding multiWebFragmentsResources/resources/for_fr_jar/META-INF
Adding multiWebFragmentsResources/resources/for_fr_jar/META-INF/resources
Adding multiWebFragmentsResources/resources/for_fr_jar/META-INF/resources/catalog
Adding multiWebFragmentsResources/resources/for_fr_jar/META-INF/resources/catalog/moreOffers
Adding multiWebFragmentsResources/resources/for_fr_jar/META-INF/resources/catalog/moreOffers/books.html
Adding multiWebFragmentsResources/resources/for_fr_jar/META-INF/resources/catalog2
Transmitting file data ................
Committed revision 45437.





[GLASSFISH-16057] Log Levels set for GF Handler is not working on start up. Created: 21/Feb/11  Updated: 02/Dec/11  Resolved: 10/Apr/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 4.0
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-next

 Description   

If user reduce the log level for GF Handler 'SEVERE' it will not log any log messages rather than 'SEVERE'.

But in current GF release it's not working need to fix this in next release.



 Comments   
Comment by naman_mehta [ 05/Apr/11 ]

Fixed this issue. Added properties in logging templates which allows user to set log levels for the same and start up code will consider the same.





[GLASSFISH-16048] Application info page: status not show correctly and virtual servers changes not saved. Created: 18/Feb/11  Updated: 22/Jun/11  Resolved: 18/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

Issue Links:
Duplicate
is duplicated by GLASSFISH-16054 Regression: Status showed incorrectly... Resolved
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

I just notice 2 issues in application information page after application is deployed.
This only occurs in DAS ONLY environment.

  • The status checkbox is always unchecked regardless whether the application is enabled or disabled. The display is wrong.
  • Changing the list of virtual servers is not persisted.

The display for the status was not correct is a regression i introduced when fixing GLASSFISH-15848.
Not able to save the virtual servers is due to the capitalization of the attribute variable. I believe the issue has been there for a while.



 Comments   
Comment by Anissa Lam [ 18/Feb/11 ]

The issue has been fixed in the trunk,

Sending appEdit.layout
Transmitting file data .
Committed revision 45179.
==================

We want to release note this to provide a workaround for user.
User will only see this issue when there is NO clusters or standalone instances created in the domain.

  • For the status of the application, always look at the applications table that lists out the applications. The status is correctly displayed there, and user can use this table to change the status as well.
  • To change the virtual server for the deployed application, use the CLI set command.

use the following CLI to see the info:

%asadmin get server.application-ref.<APPLICATION_NAME>.*

and set command to change the list of virtual servers for this application.

%asadmin set server.application-ref.<APPLICATION_NAME>.virtual-servers=<list-of-vs-separated-by-comman>

example of get :
%asadmin get server.application-ref.hello

examples of set:
%asadmin set server.application-ref.hello.virtual-servers=server,myVS
or
%asadmin set server.application-ref.hello.virtual-servers=myVS

Comment by Anissa Lam [ 18/Feb/11 ]

Fixed in the trunk.

Comment by Scott Fordin [ 12/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by shaline [ 22/Jun/11 ]

Verified on promoted b08.





[GLASSFISH-16047] [asadmin][IPv6] asadmin cannot connect to instance only listening to IPv6 loopback address Created: 18/Feb/11  Updated: 07/Apr/11  Resolved: 25/Feb/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b33, 3.1_b36, 3.1_b41
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-exclude, 3_1-ipv6

 Description   

I just wanted to "secure" a system by making GlassFish listening only to loopback interfaces. So I specified this:

<network-listener address="::1" port="4848" protocol="admin-listener" transport="tcp" name="admin-listener" thread-pool="admin-thread-pool"></network-listener>

The server starts up fine:

$ sudo netstat -tunlp | grep '21064/java' | sort
tcp6 0 0 127.0.0.1:8009 :::* LISTEN 21064/java
tcp6 0 0 ::1:3700 :::* LISTEN 21064/java
tcp6 0 0 ::1:4848 :::* LISTEN 21064/java
tcp6 0 0 ::1:6666 :::* LISTEN 21064/java
tcp6 0 0 ::1:7676 :::* LISTEN 21064/java
tcp6 0 0 ::1:8080 :::* LISTEN 21064/java
tcp6 0 0 ::1:8181 :::* LISTEN 21064/java
tcp6 0 0 ::1:8686 :::* LISTEN 21064/java
tcp6 0 0 :::33879 :::* LISTEN 21064/java
tcp6 0 0 :::3820 :::* LISTEN 21064/java
tcp6 0 0 :::3920 :::* LISTEN 21064/java
tcp6 0 0 :::43292 :::* LISTEN 21064/java
tcp6 0 0 :::54610 :::* LISTEN 21064/java
tcp6 0 0 :::56570 :::* LISTEN 21064/java

...however, I cannot stop it or access it otherwise:

$ ./bin/asadmin list-domains
domain1 not running
Command list-domains executed successfully.
$ ./bin/asadmin stop-domain domain1
CLI306 Warning - server is not running.
Command stop-domain executed successfully.



 Comments   
Comment by Tom Mueller [ 18/Feb/11 ]

The default value for the asadmin --host option is "localhost", i.e., the IPv4 localhost. If the DAS is not running on localhost, then it is required to provide the host option when running stop-domain. The following works:

asadmin --host '[::1]' stop-domain

The reason for needing the square brackets ([]) is because the host value is used in a URL (see below for more on this). Or, if you have an /etc/hosts entry for the IPv6 localhost, such as:

::1 localhost-ipv6

then the following command will work:

asadmin --host localhost-ipv6 stop-domain

If the /etc/hosts localhost entry is changed to ::1 for the system, then the regular asadmin stop-domain command will work.

There are two bugs here though.

1) The admin URL for any IPv6 literal IP address is being constructed incorrectly in the HttpConnectorAddress.getAuthority method. This method is not following RFC-2732 (http://www.ietf.org/rfc/rfc2732.txt) which requires square braces around a literal IPv6 address in a URL. I'm not sure why this class isn't using the URL class to construct the URL.

2) The list-domains subcommand isn't detecting that the domain is running, but it should. The root cause of this is actually the same as problem (1) in that list-domains extracts the admin address from the domain and passes it to the _get-restart-required command, but the address that is passed is ::1.

The list-domaims command can be made to work by define a name for ::1, such as localhost-ipv6, and using that name in the domain.xml rather than ::1.

Actually, this makes stop-domain work without having to specify the host option too.

Comment by chaoslayer [ 18/Feb/11 ]

Ah, thanx.

I'll see if those workarounds can be established on our systems.

Comment by Tom Mueller [ 25/Feb/11 ]

Fixed on the trunk in revision 45280.





[GLASSFISH-16044] appclient in cygwin passing extra empty string Created: 17/Feb/11  Updated: 07/Apr/11  Resolved: 30/Mar/11

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

Windows, Cygwin


Attachments: File AppClientTest.ear     Java Archive File AppClientTestClient.jar    
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1windows

 Description   

When running appclient on a windows machine with cygwin, the appclient is passing an extra empty String to the program arguments.

But when running on command line in windows doesnt show that problem.

See below:

Linux run:
===========
sreekanth@spidy:~/NetBeansProjects/AppClientTest$ asadmin deploy --retrieve dist --force=true dist/AppClientTest.ear
Authentication failed with password from login store: /home/sreekanth/.asadminpass
Enter admin password for user "admin">
Application deployed with name AppClientTest.
Command deploy executed successfully.
sreekanth@spidy:~/NetBeansProjects/AppClientTest$ appclient -client dist/AppClientTestClient.jar Arguments length is :0
sreekanth@spidy:~/NetBeansProjects/AppClientTest$

Window Run:
===========

aroot@bigapp-x2250-1 /cygdrive/c/ha/tmp-sree
$ /cygdrive/c/ha/glassfish3/glassfish/bin/asadmin deploy --retrieve . --force=true AppClientTest.ear
Application deployed with name AppClientTest.
Command deploy executed successfully.

aroot@bigapp-x2250-1 /cygdrive/c/ha/tmp-sree
$ /cygdrive/c/ha/glassfish3/glassfish/bin/appclient -client AppClientTestClient.jar
Arguments length is :1



 Comments   
Comment by Tim Quinn [ 18/Feb/11 ]

Sreekanth,

Please contact me directly via e-mail so I can arrange to investigate this on your system.
Thanks.

Comment by Tim Quinn [ 20/Feb/11 ]

I have reproduced this issue on a Windows system with cygwin installed.

Investigating.

Comment by Tim Quinn [ 21/Feb/11 ]

We are excluding this from 3.1.

It seems to be due to an interaction between the way the CLIBootstrap class generates the java command for launching the app client and how the cygwin shell parses the command into arguments. There is currently a trailing blank in the generated command line. This is not an issue in other environments, but cygwin in this case seems to treat the blank as a separator in front of an empty argument.

Users who have app clients that process a variable number of arguments and run those clients on Windows using cygwin should be aware of this issue. One workaround would be to make sure the client deals correctly with an empty argument.

Comment by Tim Quinn [ 14/Mar/11 ]

Release notes info:

Summary: Using cygwin on Windows, the app client container (ACC) passes an extra empty-string argument to the client's main method. This might result in the app client throwing an index-out-of-range exception if the client does not guard itself against empty argument values.

Workarounds (reiterating from the Feb. 21. comment):
1. If your client works with a variable number of arguments make sure that it protects itself against empty argument values.

2. Avoid using cygwin on Windows for clients that cannot be made to guard against an empty argument value.

Comment by Tim Quinn [ 17/Mar/11 ]

Fix checked in:

Project: glassfish
Repository: svn
Revision: 45605
Author: tjquinn
Date: 2011-03-17 18:03:10 UTC
Link:

Log Message:
------------
Fix for 16044

Under cygwin on Windows, a trailing blank on the generated java command line was parsed as an empty additional command-line argument and passed as such to the client.

This change causes the generated java command to no longer contain an extra trailing blank.

Tests: QL, deployment devtests, cygwin on Windows test

Revisions:
----------
45605

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java

Comment by Tim Quinn [ 24/Mar/11 ]

The earlier fix causes problems when the user enters JVM options on the appclient command line. There is a missing space between the user-provided JVM options and some JVM options which CLIBootstrap adds to the generated java command line.

Comment by Scott Fordin [ 24/Mar/11 ]

Added topic to 3.1 Release Notes. Added "release note added" tag.

Comment by Tim Quinn [ 30/Mar/11 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 45773
Author: tjquinn
Date: 2011-03-30 15:57:40 UTC
Link:

Log Message:
------------
Additional refinement for fix to 16044

This change resolves a problem in which user-specified JVM options were not separated from other options by a space. It also cleans up the earlier fix logic a bit and adds some javadoc for some methods.

Tests: QL, deployment devtests, cygwin on Windows test

Revisions:
----------
45773

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java





[GLASSFISH-16041] remove sun.com urls Created: 17/Feb/11  Updated: 07/Apr/11  Resolved: 22/Mar/11

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: Nazrul Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude

 Description   

[Tracking Bug]

We currently have the following sun.com urls in GlassFish 3.1 distribution. Please update them in the trunk for 3.2 when oracle.com urls are available.

Full:
http://pkg.sun.com/javaeesdk/6/release/
http://pkg.sun.com/glassfish/v3/contrib/

Web Profile:
http://pkg.sun.com/javaeesdk/6/release/
http://pkg.sun.com/glassfish/v3/contrib/



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 22/Mar/11 ]

Fix checked into trunk as SVN r45662.





[GLASSFISH-16037] create-jvm-options subcommand options incorrectly parsed by asadmin Created: 17/Feb/11  Updated: 07/Apr/11  Resolved: 18/Feb/11

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1_b38
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

The asadmin utility is incorrectly interpreting options of the create-jvm-options subcommand as asadmin utility options. As a result, an attempt to create an option, for example -Xrs, fails:

asadmin> create-jvm-options -Xrs
Non-boolean option: X, not allowed in argument: -Xrs
Usage: asadmin [-H|--host <host(default:localhost)>]
[-p|--port <port(default:4848)>] [-u|--user <user(default:admin)>]
[-W|--passwordfile <passwordfile>]
[t|-terse[=<terse(default:false)>]]
[s|-secure[=<secure(default:false)>]]
[e|-echo[=<echo(default:false)>]]
[I|-interactive[=<interactive(default:true)>]]
[?|-help[=<help(default:false)>]]
create-jvm-options [command-specific options]
Command create-jvm-options failed.

The usage message appears to be in the style of a v2 usage message. In GlasFish 3, asadmin utility options are not provided in the usage message.

To workaround this problem, run the create-jvm-options command in single mode specifying at least one asadmin utility option, for example:

dashost$ asadmin --host dashost create-jvm-options -Xrs
Created 1 option(s)
Command create-jvm-options executed successfully.



 Comments   
Comment by Bill Shannon [ 18/Feb/11 ]

Missed one case in the special cases for commands that treat unknown
options as operands.

Also, some asadmin hidden commands had short option names, which was
further confusing things. I'm removing the short names for the hidden
options.

Comment by Scott Fordin [ 24/Mar/11 ]

Added topic to 3.1 Release Notes. Added "release note added" tag.





[GLASSFISH-16035] In b43 - WebServices Samples in javaee SDK fail to deploy Created: 17/Feb/11  Updated: 19/May/11  Resolved: 19/May/11

Status: Resolved
Project: glassfish
Component/s: sample_apps
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Critical
Reporter: Alex Pineda Assignee: ramapulavarthi
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 5 system 64 bit OS, Browser is Firefox 3.6.13, Build java_ee_sdk-6u2-b43-jdk-linux.sh. JDK 1.6.0_24 or JDK1.6.0_23 Linux.


Attachments: Text File GLASSFISH-16035.patch    
Tags: 3_1-exclude

 Description   

With build43 using SDK with Linux JDK, the Web Services samples fail to deploy. This problem was not seen on build41. Just verified to make sure. Nor the failures are seen with the latest jdk (JDK1.6.0_24)

The deployment failure is shown when invoking "ant all" in /glassfish3/glassfish/samples/javaee6/webservices/hello-singleton-ejb (as one example). The error is:

deploy:
[exec] Deprecated syntax, instead use:
[exec] asadmin --user admin --passwordfile /home/sqe/Workspace/glassfish3/glassfish/samples/bp-project/passwordfile --host localhost --port 4848 deploy [options] ...
[exec] Command deploy failed.
[exec] remote failure: Error occurred during deployment: Exception while deploying the app [hello-singleton-ejb] : com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor. Please see server.log for more details.

In the server.log, the following is displayed:
[#|2011-02-17T08:52:59.785-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=80;_ThreadName=Thread-1;|Exception while deploying the app [hello-singleton-ejb]|#]

[#|2011-02-17T08:52:59.786-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=80;_ThreadName=Thread-1;|com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor
java.lang.ClassCastException: com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor
at com.sun.enterprise.deployment.io.runtime.WLWebServicesDeploymentDescriptorFile.<init>(WLWebServicesDeploymentDescriptorFile.java:62)
at com.sun.enterprise.deployment.archivist.Archivist.writeWLWebServicesDescriptors(Archivist.java:1092)
at com.sun.enterprise.deployment.archivist.Archivist.writeWLRuntimeDeploymentDescriptors(Archivist.java:1034)
at com.sun.enterprise.deployment.archivist.Archivist.writeExtraDeploymentDescriptors(Archivist.java:1045)
at com.sun.enterprise.deployment.archivist.Archivist.writeDeploymentDescriptors(Archivist.java:961)
at com.sun.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:176)
at com.sun.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:83)
at org.glassfish.javaee.core.deployment.DolProvider.saveAppDescriptor(DolProvider.java:304)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:199)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:826)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:768)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2011-02-17T08:52:59.792-0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=80;_ThreadName=Thread-1;|Exception while deploying the app [hello-singleton-ejb] : com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor|#]

The steps to reproduce this issue are:

  • Install java_ee_sdk-6u2-b43-jdk-linux.sh
  • Insert the Glassfish Server location in the build.properties file under <GF_Dir>/samples/bp-project/build.properties (in my case, I set javaee.home=/Users/sqe/glassfish3/glassfish)
  • Start the server (asadmin start-domain)
  • Go to the singleton-ejb Web Services sample location (/Users/sqe/glassfish3/glassfish/samples/javaee6/webservices/hello-singleton-ejb)
  • Execute "ant all"
    The deployment failure is seen.

The same issue is seen on the other 2 WebServices samples - hello-jaxws2.2 and hello-webserviceref



 Comments   
Comment by Chris Kasso [ 17/Feb/11 ]

Alex, in the description you say: "Nor the failures are seen with the latest jdk (JDK1.6.0_24)".

Is this saying the failure is not seen with _24?

Have you tried these on other platforms?

Comment by Alex Pineda [ 17/Feb/11 ]

I can make the system available for debugging if required. Just contact me and I will provide the username/password on the machine.

And just to clarify. On build41 the samples work with JDK1.6.0_23 or JDK1.6.0_24.

Comment by Alex Pineda [ 17/Feb/11 ]

Have not tried on other platforms yet. I will do so later today (Win7 and OEL5).

Comment by scatari [ 17/Feb/11 ]

Alex,
Can u please try the following on the same machine?

-Install B41(SDK with JDK) on a different directory.

-Make B43 GlassFish binaries to point to B41's jdk by editing asenv.conf and setting JAVA_HOME and PATH.

-Run the tests on B43 binaries to see if you can reproduce. If you can, then this can be isolated to a potential issue in the new JDK drop.

Comment by Alex Pineda [ 17/Feb/11 ]

Scatari,

I did a similar experiment.
o I installed B41 SDK. I edited the asenv.conf file to point to B43's JDK and the sample deployed correctly.
o Also, I pointed B43 to my local (not B41's) JDK which is JDK1.6.0_23 and it failed to deploy.

Comment by Hong Zhang [ 17/Feb/11 ]

I am not sure why the cast exception will happen, Bhakti might have better idea. But the stack trace attached would only be triggered when the -Dwriteout.xml=true debug option is turned on (to write out generated deployment descriptor).
And when VNC into the test machine, I did see the problematic installation (/home/sqe/Workspace/glassfish3) has this jvm option.
<jvm-options>-Dwriteout.xml=true</jvm-options>
in the domain.xml.
And the installation that worked (/home/sqe/SDK/glassfish3) did not have this jvm-option set in the domain.xml.
This could possibly explain why one had problem and the other not. Please use the default setting (with no debug jvm-option) to run the test again to see if it makes a difference.
We should also try to figure out why we would have the stack trace when the debug option is turned on. But that's a less serious issue.

Comment by Alex Pineda [ 17/Feb/11 ]

Hong,

I will try your suggestion and comment out the jvm option in domain.xml and report back.

Comment by ramapulavarthi [ 18/Feb/11 ]

I reproduced the issue and its a bug in writing out the Web Services runtime descriptor when writeout.xml system property is set.
Attaching a patch for this issue.

Comment by ramapulavarthi [ 18/Feb/11 ]

Patch for the issue.

Comment by Alex Pineda [ 18/Feb/11 ]

Hong,

I commented out "<jvm-options>-Dwriteout.xml=true</jvm-options>" in domain.xml, and the sample deployed properly on the system. Thanks for the investigative work.

Comment by Hong Zhang [ 18/Feb/11 ]

Great, thanks Alex. So that mystery is now solved. We now just need to decide whether Rama's fix should make in 3.1 or not (it probably would not as the error just happen when the debug option is turned on).

Comment by Alex Pineda [ 18/Feb/11 ]

Thanks for clarifying about the fix. Be aware that I did not explicitly add this option to domain.xml. I installed the same on both installations. I'm going to try to figure out how his happened in my testing. I'll wait to hear about the fix.

Comment by Alex Pineda [ 18/Feb/11 ]

Removing the Regression label and tag as the test case does not insert a Debug option. In other words, this is not a regression as the test has not been, to my knowledge, been executed with a jvm debug option. It's still an issue, but not a regression.

Comment by ramapulavarthi [ 18/Feb/11 ]

I would like to understand if the test execution has enabled this debug option explicitly or the domain was created with this option by default. If it is the later, then we have an issue.

Comment by Alex Pineda [ 18/Feb/11 ]

I don't believe the Installer domain creation is inserting this option as evidenced by the fact that the new installation, provided as reference, does not show the debug option in domain.xml. The test case that I execute, does not insert this option either. My guess is that a previous test that I executed, did the insertion. I plan to investigate this further. In short, the installer does not insert this option by default. That is my conclusion at this point.

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

Correct - 'asadmin create-domain' does not create the domain with this option out of the box and this is true for all distributions. This had to be the artifact of the BAT test run.

Comment by Chris Kasso [ 18/Feb/11 ]

Based on the information we have this is not a stopper. Excluding it from 3.1.

Comment by ramapulavarthi [ 18/Feb/11 ]

Committed a fix to the trunk.

Log Message:
------------
GLASSFISH-16035: WLWebServicesDeploymentDescriptorFile expects only WebServicesDescriptor in the constructor.

Revisions:
----------
45182

Modified Paths:
---------------
trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/Archivist.java

Comment by ramapulavarthi [ 19/May/11 ]

Fixed in v3.1.1 as rev:45182





[GLASSFISH-16015] My JAX-RPC client app needs to be redeployed every time I restart GlassFish V3.1 Created: 16/Feb/11  Updated: 27/Apr/11  Resolved: 01/Mar/11

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

GlassFish 3.1 b43 on Windows XP


Attachments: Java Archive File deployment-javaee-core.jar    
Tags: 3_1_1-approved

 Description   

When I deploy a JAX-RPC client .war file to GlassFish I am able to use the application. When I restart GlassFish, I get the following exception when trying to use the JAX-RPC client. The only way I can resolve it is to undeploy then deploy the application, then restart GlassFish. If I don't restart GlassFish after redeploying then I still get the error. When I try using the "redeploy" feature in GlassFish, I seem to still have the problem.

[#|2011-02-16T17:33:44.378-0500|WARNING|glassfish3.1|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=93;_ThreadName=Thread-1;|
javax.xml.ws.WebServiceException: null is not a valid service
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:198)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:186)
at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:111)
at javax.xml.ws.Service.<init>(Service.java:92)
at javax.xml.ws.Service.create(Service.java:722)
at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:193)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:1036)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:772)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:740)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:172)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:498)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.ijws.folioservice.client.demo.DisplayFolioServlet.getFolioService(DisplayFolioServlet.java:202)
at com.ijws.folioservice.client.demo.DisplayFolioServlet.getFolioServiceSEIPort(DisplayFolioServlet.java:223)
at com.ijws.folioservice.client.demo.DisplayFolioServlet.searchFolios(DisplayFolioServlet.java:145)
at com.ijws.folioservice.client.demo.DisplayFolioServlet.processRequest(DisplayFolioServlet.java:62)
at com.ijws.folioservice.client.demo.DisplayFolioServlet.doGet(DisplayFolioServlet.java:184)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

This is the line that causes the problem:

folioService = (com.ijws.folioservice.client.FolioService) ic.lookup("java:comp/env/service/FolioService");

This program is a few years old. It works on GlassFish 2.1.1, 3.0.1. The first time I noticed this problem is with GlassFish 3.1.



 Comments   
Comment by Bhakti Mehta [ 16/Feb/11 ]

I have reproduced this issue locally and working to identify the cause. However it is too risky to fix this late in the release cycle so have excluded it for 3.1. Will attach a patch to this issue soon

Comment by Bhakti Mehta [ 16/Feb/11 ]

Just to give more update. I tried with my local workspace and see the following . If I deploy the client and endpoint and restart glassfish I see this error when accessing the client.
However if I try either of the following
case 1 undeploy and deploy the client app or
case 2 just redeploy client app I do not need to restart gf it works fine for me in both these cases and I can access the client application.

Comment by rdelaplante [ 16/Feb/11 ]

Great job finding and fixing it so quickly. Isn't the purpose of these release candidates to fix bugs for the final release? This seems pretty critical to me (having to redeploy each time I restart GlassFish)

Comment by Bhakti Mehta [ 16/Feb/11 ]

Sorry I do not have the patch as yet I am still working on identifying the cause

Comment by rdelaplante [ 17/Feb/11 ]

Just making some noise about the 3_1-exclude tag in hopes to change your mind... This is a regression, and unless fixed then we cannot use GlassFish 3.1 in production. Having to re-deploy every time the server is restarted is too risky.

If you fixed it the day after 3.1 goes final, would I have to wait 3 - 6 months for GlassFish 3.1.1 to be released so I can get the patch?

Comment by Bhakti Mehta [ 17/Feb/11 ]

Here is a jar file with the fix. This works for me please can you try that.
Here is the patch
Index: src/main/java/org/glassfish/javaee/core/deployment/JavaEEDeployer.java
===================================================================
— src/main/java/org/glassfish/javaee/core/deployment/JavaEEDeployer.java (revision 45171)
+++ src/main/java/org/glassfish/javaee/core/deployment/JavaEEDeployer.java (working copy)
@@ -198,8 +198,6 @@
try {
prepareScratchDirs(dc);

  • if (! dc.getCommandParameters(OpsParams.class).origin.isArtifactsPresent()) { - // only generate artifacts when there is no artifacts present //In jaxrpc it was required to run //Wscompile to generate the artifacts for clients too. @@ -211,7 +209,9 @@ jaxrpcCodeGenFacade.run(habitat,dc,getModuleClassPath(dc), true) ; }

    }

  • generateArtifacts(dc);
    + if (! dc.getCommandParameters(OpsParams.class).origin.isArtifactsPresent()) { + // only generate artifacts when there is no artifacts present + generateArtifacts(dc); }

    return true;
    } catch (Exception ex) {

Comment by rdelaplante [ 18/Feb/11 ]

Thank you, it works!

Pre-tests:
==========

1) Started from a state where JAX-RPC client did not work.

2) From GlassFish web admin console I "reloaded" or "restarted" the application, then tested again. It still did not work.

3) I re-deployed the application from GlassFish web admin console, and the application worked again.

4) I restarted GlassFish, and the application stopped working.

Testing the patch:
==================

1) Shut down GlassFish 3.1-b42

2) Replace deployment-javaee-core.jar in \glassfish\modules\

3) Started GlassFish

4) Tried the application again, and it works!

5) Restarted GlassFish and tried again. It still works!

Comment by Bhakti Mehta [ 01/Mar/11 ]

Fixed svn rev 45200. Added the 3_1-next tag so this can be considered for the next patch,update or dot dot release

Comment by Bhakti Mehta [ 27/Apr/11 ]

Also committed to 3.1.1 branch 46172





[GLASSFISH-15996] Regression: nodes tree not updated with new lifecycle module Created: 15/Feb/11  Updated: 23/Jun/11  Resolved: 03/Mar/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01, 4.0_b01

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

build: promoted b43


Tags: 3_1_1-verified

 Description   

Tried this on Firefox on windows xp and safari on mac with the same result: newly created lifecycle module is not displayed in the tree. Steps to reproduce:

1. Click on Lifecycle Modules, New button.
2. Fill in the required fields and click Save to create a new lifecycle module.
3. New module is displayed in the table, but the tree on the left is never updated with it.

Workaround: reload the Admin Console url.

This worked in earlier builds, e.g. b28 (see issue http://java.net/jira/browse/GLASSFISH-14598).



 Comments   
Comment by Anissa Lam [ 03/Mar/11 ]

Fixed in the trunk on 3/3/2011.

Sending common/src/main/resources/applications/lifecycles.jsf
Transmitting file data .
Committed revision 45394.

Comment by lidiam [ 23/Jun/11 ]

Verified in build b08.





[GLASSFISH-15995] Configuration: server config displayed, when GMS for any other config is chosen in right frame Created: 15/Feb/11  Updated: 23/Jun/11  Resolved: 19/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

promoted build b43


Attachments: JPEG File wrong-config.JPG    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16027 Configuration: right hand side GMS li... Closed
Tags: 3_1-exclude, 3_1_1-verified

 Description   

Steps to reproduce:

1. Create a cluster, e.g. c-1.
2. Click on cluster's configuration Tree Node.
3. In the right hand frame click on Group Management Services - notice that the right item is highlighted in the nodes tree, however at the top of the page it says:

Configuration Name:

server-config

This only happens when clicking on GMS in the right hand list. If it's clicked through the expansion of the nodes tree, in the left frame, the correct config is displayed.

The same issue exists for a standalone instance - if GMS is chosen on the right, server-config GMS is displayed, even though tree highlighting will be correctly showing standalone instance's GMS.



 Comments   
Comment by Anissa Lam [ 15/Feb/11 ]

The tree highlight is wrong.
Always look at the configuration name of the page.

This is a bug that there is no config name passed to the GMS page, and so it just use server-config.

Comment by lidiam [ 17/Feb/11 ]

This problem occurs for any config, when GMS is clicked in the right hand side panel. Also, there is no GMS under server-config, which makes it even more confusing.

Comment by Anissa Lam [ 19/Feb/11 ]

Project: glassfish
Repository: svn
Revision: 45187
Author: anilam
Date: 2011-02-20 00:51:28 UTC
Link:

Log Message:
------------
GLASSFISH-15995. Fix configName for the GMS configuration plugin link.

Revisions:
----------
45187

Modified Paths:
---------------
trunk/v3/admingui/cluster/src/main/resources/configuration/gmsConfigurationLink.inc

Diffs:
------
Index: trunk/v3/admingui/cluster/src/main/resources/configuration/gmsConfigurationLink.inc
===================================================================
— trunk/v3/admingui/cluster/src/main/resources/configuration/gmsConfigurationLink.inc (revision 45186)
+++ trunk/v3/admingui/cluster/src/main/resources/configuration/gmsConfigurationLink.inc (revision 45187)
@@ -43,7 +43,7 @@
<sun:property rendered="#

{pageSession.gmsShowIt}">
<sun:hyperlink rendered="#{pageSession.gmsShowIt}

"
toolTip="$resource

{i18ncs.tree.gms.tooltip}

"

  • url="/cluster/configuration/gms.jsf?configName=$ {configName}

    "
    + url="/cluster/configuration/gms.jsf?configName=#

    {pageSession.configName}

    "
    >

<sun:image url="/resource/cluster/images/management_services.gif" />

Comment by lidiam [ 23/Jun/11 ]

Verified in build b08.





[GLASSFISH-15993] Properties: runtime exception on cancel for DAS instance properties Created: 15/Feb/11  Updated: 24/Jun/11  Resolved: 19/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b42
Fix Version/s: 3.1.1_b01

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

promoted build b43


Attachments: JPEG File properties-runtime-exception.JPG     Text File server.log    
Tags: 3_1-exclude, 3_1_1-verified

 Description   

Steps to reproduce:

1. Click on server (Admin Server), Properties tab.
2. Click on Instance Properties.
3. Click Cancel - runtime exeption is printed on screen.

This only happens for DAS Instance Properties tab. Cancel works fine on System Properties screen for DAS and on all other properties tabs for clusters, clustered instances and standalone instances.



 Comments   
Comment by lidiam [ 15/Feb/11 ]

Removed the 3_1-exclude tag, so that this issue can be evaluated.

Comment by Anissa Lam [ 15/Feb/11 ]

Not show stopper. exclude from 3.1

Comment by Anissa Lam [ 19/Feb/11 ]

Fixed in trunk.

Project: glassfish
Repository: svn
Revision: 45186
Author: anilam
Date: 2011-02-20 00:32:27 UTC
Link:
Log Message:
------------
GLASSFISH-15993. Specify parent page for DAS instance properties page's cancel button redirect to.

Revisions:
----------
45186

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/resources/appServer/instanceProperties.jsf

Diffs:
------
Index: trunk/v3/admingui/common/src/main/resources/appServer/instanceProperties.jsf
===================================================================
— trunk/v3/admingui/common/src/main/resources/appServer/instanceProperties.jsf (revision 45185)
+++ trunk/v3/admingui/common/src/main/resources/appServer/instanceProperties.jsf (revision 45186)
@@ -2,7 +2,7 @@

DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.

  • Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved.
    + Copyright (c) 2010-2011 Oracle and/or its affiliates. All rights reserved.

The contents of this file are subject to the terms of either the GNU
General Public License Version 2 only ("GPL") or the Common Development
@@ -54,8 +54,7 @@
urlencode(value="#

{pageSession.instanceName}

" encoding="UTF-8" result="#

{pageSession.encodedInstanceName}");
setSessionAttribute(key="serverInstTabs" value="instanceProps");
setPageSessionAttribute(key="listLink" value="#{request.contextPath}/common/appServer/instanceProperties.jsf?instanceName=${instanceName}");
-
-
+ setPageSessionAttribute(key="parentPage", value="#{request.contextPath}/common/appServer/serverInstGeneralPe.jsf?instanceName=#{pageSession.encodedInstanceName}

");
setPageSessionAttribute(key="selfPage", value="#

{request.contextPath}

/common/appServer/instanceProperties.jsf?instanceName=#

{pageSession.encodedInstanceName}");
setPageSessionAttribute(key="parentUrl", value="#{sessionScope.REST_URL}/servers/server/#{pageSession.encodedInstanceName}

");
setPageSessionAttribute(key="selfUrl", value="#

{pageSession.parentUrl}

");

Comment by lidiam [ 24/Jun/11 ]

Verified in build b08.





[GLASSFISH-15992] Properties: table wiped out on sort, error displayed afterwards Created: 15/Feb/11  Updated: 24/Jun/11  Resolved: 20/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

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

promoted build b43


Attachments: JPEG File noproperties-clickinstance.JPG     JPEG File noproperties.JPG     Text File server.log    
Tags: 3_1-exclude, 3_1_1-verified

 Description   

Steps to reproduce:

1. Click on server (Admin Server), Properties tab.
2. Click Add Property and fill out the blanks. Before or after hitting save (makes no difference), click on Override Value link, that sorts the table. Issue 1: At this point all the properties from the table disappear.
3. Click on Instance Properties tab - issue 2: the following error is displayed:

An error has occurred
REST Request 'http://localhost:4848/management/domain/servers/server//system-properties' failed with response code '404'.

Clicking anywhere in nodes tree clears out the issue.

This problem exists with cluster system properties table as well. Without adding any properties, if I click Override Value link, the table content disappears and the "wait, long running process" message shows and never goes away (have to reload the url). In case of standalone instance, table content disappears but the "wait" message does not come on.

This problem is present for both Current Value and Override Value sorting links on the properties tabs. Once the error occurs clicking on any tab for the same cluster or instance produces the 404 error.

In case of the sorting link Instance Variable Name on the standalone instance system properties tab, once I clicked that the "wait" message appeared and never went away.



 Comments   
Comment by lidiam [ 17/Feb/11 ]

Removed the exclude tag, so that the issue can be evaluated.

Comment by Anissa Lam [ 17/Feb/11 ]

This doesn't classify as show stopper. Add 3_1-exclude and Jason can fix this for 3.2.

Comment by Anissa Lam [ 20/Feb/11 ]

The value specified to sort the column is wrong, thus causing the issue.
Also notice that the value specified in the currentValue column for sorting is wrong too, fixed it as well.
Fix checked into the trunk.

Project: glassfish
Repository: svn
Revision: 45189
Author: anilam
Date: 2011-02-20 18:16:12 UTC
Link:

Log Message:
------------
GLASSFISH-15992 Fix the value that should be used to sort the currentValue and overrideValue column in the Systems Properties table.

Revisions:
----------
45189

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/resources/configuration/systemProperties.jsf

Diffs:
------
Index: trunk/v3/admingui/common/src/main/resources/configuration/systemProperties.jsf
===================================================================
— trunk/v3/admingui/common/src/main/resources/configuration/systemProperties.jsf (revision 45188)
+++ trunk/v3/admingui/common/src/main/resources/configuration/systemProperties.jsf (revision 45189)
@@ -2,7 +2,7 @@

DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.

  • Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved.
    + Copyright (c) 2010-2011 Oracle and/or its affiliates. All rights reserved.

The contents of this file are subject to the terms of either the GNU
General Public License Version 2 only ("GPL") or the Common Development
@@ -114,12 +114,12 @@
<sun:tableColumn headerText="$resource

{i18n.systemProps.colInstanceName}

" sort="name" rowHeader="$boolean

{false}" id="col2">
<sun:textField columns="$int{40}" maxLength="#{sessionScope.fieldLengths['maxLength.common.PropertyName']}" id="col1St" value="#{td.value.name}" />
</sun:tableColumn>
- <sun:tableColumn id="currentValueCol" headerText="$resource{i18n.systemProps.ColCurrentValue}" sort="value" rowHeader="$boolean{false}

" id="col3">
+ <sun:tableColumn id="currentValueCol" headerText="$resource

{i18n.systemProps.ColCurrentValue}

" sort="currentValue" rowHeader="$boolean

{false}" id="col3">
<h:outputText id="currentVal" value="#{td.value.currentValue}" />
</sun:tableColumn>
- <sun:tableColumn id="overrideValCol" headerText="$resource{i18n.inst.ColOverrideValue}" sort="value" rowHeader="$boolean{false}

">
+ <sun:tableColumn id="overrideValCol" headerText="$resource

{i18n.inst.ColOverrideValue}

" sort="overrideValue" rowHeader="$boolean

{false}

">
<sun:textField id="overrideVal" columns="$int

{40}

" maxLength="#

{sessionScope.fieldLengths['maxLength.common.PropertyValue']}

" value="#

{td.value.overrideValue}

"/>
</sun:tableColumn>

Comment by lidiam [ 24/Jun/11 ]

Verified in build b08.





[GLASSFISH-15990] Properties: success message on save not displayed Created: 15/Feb/11  Updated: 23/Jun/11  Resolved: 10/Mar/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

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

promoted build b43


Tags: 3-1_next, 3_1_1-verified

 Description   

Steps to reproduce:

1. Create a cluster with one instance.
2. Go to clustered instance page, Properties tab.
3. Click Add Property and fill in the blanks. Hit Save and notice that "New values successfully saved" message does not appear.

This only happens for a clustered instance. The message is displayed fine for a standalone instance.



 Comments   
Comment by Jason Lee [ 10/Mar/11 ]

Fix committed (r45473)

Comment by lidiam [ 23/Jun/11 ]

Verified in build b08.





[GLASSFISH-15987] Display Restart Required when a system-property which is referenced by a jvm-option is changed Created: 15/Feb/11  Updated: 07/Apr/11  Resolved: 17/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Restart Required should also appear in Admin Console and 'asadmin list-domains' when a change is made to the system-property which is referenced by a jvm-option. In the code we need to
check if the system property is changed and referenced by a jvm-options
and show the Restart Required.

For example in server-config:

1) Create a system property
<system-property name="JVM_HEAP_SIZE" value="1090m"></system-property>

2) Change jvm option to use system property
<jvm-options>-Xmx$

{JVM_HEAP_SIZE}

</jvm-options>

3) Restart GlassFish

4) Change system property value for JVM_HEAP_SIZE

5) Upper left of Admin Console does not show Restart Required
asadmin list-domains does not show 'requires restart'

Checked on v2.1.1, that changing a system-property referenced by a jvm-option, show restart required in asadmin list-domains (The Admin Console doesn't display):

C:\glassfish-v2.1.1-b31g\glassfish\bin>asadmin list-domains
domain1 requires restart
Command list-domains executed successfully.



 Comments   
Comment by Jennifer Chou [ 15/Feb/11 ]

I checked in v2.1.1 that even a change to a system property that's not referenced by anything else, will trigger a restart required to be displayed.

C:\glassfish-v2.1.1-b31g\glassfish\bin>asadmin list-domains
domain1 requires restart
Command list-domains executed successfully.

So in the code, we can just check whether a system property is changed and trigger a restart required state.

Comment by Chris Kasso [ 16/Feb/11 ]

We have a collection of "Restart Required" issues that remain unresolved in 3.1. This likely warrants an umbrella Release Note item which addresses the more general problems we are seeing in this area. Here's a query that identifies many of the existing "Restart Required" issues:

http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10358

Comment by Tom Mueller [ 01/Mar/11 ]

The root cause of this problem is that when a system property change is made, the GenericJavaConfigListener class does not take into account that some JVM options, such as -Xmx, might be depending on the value of a system property, so the system property change event is not returned from GenericJavaConfigListener as an UnprocessedChangeEvent, so the UnprocessedConfigListener doesn't pick it up to set the restart required flag.

The processing of the JVM options, including resolution of property values, occurs within the launcher, which is executed by asadmin, not the server (specifically in the GFLauncher class when it calls TokenResolver). There is no record kept of what tokens were resolved, or where they came from.

Considering this a bit deeper, the token resolution that occurs for JVM options uses as its sources the following:

1. the shell environment, e.g., "export a=b"
2. values in the asenv.conf or asenv.bat file
3. values passed via -Da=b as specified in the asadmin script
4. system-properties in the domain.xml (server, config, and domain)
5. JVM options (-Da=b in the jvm-options in the domain.xml)
6. profiler properties (from the domain.xml)

If any of these change such that the JVM options would be recalculated for the instance, then a restart-required should be triggered. For example, if the asenv.conf file or asadmin file is edited, or the user changes their environment. The server cannot detect changes in the latter, but it could be looking at those files. This bug is only about changes to system-properties in the domain.xml, but it does raise the question of what else should be checked too.

The suggested fix for this bug is to modify the GenericJavaConfigListener class so that it looks at the token that are referenced by the JVM options, and if the value of a token changes, then the change should be returned as an UnprocessedChangeEvent. This will require making GenericJavaConfigListener listen for system property change notifications.

Comment by Scott Fordin [ 07/Mar/11 ]

Added issue to 3.1 Release Notes as part of "Restart Required" umbrella issue.

Comment by Tom Mueller [ 08/Mar/11 ]

This isn't actually fixed yet.

Comment by Tom Mueller [ 17/Mar/11 ]

Fixed in revision 45608 on the trunk.

If a system-property is referenced by a JVM option, any change to that any system property with that name will cause a restart-required, even if the actual value did not change. For example, consider this:

<domain>
<system-property name="foo" value="bar"/>
<servers>
<server config-ref="server-config">
<system-property name="foo" value="baz"/>
</server>
</servers>
<configs>
<config name="server-config">
<java-config>
<jvm-options>-Dabc=$

{foo}

</jvm-options>
</java-config>
</config>
</configs>
</domain>

If you then do:
asadmin create-system-property --target domain foo=xyz

This will trigger the restart-required flag, even though the <server> value is really overriding the value for foo, so when the server restarts, the value of the abc property won't change.

If this really bothers you, please file another issue.

However, the fix that is checked in fixes the problem from the initial description.

Comment by Scott Fordin [ 18/Mar/11 ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Scott Fordin [ 24/Mar/11 ]

Added "3_1-release-note-added" tag.





[GLASSFISH-15986] Column APPLICATIONID is missing from bundled sql scripts for ejb timer table creation. Created: 15/Feb/11  Updated: 13/Apr/11  Resolved: 04/Mar/11

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

In 3.1, the bundled timer table creation sql scripts are missing column APPLICATIONID.

sony@nila:/home2/sony/builds/glassfish3/glassfish/lib/install/databases$ cat ejbtimer_derby.sql
CREATE TABLE EJB_TIMER_TBL (
CREATIONTIMERAW BIGINT NOT NULL,
BLOB BLOB(2G),
TIMERID VARCHAR(255) NOT NULL,
CONTAINERID BIGINT NOT NULL,
OWNERID VARCHAR(255),
STATE INTEGER NOT NULL,
PKHASHCODE INTEGER NOT NULL,
INTERVALDURATION BIGINT NOT NULL,
INITIALEXPIRATIONRAW BIGINT NOT NULL,
LASTEXPIRATIONRAW BIGINT NOT NULL,
SCHEDULE VARCHAR(255),
CONSTRAINT PK_EJB_TIMER_TBL PRIMARY KEY (TIMERID)
) ;



 Comments   
Comment by marina vatkina [ 15/Feb/11 ]

I'm not sure how this could happen, but all but one .sql files are missing this column. The sql files are for the user as a ref point, or to be able to create the table themselves. By default EJB Timer service creates the table on the 1st deploy.

Fixing the files won't affect the execution.

Comment by marina vatkina [ 15/Feb/11 ]

Fixed on trunk with rev 45149

Comment by Scott Fordin [ 04/Mar/11 ]

Need more information to add to notes.

Comment by Scott Fordin [ 04/Mar/11 ]

Added issue to 3.1 Release Notes.

Comment by Scott Fordin [ 24/Mar/11 ]

Added "3_1-release-note-added" tag.





[GLASSFISH-15985] NullPointerException when accessing OSGi web application Created: 15/Feb/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Resolved
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1_b38, 3.1_b41 , 3.1_b42
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: chaoslayer Assignee: Ed Burns
Resolution: Fixed Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File dummy-web.war     Text File message.txt     Text File server-3.1-b36.log     Text File server-3.1-b37.log    
Status Whiteboard:

jsf_2_1_1

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Deployment of the web application works fine:

INFO: Installed /srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Started bundle: file:/srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Started bundle: file:/srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Expanded at file:/tmp/osgiapp6345962157332461681/
INFO: SEC1002: Security Manager is OFF.
INFO: SEC1010: Entering Security Startup Service
INFO: SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
INFO: SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
INFO: SEC1011: Security Service(s) Started Successfully
INFO: WEB0169: Created HTTP listener [http-listener-1] on host/port [0.0.0.0:8080]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [admin-listener] on host/port [0.0.0.0:4848]
INFO: WEB0171: Created virtual server [server]
INFO: WEB0171: Created virtual server [__asadmin]
INFO: WEB0172: Virtual server [server] loaded default web module []
INFO: Portable JNDI names for EJB DummySingleton : [java:global/org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT/DummySingleton, java:global/org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT/DummySingleton!org.glassfish.osgi.web.dummy.DummySingletonLocal]
INFO: WELD-000900 $

{parsedVersion (osgiVersion}

)
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: total number of classes with faces annotation = 0
INFO: Total number of available updates : 0
INFO: Initializing Mojarra 2.1.0 (FCS 2.1.0-b11) for context '/dummy-web'
INFO: Faces Config uris excluding the ones named as faces-config.xml = []
INFO: Facelet Config uris = [embeddedjar:bundle://252.0:0/WEB-INF/lib/prettyfaces-jsf2-3.2.0.jar!/META-INF/ocpsoft-pretty-faces.taglib.xml]
INFO: PrettyFilter starting up...
INFO: PrettyFilter initialized.
INFO: WEB0671: Loading application [org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT] at [/dummy-web]
INFO: Registered ServletContext as a service with properties:

{osgi.web.symbolicname=org.glassfish.osgi.dummy-web, osgi.web.version=1.0.0.SNAPSHOT, osgi.web.contextpath=/dummy-web}


INFO: deployed bundle org.glassfish.osgi.dummy-web [252] at file:/tmp/osgiapp6345962157332461681/

...but when I try to access it via HTTP:

SEVERE: WebModule[/dummy-web]PWC1321: Error invoking requestInitialized method on ServletRequestListener com.ocpsoft.pretty.faces.config.PrettyConfigListener
java.lang.NullPointerException
at com.sun.faces.application.ServletContextSensitiveSingletonStore.<init>(ServletContextSensitiveSingletonStore.java:83)
at com.sun.faces.application.ApplicationFactoryImpl.getApplication(ApplicationFactoryImpl.java:92)
at com.ocpsoft.pretty.faces.util.FacesFactory.getApplication(FacesFactory.java:31)
at com.ocpsoft.pretty.faces.config.PrettyConfigListener.requestInitialized(PrettyConfigListener.java:34)
at org.apache.catalina.core.StandardContext.fireRequestInitializedEvent(StandardContext.java:4551)
at org.apache.catalina.core.StandardHostValve.preInvoke(StandardHostValve.java:626)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

attached a test case (dummy-web.war).

I've tested this against b33, b36, b38, b41, and b42. Up to b36 all was fine, starting with b41 the above exception is being thrown.

In b38, the behavior was even more strange:

^^ ???

...HTTP access returned a 404 (expected after those lines), but a OSGi bundle "refresh" yield this:

INFO: Expanded at file:/tmp/osgiapp8864019535236458366/
INFO: Deleted /tmp/osgiapp8864019535236458366
SEVERE: Failed while deploying bundle org.glassfish.osgi.dummy-web [369]
INFO: Removed bundle 369 against context path /dummy-web
WARNING: Failed to deploy bundle org.glassfish.osgi.dummy-web [369]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.osgi.dummy-web [369] failed because of following reason: Failed while deploying bundle org.glassfish.osgi.dummy-web [369] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [369] ], root cause: Application name org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT is already in use. Please pick a different name.
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [369] ], root cause: Application name org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT is already in use. Please pick a different name.
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
... 10 more



 Comments   
Comment by Shing Wai Chan [ 15/Feb/11 ]

This is an OSGi jsf web application.
There are two issues here:
(1) The first access of OSGi web application have NPE.
(2) There is a problem in redeployment of OSGi web application.

Assign to jsf team to investigate (1).

Comment by rogerk [ 15/Feb/11 ]

Assigning to Ed as prior commit may be the cause.

Comment by Ed Burns [ 15/Feb/11 ]

Does the server configuration in which this bug manifests use clusters or virtual servers?

Comment by Ed Burns [ 15/Feb/11 ]

Because this is an OSGi web application, I assume I must deploy it with "--type osgi" correct?

Comment by Ed Burns [ 15/Feb/11 ]

I can reproduce the problem.

Here is the log output.

Comment by Ed Burns [ 15/Feb/11 ]

By omitting the --type osgi argument from the deployment, this causes the problem to not manifest. Of course, it is a real bug, but it is not a blocker for 3.1.

Comment by chaoslayer [ 15/Feb/11 ]

I usually deploy those WABs using the .../autodeploy/bundles/ Felix FileInstall watch directory.

Apart from that I disagree by excluding this for the 3.1 release because it is a real regression and OSGi/JavaEE is a real target for GlassFish 3.1 and we already use it (currently with b36) just short before our application release.

As there are numerous issues resolved since b36 regarding stability/performance and bugfixes we are seriously looking forward to use a later build and hopefully switch to the final release.

However, this bug would completely block us doing so and we'll have to live with workarounds/hacks.

Comment by Sanjeeb Sahoo [ 16/Feb/11 ]

Can anyone tell me which check-in caused this regression? It is sad that we have caused a regression in builds just prior to release of 3.1.

Comment by chaoslayer [ 16/Feb/11 ]

Just tested the b37 and even that one is affected by this problem.

I've attached two log files for comparison both with felix log level set to DEBUG in order to see, if that's a wiring problem, but doesn't seem so.

Log files:

  • server-3.1-b36.log - OK
  • server-3.1-b37.log - FAIL
Comment by chaoslayer [ 16/Feb/11 ]

Well, as the "FacesContext.getCurrentInstance()" returns "null" (introduced by Mojarra 2.1-b10), I just thought about adding a custom faces-config (stored in a file "META-INF/weld.faces-config.xml") with the following content:

<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">
<factory>
<application-factory>org.glassfish.weld.jsf.WeldApplicationFactory</application-factory>
</factory>

</faces-config>

...and now it works. So basically it seems, that FacesContext.setCurrentInstance is not called unless I provide a specific application factory class, weird...

...a little debugging against a 3.1-b41 with mojarra 2.1-b11 yield the following:

Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at FacesContext.java:845.
User program running

...so the "FacesContext.setCurrentInstance()" is always called after the call to "FacesContext.getCurrentInstance()" is issued by the ServletContextSensitiveSingletonStore which is obviously the wrong order things should happen.

Using the custom *.faces-config.xml file I see the following invocations:

Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running

...which seems totally correct.

Comment by chaoslayer [ 21/Feb/11 ]

Any progress on this one?

Comment by Ed Burns [ 02/Mar/11 ]

Ok, I see the same problem, even today.

Investigating further.

Comment by Ed Burns [ 03/Mar/11 ]

Committed to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationFactoryImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/application/InjectionApplicationFactory.java
Deleting jsf-ri/src/main/java/com/sun/faces/application/ServletContextSensitiveSingletonStore.java
Sending jsf-ri/src/main/java/com/sun/faces/application/WebappLifecycleListener.java
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
Adding jsf-test/GLASSFISH-15985
Adding jsf-test/GLASSFISH-15985/build.xml
Adding (bin) jsf-test/GLASSFISH-15985/dummy-web.war
Sending jsf-test/build.xml
Transmitting file data ........
Committed revision 8887.

Comment by Ed Burns [ 04/Mar/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationFactoryImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/application/InjectionApplicationFactory.java
Deleting jsf-ri/src/main/java/com/sun/faces/application/ServletContextSensitiveSingletonStore.java
Sending jsf-ri/src/main/java/com/sun/faces/application/WebappLifecycleListener.java
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
Adding jsf-test/GLASSFISH-15985
Adding jsf-test/GLASSFISH-15985/build.xml
Adding (bin) jsf-test/GLASSFISH-15985/dummy-web.war
Sending jsf-test/build.xml
Transmitting file data ......
Committed revision 8899.

Comment by Sanjeeb Sahoo [ 04/Mar/11 ]

This bug needs to remain opened until a version of mojarra containing the fix is integrated.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Ed Burns [ 08/Apr/11 ]

Integrated into GlassFish 3.1.1

Comment by Scott Fordin [ 13/Apr/11 ]

Release Note still needed?

Comment by Ed Burns [ 14/Apr/11 ]

Release notes are only needed if you are writing releasenotes for 3.1.

Comment by Scott Fordin [ 14/Apr/11 ]

Thanks. I go back to my previous comment then: I need more info to include these in the 3.1 Release Notes. Specifically, a concise description and workaround.

Comment by Scott Fordin [ 12/May/11 ]

Added topic to 3.1 Known Issues section of the 3.1-3.1.1 Release Notes. Not convinced I have all the information I need. For example, not clear to me what the downsides are to omitting --type osgi from the deploy subcommand. Also not clear what the implications are, if any, when deploying from an autodeploy directory or the Admin Console.





[GLASSFISH-15982] Log Viewer passing wrong file name to the backend code... Created: 14/Feb/11  Updated: 07/Apr/11  Resolved: 10/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

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

All


Tags: 3-1_next, 3_1-exclude

 Description   

When user views rotated server log file for any instances and now change instance drop down value, it passes old log file name to the back end code.

e.g.
Server having two log files.

1. server.log
2. server.log_rotated_log_file

in1 having two log files.

1. server.log
2. in1_server.log_rotated_log_file

Now user opens log viewer and viewing instance 'server' log file is 'server.log_rotated_log_file'. It gives correct output. Now user changes instance drop down to 'in1' and at that time admin gui passes wrong file name to back end code. It passes instance name as 'in1' and log file name as 'server.log_rotated_log_file' which are totally wrong and mismatching.

Need following changes to avoid:
When user changes drop down for instance admin gui must have to pass value as server.log as file name. Don't pass any rotated log file name when user changes instance drop down value.



 Comments   
Comment by sirajg [ 10/Mar/11 ]

Diffs :
— src/main/resources/logViewer/logViewer.jsf (revision 45406)
+++ src/main/resources/logViewer/logViewer.jsf (working copy)
@@ -354,6 +354,7 @@
gf.getMapKeys(Map="#

{requestScope.servers.data.extraProperties.childResources}

" Keys="#

{requestScope.servers}

");
</ui:event>
<ui:event type="command">
+ setAttribute(key="logFile", value="#

{null}

");
gf.navigate(page="#

{request.contextPath}

/common/logViewer/logViewer.jsf");
</ui:event>





[GLASSFISH-15972] Log Viewer: When changing instance or log file, details can no longer be viewed for instance logs Created: 14/Feb/11  Updated: 07/Apr/11  Resolved: 03/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-exclude, 3_1-next

 Description   

When switching either the instance or log file drop downs in Log Viewer modify search, the details screen appears blank for each event selected. Note that the URL generated before switching the instance or log file looks like:

http://localhost:4848/common/logViewer/logEntryDetail.jsf?instanceName=test&logLevel=INFO&logFile=server.log&recNumber=31

And the URL generated after switching the instance or log file:

http://localhost:4848/common/logViewer/logEntryDetail.jsf?instanceName=test&logLevel=INFO&logFile=&recNumber=31

Where the second url does not have a parameter for 'logFile'.

The following error is generated in the DAS server.log

[#|2011-02-14T10:49:29.414-0500|WARNING|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.server.logging.logviewer.backend|_ThreadID=92;_ThreadName=Thread-1;|CORE10007: Requested Log file is not Found: /home/testuser/glassfish3/glassfish/domains/domain1/../../nodes/localhost-domain1/test/logs/$

{com.sun.aas.instanceRoot}

/logs/server.log|#]

It appears that if the parameter is blank the default log file is used but it is used by appending to the current instance log path which is invalid. This would not be a major issue except that in some cases the default log file is not the current "server.log". This could also possibly be related to GLASSFISH-15822.

Reproducible:

Always

Steps to reproduce:

1. Install a fresh version of glassfish 3.1_b41.
2. Create a new standalone instance
3. View the logs for that instance and verify that the details of an event can be viewed.
4. Change the instance to server and then back to the instance you created. Alternatively, force a log rotation and then switch the log file to the rotated log and back.
5. Attempt to view the details for the instance you created. The details screen will be blank and an error will be logged to the DAS.



 Comments   
Comment by Anissa Lam [ 14/Feb/11 ]

Thanks for reporting.
We will look into this for 3.2.

Comment by naman_mehta [ 14/Feb/11 ]

I tried as per below but not reproducible.

1. setup gf
2. start gf
3. create stand alone instance on another machine
4. stared instance
5. open log viewer for server.
6. click on view log files and viewed for server. it looks fine to me.
7. change instance drop down to new instance 'in1'.
8. log viewer looks fine to me and shows content of in1 only.
9. rotated instance log.
10. rotated server log.
11. click on server it showing blank screen as server.log has no data because it's rotated.
12. select rotated server log file it shows correct data.
13. select server log file again shows correct data.
14. now select in1 log.
15. shows no data for server log as it's rotated.
16. select rotated server log file it shows correct data.

Let me know if anything missing here.

Comment by chuha [ 15/Feb/11 ]

Sorry about that, I probably wasn't as clear as I could have been.

Notes:
1. This does NOT seem to affect the server (DAS) instance.
2. I have not done sufficient testing with remote instances to say for sure whether this bug affects remote instances. My initial testing this morning shows that it does but I need to create more test cases to verify.
3. When bringing up the Log Viewer using "View Log Files" the correct logs are shown under Log Viewer results no matter which instance or log file for that instance is selected. The problem is only evident when click the "details" link for a given link. This is often necessary as the message is truncated for each event in the main view.

Steps to reproduce:
1. Install/Setup/Start Glassfish (using glassfish 3.1_b42 now)
2. Create a standalone instance on the same machine (local). We'll call this instance "test".
3. Start the test instance.
4. Go to standalone instances and select the test instance.
5. Click "View Log Files".
6. By default the test instance will be selected and server.log will be the log file. The proper logs are shown in the Log Viewer Results.
7. Click details for one of the event. The entire event will be properly shown in the Log Entry Detail screen.
8. Change the instance to the server (DAS) instance. The logs for that instance will be shown.
9. Change the instance back to the test instance. The proper logs for the test instance will be shown.
10. Click the details for one of the events. The values in the Log Entry Detail screen will now be blank.

Again, I will do more testing with remote instances to verify this can be reproduced there. This can also be reproduced with by having multiple log files for a given instance (by rotating, etc.). The key thing is that once wither of the selection boxes are changed for "Instance" or "Log File", the details for log events can no longer be displayed in the Log Entry Detail screen for any instance other than the server instance.

Thanks again for looking into this. If you need any other details, please let me know.

Comment by sirajg [ 03/Mar/11 ]

Fixed by setting up the right value for #

{pageSession.logFile}

. revision 45391





[GLASSFISH-15965] Clustered instance page is missing Rotate Log button Created: 11/Feb/11  Updated: 06/Jul/11  Resolved: 25/Mar/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

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

promoted b41


Tags: 3-1_next, 3_1-exclude, 3_1_1-verified

 Description   

I thought this has already been logged a while back but cannot find a relevant issue, hence logging it here.

Clustered instance page is missing Rotate Log button. The backend functionality is there, since I can execute asadmin rotate-log --target=<clustered instance> and it works fine. Initially logging backend only allowed rotating of the log files for the whole cluster, but that's been changed. Therefore we should add Rotate Log button to clustered instance page to make it consistent with CLI and standalone instance page.



 Comments   
Comment by sirajg [ 25/Mar/11 ]

Fixed revision 45745

+ <sun:button id="rotateLog" text="$resource

{i18n.button.rotateLog}

" primary="#

{false}

" disabled="#

{pageSession.isStopped}

"
+ onClick="if ( getConfirm(this, '$resource

{i18nc.msg.JS.confirmRotateLog}

') )
+ { return submitAndDisable(this, '$resource

{i18n.button.Processing}

');}
+ else

{return false;}

" >
+ <!command
+ createMap(result="#

{requestScope.map}");
+ mapPut(map="#{requestScope.map}

", key="target", value="#

{pageSession.encodedInstanceName}

");
+ gf.restRequest(
+ endpoint="#

{sessionScope.REST_URL}

/rotate-log"
+ attrs="#

{requestScope.map}

"
+ method="POST"
+ result="#

{pageSession.props}

");
+ gf.redirect("#

{pageSession.selfPage}

");/>
+
+ </sun:button>
+

Comment by lidiam [ 06/Jul/11 ]

Verified in build ogs-3.1.1-b11-07_04_2011-aix.zip.





[GLASSFISH-15957] Need to return valid (existing) system rar names as per the distribution Created: 10/Feb/11  Updated: 02/Dec/11  Resolved: 12/Feb/11

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: 4.0
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-exclude

 Description   

Currently, connector runtime does not determine the profile in which its running while listing the system resource-adapters via hidden CLI commands for GUI,
as well while validating the resources (jms/connector) in a particular profile (web/classic).

Fix will be to determine the profile (by some means, eg: presence of RAR) and provide the system rars list appropriately. This way, in web profile, user will not be able to create a connector-connection-pool for jmsra/jaxr-ra (both are not included in web-profile) and appropriate error message (invalid RA name) can be provided.



 Comments   
Comment by Jagadish [ 10/Feb/11 ]

Refer the related issues :

http://java.net/jira/browse/GLASSFISH-15931
http://java.net/jira/browse/GLASSFISH-15933
http://java.net/jira/browse/GLASSFISH-15932

Comment by Jagadish [ 12/Feb/11 ]

FIX INFORMATION :

svn log -v -r 45077

Modified Paths:
---------------
trunk/v3/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ConnectorConnectionPoolManager.java
trunk/v3/connectors/connectors-internal-api/src/main/java/com/sun/appserv/connectors/internal/api/ConnectorsUtil.java
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/ConnectorRuntime.java
trunk/v3/connectors/connectors-internal-api/src/main/java/com/sun/appserv/connectors/internal/api/ConnectorsClassLoaderUtil.java
trunk/v3/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/AdminObjectManager.java





[GLASSFISH-15953] Web Embedded API support for security related configuration for webapp Created: 10/Feb/11  Updated: 07/Apr/11  Resolved: 01/Mar/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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


 Description   

Web Embedded API support for web application security related configuration such as login configuration, web resource collection, and security constraints.



 Comments   
Comment by Nithya Ramakrishnan [ 23/Feb/11 ]

Can you please elucidate about the requirement. Support for all that you mention is available in the embedded mode even in 3.1, as in-memory data.

Comment by Amy Roh [ 23/Feb/11 ]

The description should read "Web Embedded API programmatic support for web application security related configuration". The summary and description have been changed to be more clear.

Comment by Amy Roh [ 01/Mar/11 ]

Fixed in svn 45210 and 45283.





[GLASSFISH-15914] Sporadical error messages Created: 09/Feb/11  Updated: 27/May/11  Resolved: 26/May/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1_b40
Fix Version/s: 3.1.1_b01

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

Cluster with virtual server (hosting), two instances few virtual hosts


Tags: 3_1-next

 Description   

I got sometimes error message. Probelm disapear after few refreshes or after going to other virtual host.

Report of HTTP
HTTP Status 500 - Cannot find message associated with key standardEngine.noHost
type Exception report
messageCannot find message associated with key standardEngine.noHost
descriptionThe server encountered an internal error (Cannot find message associated with key standardEngine.noHost) that prevented it from fulfilling this request.
exception
java.lang.IllegalStateException
note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 3.1 logs.

Logs shows
[#|2011-02-09T19:47:42.466+0100|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web._vs.server|_ThreadID=123;_ThreadName=Thread-14;|StandardWrapperValve[default]: PWC1406: Servlet.service() for servlet default threw exception
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:505)
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:810)
at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:232)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:337)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:817)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:746)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:939)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:662)



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

Fix for the error message:

Sending web-core/src/main/java/org/apache/catalina/connector/CoyoteAdapter.java
Sending web-core/src/main/resources/org/apache/catalina/connector/LocalStrings.properties
Transmitting file data ..
Committed revision 45022.

Comment by Shing Wai Chan [ 09/Feb/11 ]

Note that the above means that request.getHost() is null.
The fixed error message will print information about getRequest().getServerName().
This will help us to identify if there is any issue in a particular configuration.

Comment by rsmogura [ 12/May/11 ]

I saw this again with version 3.2-b03.

P.S. Any way to reopen issue?

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

My previous fix is for "HTTP Status 500 - Cannot find message associated with key standardEngine.noHost". Do you still see that?

There is an IllegalStateException as the response is already committed.
From stack trace, mod_jk is used.

Do you have the steps to reproduce this?

Comment by rsmogura [ 16/May/11 ]

Sorry. I see similar error, in same situation and configuration, but different content, after some time of stand by (no processing) I got message something about no host name and IP address, what is interesting I saw this IP address changes, and after few requests everything works correct. I should have properly configured virtual hosting as well with GF and mod_jk.

Maybe later I will be able to grab detailed message, as in logs I have only java.lang.IllegalStateException.

Maybe Your patch just fixed message, but I wonder why I got 500 with no host.

If You want I may open new bug.

Comment by rsmogura [ 19/May/11 ]

I captured this error, it's only visible as error response, logs only shows IlleglaStateException without any usable root cause.

HTTP Status 500 - No Host matches server name 217.118.26.142
type Exception report
message No Host matches server name 217.118.26.142

descriptionThe server encountered an internal error (No Host matches server name 217.118.26.142) that prevented it from fulfilling this request.
exception
java.lang.IllegalStateException
note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 3.2-b03 logs.

After refresh page loads, but for one (image) file in response I got 500 error. Next refresh gives "No Host matches server name 217.118.26.143" in content of CSS file (IP changed), debugging shows browser doesn't sends cookie that points requests to particular node. Next refresh and everything works correctly.

Comment by Amy Roh [ 23/May/11 ]

Please include your domain.xml and complete server.log in order to understand your setup and reproduce the error.

Comment by rsmogura [ 26/May/11 ]

domain.xml - stripped from passwords, resources IPs, user's names etc

Comment by Amy Roh [ 26/May/11 ]

This is apache configuration, dns, or file permission problem. Do you have 217.118.26.142 in the /etc/hosts file?

I found these configuration setup suggestions to avoid the "No Host matches server name" issue and there are others you can find online.

http://rc3.org/2004/12/12/no-host-matches-server-name
http://www.webmasterworld.com/apache/3038131.htm





[GLASSFISH-15905] UnsupportedOperationException when deploying JSF2 application that uses MyFaces CoDI Created: 09/Feb/11  Updated: 07/Apr/11  Resolved: 30/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

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

Attachments: File 15905.diff     File GlassfishIssues.war    
Tags: 3-1_next

 Description   

Hi have a simple WAR application that I want to deploy to Glassfish.

The actual deployment works (I can launch the application), but I am getting an UnsupportedOperationException



 Comments   
Comment by mwessendorf [ 09/Feb/11 ]

the stack trace

[#|2011-02-09T09:17:34.252+0100|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.context|_ThreadID=24;_ThreadName=Thread-1;|Exception when handling error trying to reset the response.
java.lang.UnsupportedOperationException
at javax.faces.context.FacesContext.getExceptionHandler(FacesContext.java:280)
at org.apache.myfaces.extensions.cdi.jsf2.impl.navigation.CodiNavigationHandler.isUnhandledExceptionQueued(CodiNavigationHandler.java:77)
at org.apache.myfaces.extensions.cdi.jsf2.impl.navigation.CodiNavigationHandler.handleNavigation(CodiNavigationHandler.java:63)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:130)
at org.apache.myfaces.extensions.cdi.jsf.impl.security.SecurityViolationAwareActionListener.processAction(SecurityViolationAwareActionListener.java:49)
at org.apache.myfaces.extensions.cdi.jsf.impl.config.view.ViewControllerActionListener.processAction(ViewControllerActionListener.java:60)
at org.apache.myfaces.extensions.cdi.jsf.impl.listener.action.CodiActionListener.processAction(CodiActionListener.java:52)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:223)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
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.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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

Comment by mwessendorf [ 09/Feb/11 ]

The WAR file

Comment by mwessendorf [ 09/Feb/11 ]

=== PLEASE NOTE ===

I am using a (hosted) remote Database.
<jta-data-source>CloudBeesDS</jta-data-source>

I am using a MySQL Database, hosted by CloudBees folks - but any MySQL Database should work
(or even the default Derby - you just need to change that in WEB-INF/classes/META-INF/persistence.xml)

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

Comment by mwessendorf [ 09/Feb/11 ]

The source code of my demo is located here:

https://github.com/matzew/modern-ee-app20

(the generated WAR does contain a lot of JAR files, that are not needed)
Before I deployed the application I removed them (see my WAR file)

Please note as well, that I (by hand) modified the persistence.xml (and configured a DataSource in Glassfish) => all the info is available within my attached WAR file...

Comment by Anissa Lam [ 09/Feb/11 ]

Transfer to 'jsf' for evaluation.

Comment by rogerk [ 09/Feb/11 ]

Hello Matthias -

This seems like some configuration problem where the default ExceptionHandler is not getting called.
The fact that javax.faces.context.FacesContext.getExceptionHandler is throwing the UnsupportedOperationException is suspicious. Hard to tell what the exact problem is without seeing the Myfaces CODI source code.
Also, can you provide a persistence.xml that works on deployment to GlassFish? the provided one in the war still references the Cloudbees stuff. Been quite some time since I did anything with jpa.

Comment by mwessendorf [ 10/Feb/11 ]

Hi roger!

just change this line:
<jta-data-source>CloudBeesDS</jta-data-source>

to:
<jta-data-source>jdbc/__default</jta-data-source>

Comment by rogerk [ 10/Feb/11 ]

Great. Thanks. I've made the change to persistence.xml and was able to deploy and run the application without issueI can bring up the main page. There are other (CDI) related issues with the app - for example attempting to create a new person results in:

javax.servlet.ServletException: /new_person.xhtml @35,78 value="#

{createPerson.person.firstname}

": Target Unreachable, identifier 'createPerson' resolved to null

Comment by mwessendorf [ 10/Feb/11 ]

Yep, Weld integration issues. See: GLASSFISH-15906

Are you saying you don't get the UnsupportedOperationException, when deploying the app via the console ?

(I am on Linux/Ubuntu + 3.1 RC2 (b41))

Comment by rogerk [ 10/Feb/11 ]

I deploy the app via asadmin command line.

Comment by mwessendorf [ 10/Feb/11 ]

I filed this bug against the admin console (web application)

After deployment, in there, I do get this exception

Not used the command line tool

Comment by rogerk [ 10/Feb/11 ]

Ok I do see the exception when deploying with the admin console.
Again, this appears to be some configuration related issue where the default ExceptionHandler is not called.
But it only happens when deploying with admin console. So I think this should be evaluated there.

Comment by rogerk [ 10/Feb/11 ]

admin_gui for evaluation.

Comment by Anissa Lam [ 10/Feb/11 ]

Getting help from Jason.

Comment by Jason Lee [ 10/Feb/11 ]

Based on the comments in the bugs listed below and a discussion with Ryan Lubke, it seems that deploying the app in the same thread as the console is causing issues with the JSF environment of the newly deployed and started application. The fix, then, is to move the deployment to a new thread, which this patch does via a FutureTask and a Callable.

How bad is its impact? (Severity)
I think this is pretty severe, as it affects at least every app that uses CODI, and possibly more apps. See issues GLASSFISH-3133 and GLASSFISH-3022 for some more contet.

How often does it happen? (Frequency)
Every time

How much effort is required to fix it? (Cost)
Moderate

What is the risk of fixing it? (Risk)
We're changing the deployment code used by the console, so there's the risk that this could introduce new bugs on the page. I have tested the fix manually, though, with both ears and wars and have seen no issues.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes. The app can be successfully deployed via the CLI or via REST (the console currently uses the DeploymentFacility. These pages were not converted to REST due to time constraints).

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.

How long has the bug existed in the product?
Unknown. Probably for quite some time, given the dates on the two issue referenced above.

Do regression tests exist for this issue?
There are no automated tests for this due to the use of an iframe on the page. Fixing that test, though, will be given increased priority.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Since there are no automated tests, manual deployment of of various application types (ear, war, etc) is suggested.

When will a tested fix be ready for integration?
Diff attached.

Comment by Nazrul [ 10/Feb/11 ]

Lets address this in the trunk (3.2).

Comment by Anissa Lam [ 30/Mar/11 ]

I have converted all the GUI code from using Deployment Facility to go through REST. This means that deploy/undeploy will not be running in the same thread as GUI.
Fix checked in. When the nightly build is available (probably in the next 2 days), you can verify that.

Here is the commit. Fix checked into the trunk before branch, means it will make it to 3.2 b01 AND 3.1.1 b01.

Project: glassfish
Repository: svn
Revision: 45798
Author: anilam
Date: 2011-03-31 00:40:08 UTC
Link:

Log Message:
------------
GLASSFISH-15905. Remove dependency on Deployment Facility, convert all functions and utilities from using DF to REST. This is so deploy/undeploy of any application will not be run on the same thread as the console.
Fix the following issues, it wasn't filed, but noticed during testing of the change:

  • shouldn't show the osgi type checkbox for deployed RAR
  • when user 'restart' an application, only call disable/enable on the application IF that target is enabled. Otherwise, it is an no-op.
  • when adding default web module to VS during VS creation/edit, ensure that the selected app is indeed deployed to that VS.

Revisions:
----------
45798

Comment by Anissa Lam [ 31/Mar/11 ]

First nightly build from 3.2 is available. You can download it from
http://download.java.net/glassfish/3.2/nightly
mwessendorf , Please verify that this fixes your problem.





[GLASSFISH-15884] Unable to use a custom Keystore for SSL with embedded version Created: 08/Feb/11  Updated: 07/Apr/11  Resolved: 08/Feb/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

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

Windows XP SP3
Java 1.6 for business u18
Glassfish-embedded-all-b41.jar


Tags: 3_1-exclude, embedded, ssl

 Description   

Hello,

I'm trying to use a custom keystore to configure a HTTPS listener in glassfish with the following code :

GlassFish glassfish = GlassFishRuntime.bootstrap().newGlassFish();
glassfish.start();

// Create a web container, and https listener.
WebContainer webcontainer = glassfish.getService(WebContainer.class);
HttpsListener listener = new HttpsListener();
listener.setPort(9191);
listener.setId("https-listener-2");
listener.setProtocol("https"); // enable security
SslConfig sslConfig = new SslConfig();
sslConfig.setKeyStore("C:\\temp
mykeystore.jks");
sslConfig.setKeyPassword("Abcd1234");
sslConfig.setTrustStore(new File("C:\\temp
mykeystore.jks"));
listener.setSslConfig(sslConfig);
webcontainer.addWebListener(listener);

When a connect to my server in the 9191 port, the certificate used is not the one in my keystore, but the one located in

{instanceRoot}

/config/keystore.jks

After digging in the open and resolved issues on Embedded-Glassfish, it appears that the issue is caused by the fix of "GLASSFISH-14572 - Unable to create https listeners in embedded glassfish" which force the value of the KeyStore/TrustStore properties through the jvm-options in the embedded domain.xml (in org.glassfish.embed package)

After doing a rollback of the change (i.e removing the 2 jvm-options lines from the domain.xml) the glassfish server correctly use the system properties defined.

However, setting the KeyStore/TrustStore/Password through the org.glassfish.embeddable.web.config.SslConfig object does not seem to have any impact. If the system properties are set, they take precedence. If they are not set, the following error is thrown :

SEVERE: Failed to load keystore type JKS with path null due to null
java.lang.NullPointerException
at java.io.File.<init>(File.java:222)
at com.sun.grizzly.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:326)
at com.sun.grizzly.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:272)
at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.getKeyManagers(JSSE14SocketFactory.java:203)
...

Once the SslConfig usage is fixed, it would be nice to be able to change the KeyStore type to something else than JKS through the same object.



 Comments   
Comment by Bhavanishankar [ 08/Feb/11 ]

The fix for 14572 was to made so that HTTPS listener creation works out of the box. As you rightly pointed out, you can always specify -Djavax.net.ssl.keyStore and -Djavax.net.ssl.trustStore when launching your embedded program.

Assigning to web container to look into why the configurations specified programmatically via SslConfig don't take precedence over the system properties.

Comment by gastush [ 08/Feb/11 ]

The problem with setting -Djavax.net.ssl.keyStore when launching the program is that it gets overrideng by the "default" values taken from the domain.xml file.
Just do the following to see it in action :

System.out.println(System.getProperty("javax.net.ssl.keyStore"));
GlassFishRuntime gfr = GlassFishRuntime.bootstrap();
GlassFish glassfish = gfr.newGlassFish();
glassfish.start();
System.out.println(System.getProperty("javax.net.ssl.keyStore"));

run with java -Djavax.net.ssl.keyStore=somekeystore.jks argument

And you will see that the value before and after are different, which is not what I was expecting.
After starting the glassfish server, the javax.net.ssl.keyStore property contains the value defined in the domain.xml and not the one given on the command line.

Comment by Bhavanishankar [ 08/Feb/11 ]

Okay, I see. So, basically we have 2 issues here:

1. keyStore & trustStore settings from domain.xml is always getting used.

2. listener.setSslConfig(sslConfig) is not working as expected.

Workaround for #1 is to get the domain.xml from http://embedded-glassfish.java.net/domain.xml and change keystore/truststore vm options and use it while embedding GlassFish, like this:

GlassFishRuntime gfr = GlassFishRuntime.bootstrap();
GlassFishProperties gfProps = new GlassFishProperties();
gfProps.setConfigFileURI(new File("modified-domain.xml").toURI().toString());
GlassFish glassfish = gfr.newGlassFish(gfProps);
glassfish.start();

IMO, #1 is a generic issue in the sense that any vm options supplied by the user should always take precedence over what is in domain.xml. So, I will file a separate issue for #1, and leave this issue for addressing #2.

Comment by Bhavanishankar [ 08/Feb/11 ]

I meant "#1 is a generic issue in the sense that any 'system property' supplied by the user should always take precedence over what is in domain.xml's jvm-options."

Comment by Amy Roh [ 08/Feb/11 ]

The ability to configure SSL connector over the system properties will be implemented in 3.2.

Comment by Amy Roh [ 08/Feb/11 ]

Fixed

Sending web-embed/api/src/main/java/org/glassfish/embeddable/web/HttpsListener.java
Sending web-embed/api/src/main/java/org/glassfish/embeddable/web/config/SslConfig.java
Sending web-embed/impl/src/main/java/org/glassfish/web/embed/impl/WebContainerImpl.java
Transmitting file data ...
Committed revision 45006.





[GLASSFISH-15871] create-protocol gives {0} in error message Created: 06/Feb/11  Updated: 07/Apr/11  Resolved: 23/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b40
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-exclude

 Description   

When creating a duplicate protocol, backend specifies the protocol name by saying

{0}
GUI is showing this error msg from ActionReport to user, and thus is wrong also.

%asadmin list-protocols test
http-listener-1
http-listener-2
admin-listener
AAA-protocol
Command list-protocols executed successfully.


%asadmin create-protocol --target test AAA-protocol
remote failure: {0}

protocol already exists. Cannot add duplicate protocol.
Command create-protocol failed.



 Comments   
Comment by Chris Kasso [ 07/Feb/11 ]

Not a stopper for 3.1

Comment by Justin Lee [ 23/Mar/11 ]

fix for GLASSFISH-15871
clarify/simplify null check

File summary : 2 files affected in 1 modules.
Modules affected : admin

Module [admin]:
2 Modified files:
src/main/java/org/glassfish/web/admin/cli/CreateVirtualServer.java 43644=>45699
src/main/java/org/glassfish/web/admin/cli/CreateProtocol.java 41809=>45699

Committed at Mar 23, 2011 10:00:57 PM





[GLASSFISH-15866] Need to process EJB descriptors within .war for resource-adapter references Created: 05/Feb/11  Updated: 02/Dec/11  Resolved: 05/Feb/11

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: 4.0
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-exclude

 Description   

In order to determine the resource-adapter visibility for an application, we look at the applications descriptors for "resources", "resource-adapter-mid" related references.

In case of such a reference defined in an EJB in a .war, we seem to be missing them as we do not process "extensions" descriptors.

Fix would be to consider the extension descriptors of all of the bundle descriptors which will solve the potential issue.



 Comments   
Comment by Jagadish [ 05/Feb/11 ]

FIX INFORMATION :

svn log -v -r 44941
Modified Paths:
---------------
trunk/v3/connectors/connectors-internal-api/src/main/java/com/sun/appserv/connectors/internal/api/AppSpecificConnectorClassLoaderUtil.java





[GLASSFISH-15833] asadminenv.conf is included in distributions but not used Created: 04/Feb/11  Updated: 07/Apr/11  Resolved: 21/Feb/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b40
Fix Version/s: 3.1.1_b01

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

Tags: 3_1-exclude

 Description   

From a peek at the code this file does not appear to be referred to anywhere but in some upgrade code.
If its not used, why is it part of an installation in the first place?

Within support, when you are supporting multiple versions (I have 30+ installs on a machine) pretty much every domain is custom and putting the environment variable settings in the asadminenv.conf was a simple way of recording key config information and made administering and making changes to a particular install's domain simpler.

Environment variables are still supported, so I can set: AS_ADMIN_PORT, for example, but shouldn't the contents of the asadminenv.conf be read in and used as initial values that are then either overridden from first the environment, or by a command line argument.

If the use of the asadminenv.conf file is deprecated is that documented? There's no mention in the asadmin --help man page.

At the vary least if it is deprecated add a comment to the asadminenv.conf file to say so and make it clear that its contents are not used (though that won't help a customer that upgrades from 2.x to 3.1 and wonders why their settings aren't being used).

Personally I'd like it to stay and work as it did in 2.x - it was a very handy addition to 2.x and it'll be a shame to see it go.



 Comments   
Comment by Tom Mueller [ 04/Feb/11 ]

Agreed that the asadminenv.conf file is not used in v3 and should be removed from the distribution.

I have not found any mention of this file in either the 2.1 or 3.0 documentation for the asadmin command. Looked in these places:

3.0.1: http://download.oracle.com/docs/cd/E19798-01/821-1758/6nmnj7q2l/index.html
2.1.1: http://download.oracle.com/docs/cd/E19879-01/820-4332/6nfq9891d/index.html

So this appears to have been an undocumented feature, so it isn't surprising that there is no documentation that it went away.

In GlassFish 3.1, the glassfish/config/asenv.conf file can be used set environment variables for the asadmin command because the asadmin shell script sources asenv.conf. For example, to set the default port used by asadmin, add this to the file:

export AS_ADMIN_PORT=4849

Given this, the asadminenv.conf file is not needed anymore.

Comment by tecknobabble [ 04/Feb/11 ]

The asadminenv.conf was mentioned in the online help for the admin console.

Its not easy to provide a link to a copy as a result but if you logged into a 2.x domain, went to the help, the the "Application Server Profiles" and "To Create a Domain With a Specific Profile" both made a small mention about the asadminenv.conf file as the file that contained the setting for the default profile the asadmin create-domain command would use if there was no --profile <profile>.

But since the asenv.conf can be used then that's fine. It would save confusion if the asadminenv.conf file is removed from the distribution.

Comment by Tom Mueller [ 21/Feb/11 ]

Fixed in revision 45195 on the trunk.
The asadminenv.conf file has been removed from the distribution.