<< Back to previous view

[GLASSFISH-4306] GUI needs help in placing a 'stand by' msg. Created: 28/Feb/08  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-4305 standby msg when app is down for main... Open
Issuezilla Id: 4,306
Tags:
Participants: Anissa Lam, harpreet, jluehe and Tom Mueller

 Description   

This is AdminConsole-015 in
http://wiki.glassfish.java.net/Wiki.jsp?page=V3AdminConsoleImprovements

Placement of a configurable (with default) "stand by" message when an
application is down for maintenance or is in the process of being re-deployed

An admin_gui enhancement is opened, and now opening this as GUI depends on web
container for this.
GUI teams need web container to provide a way for achieving this.



 Comments   
Comment by harpreet [ 04/Mar/08 12:28 PM ]

changing target release from 9.1.1 to v3.

Comment by jluehe [ 18/Mar/08 03:54 PM ]

This is a request for an enhancement, not a bug.

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

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





[GLASSFISH-3468] Application Libraries - Specify in Sun DD Created: 06/Aug/07  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: danielrhoades Assignee: jluehe
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 3,468
Tags:
Participants: danielrhoades, Hong Zhang, jfarcand, jluehe and Tom Mueller

 Description   

The --libraries or "Libraries" field in asadmin can be used to specify
additional runtime library dependancies for applications.

Currently there is no way to add this information to the Sun DD, this prevents
applications depending on libraries being autodeployed and makes rapid
development in IDEs like Netbeans slower as the package has to be manually
deployed after each development iteration.

See forum thread for more information:

http://forums.java.net/jive/thread.jspa?messageID=229456



 Comments   
Comment by Hong Zhang [ 06/Aug/07 06:15 AM ]

Assign to Jan as web team owns the sun-web-app dd contents. The deployment team
will make the relevant deployment changes when this work starts.

Comment by Hong Zhang [ 06/Aug/07 06:15 AM ]

add myself to Cc

Comment by jfarcand [ 18/Feb/08 05:46 PM ]

Re-assign to myself.

Comment by jfarcand [ 02/Sep/08 10:25 AM ]

Re-assign to Jan to see what he thinks. It should be simple for us to implement
such support, except it will require a change to sun-web DTD....

Comment by Tom Mueller [ 06/Mar/12 09:55 PM ]

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





[GLASSFISH-4589] Add support for session tracking via SSL session id Created: 02/Apr/08  Updated: 06/Mar/12

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

Type: New Feature Priority: Major
Reporter: jluehe Assignee: jluehe
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 4,589
Tags:
Participants: jluehe and Tom Mueller

 Description   

See http://forums.java.net/jive/thread.jspa?threadID=38902&tstart=0



 Comments   
Comment by jluehe [ 26/Aug/08 02:09 PM ]

This is a new feature, and not the enhancement of an existing one.

Comment by jluehe [ 07/Apr/10 08:55 AM ]

Joe (java.net id "infosun") posted this interesting comment to the above froum
thread:

<comment>
Jan Luehe described a possible solution in his Blog "GlassFish Support for
Cookie-less HTTP Sessions"
http://blogs.sun.com/jluehe/date/200712

follow the example and replace his invoke method with the following code.

@Override
public int invoke(Request request, Response response) throws IOException,
ServletException
{
CoyoteRequest coyoReq = (CoyoteRequest) request;
coyoReq.getAttribute(Globals.CERTIFICATES_ATTR); // call
populateSSLAttributes();
String cid =
(String)coyoReq.getAttribute("javax.servlet.request.ssl_session");
if(cid != null)

{ coyoReq.setRequestedSessionId(cid); }

return INVOKE_NEXT;
}

works for me under Glassfish v2ur2.

Joe
</comment>

This should continue to work with GF v3.

All that's left to do would be to install this special-purpose valve (that is,
add it to the application's pipeline) for any application that had SSL
configured as its session tracking mode.

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

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





[GLASSFISH-7149] 1st access to resources in jars in web apps is slow Created: 05/Feb/09  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: Dies Koper Assignee: jluehe
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,149
Tags:
Participants: Dies Koper, jluehe and Tom Mueller

 Description   

When including a jar with resources in a web app's WEB-INF/lib, at the
moment a resource is first accessed from the application the jar's
contents is extracted into the generated directory.

This means that when there are many resources in a jar, there is a long
delay when accessing the first resource. This is also noticeable when
accessing the admin console each time after starting the domain.

Jan answered to my question about it in the dev ML:

--------------------------------
GlassFish inherited this behaviour from Tomcat.
The motivation for it is summarized in this Tomcat FAQ entry:

I want to redeploy web applications, how do I prevent resources from
getting locked?

Most locking issues will occur with JARs from /WEB-INF/lib, and are
useally caused by access through URLs. Tomcat has mechanisms to allow
avoiding locking. In Tomcat 5.0, a mechanism exists to prevent locking
when accessing resources using the getResource method of the URL
classloader (many applications, such as Xerces, do not set the use of
caching to false before opening the URL connection, causing
locking). If such a call occurs, resources inside the JARs will be
extracted to the work directory of the web application. In Tomcat 5.5,
this mechanism is disabled by default (as it has a non negligible
influence on startup times, and is often useless), and can be enabled
using the antiJARLocking attribute of the Context element.

GlassFish still enables antiJARLocking by default, and currently does
not provide any way of turning it off.

We should definitely support a way of turning antiJARLocking off
(and might want to consider turning it off by default), by honoring
the antiJARLocking attribute in Tomcat's context.xml, and adding a
similar property to sun-web.xml.
--------------------------------



 Comments   
Comment by Dies Koper [ 17/Nov/09 10:42 PM ]

Adding my comment to Jan at the time:
(I suspect the reason the Admin Console is now not packaged as a war anymore
because of this slow-down. I suppose fixing this issue would allow the Admin
Console or any other similar application to have reasonable performance even
packaged as a war/ear).

I do think a better solution is to do what the EJBClassLoader does, instead of
just disabling antiJARLocking.

What EJBClassLoader does in its getResource (findResource0 really) and
getResourceAsStream methods is, it wraps the stream to a resource with a special
stream class (SentinelInputStream) that has a close method. When an application
is redeployed, the container calls a method in the EJBClassLoader that will
close all streams of the resources explicitly.

This is much more reliable than waiting for the gc to kick in. It also solves
the problem of the URL connection's caching not disabled by the user application.

I don't think making antiJARLocking user configurable is the way to go,
especially when it is possible to solve the problem completely.

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

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





[GLASSFISH-10971] Ability to configure the usage of double quotes on the elements logged in to the access log Created: 11/Nov/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: imranbohoran Assignee: jluehe
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,971
Tags:
Participants: imranbohoran, jluehe and Tom Mueller

 Description   

The HTTP access log currently has a bunch of useful information that one can
choose to be logged. However these elements are all logged with surrounding
double-quotes. This poses problems for applications needing to scan these logs
based on predefied formats.
Therefore can we;
1. Have the access logging provide a configurable property that indicates what
character should be used and the default can be kept as double quotes.
2. Or (better) simply let the format definition be driven off based on what the
user has specified for. i.e. The user would say the format of the log to be;
%client.name% [%header.Host%] [%datetime%] "%request%" %status% %response.length%
where the logging would happen as
11.23.43.111 [www.example.com] [11/Nov/2009:09:33:54 +0000] "GET
/my-app/myresource.html HTTP/1.0" 200 233

I'd vote for (2) as it gives users to configure what ever they need using the
tokens provided by GF.

A discussion thad led to this enhancement request can be found at;
http://forums.java.net/jive/message.jspa?messageID=371289#371289

Thanks!!

Cheers
– Imran



 Comments   
Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

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





[GLASSFISH-11697] subdomain wildcard support Created: 17/Mar/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: pradyut Assignee: jluehe
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,697
Tags:
Participants: jluehe, pradyut and Tom Mueller

 Description   

Hi

I want to set up a virtual server for subdomain

my domain is redirected from
pradyut.dyndns.org

to pradyut.dyndns.org/WebApplicationSecurity

using a virtual server whose default web module is
WebApplicationSecurity
I have used the string "${com.sun.aas.hostName},pradyut.dyndns.org"
in the hosts of the virtual server

now to the question
if someone enters "newa.pradyut.dyndns.org"
how can i redirect to

pradyut.dyndns.org/WebApplicationSecurity/newa

or "*.pradyut.dyndns.org"
redirects to pradyut.dyndns.org/WebApplicationSecurity/*

Thanks
Pradyut



 Comments   
Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

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





[GLASSFISH-2098] Move the code that clears session from manager cache in the event of a failover to CoyoteRequest.doGetSession() Created: 18/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 9.1pe
Fix Version/s: not determined

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

Operating System: All
Platform: Sun


Issuezilla Id: 2,098
Tags:
Participants: gfbugbridge, jfarcand, jluehe and Tom Mueller

 Description   

Move the logic that, in the event of a failover (detected via jrouteId
mismatch), removes the session (matching the requested session id) from the
session manager's cache and loads it from the session manager's store, from

com.sun.enterprise.ee.web.sessmgmt.SessionLockingStandardPipeline()

to

org.apache.coyote.tomcat5.CoyoteRequest.doGetSession()

to ensure that the session cached in the request is never a stale session
obtained from the session manager's cache (when it should have been cleared from
the cache and loaded from the store).

Currently, this logic is implemented only when acquiring and foreground-locking
a session in the SessionLockingStandardPipeline.

If we didn't move the logic into CoyoteRequest, we'd have to duplicate it in

org.apache.catalina.core.StandardHostValve.invoke()

where we update a session's last accessed time (we don't want to update the last
accessed time of a stale session following a failover), and possibly other
places as well.



 Comments   
Comment by jluehe [ 18/Jan/07 05:34 PM ]

Adding lwhite to interest list

Comment by gfbugbridge [ 19/Jan/07 07:00 AM ]

<BT6515200>

Comment by jluehe [ 31/May/07 04:27 PM ]

Not a stopper.

Comment by jfarcand [ 18/Feb/08 05:49 PM ]

..and try to avoid adding dependencies of org.apache.catalina inside
org.apache.coyote so GlassFish can re-use the Grizzly's objects instead of the
Tomcat 5 one. The only way to do that is by making sure catalina object aren't
referenced in that package

Comment by Tom Mueller [ 06/Mar/12 09:58 PM ]

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





[GLASSFISH-3067] Could not get Attributes for WebModule MBean Created: 25/May/07  Updated: 19/Mar/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: llc Assignee: jluehe
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: File mbean.war    
Issuezilla Id: 3,067
Tags:
Participants: gfbugbridge, guojje, jluehe, llc, sirajg and Tom Mueller

 Description   

Running the AMX unit test com.sun.enterprise.management.base.GetSetAttributeTest results in the
following failures:

WARNING: Could not get Attributes for "amx:j2eeType=WebModule,name=//__asadmin/
web1,J2EEServer=server,J2EEApplication=null"
DefaultWebXML

WARNING: Could not get Attributes for "amx:j2eeType=WebModule,name=//
server/,J2EEServer=server,J2EEApplication=null"
DefaultWebXML

WARNING: Could not get Attributes for "amx:j2eeType=WebModule,name=//server/__wstx-
services,J2EEServer=server,J2EEApplication=null"
DefaultWebXML
Override

AMX gets these Attributes from the underlying com.sun.appserv MBean. The getting of them seems to
be flaky. When I ran the test again, I see different failures:

WARNING: Could not get Attributes for "amx:j2eeType=WebModule,name=//
server/,J2EEServer=server,J2EEApplication=null"
HasWebServices

WARNING: Attribute HasWebServices failed with class javax.management.AttributeNotFoundException:
HasWebServices

WARNING: Could not get Attributes for "amx:j2eeType=WebModule,name=//server/__wstx-
services,J2EEServer=server,J2EEApplication=null"
HasWebServices

WARNING: Attribute HasWebServices failed with class javax.management.AttributeNotFoundException:
HasWebServices



 Comments   
Comment by jluehe [ 25/May/07 02:54 PM ]

Hi Lloyd, when filing a regression bug, it would help if the exact build number
on which the regression was noticed was included in the bug report.

The only recent change in the JMX area that might be related has been an
incremental fix for:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=2999
("Web app in EAR breaks getChildTargetModuleID")

which added "name" to the list of MBean attributes of a web module, but I don't
see how this could have caused what you are seeing. Also, when accessing a web
module MBean via the HTML adaptor, I still see "hasWebServices", along with the
new "name" attribute, exposed.

Comment by llc [ 25/May/07 03:10 PM ]

It might be that this isuse has existed for some time (many months). That's why I can't say when.

Please note that some of the MBeans have the Attribute, and some do not. So you can't just check one
of them and assume it's OK.

Comment by jluehe [ 25/May/07 03:12 PM ]
      • Issue 3070 has been marked as a duplicate of this issue. ***
Comment by jluehe [ 25/May/07 03:57 PM ]

I've attached a simple WAR whose servlet retrieves all MBeans of type
"j2eeType=WebModule", and then logs (to server.log) the MBean's object name
along with all the MBean's attribute names and values.

Please deploy the WAR and access its servlet at this path: /mbean/MBeanServlet

You will see that for each web module, the "hasWebServices" attribute can be
read successfully and returns the expected value: It returns "false" for all the
system apps except for:

com.sun.appserv:j2eeType=WebModule,name=//server/__wstx-services,J2EEApplication=null,J2EEServer=server|#]

for which it returns "true".

So, I don't think this is a web container issue.

Please assign back to me if you feel differently.

Comment by jluehe [ 25/May/07 04:01 PM ]

Created an attachment (id=936)
Test webapp

Comment by gfbugbridge [ 25/May/07 05:01 PM ]

<BT6562475>

Comment by llc [ 29/May/07 04:39 PM ]

The problem is flaky success (or failure) of the Attributes. AMX just tries to get the Attributes, and they
sporadicaly fail. Yes, I think it's a problem in the com.sun.appserv MBean.

Quite possibly it's a timing issue--some sort of initialization problem. It is most definitely not an AMX
problem, and it most definitely exists.

Comment by llc [ 29/May/07 04:49 PM ]

[First, I don't know if this is a WebModule problem or an 'admin' problem--I just know it's not an AMX
problem.]

I tried jmxcmd (command line interface) directly against the com.sun.appserv:j2eeType=WebModule
MBeans, and the attributes cannot be obtained; see below; nothing is returned:

jmxcmd> find com.sun.appserv:j2eeType=WebModule
com.sun.appserv:j2eeType=WebModule,name=//__asadmin/,J2EEServer=server,J2EEApplication=null
com.sun.appserv:j2eeType=WebModule,name=//__asadmin/
web1,J2EEServer=server,J2EEApplication=null
com.sun.appserv:j2eeType=WebModule,name=//server/,J2EEServer=server,J2EEApplication=null
com.sun.appserv:j2eeType=WebModule,name=//server/
_JWSappclients,J2EEServer=server,J2EEApplication=_JWSappclients
com.sun.appserv:j2eeType=WebModule,name=//server/__wstx-
services,J2EEServer=server,J2EEApplication=null
jmxcmd> get tldScanTime com.sun.appserv:j2eeType=WebModule,*
jmxcmd> get defaultWebXml com.sun.appserv:j2eeType=WebModule,*
jmxcmd>

Here is a stack crawl from the server side showing an example of the failure:

[#|2007-05-29T16:43:22.405-0700|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|
_ThreadID=21;_ThreadName=RMI TCP Connection(18)192.168.1.5;_RequestID=88ba213a
b009-4816-91fe-cd2b79a161e2;|
javax.management.AttributeNotFoundException: Cannot find attribute tldScanTime get method name
at com.sun.org.apache.commons.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:
313)
at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.getAttribute(DynamicMetaDataImpl.java:96)
at com.sun.jmx.mbeanserver.MetaDataImpl.getAttribute(MetaDataImpl.java:181)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute
(DefaultMBeanServerInterceptor.java:638)
at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:659)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.getAttribute(Unknown Source)
at com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.getAttribute
(SunoneInterceptor.java:317)
at com.sun.enterprise.interceptor.DynamicInterceptor.getAttribute(DynamicInterceptor.java:192)
at com.sun.enterprise.management.support.DelegateToMBeanDelegate.getAttribute
(DelegateToMBeanDelegate.java:122)
at com.sun.enterprise.management.support.MappedDelegate.getAttribute(MappedDelegate.java:
244)
at com.sun.enterprise.management.support.AMXImplBase.delegateGetAttribute(AMXImplBase.java:
828)
at com.sun.enterprise.management.support.AMXImplBase.getAttributeInternal(AMXImplBase.java:
1061)
at com.sun.enterprise.management.support.AMXImplBase.getAttribute(AMXImplBase.java:1020)
at com.sun.enterprise.management.support.AMXImplBase.getAttributes(AMXImplBase.java:1119)
at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.getAttributes(DynamicMetaDataImpl.java:125)
at com.sun.jmx.mbeanserver.MetaDataImpl.getAttributes(MetaDataImpl.java:189)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttributes
(DefaultMBeanServerInterceptor.java:696)
at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttributes(JmxMBeanServer.java:686)
at com.sun.enterprise.interceptor.DynamicInterceptor.getAttributes(DynamicInterceptor.java:232)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1389)
at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run
(RMIConnectionImpl.java:1245)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation
(RMIConnectionImpl.java:1341)
at javax.management.remote.rmi.RMIConnectionImpl.getAttributes(RMIConnectionImpl.java:633)
at sun.reflect.GeneratedMethodAccessor286.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:613)

Comment by jluehe [ 31/May/07 02:31 PM ]
      • Issue 3074 has been marked as a duplicate of this issue. ***
Comment by jluehe [ 01/Jun/07 04:16 PM ]

Hmm, this seems to be working for me:

jmxcmd> connect --protocol sun-as-rmi --port 8686 --user admin --password-file
/home/luehe/pwd local-rmi
Established connection to local-rmi using sun-as-rmi
Connection local-rmi
(USER=admin,PASSWORD_FILE=/home/luehe/pwd,PASSWORD=adminadmin,PROTOCOL=sun-as-rmi,cache-mbean-info=false,HOST=localhost,PORT=8686)
is now the active connection

jmxcmd> find com.sun.appserv:j2eeType=WebModule
com.sun.appserv:j2eeType=WebModule,name=//__asadmin/,J2EEServer=server,J2EEApplication=null
com.sun.appserv:j2eeType=WebModule,name=//__asadmin/web1,J2EEServer=server,J2EEApplication=null
com.sun.appserv:j2eeType=WebModule,name=//server/,J2EEServer=server,J2EEApplication=null
com.sun.appserv:j2eeType=WebModule,name=//server/_JWSappclients,J2EEServer=server,J2EEApplication=_JWSappclients
com.sun.appserv:j2eeType=WebModule,name=//server/__wstx-services,J2EEServer=server,J2EEApplication=null

jmxcmd> get tldScanTime com.sun.appserv:j2eeType=WebModule,*
--com.sun.appserv:j2eeType=WebModule,name=//__asadmin/web1,J2EEApplication=null,J2EEServer=server--
tldScanTime=6

--com.sun.appserv:j2eeType=WebModule,name=//server/__wstx-services,J2EEApplication=null,J2EEServer=server--
tldScanTime=2

--com.sun.appserv:j2eeType=WebModule,name=//server/,J2EEApplication=null,J2EEServer=server--
tldScanTime=1

--com.sun.appserv:j2eeType=WebModule,name=//server/_JWSappclients,J2EEApplication=_JWSappclients,J2EEServer=server--
tldScanTime=1

--com.sun.appserv:j2eeType=WebModule,name=//__asadmin/,J2EEApplication=null,J2EEServer=server--
tldScanTime=670

jmxcmd> get hasWebServices com.sun.appserv:j2eeType=WebModule,*
--com.sun.appserv:j2eeType=WebModule,name=//__asadmin/web1,J2EEApplication=null,J2EEServer=server--
hasWebServices=false

--com.sun.appserv:j2eeType=WebModule,name=//server/__wstx-services,J2EEApplication=null,J2EEServer=server--
hasWebServices=true

--com.sun.appserv:j2eeType=WebModule,name=//server/,J2EEApplication=null,J2EEServer=server--
hasWebServices=false

--com.sun.appserv:j2eeType=WebModule,name=//server/_JWSappclients,J2EEApplication=_JWSappclients,J2EEServer=server--
hasWebServices=false

--com.sun.appserv:j2eeType=WebModule,name=//__asadmin/,J2EEApplication=null,J2EEServer=server--
hasWebServices=false

Comment by llc [ 01/Jun/07 04:17 PM ]

It works for me too, on a dual core machine. On quad core it fails.

Comment by jluehe [ 04/Jun/07 08:26 AM ]

This does not seem to be a regression after all. Therefore, removing
"regression" from issue summary.

Per llc:

It's a very strange bug--different Attributes fail at different times on my
quad-core machine. The dual core seems not to fail.

Downgrading to a P4.

Comment by jluehe [ 05/Jun/07 08:13 AM ]

Changing Summary line, since this is not a regression

Comment by sirajg [ 06/Jun/07 08:33 AM ]
      • Issue 3073 has been marked as a duplicate of this issue. ***
Comment by Tom Mueller [ 06/Mar/12 09:55 PM ]

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

Comment by guojje [ 16/Mar/12 03:13 AM ]

it is absolutely a issues, how soon will it be fixed?

Comment by guojje [ 19/Mar/12 05:39 AM ]

I have fixed it. it is a thread safe issues.

In class ManageMbean of commons-modeler project, the method createMbeanInfo does not aquire lock when it accessed the fields
(contains attributes,notification and so on).

so it is necessary to add syschronized(attributes) when access attributes.





[GLASSFISH-3559] V2: Roller deployed with default contextroot doesn't respond consistently Created: 30/Aug/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: sakthivelg Assignee: jluehe
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,559
Tags:
Participants: gfbugbridge, jluehe, sakthivelg and Tom Mueller

 Description   

I have deployed roller blog/weblogger onto GF v2.

It's responses were wierd, When reloading the roller URL in browser a few times
http://hostname:8080/roller/
I get either HTTP 500 error , right/expected response (sometimes) OR response
without css.

And CSS itself is retrieved fine every other time
http://hostname:8080/roller/roller-ui/styles/layout.css

After some playing around, I have redeployed roller to glassfish with "--
contextroot /roller" and it seems to work fine
>> asadmin deploy --contextroot /roller roller.war

Earlier i had deployed without any contextroot and so, context was
just "roller" with no leading/trailing "/"
>> asadmin deploy roller.war

Why is this so very unexpected behavior from GF?



 Comments   
Comment by jluehe [ 30/Aug/07 09:29 AM ]
      • Issue 3560 has been marked as a duplicate of this issue. ***
Comment by jluehe [ 30/Aug/07 09:31 AM ]
      • Issue 3561 has been marked as a duplicate of this issue. ***
Comment by jluehe [ 30/Aug/07 09:32 AM ]
      • Issue 3562 has been marked as a duplicate of this issue. ***
Comment by jluehe [ 30/Aug/07 09:32 AM ]
      • Issue 3564 has been marked as a duplicate of this issue. ***
Comment by jluehe [ 30/Aug/07 09:33 AM ]
      • Issue 3563 has been marked as a duplicate of this issue. ***
Comment by jluehe [ 30/Aug/07 09:56 AM ]

Fixing the bug's subcomponent

Comment by jluehe [ 30/Aug/07 10:08 AM ]

By default, the deployment uses the name of the WAR file to determine a webapp's
context root, i.e., when you deploy roller.war without overriding the context
root (either in sun-web.xml or on the asadmin command line), it will be deployed
at "/roller", effectively doing the same as:

asadmin deploy --contextroot /roller roller.war

When you get a 500 error, do you see any stack traces in your server.log that
might help us understand the issue? Also, could you attach your version of
roller.war to this issue, so I could try to reproduce locally?

Downgrading to a P4 for the time being. Issue might be related to your local setup.

Comment by sakthivelg [ 30/Aug/07 10:47 AM ]

"asadmin deploy roller.war" deplos with contextroot "roller" with no leading "/"
I am not sure, if there was any stack trace in the server.log
BTW, this apache-roller 4.0 RC (latest)

Comment by gfbugbridge [ 30/Aug/07 05:00 PM ]

<BT6599660>

Comment by Tom Mueller [ 06/Mar/12 09:55 PM ]

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





[GLASSFISH-3865] Enabling cache in SJSAS 9.1 results in default apps being ignored Created: 21/Nov/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: danielrhoades Assignee: jluehe
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,865
Status Whiteboard:

as91ur1-na

Tags:
Participants: danielrhoades, jfarcand, jluehe, sanandal and Tom Mueller

 Description   

See thread http://forums.java.net/jive/thread.jspa?messageID=246583

Enabling the HTTP cache (steps outlined in thread) results in default apps for
the virtual hosts on the app server being forgotten.

They will be remembered again on stop/start or by setting the default app to
null, then setting it back to the app again via the asadmin GUI. I've noticed
it effecting virtual hosts that have a default app assigned out of an EAR.

Thanks

Dan



 Comments   
Comment by jluehe [ 21/Nov/07 08:19 AM ]

Not a stopper for 9.1 UR1.

Comment by jfarcand [ 21/Nov/07 08:28 AM ]

Will take a look.

Comment by jfarcand [ 08/Jan/08 04:36 PM ]

Not sure we can fix/touch that old code for 9.1.1. Re-assign to Jan to see what
he thinks.

Comment by jluehe [ 08/Jan/08 05:42 PM ]

Hi Dan,

the thread under http://forums.java.net/jive/thread.jspa?messageID=246583 seems
to focus on "SJSAS 9.1 stops responding on 8080", for which you filed this bug:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=3861

But in the above thread, you also mention this:

> When I said stop responding... what I "actually" meant was:
>
> It seems to ignore default apps for virtual hosts immediately after
> saving the settings.

Do you see a "real hang" anywhere, or is it only that the default app seems to
be ignored? Is 3861 a duplicate of 3865?

Can you please send exact instructions on how to reproduce the "default app
being ignored" issue?

Thanks,

Jan

Comment by sanandal [ 11/Jan/09 07:01 AM ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 09:55 PM ]

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





[GLASSFISH-4702] exceptions thrown when attempt to deploy multiple portlet apps Created: 09/Apr/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: camucci Assignee: jluehe
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


File Attachments: Text File bug1168_2ndApp.war     Text File bug1168_portlets.war    
Issuezilla Id: 4,702
Tags:
Participants: camucci, Hong Zhang, jfarcand, jluehe, sanandal and Tom Mueller

 Description   

This issue was filed as a VWP/Woodstock bug, but exceptions seen in the domain
server.log would indicate a missing file in Glassfish and/or the Portlet
Container RC2:

Original bug filed: https://woodstock.dev.java.net/issues/show_bug.cgi?id=1168

Steps to reproduce :
1. Install NetBeans 6.1 Beta
2. Install Portal Pack plugins from http://portalpack.netbeans.org/nb6/download.html

  • Download portal pack 2.0 Beta 3 zip file and install all nbms inside
    that zip.
  • Download visual portlet builder nbm and install it.

3. Start NetBeans 6.1
4. Create a Web Application
5. On the web application Right Click > New > Visual Web JSF Portlet Page
6. Design your portlet application and create a war
7. Deploy the war on Portlet Container RC2 which is available at
https://portlet-container.dev.java.net/public/Download.html
8. Verify the deployed portlet at http://localhost:[port]/portletdriver/ is
displayed properly
9. Create/Deploy another portlet web application using step 4-7
10. Now go to the same url http://localhost:[port]/portletdriver/
You will notice that first portlet is not displayed properly. Only the second
one is displayed properly.

The exception thrown in the /glassfish/domains/domain1/logs/server.log is:

[#|2008-04-09T08:11:30.328-0400|WARNING|sun-appserver9.1|debug.com.sun.portal.portletcontainer.invoker|_ThreadID=22;_ThreadName=httpSSLWorkerThread-8080-1;bug1168_portlets.VisualWebJSF;_RequestID=8afd4a7d-9cc7-4bdb-a058-b74607b15cbc;|PSPL_PCCTXCSPPCI0006
: Exception thrown while rendering content for portlet window
bug1168_portlets.VisualWebJSF.
com.sun.portal.container.ContainerException:
PortletContainer.getMarkup():getting content java.io.FileNotFoundException:
/servlet/PortletAppEngineServlet
at
com.sun.portal.portletcontainer.impl.PortletContainer.getMarkup(PortletContainer.java:259)
at
com.sun.portal.portletcontainer.invoker.WindowInvoker.getPortletContent(WindowInvoker.java:322)
at
com.sun.portal.portletcontainer.invoker.WindowInvoker.render(WindowInvoker.java:242)
at
com.sun.portal.portletcontainer.driver.PortletContent.getContent(PortletContent.java:68)
at
com.sun.portal.portletcontainer.driver.DesktopServlet.getPortletContents(DesktopServlet.java:295)
at
com.sun.portal.portletcontainer.driver.DesktopServlet.getAllPortletContents(DesktopServlet.java:241)
at
com.sun.portal.portletcontainer.driver.DesktopServlet.doGetPost(DesktopServlet.java:134)
at
com.sun.portal.portletcontainer.driver.DesktopServlet.doGet(DesktopServlet.java:88)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at
org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
java.io.FileNotFoundException: /servlet/PortletAppEngineServlet
at
org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:732)
at
org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:384)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at
org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:855)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:703)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:660)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:578)
at
com.sun.portal.portletcontainer.impl.PortletContainer.invokePAE(PortletContainer.java:790)
at
com.sun.portal.portletcontainer.impl.PortletContainer.invokePAE(PortletContainer.java:673)
at
com.sun.portal.portletcontainer.impl.PortletContainer.getMarkup(PortletContainer.java:209)
at
com.sun.portal.portletcontainer.invoker.WindowInvoker.getPortletContent(WindowInvoker.java:322)
at
com.sun.portal.portletcontainer.invoker.WindowInvoker.render(WindowInvoker.java:242)
at
com.sun.portal.portletcontainer.driver.PortletContent.getContent(PortletContent.java:68)
at
com.sun.portal.portletcontainer.driver.DesktopServlet.getPortletContents(DesktopServlet.java:295)
at
com.sun.portal.portletcontainer.driver.DesktopServlet.getAllPortletContents(DesktopServlet.java:241)
at
com.sun.portal.portletcontainer.driver.DesktopServlet.doGetPost(DesktopServlet.java:134)
at
com.sun.portal.portletcontainer.driver.DesktopServlet.doGet(DesktopServlet.java:88)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at
org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)



 Comments   
Comment by Hong Zhang [ 09/Apr/08 06:14 AM ]

Assign to web container for initial investigation.

Comment by jfarcand [ 09/Apr/08 07:54 AM ]

Can you attach the war file directly? I can deploy file using vim Thanks!

Comment by camucci [ 09/Apr/08 08:04 AM ]

Created an attachment (id=1430)
1 of 2 very basic nb6.1/vwp project to demonstrate exceptions thrown

Comment by camucci [ 09/Apr/08 08:05 AM ]

Created an attachment (id=1431)
2nd war

Comment by jfarcand [ 23/Apr/08 07:06 AM ]

Re-assign to Jan...

Comment by sanandal [ 11/Jan/09 07:01 AM ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

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





[GLASSFISH-4984] [V3] Add "suspend" and "resume" container lifecycle methods Created: 02/May/08  Updated: 06/Mar/12

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 4,984
Status Whiteboard:

gfv3-prelude-excluded

Tags:
Participants: jluehe, kumara and Tom Mueller

 Description   

In V3, disabling a webapp (standalone or embedded in EAR) means stopping, and
enabling it means restarting it.

This is different from V2, where disabling a standalone webapp meant leaving the
webapp running, but causing any requests mapped to it to result in a 503
("Service Unavailable") response. Also in V2, disabling a webapp embedded in an
EAR meant stopping it. There has been a bug filed against V2 regarding this
inconsistent behaviour, see
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4173 ("Inconsistent
behavior for disable/re-enable of a war vs. an war in an ear").

See the following reply from Jerome in an email exchange him and I were having.
The plan is to add 2 new lifecycle methods in V3: "suspend" and "resume", which,
in the case of the web container, will have the same semantics as enable/disable
for a standalone webapp in V2 (i.e., "suspend" will simply mark the webapp as
unavailble, without stopping it, and will cause any requests mapped to it to
result in a 503 response).

-------BEGIN REPLY-------
so I think we need to carefully plan for this. For instance for backward
compatibility, it may be that enable/disable would continue to correspond to
start/stop while we could have new administrative commands suspend/resume to
correspond to new methods like you
suggested on the ApplicationContainer (suspend/resume maybe).

I am saying backward compatibility would mean that enable/disable lead to
start/stop because well since we have different incompatible behaviour between
web apps and the rest, we have to choose which one represented the intented
behaviour. So I am inclined to say that the web container was wrong but we can
certainly discuss that point.

We also need to understand that some container may not be able to do an
enable/disable, then if an application is deployed to several containers and one
of them is incapable or suspend/resume, i assume we should revert and fail the
corresponding suspend/resume action.

I really don't think we can fix the other container to support enable/disable
like the web container understands it today, unless we align them and that's
really not a deployment bug for Hong... so my proposal (which seems to just be a
slight digression of yours) is indeed to add methods to ApplicationContainer but
also add Admin commands and have the scenarios well defined when some containers
cannot support a suspend/resume command. Those new methods and commands should
be suspend/resume and we should keep the current start/stop semantics intact.
-------END REPLY-------



 Comments   
Comment by jluehe [ 12/May/08 02:56 PM ]

Incremental fix: Added suspend() and resume() methods to the various containers.
For now, only the web container implements these methods properly for
(standalone) WAR files. All other containers simply return false.

Sending
common/common-util/src/main/java/org/glassfish/deployment/common/DummyApplication.java
Sending
common/glassfish-api/src/main/java/org/glassfish/api/deployment/ApplicationContainer.java
Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/module/ConnectorApplication.java
Sending
core/kernel/src/main/java/com/sun/enterprise/v3/server/ApplicationLifecycle.java
Sending
distributions/external/grizzly-jruby/src/main/java/com/sun/enterprise/rails/RailsApplication.java
Sending
ejb/ejb-container/src/main/java/org/glassfish/ejb/startup/EjbApplication.java
Sending
ejb/ejb-container/src/main/java/org/glassfish/ejb/startup/EjbApplicationContainer.java
Sending
extras/phobos/src/main/java/com/sun/enterprise/phobos/GlassFishPhobosAdapter.java
Sending
persistence/jpa-connector/src/main/java/org/glassfish/persistence/jpa/JPAApplication.java
Sending
web/tomcat-connector/src/main/java/com/sun/enterprise/web/tomcat/TomcatApplication.java
Sending web/webtier/src/main/java/com/sun/enterprise/web/WebApplication.java
Sending web/webtier/src/main/java/com/sun/enterprise/web/WebContainer.java
Transmitting file data ............
Committed revision 20796.

Comment by kumara [ 19/Aug/08 10:41 PM ]

Add gfv3-prelude-include to status whiteboard

Comment by kumara [ 03/Sep/08 01:16 AM ]

v3 defect tracking

Comment by jluehe [ 04/Sep/08 10:30 AM ]

Not required for Prelude

Comment by kumara [ 24/Oct/08 08:14 PM ]

Reclassifying as P4 because these issues are not must fix for prelude release.
This issue will be scrubbed after prelude release and will be given the right
priority for v3 final release.

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

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





[GLASSFISH-5064] Enabling monitoring leads to InstanceNotFoundException Created: 25/May/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Scott Oaks Assignee: jluehe
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,064
Tags:
Participants: jfarcand, jluehe, llc, sanandal, Scott Oaks, sirajg and Tom Mueller

 Description   

I have created a simple cluster. In the admin GUI, I navigate to the C1-cluster
config section, monitoring service, and set all monitoring services to LOW. Now
whenever the DAS is restarted, it throws this exception (for lots of different
MBeans):

[#|2008-05-24T05:50:51.215-0700|SEVERE|sun-appserver9.1|javax.enterprise.system.
container.web.pwc|_ThreadID=19;_ThreadName=Thread-19;_RequestID=19f851d8-5c97-48
a8-9efc-053b9a6b035a;|PWC1002: Failed to read attribute requestCount from MBean
com.sun.appserv:j2eeType=Servlet,name=RegistrationRequesterPortTypeImpl,WebModul
e=//server/__wstx-services,J2EEApplication=null,J2EEServer=C1-instance2
javax.management.InstanceNotFoundException: This operation failed, because it co
uld not be handled by this domain.
An example of such an operation is creating application server instances or clus
ters when they are not supported by the given domain.
The actual error is: MBean instance not found: com.sun.appserv:j2eeType=Servlet,
name=RegistrationRequesterPortTypeImpl,WebModule=//server/__wstx-services,J2EEAp
plication=null,J2EEServer=C1-instance2
at com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.manufactur
eAndRegisterMBean(SunoneInterceptor.java:663)
at com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.registerWi
thPersistenceCheck(SunoneInterceptor.java:692)
at com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.getAttribu
te(SunoneInterceptor.java:315)
at com.sun.enterprise.interceptor.DynamicInterceptor.getAttribute(Dynami
cInterceptor.java:192)
at com.sun.enterprise.web.monitor.impl.PwcServletStatsImpl.queryStatisti
c(PwcServletStatsImpl.java:180)
at com.sun.enterprise.web.monitor.impl.PwcServletStatsImpl.getRequestCou
nt(PwcServletStatsImpl.java:152)
at com.sun.enterprise.web.stats.ServletTimeStatisticImpl.getCount(Servle
tTimeStatisticImpl.java:61)
at sun.reflect.GeneratedMethodAccessor114.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.appserv.management.util.j2ee.J2EEUtil.statisticToMap(J2EEUtil
.java:115)
at com.sun.appserv.management.j2ee.statistics.MapStatisticImpl.<init>(Ma
pStatisticImpl.java:90)
at com.sun.enterprise.management.monitor.MonitoringStatsImplBase.getStat
isticsFromDelegate(MonitoringStatsImplBase.java:643)
at com.sun.enterprise.management.monitor.ServletMonitorImpl.getStatistic
sFromDelegate(ServletMonitorImpl.java:94)
at com.sun.enterprise.management.monitor.MonitoringStatsImplBase.getStat
isticsFromDelegate(MonitoringStatsImplBase.java:551)
at com.sun.enterprise.management.monitor.MonitoringStatsImplBase.createS
tatsImpl(MonitoringStatsImplBase.java:698)
at com.sun.enterprise.management.monitor.MonitoringStatsImplBase.getStat
s(MonitoringStatsImplBase.java:752)
at com.sun.enterprise.management.monitor.MonitoringStatsImplBase.initSta
tisticNames(MonitoringStatsImplBase.java:422)
at com.sun.enterprise.management.monitor.MonitoringStatsImplBase.preRegi
sterHook(MonitoringStatsImplBase.java:915)
at com.sun.enterprise.management.support.AMXImplBase.preRegister(AMXImpl
Base.java:2215)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.preRegisterInvo
ke(DefaultMBeanServerInterceptor.java:1010)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamic
MBean(DefaultMBeanServerInterceptor.java:938)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(
DefaultMBeanServerInterceptor.java:917)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(D
efaultMBeanServerInterceptor.java:312)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.j
ava:482)
at com.sun.enterprise.interceptor.DynamicInterceptor.registerMBean(Dynam
icInterceptor.java:263)
at com.sun.enterprise.management.support.Loader.registerNew(Loader.java:
427)
at com.sun.enterprise.management.support.LoaderOfOld.registerNew(LoaderO
fOld.java:212)
at com.sun.enterprise.management.support.LoaderOfOld.ensureNew(LoaderOfO
ld.java:397)
at com.sun.enterprise.management.support.LoaderOfOld.syncWithOld(LoaderO
fOld.java:417)
at com.sun.enterprise.management.support.Loader._sync(Loader.java:548)
at com.sun.enterprise.management.support.Loader.sync(Loader.java:522)
at com.sun.enterprise.management.support.Loader.handleMBeanRegistered(Lo
ader.java:209)
at com.sun.enterprise.management.support.LoaderRegThread.processRegistra
tion(LoaderRegThread.java:204)
at com.sun.enterprise.management.support.LoaderRegThread.process(LoaderR
egThread.java:253)
at com.sun.enterprise.management.support.LoaderRegThread.run(LoaderRegTh
read.java:154)

#]


 Comments   
Comment by sirajg [ 28/May/08 06:43 AM ]

Update from LLoyd :

Synopsis: I've seen this before. Tomcat register MBeans prior to them being
prepared to service requests, eg statistics.

1. AMX gets a JMX Notification that a new MBean has been registered. In this
case it's some kind of monitoring MBean.

2. AMX calls getStats() to get the statistics so as to prepare the MBeanInfo,
deal with some bugs in the underlying layer, etc. This is MonitoringStatsImplBase.

3. Getting the Stats is OK, then AMX gets a Statistic, attempting to fetch the
count from it.

4. The Statistic implementation (tomcat's I think) is not ready to provided
statistics. In this case, it looks like it requires them from an MBean that
doesn't exist yet.

What you can do:
1. In Loader.registerNew(), print out the name of the MBean that AMX is being
told to register. You can do this at several points.
2. You can verify that the com.sun.appserv MBean that AMX is working with
actually is registered. It had to be or AMX wouldn't be dealing with it.
But one possibility is that it was registered then immediately unregistered. I
don't think that's the case; I think the InstanceNotFound is actually another
MBean required by the Stats impl.

In short, this is a lower layer bug, probably in the Tomcat code itself. I
reported it once, some time ago, but I hadn't seen it in a long time.

NOTE: debugging or logging may make the problem disappear, due to its
race-condition nature.

Comment by sirajg [ 28/May/08 01:16 PM ]

The mbean reported in the error message exists, as seen after startup.
The corresponding monitoring mbean also exists. An example of a monitoring mbean
would be :
com.sun.appserv:type=servlet,name=RegistrationRequesterPortTypeImpl,category=monitor,server=C1-instance2,webmodule-virtual-server=//server/__wstx-services

The error messages are sporadic - i.e. different servlet mbeans are not found
during different startups. Could be a race condition. Transferring to web
container as per previous comments.

Comment by llc [ 02/Jun/08 11:23 AM ]

Siraj,

What is going on here is a race condition created by the Tomcat MBean registration code, which registers
MBeans prematurely, before they are ready to respond to getAttribute(). In particular, AMX expects that any
of the com.sun.appserv MBeans, once registered, can respond to getAttribute(). In this case, AMX calls
getStatistics() which returns a PwcServletStatsImpl which tries to call an MBean that hasn't yet been
registered.

It's misleading to say "the MBean exists" unless you specify when and how that was determined. And
"looking" can make it exist in the sense that this is a race condition, and any code or debugger activity
changes the behavior. The exception occurs precisely because it does not exist when it's needed. That it
might exist 1 microsecond or 1ms or 1 second later doesn't help if it's needed just prior.

Really this should be fixed in the web container code. But there is probably a viable hack for AMX to retry
in the case of a failure.

Comment by llc [ 02/Jun/08 12:02 PM ]

I've take a close look at the code involved: com.sun.enterprise.web.monitor.implPwcServletStatsImpl. The
SAME FLAW EXISTS IN EVERY 'StatsImpl' class, so we're likely to get a whole series of escalations unless the
architectural flaw is fixed.

The reasons for the failure are glaring: the Servlet monitoring MBean is created before the MBean for the
Servlet itself is created. It is the monitoring MBean which returns an instance of PwcServletStatsImpl; PwcServletStatsImpl requires that the Servlet MBean exist already.

Key points about PwcServletStatsImpl:
1. Its constructor is not thread-safe, the usual "visibility" issues with 'servletObjName'.

2. The constructor squelches exceptions, leading to creation of a useless PwcServletStatsImpl with
'servletObjName' set to null, leading to further downstream exceptions.

3. The same brain-dead code repeats is repeated in other 'StatsImpl' classes.

4. It creates an ObjectName 'servletObjName ' for the Servlet it is going to return statistics from. But that
MBean is not yet registered.

5. When any of the getter methods are called, they call queryStatistic(), which calls server.getAttribute() on
the Servlet MBean that has not been registered.

In short, this is very poor quality code, with a fundamantally broken architecture.

What needs to happen:

  • the monitoring MBean must be registered only after the other MBean(s) upon which it depends have
    been registered.
  • should be thread-safe
  • should use common utility routines

...

This design flaw can be detected by inserting the following code into the constructor for
'PwcServletStatsImpl' (and all other such StatsImpl MBeans):

if ( ! server.isRegistered(<ObjectName.) ) {
throw new IllegalStateException("MBean " + objectName + "is not registered" );
}

The above code should be done for every ObjectName upon which the 'StatsImpl' depends.

Comment by llc [ 02/Jun/08 12:19 PM ]

Last comment: before we fix any of this, there are two key points:

1. The issue arises because AMX uses the newly-registred monitoring MBean. Eventually all the requisite
MBean(s) the monitoring MBean depends on apparently do get registered, it's just that those MBeans are
non-functional for some indeterminate period of time, typically a fraction of a second.

2. If the 'asadmin' CLI and our admin GUI do not use AMX for monitoring Servlets and web modules, then the
exceptions can be ignored.

3. Any users attempting to monitor via AMX are out of luck without a fix. This is probably a low priority.

Comment by jfarcand [ 17/Jul/08 02:37 PM ]

The Dispatcher is back -> Jan

Comment by jfarcand [ 17/Jul/08 03:04 PM ]

...

Comment by sanandal [ 11/Jan/09 07:01 AM ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 10:00 PM ]

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





[GLASSFISH-4649] NPE in server logs Created: 07/Apr/08  Updated: 05/Dec/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: pcmreddy Assignee: jluehe
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 4,649
Tags:
Participants: Askar Kalykov, jfarcand, jluehe, pcmreddy, sanandal and Tom Mueller

 Description   

We found the following exception in GlassFish server log. Is this is a known
issue? Is there any work around for this problem?

I do not have any special steps to reproduce this. How ever this Exception
appeared on two different machines with the following configuration.

We saw this problem twice in last two weeks.
Deployment was OK, We did not see any problem with application after the deployment.

This could cause problem in monitoring system due to spurious alerts.

Server details :
GlassFish V2
jdk1.6.0_05
Solaris 10 on T2K

java.lang.NullPointerException
at java.lang.String.startsWith(String.java:1422)
at java.lang.String.startsWith(String.java:1451)
at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:916)
at org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:491)
at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:774)
at org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1519)
at
org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1475)
at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:306)
at org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:903)
at org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:785)
at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:644)
at org.apache.coyote.tomcat5.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:436)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:237)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at
com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:380)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)



 Comments   
Comment by jfarcand [ 17/Jul/08 02:35 PM ]

The dispatcher is back -> Jan

Comment by sanandal [ 11/Jan/09 07:01 AM ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 09:57 PM ]

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

Comment by Askar Kalykov [ 05/Dec/13 03:54 AM ]

I also experienced same issue on my Glassfish 3.11 (SunOS 5.11)
-bash-4.1$ java -version
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) Server VM (build 20.4-b02, mixed mode)

Log excerpt:

Dec 5, 2013 5:37:59 AM org.apache.catalina.connector.CoyoteAdapter service
SEVERE: PWC3989: An exception or error occurred in the container during the request processing
java.lang.NullPointerException
at java.lang.String.startsWith(String.java:1421)
at java.lang.String.startsWith(String.java:1450)
at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:918)
at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:879)
at org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:523)
at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:794)
at org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1537)
at org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1493)
at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:324)
at com.sun.grizzly.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:1094)
at com.sun.grizzly.util.http.mapper.Mapper.internalMap(Mapper.java:961)
at com.sun.grizzly.util.http.mapper.Mapper.map(Mapper.java:820)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:512)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:271)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Dec 5, 2013 5:38:00 AM org.apache.catalina.connector.CoyoteAdapter service
SEVERE: PWC3989: An exception or error occurred in the container during the request processing
java.lang.NullPointerException
at java.lang.String.startsWith(String.java:1421)
at java.lang.String.startsWith(String.java:1450)
at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:918)
at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:879)
at org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:523)
at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:794)
at org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1537)
at org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1493)
at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:324)
at com.sun.grizzly.util.http.mapper.Mapper.internalMapWrapper(Mapper.java:1094)
at com.sun.grizzly.util.http.mapper.Mapper.internalMap(Mapper.java:961)
at com.sun.grizzly.util.http.mapper.Mapper.map(Mapper.java:820)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:512)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:271)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Dec 5, 2013 5:41:01 AM com.sun.enterprise.resource.pool.ConnectionPool deleteResource
WARNING: RAR5035:Unexpected exception while destroying resource from pool DOF. Exception message: Error while destroying resource :No more data to read from socket

Admins tried to start server (that was ok before) serveral times with no success until it eventually started up with no exception stacktraces. Also, there is following interesting entry in log file that was logged during these unsuccessful attempts:

INFO: ERROR: Bundle org.glassfish.fighterfish.osgi-jpa [263] Error starting file:/usr/share/glassfish3/glassfish/modules/autostart/osgi-jpa.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.fighterfish.osgi-jpa [263]: Unable to resolve 263.0: missing requirement [263.0] osgi.wiring.package; (&(osgi.wiring.package=org.eclipse.persistence.tools.weaving.jpa)(version>=2.2.0)))
Dec 5, 2013 9:05:24 AM
SEVERE: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.fighterfish.osgi-jpa [263]: Unable to resolve 263.0: missing requirement [263.0] osgi.wiring.package; (&(osgi.wiring.package=org.eclipse.persistence.tools.weaving.jpa)(version>=2.2.0))
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)





[GLASSFISH-10460] HTTP Service Access Log request filtering Created: 20/Oct/09  Updated: 06/Mar/12

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

Type: Improvement Priority: Trivial
Reporter: ggierer Assignee: jluehe
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,460
Tags:
Participants: ggierer, jluehe and Tom Mueller

 Description   

We have an active site which requires access logging for statistical purposes.
Currently access logs create 100MB+ of data per day. It would be very nice to
be able to configure the logging for certain url patterns (eg include all
requests ending in .html or .jsp, or perhaps containing the path /secure/* ).
This means we could exclude logging for items that are not of interest (in other
words I do not want to log requests for images, css, javascript etc.) This was
originally posted as a how-to question on the forums
(http://forums.java.net/jive/thread.jspa?threadID=68266&tstart=0).



 Comments   
Comment by jluehe [ 21/Oct/09 11:39 AM ]

Recategorizing

Comment by Tom Mueller [ 06/Mar/12 09:57 PM ]

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





Generated at Fri Apr 18 13:58:56 UTC 2014 using JIRA 4.0.2#472.