[GLASSFISH-6666] Ability to log to SLF4J Created: 29/Oct/08  Updated: 06/Jun/12

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

Type: Improvement Priority: Major
Reporter: cowwoc Assignee: naman_mehta
Resolution: Unresolved Votes: 25
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,666

 Description   

I'm trying to get Glassfish to log to slf4j instead of Java Logging but I've run
into a dead end: http://forums.java.net/jive/thread.jspa?threadID=52441&tstart=30

It would be great if the Glassfish logging mechanism was plugable or at the very
least if I could somehow get access to the original System.out object to pass
into slf4j.



 Comments   
Comment by niklash [ 31/Dec/08 ]
      • Issue 6666 has been confirmed by votes. ***
Comment by cowwoc [ 13/Feb/11 ]

Can someone from the Glassfish team please comment on this issue?

Comment by cowwoc [ 13/Feb/11 ]

http://hwellmann.blogspot.com/2010/12/glassfish-logging-with-slf4j-part-2.html contains a workaround for redirecting all Glassfish logs onto slf4j. I'm still looking for a way to redirect on a per-webapp basis.

Comment by cinhtau [ 14/Feb/11 ]

Per webapp basis you have to put an independent logback.xml and invoke JoranConfigurator directly. That's the trick. See http://logback.qos.ch/manual/configuration.html

Comment by cowwoc [ 14/Feb/11 ]

I understand, but you're still requiring me to place slf4j libraries in the global location and hook all java.util.logging instances to slf4j whether they want it or not.

Comment by orair [ 26/Jan/12 ]

If the logging libraries are on a shared place, configure Glassfish per webapp basis will probably need to create contexts. See http://logback.qos.ch/manual/loggingSeparation.html#ContextJNDISelector for more information.

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by cowwoc [ 01/Jun/12 ]

I ended up redirecting slf4j to java.util.logging (JUL). To do this simply use slf4j-jdk14 as your logger implementation in place of logback. Unfortunately, this trades off one problem for another.

On the one hand, your logging is unified. On the other hand, you inherit all the problems associated with JUL. You cannot use any logback-specific features. You cannot use logback.xml to configure your logging. In fact, you cannot even configure different logging rules per webapp (see GLASSFISH-18776). I ended up with the following code in my ServletContextListener:

@Override
public void contextInitialized(ServletContextEvent servletContextEvent)
{
  super.contextInitialized(servletContextEvent);

  // WORKAROUND: http://java.net/jira/browse/GLASSFISH-18776
  java.util.logging.Logger.getLogger("com.foo.bar").setLevel(Level.ALL);
}

It doesn't solve the problem of all webapps sharing the same logging configuration, but at least now the configuration is packaged in the webapp itself (as opposed to logging.properties in Glassfish's installation directory).

Comment by jthoennes [ 06/Jun/12 ]

We managed to deploy SLF4J as an OSGi bundle. So you can deploy it in the normal way instead of in the lib directory.
And the configuration could be done in the bundle activator.





[GLASSFISH-5922] V3 should output log message with ANSI escape sequence to generate colors Created: 05/Sep/08  Updated: 06/Mar/12

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

Type: Improvement Priority: Major
Reporter: vivekp Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Attachments: PNG File ansilog.png    
Issuezilla Id: 5,922

 Description   

Modern log generators output log messages using ANSI escape sequences so that
terminals (such as gnome-terminal) can display such log messages with the right
colours. For example, when a SERVER message is displayed, the SERVER would be
coloured read.

I will attach a screen shot where the Rails application log messages piped thru
the v3 logger appears color coded on Ubuntu gnome-terminal.

For example, here is the log message with the escape sequence characters:
-------------------
INFO: Upload Create (0.002076) INSERT INTO "uploads"
("filename", "content_type", "size", "created_at", "updated_at")
VALUES('183.patch', 'text/x-patch', 1960, '2008-09-04 00:12:41', '2008-09-04
00:12:41')
INFO: SQL (0.000380) SELECT
currval('public.uploads_id_seq')
INFO: Redirected to http://localhost:8080/uploader/uploads
INFO: Completed in 0.05216 (19 reqs/sec) | DB: 0.00885 (16%) | 302 Found
http://localhost/uploader/uploads

see the "[4;35;1" sequences, these are ANSI escape sequences to generate colors.



 Comments   
Comment by vivekp [ 05/Sep/08 ]

Created an attachment (id=1766)
colored log

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-18048] Deadlock in corba logging Created: 19/Dec/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: logging, orb
Affects Version/s: 3.1.1
Fix Version/s: 4.1.1

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

Attachments: Text File stack.txt    
Tags: 3_1_2-exclude

 Description   

We have encountered a deadlock coming from the corba code trying to do logging. It has happened several times over the past few days as load has increased on our production system. We have not previously seen this problem, so it likely takes specific load conditions to reproduce. Attached are stack traces from the two threads involved in the deadlock.



 Comments   
Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-19640] Need test-cases that use "list-jndi-entries" in "resources-admin-cli" tests Created: 06/Feb/13  Updated: 21/Sep/15

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

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

Issue Links:
Dependency
depends on GLASSFISH-19647 List-Jndi-Entries command is not retu... Resolved

 Description   

We currently have "resources-admin-cli" tests that tests various combinations of enabling resources in various targets.
We look for "list-xxx-resources" or "list-resource-refs" to validate them which primarily tests the configuration (domain.xml)

It is also necessary to check whether the JNDI entries are also present (or not present) when doing list-resource-refs tests.
We can use "list-jndi-entries" to make sure that the runtime also works as expected.






[GLASSFISH-10300] Failed to read attribute XXX from MBean com.sun.appserv:type=Manager,path=/logs,host=server if /logs failed to deploy Created: 15/Oct/09  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 10,300
Status Whiteboard:

V2.1.1_exclude

Tags: 3_1-exclude

 Description   

I get a whole bunch of errors in the logs each time I start glassfish, each
looking the same except a different attribute is reported; this seems to be
related to an app that failed to deploy.

If deployment fails, it should probably not bother with whatever is causing
these errors:

[#|2009-10-15T06:17:48.343-0700|SEVERE|sun-appserver9.1|org.apache.catalina.core.StandardContext|_ThreadID=10;_ThreadName=main;_RequestID=67431d93-b914-4021-8047-0830b9a68b1d;|PWC1300:
Error starting resources in context /logs|#]

[#|2009-10-15T06:17:48.343-0700|SEVERE|sun-appserver9.1|org.apache.catalina.core.StandardContext|_ThreadID=10;_ThreadName=main;_RequestID=67431d93-b914-4021-8047-0830b9a68b1d;|PWC4430:
Document base
/usr/local/glassfish/domains/domain1/applications/j2ee-modules/glassfish-dashboard
does not exist or is not a readable directory|#]

[#|2009-10-15T06:17:48.349-0700|SEVERE|sun-appserver9.1|org.apache.catalina.core.StandardContext|_ThreadID=10;_ThreadName=main;_RequestID=67431d93-b914-4021-8047-0830b9a68b1d;|PWC1306:
Startup of context /logs failed due to previous errors|#]

[#|2009-10-15T06:17:48.349-0700|INFO|sun-appserver9.1|org.apache.catalina.core.StandardContext|_ThreadID=10;_ThreadName=main;|PWC1240:
Container WebModule[/logs] has not been started|#]

[#|2009-10-15T06:17:48.367-0700|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web.pwc|_ThreadID=15;_ThreadName=Thread-12;_RequestID=8573594f-aae6-4863-9379-157dce0bdcf4;|PWC1002:
Failed to read attribute expiredSessions from MBean
com.sun.appserv:type=Manager,path=/logs,host=server
javax.management.InstanceNotFoundException: This operation failed, because it
could not be handled by this domain.
An example of such an operation is creating application server instances or
clusters when they are not supported by the given domain.
The actual error is: MBean instance not found:
com.sun.appserv:type=Manager,path=/logs,host=server
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.manufactureAndRegisterMBean(SunoneInterceptor.java:663)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.registerWithPersistenceCheck(SunoneInterceptor.java:692)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.getAttribute(SunoneInterceptor.java:315)
at
com.sun.enterprise.interceptor.DynamicInterceptor.getAttribute(DynamicInterceptor.java:192)
at
com.sun.enterprise.web.monitor.impl.PwcWebModuleStatsImpl.queryStatistic(PwcWebModuleStatsImpl.java:418)
at
com.sun.enterprise.web.monitor.impl.PwcWebModuleStatsImpl.getExpiredSessionsTotal(PwcWebModuleStatsImpl.java:248)
at
com.sun.enterprise.web.stats.WebModuleStatsImpl.getExpiredSessionsTotal(WebModuleStatsImpl.java:256)
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.admin.monitor.stats.GenericStatsImpl.getStatistic(GenericStatsImpl.java:119)
at
com.sun.enterprise.admin.monitor.stats.GenericStatsImpl.getStatisticsOneByOne(GenericStatsImpl.java:145)
at
com.sun.enterprise.admin.monitor.stats.GenericStatsImpl.getStatistics(GenericStatsImpl.java:136)
at
com.sun.enterprise.web.stats.WebModuleStatsImpl.getStatistics(WebModuleStatsImpl.java:347)
at
com.sun.enterprise.admin.monitor.registry.spi.StatsHolderMBeanImpl.getStatistics(StatsHolderMBeanImpl.java:398)
at
com.sun.enterprise.admin.monitor.registry.spi.StatsHolderMBeanImpl.invoke(StatsHolderMBeanImpl.java:213)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.invoke(Unknown Source)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at
com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at
com.sun.enterprise.management.support.DelegateToMBeanDelegate.invoke(DelegateToMBeanDelegate.java:184)
at
com.sun.enterprise.management.support.MappedDelegate.invoke(MappedDelegate.java:389)
at
com.sun.enterprise.management.support.DelegateInvocationHandler.invoke(DelegateInvocationHandler.java:98)
at com.sun.enterprise.management.monitor.$Proxy13.getStatistics(Unknown Source)
at
com.sun.enterprise.management.monitor.MonitoringStatsImplBase.checkUnderlyingMBean(MonitoringStatsImplBase.java:347)
at
com.sun.enterprise.management.monitor.MonitoringStatsImplBase.preRegisterHook(MonitoringStatsImplBase.java:912)
at
com.sun.enterprise.management.support.AMXImplBase.preRegister(AMXImplBase.java:2215)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.preRegisterInvoke(DefaultMBeanServerInterceptor.java:1010)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:938)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
com.sun.enterprise.interceptor.DynamicInterceptor.registerMBean(DynamicInterceptor.java:263)
at com.sun.enterprise.management.support.Loader.registerNew(Loader.java:427)
at
com.sun.enterprise.management.support.LoaderOfOld.registerNew(LoaderOfOld.java:212)
at
com.sun.enterprise.management.support.LoaderOfOld.ensureNew(LoaderOfOld.java:397)
at
com.sun.enterprise.management.support.LoaderOfOld.syncWithOld(LoaderOfOld.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(Loader.java:209)
at
com.sun.enterprise.management.support.LoaderRegThread.processRegistration(LoaderRegThread.java:204)
at
com.sun.enterprise.management.support.LoaderRegThread.process(LoaderRegThread.java:253)
at
com.sun.enterprise.management.support.LoaderRegThread.run(LoaderRegThread.java:154)

#]

Steps to reproduce:

1. Deploy a war
2. Delete the war folder without undeploying it
3. Now glassfish is angry

Sometimes we have to bypass glassfish' undeploy because glassfish won't start
due to something that is deployed; in that case we deleted the folder but
glassfish still tries to deploy it and then prints all those errors.



 Comments   
Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 07/Oct/10 ]

Excluding these issues from v3.1

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-10093] Warning: IllegalArgumentException: "timers" / OldTypesBase.oldObjectNameToJ2EEType Created: 08/Oct/09  Updated: 20/Feb/11

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 9.1peur2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: hegalor Assignee: naman_mehta
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,093
Status Whiteboard:

V2.1.1_exclude


 Description   

According to:

GlassFish log every startup and deploy:

[#|2008-10-10T13:45:33.511+0200|WARNING|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=16;_ThreadName=Thread-17;_RequestID=f3d46049-f163-4b65-b286-617e104cefcd;|java.lang.IllegalArgumentException:
"timers"
com.sun.enterprise.management.support.OldTypesBase.oldObjectNameToJ2EEType(OldTypesBase.java:153)
com.sun.enterprise.management.support.oldconfig.OldProps.<init>(OldProps.java:187)
com.sun.enterprise.management.support.LoaderOfOldMonitor.oldToNewObjectName(LoaderOfOldMonitor.java:265)
com.sun.enterprise.management.support.LoaderOfOld.syncWithOld(LoaderOfOld.java:415)
com.sun.enterprise.management.support.Loader._sync(Loader.java:548)
com.sun.enterprise.management.support.Loader.sync(Loader.java:522)
com.sun.enterprise.management.support.Loader.handleMBeanRegistered(Loader.java:209)
com.sun.enterprise.management.support.LoaderRegThread.processRegistration(LoaderRegThread.java:204)
com.sun.enterprise.management.support.LoaderRegThread.process(LoaderRegThread.java:253)
com.sun.enterprise.management.support.LoaderRegThread.run(LoaderRegThread.java:154)

#]

Is there any thing very bad, or is this only a wrong logging?



 Comments   
Comment by hegalor [ 08/Oct/09 ]
      • Issue 10093 has been confirmed by votes. ***
Comment by marina vatkina [ 08/Oct/09 ]

-> AMX

Comment by llc [ 08/Oct/09 ]

This is not relevant to V3, and never will be.

The message indicates that there is a configuration element which is not represented as an MBean.

It can safely be ignored.

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman





[GLASSFISH-2018] amx:j2eeType=X-WebModuleVirtualServerMonitor Created: 11/Jan/07  Updated: 20/Feb/11

Status: Reopened
Project: glassfish
Component/s: amx
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

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

Operating System: All
Platform: All


Issuezilla Id: 2,018

 Description   

AMX unit tests detect inconcistencey problems:

.getAllMonitoringStats, 25 MBeans: 58ms
checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//__asadmin/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError, msg = Statistic names for
"amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//__asadmin/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" obtained via Statistic names do not match those obtained via introspection:
via names:

{ActiveSessionsCurrent,ActiveSessionsHigh,ExpiredSessionsTotal,JSPCount,JSPErrorCount,JSPReloadCoun t,RejectedSessionsTotal,ServletProcessingTimes,Sessions,SessionsTotal}
via introspection: {ActiveSessionsCurrent,ActiveSessionsHigh,CachedSessionsCurrent,ContainerLatency,ExpiredSessionsTo tal,JSPCount,JSPErrorCount,JSPReloadCount,PassivatedSessionsCurrent,RejectedSessionsTotal,ServletPro cessingTimes,SessionPersistTime,SessionSize,Sessions,SessionsTotal}
checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//server/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError, msg = Statistic names for
"amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//server/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" obtained via Statistic names do not match those obtained via introspection:
via names:{ActiveSessionsCurrent,ActiveSessionsHigh,ExpiredSessionsTotal,JSPCount,JSPErrorCount,JSPReloadCount,RejectedSessionsTotal,ServletProcessingTimes,Sessions,SessionsTotal}

via introspection:

{ActiveSessionsCurrent,ActiveSessionsHigh,CachedSessionsCurrent,ContainerLatency,ExpiredSessionsTo tal,JSPCount,JSPErrorCount,JSPReloadCount,PassivatedSessionsCurrent,RejectedSessionsTotal,ServletPro cessingTimes,SessionPersistTime,SessionSize,Sessions,SessionsTotal}

Ran test method checkStatsClassSuppliesAllStatistics on 25 candidates in 306ms



 Comments   
Comment by gfbugbridge [ 17/Jan/07 ]

<BT>

Comment by gfbugbridge [ 17/Jan/07 ]

<BT6514375>

Comment by km [ 01/Feb/07 ]

Monitoring.

Comment by sirajg [ 15/Feb/07 ]

Some stats appear to be missing - need to add the missing stats

Comment by sirajg [ 23/Feb/07 ]

The difference in the 2 lists described in the bug report are the follo statistics :
CachedSessionsCurrent
ContainerLatency
PassivatedSessionsCurrent
SessionSize

These are all exposed to the user through the admin infrastructure in EE. There
may have been something wrong with the test that generated these results.

Comment by llc [ 27/Feb/07 ]

The error message is correct: the names do not match what is actually in the Stats object.

Comment by sirajg [ 12/Apr/07 ]

All the relevant monitoring statistics are exposed in admin interfaces.

Comment by llc [ 13/Apr/07 ]

The unit test is still failing. Looks like all the problems have been rectified except one: the Statistic
"PassivatedSessionsCurrent" is supplied from getStatistics(), but is not supplied in getStatisticNames():

checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//__asadmin/web1,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError,
msg = Statistic names for "amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//__asadmin/
web1,X-ApplicationMonitor=null,X-ServerRootMonitor=server" obtained via Statistic names do not
match those obtained via introspection:

via names:
ActiveSessionsCurrent, OK
ActiveSessionsHigh, OK
ExpiredSessionsTotal, OK
JSPCount, OK
JSPErrorCount, OK
JSPReloadCount, OK
RejectedSessionsTotal, OK
ServletProcessingTimes, OK
Sessions, OK
SessionsTotal OK

via introspection:
ActiveSessionsCurrent, OK
ActiveSessionsHigh, OK
ExpiredSessionsTotal, OK
JSPCount, OK
JSPErrorCount, OK
JSPReloadCount, OK
PassivatedSessionsCurrent, **** NOT OK ***
RejectedSessionsTotal, OK
ServletProcessingTimes, OK
Sessions, OK
SessionsTotal OK

1) testStatsClassSuppliesAllStatistics(com.sun.enterprise.management.monitor.MonitorTest)
java.lang.AssertionError
at com.sun.enterprise.management.AMXTestBase.testAll(AMXTestBase.java:562)
at com.sun.enterprise.management.monitor.MonitorTest.testStatsClassSuppliesAllStatistics
(MonitorTest.java:513)

Comment by sirajg [ 23/May/07 ]
      • Issue 3036 has been marked as a duplicate of this issue. ***
Comment by llc [ 25/May/07 ]

Statistic names come from other module classes. Not sure which exact piece of code to look at, but I think
it should be somewhere in
appser-core-ee\com.sun.enterprise.ee.web.stats.EEWebModuleStatsImpl or
appserv-core\com.sun.enterprise.web.stats.WebModuleStatsImpl

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman





[GLASSFISH-3894] fix AMX unit test failure: ProfilerConfig Created: 03/Dec/07  Updated: 06/Mar/12

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 3,894
Status Whiteboard:

as91ur1-na


 Description   

Investigate why a ProfilerConfig cannot be removed during the unit tests runs.

[java] [java] *** testing com.sun.enterprise.management.config.ProfilerConfigTest ***
[java] [java] .E.
[java] [java] Time: 0.026
[java] [java] There was 1 error:
[java] [java] 1)
testCreateRemoveProfiler(com.sun.enterprise.management.config.ProfilerConfigTest)java.lang.Assertion
Error: Can't remove ProfilerConfig from amx:j2eeType=X-JavaConfig,name=na,X-
ConfigConfig=server-config
[java] [java] at
com.sun.enterprise.management.config.ProfilerConfigTest.testCreateRemoveProfiler(ProfilerConfigTest.
java:123)
[java] [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] [java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] [java] at com.sun.enterprise.management.TestRunner.runSuite(TestRunner.java:103)
[java] [java] at com.sun.enterprise.management.TestRunner.testClass(TestRunner.java:112)
[java] [java] at com.sun.enterprise.management.TestRunner.runTests(TestRunner.java:131)
[java] [java] at com.sun.enterprise.management.TestRunner.runAll(TestRunner.java:333)
[java] [java] at com.sun.enterprise.management.TestMain.iterateTests(TestMain.java:925)
[java] [java] at com.sun.enterprise.management.TestMain.<init>(TestMain.java:887)
[java] [java] at com.sun.enterprise.management.TestMain.main(TestMain.java:220)



 Comments   
Comment by llc [ 03/Dec/07 ]

This is one of several fixed to yield a clean AMX unit test run.

Comment by sanandal [ 11/Jan/09 ]

"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 kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-3893] fix AMX unit test failure: BeeanPoolMonitors missing Container MBean Created: 03/Dec/07  Updated: 06/Mar/12

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 3,893
Status Whiteboard:

as91ur1-na


 Description   

Some xxx are missing their Container MBeans during the AMX unit test run. Investigate and determine
if this is a time/transition problem or a real issue with missing MBeans.

      • testing com.sun.enterprise.management.base.AMXTest ***
        .checkContainerObjectName failed for: "amx:j2eeType=X-BeanPoolMonitor,name=bean-pool,X-
        ApplicationMonitor=InboundMessageApp,X-EJBModuleMonitor=mailconnectorEjb.jar,X-
        MessageDrivenBeanMonitor=JavaMailMDB,X-ServerRootMonitor=server" with Exception of type
        javax.management.AttributeNotFoundException, msg = Attribute not found: "ContainerObjectName"
        [amx:j2eeType=X-MessageDrivenBeanMonitor,name=JavaMailMDB,X-
        EJBModuleMonitor=mailconnectorEjb.jar,X-ServerRootMonitor=server,X-
        ApplicationMonitor=InboundMessageApp,*]
        [java] [java] checkContainerObjectName failed for: "amx:j2eeType=X-
        BeanPoolMonitor,name=bean-pool,X-ApplicationMonitor=SimpleMessageApp,X-
        EJBModuleMonitor=mdb-simpleEjb.jar,X-MessageDrivenBeanMonitor=SimpleMessageEJB,X-
        ServerRootMonitor=server" with Exception of type javax.management.AttributeNotFoundException, msg
        = Attribute not found: "ContainerObjectName" [amx:j2eeType=X-
        MessageDrivenBeanMonitor,name=SimpleMessageEJB,X-EJBModuleMonitor=mdb-simpleEjb.jar,X-
        ServerRootMonitor=server,X-ApplicationMonitor=SimpleMessageApp,*]
        [java] [java] E.....Can't get container for: amx:name=bean-pool,X-
        EJBModuleMonitor=mailconnectorEjb.jar,X-ApplicationMonitor=InboundMessageApp,X-
        ServerRootMonitor=server,j2eeType=X-BeanPoolMonitor,X-MessageDrivenBeanMonitor=JavaMailMDB


 Comments   
Comment by llc [ 03/Dec/07 ]

This is one of several bugs that fixing will allow a clean AMX unit test run.

Comment by sanandal [ 11/Jan/09 ]

"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 kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-3892] fix AMX unit test failure: WebModuleVirtualServerMonitor statistics Created: 03/Dec/07  Updated: 06/Mar/12

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 3,892
Status Whiteboard:

as91ur1-na


 Description   

Failure is caused by underlying com.sun.appserv MBeans, fix needs to be done there.

WebModuleVirtualServerMonitor

..checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//server/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError, msg = Statistic names for
"amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//server/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" obtained via Statistic names do not match those obtained via introspection:



 Comments   
Comment by llc [ 03/Dec/07 ]

This is one of several fixes designed to allow a zero-error run of the AMX unit tests.

Comment by sanandal [ 11/Jan/09 ]

"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 kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-4093] incorrect state after stopping modules through AMX Created: 06/Feb/08  Updated: 20/Feb/11

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: v2.1
Fix Version/s: None

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

Operating System: Linux
Platform: Linux


Issuezilla Id: 4,093
Status Whiteboard:

as911-na


 Description   

Stopping a web module through AMX ends up in an incorrect state in its JSR77 MBean.

To reproduce the problem:

  • deploy a web module
  • look for the web nodule with AMX and get a J2EEDeployedObject.
  • invoke stop() on the J2EEDeployedObject that is in the STATE_RUNNING
    (1) state.
  • the web module is stopped and not available anymore in my browser
  • look again for the web module via AMX and check the state
  • the web module is in the STATE_STARTING (0) state !!!
  • after that you may invoke start() via AMX, the web module is restarted
    and gets STATE_RUNNING again.

Looks like it is a binary (0/1) state machine instead of following the states
described in StateManageable.



 Comments   
Comment by llc [ 11/Feb/08 ]

The request for attribute 'state' is passed through to the com.sun.appserv MBean, so this is a bug at
that level.

The logic in stop() looks correct, it's hard to see how the module could be in STATE_STARTING.

try

{ this.state = this.STOPPING_STATE; this.stateChanged("j2ee.state.stopping"); module.stop(this); this.state = this.STOPPED_STATE; this.stateChanged("j2ee.state.stopped"); }

catch(Exception ex)

{ this.state = this.FAILED_STATE; this.stateChanged("j2ee.state.failed"); if(ex instanceof RuntimeException) throw (RuntimeException)ex; throw new RuntimeException(ex); }

Furthermore, if the module is started in STATE_STARTING, an exception should be thrown:
public void start() {

if ((this.state == this.STARTING_STATE) ||
(this.state == this.RUNNING_STATE) ||
(this.state == this.STOPPING_STATE))

{ throw new RuntimeException( new Exception ("cannot start because the current state is " + this.state)); }

So none of this makes any sense at all; it's "impossible".

This would have to be debugged to understand what's going on.

Comment by llc [ 11/Feb/08 ]

Whlle the logic looks OK, the code is not thread safe; variable 'state' is not protected by anything. Still, it
seems highly unlikely to the the issue given typical write-through processor caches. To fix the thread
safety issue (but possibly not the bug), change the variable to:

private volatile int state = this.RUNNING_STATE;

However, there is also a setstate() method. I suspect that the problem is caused by an "external force"
which is whacking the 'state' variable to the wrong value, since the logic inside J2EEDeployedObjectMdl
seems OK.

Comment by harpreet [ 16/Apr/08 ]

assigning to Sreenivas for further investigation.

Comment by msreddy [ 16/Apr/08 ]

Based on jsr77, user is allowed to do such operations only when the
state-management attribute is set to true, in our case that is false.

Comment by harpreet [ 16/Apr/08 ]

Marking for next release

Comment by sanandal [ 11/Jan/09 ]

"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 kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 10/Feb/11 ]

It appears that a web module cannot even be stopped via JMX in 3.1.
When the operation is tried via jconsole, you get a InvocationTargetException

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman





[GLASSFISH-7089] Hierarchical Custom MBeans Created: 26/Jan/09  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 7,089
Status Whiteboard:

v2.1.1_exclude


 Description   

Provide a way to register a Custom MBean so it shows in a hierarchical layout in
the glassfish admin console.

For example if ObjetName is "user/agents:type=impl.Agent,name=agent1" it should
show a mbean call agent1 in a subtree called "agents" under "Custom MBeans"



 Comments   
Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-7011] GlassFish logging disappears with AIX Java 6 Created: 08/Jan/09  Updated: 06/Mar/12

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

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

Operating System: AIX
Platform: All


Issuezilla Id: 7,011

 Description   

Compared to Java 5 on AIX, the new Java 6 JVM from IBM (J9 1.6.0 SR2) ships with a jre/lib/logging.jar file
which appears to cause issues with GlassFish logging as expressed here: http://forums.java.net/jive/thread.jspa?messageID=323078#323078

Same instance of GlassFish running on Java 5 (SR8a) works as expected.



 Comments   
Comment by sanandal [ 11/Jan/09 ]

"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 David Delabassee [ 19/Feb/09 ]

adding delabassee in CC

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-13133] Glassfish 2.1 throws logger exceptions with JAVAAGENT option Created: 26/Aug/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: v2.1.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: sompr04 Assignee: naman_mehta
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 13,133
Status Whiteboard:

3.1-exclude


 Description   

HI,

When I am running an application with -javaagent option in GLASSFISH2.1, few
conflicts happened and the following exception is thrown in server.log

I searched in Google and I found that it is a known issue but solution was
nowhere mentioned.

One of our high priority customer is facing issues with this problem. Kindly
let us know if there is any solution/workaround for this problem.

Could not load Logmanager "com.sun.enterprise.server.logging.ServerLogManager"
java.lang.ClassNotFoundException:
com.sun.enterprise.server.logging.ServerLogManager
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.util.logging.LogManager$1.run(LogManager.java:168)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.<clinit>(LogManager.java:158)
at java.util.logging.Logger.getLogger(Logger.java:273)
at sun.awt.AppContext.<clinit>(AppContext.java:114)
at java.beans.Introspector.getBeanInfo(Introspector.java:157)
at com.wily.org.apache.log4j.config.PropertySetter.introspect
(PropertySetter.java:66)
at com.wily.org.apache.log4j.config.PropertySetter.getPropertyDescriptor
(PropertySetter.java:234)
at com.wily.org.apache.log4j.config.PropertySetter.setProperty
(PropertySetter.java:146)
at com.wily.org.apache.log4j.config.PropertySetter.setProperties
(PropertySetter.java:120)
at com.wily.org.apache.log4j.config.PropertySetter.setProperties
(PropertySetter.java:87)
at com.wily.org.apache.log4j.PropertyConfigurator.parseAppender
(PropertyConfigurator.java:640)
at com.wily.org.apache.log4j.PropertyConfigurator.parseCategory
(PropertyConfigurator.java:603)
at com.wily.org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers
(PropertyConfigurator.java:524)
at com.wily.org.apache.log4j.PropertyConfigurator.doConfigure
(PropertyConfigurator.java:408)
at com.wily.org.apache.log4j.PropertyConfigurator.configure
(PropertyConfigurator.java:340)
at com.wily.util.feedback.backend.log4j.Log4JBackend.configureFromProperties
(Log4JBackend.java:97)
at com.wily.util.feedback.WilyLog4JConfigureAndWatchHelper.onChange
(WilyLog4JConfigureAndWatchHelper.java:62)
at com.wily.util.ConfigurationWatcher.addConfigurationListener
(ConfigurationWatcher.java:147)
at com.wily.util.feedback.AsynchFeedbackChannel.setConfiguration
(AsynchFeedbackChannel.java:66)
at com.wily.util.feedback.CachingDelegatingFeedbackChannel.setConfiguration
(CachingDelegatingFeedbackChannel.java:212)
at
com.wily.introscope.agent.enterprise.EnterpriseAgent.setAgentFeedbackConfigurati
on(EnterpriseAgent.java:492)
at com.wily.introscope.agent.enterprise.EnterpriseAgent.loadLogConfiguration
(EnterpriseAgent.java:454)
at
com.wily.introscope.agent.enterprise.EnterpriseAgent.doPostConstructionInitializ
e(EnterpriseAgent.java:178)
at
com.wily.introscope.agent.runtime.java.enterprise.Java2EnterpriseAgent.doPostCon
structionInitialize(Java2EnterpriseAgent.java:37)
at com.wily.introscope.agent.ACommonAgent.postConstructionInitialize
(ACommonAgent.java:378)
at com.wily.introscope.agent.AgentShim.doCreateDelegate(AgentShim.java:594)
at com.wily.introscope.agent.AgentShim.createDelegate(AgentShim.java:503)
at com.wily.introscope.agent.AgentShim.getDelegateAgent(AgentShim.java:473)
at
com.wily.introscope.agent.AgentShim.ProbeBuilderEntryPoint_initializeAgentShim
(AgentShim.java:715)
at com.wily.introscope.api.instrument.JavaAgent.premain(JavaAgent.java:95)
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 sun.instrument.InstrumentationImpl.loadClassAndStartAgent
(InstrumentationImpl.java:323)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain
(InstrumentationImpl.java:338)



 Comments   
Comment by sompr04 [ 26/Aug/10 ]

Created an attachment (id=4744)
Server Log

Comment by tcrane [ 27/Aug/10 ]
      • Issue 13133 has been confirmed by votes. ***
Comment by naman_mehta [ 01/Sep/10 ]

Please provide me the steps to reproduce the same. Is this applicable to GF 3.1
also?

Comment by sompr04 [ 01/Sep/10 ]

Hi Naman,

We have a javaagent application which has logging as well. When JVM started,
our agent code runs in very beginning (in premain) and logs some infomration,
it tries to find com.sun.enterprise.server.logging.ServerLogManager class since
Glassfish is setting the following system property at startup.
<sysproperty key="java.util.logging.manager"
value="com.sun.enterprise.server.logging.ServerLogManager"/>

According to SUN
http://download.oracle.com/javase/1.4.2/docs/api/java/util/logging/LogManager.ht
ml,
we need to include the LogManager i.e. ServerLogManager class and related
classes in System Classpath.

But GlassFish is not including any JARs in system classpath.

The issue is reproducible only with 1.6 JDK where as in JDK1.5, the issue is
not reproducible.

You should be able to reproduce the issue with any JAVAAGENT that does logging
and in JDK 1.6.

Thanks
Pradeep

Comment by tcrane [ 01/Sep/10 ]

Naman,
When is GlassFish 3.1 going to be released? If it is released where is the link
to download? The customer is interested in 3.1 if it is released

Comment by naman_mehta [ 06/Oct/10 ]

If you consider this comment then in 3.1 we don't set any sysproperty for
logging. The issue is reproducible only with jdk 1.6 not in 1.5. So as per my
understanding this issue is not related to 3.1. Already it marked as 3.1-exclude.

I am lowering it's priority to P3 and need to test with v2.

Comment by naman_mehta [ 06/Oct/10 ]

Changing priority to P4 as need to fix in v2.





[GLASSFISH-11346] Cannot set custom log handler. Class load error. Created: 20/Dec/09  Updated: 06/Mar/12

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

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

Operating System: Windows XP
Platform: All


Issuezilla Id: 11,346

 Description   

When trying to set a custom log handler, either by using the GUI or by manually
modifying the 'logging.properties' file, a ClassNotFoundException is thrown.



 Comments   
Comment by carlavmott [ 04/Jan/10 ]

Is the class for the custom handler in the classpath? This will have to be done
manually. We recommend that you write the custom handler as an OSGi service so
it can be found automatically.

Comment by carlavmott [ 15/Feb/10 ]

I have not heard back on this issue so I'm down grading it. I believe the
problem is that the handler class is not in the server classpath and therefore
not found but I can not verify.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-11815] FINE logs have an incorrect syslog facility Created: 22/Apr/10  Updated: 06/Jan/11

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: v2.1.1
Fix Version/s: None

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

Operating System: Linux
Platform: Linux


Issuezilla Id: 11,815

 Description   

When syslog is activated, INFO and above logs are sent to syslog facility System
Daemons (3) as per the documentation but FINE logs are sent to syslog facility Mail
system (2)

on Debian Lenny. steps to reproduce:
1. add required package: apt-get install libstdc++5
2. from Glassfish admin, in Application server, check "Write to system log"
3. from Glassfish admin enable FINE logs
4. configure rsyslog.conf
$template debugFormat,"F%syslogfacility%P%syslogpriority% %msg%\n"
:msg, contains, "dhatim" /var/log/dhatim.log;debugFormat
5. generate logs from Glassfish. Output is:
F2P7 [#|2010-04-21T22:26:50.036+0200|FINE|sun-appserver2.1|...
F3P6 [#|2010-04-21T22:26:50.043+0200|INFO|sun-appserver2.1|...



 Comments   
Comment by carlavmott [ 26/Apr/10 ]

Is this bug in v2 or v3? The code for the two release is completely different.
It seems that you see this problem on v2.x, right?

Comment by pdechastellier [ 27/Apr/10 ]

this issue is on v2.1.1.

Comment by carlavmott [ 27/Apr/10 ]

Reassigning to Justin since he works on the v2.x stuff

Comment by Justin Lee [ 06/Oct/10 ]

reassigning

Comment by naman_mehta [ 06/Oct/10 ]

Not producible on 3.1 so will fix later on.

Comment by naman_mehta [ 06/Oct/10 ]

Changing priority to P4 as need to fix in v2.





[GLASSFISH-6565] NoClassDefFoundError: java/sql/NClob on undeploy Created: 16/Oct/08  Updated: 06/Jan/11

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

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

Operating System: Windows XP
Platform: PC


Issuezilla Id: 6,565
Status Whiteboard:

v3_exclude


 Description   

I am using v2 ur 2. I have started the AS with jdk 5 update 16.

I have a web app (attached).

I deploy the web app with asadmin.
it deploys "clean"

I hit the apps front page. http://localhost:8080/TravelCenter
I get an exception... which I expect, because the resources have not been
defined (shoot me I am lazy).

I use asadmin to undeploy the app.
I get the exception that triggered
http://www.netbeans.org/issues/show_bug.cgi?id=150332. The user that reported
this found the issue in v2.1 b56...

I checked the source of the app... it doesn't appear to use NClob.



 Comments   
Comment by Tim Quinn [ 17/Oct/08 ]

I am transferring this to the web team. In reading the stack trace in the
NetBeans issue I infer that the problem occurs as the web container is trying to
serialize session information as the app is stopped (as part of the undeployment).

Web folks, please send this back if you find that the problem implicates
deployment in some way.

  • Tim
Comment by jluehe [ 17/Oct/08 ]

Tim, you were right in assigning this to the web team.

I had already filed the following issue:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=6447
("Avoid serializing and saving sessions to file during un- or redeployment
(unless requested by user)")

based on a user request in the forum.

I'll go ahead and mark one as a duplicate of the other.

Comment by jluehe [ 17/Oct/08 ]

Duplicate of 6447

      • This issue has been marked as a duplicate of 6447 ***
Comment by vince kraemer [ 17/Oct/08 ]

Before we close this as a dup, I would like to know why the server is looking
for java.sql.NClob, when the server has been started under JDK 5.... and the
deployed app doesn't contain a reference to java.sql.NClob...

The ST makes me wonder if there is some component of V2 UR 2 which has been
compiled against JDK 6 and shipped in out Java EE 5 app server???

Comment by vince kraemer [ 17/Oct/08 ]

This also affects V2.1... and should probably be resolved in the v3 code line
and the v2 code...

Comment by sanandal [ 11/Jan/09 ]

"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 Justin Lee [ 21/Sep/09 ]

not a v3 bug

Comment by Justin Lee [ 19/Oct/10 ]

reassigning to the 2.x owner





[GLASSFISH-4518] Exceptions in server.log - dotted property names Created: 27/Mar/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: gopalan Assignee: naman_mehta
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,518
Status Whiteboard:

v3_exclude, v2.1.1_exclude

Tags: 3_1-exclude

 Description   

Lloyd L Chambers wrote:
> One theory (without looking at the parsing code): Properties with a "." in
them might not work (eg "com.sun.caps.domain.name"); they cannot be parsed
because the "." is the delimiter for dotted names themeselves.
>
> However, there is another similar problem I've seen with dotted names, so it
might not be a parsing problem.
>
> You can file a bug on this. Perhaps for V3 there can be a fix. For V2 it's
something that could be prioritized.
>
> Lloyd
>
> On Mar 26, 2008, at 7:40 PM, Gopalan Suresh Raj wrote:
>> I work in the SOA/BI division on the Java CAPS product.
>>
>> We take GlassFish and add Java CAPS, AM, and other Sun products on top of it
to create the Java CAPS product.
>>
>> When we install the product, and start the App Server, we get the following
exceptions in the server.log.
>>
>> On examining these, I am guessing these exceptions are being thrown from
either AMX or CLI. All of these are related to MBeans registered on the
com.sun.appserv domain. If you look at the MBeans in question, they are all
coming from MBeans that have a getProperties() operation with the keys that
either AMX or CLI is complaining about (I am guessing it is AMX or CLI since
they all happen with MBeans registered on the com.sun.appserv domain, and are
logged from javax.enterprise.system.tools.admin during application server
startup). These are logged on each and every startup of the GlassFish App Server.
>>
>> Can you advise on why this is happening, and what could be done to get rid of
these exceptions?
>>
>> Cheers
>> Gopalan.
>>
>>
>>
>>
[#|2008-03-26T17:09:40.897-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.XWS_ClientProvider.property.signature.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:40.913-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"domain.applications.lifecycle-module.JBIFramework.property.com.sun.jbi.home"|#]
>>
>>
[#|2008-03-26T17:09:40.929-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.XWS_ServerProvider.property.encryption.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:40.944-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.domain.name"|#]
>>
>>
[#|2008-03-26T17:09:40.944-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ClientProvider.property.security.config"|#]
>>
>>
[#|2008-03-26T17:09:40.960-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ClientProvider.property.encryption.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:40.960-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ServerProvider.property.security.config"|#]
>>
>>
[#|2008-03-26T17:09:40.975-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.applications.lifecycle-module.JBIFramework.property.com.sun.jbi.home"|#]
>>
>>
[#|2008-03-26T17:09:40.991-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ClientProvider.property.dynamic.username.password"|#]
>>
>>
[#|2008-03-26T17:09:41.054-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.name"|#]
>>
>>
[#|2008-03-26T17:09:41.054-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"domain.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.sslport"|#]
>>
>>
[#|2008-03-26T17:09:41.054-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ServerProvider.property.signature.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"domain.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.name"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.XWS_ClientProvider.property.dynamic.username.password"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"domain.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.port"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"domain.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.domain.name"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.XWS_ClientProvider.property.encryption.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ClientProvider.property.signature.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:41.085-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ServerProvider.property.encryption.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:41.085-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.sslport"|#]
>>
>>
[#|2008-03-26T17:09:41.085-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.port"|#]
>>
>>
[#|2008-03-26T17:09:41.100-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.XWS_ServerProvider.property.signature.key.alias"|#]
>>
>>
[#|2008-03-26T17:10:20.641-0700|INFO|sun-appserver9.1|com.sun.jbi.framework|_ThreadID=21;_ThreadName=httpWorkerThread-4848-1;|JBIFW0012:
JBI framework startup complete.|#]
>>
>>
[#|2008-03-26T17:10:21.344-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.deployment|_ThreadID=18;_ThreadName=Timer-10;|deployed
with moduleid = amserver|#]



 Comments   
Comment by mwhite [ 28/Jul/08 ]

Adding myself to receive notification of activity on this issue.

Comment by sanandal [ 11/Jan/09 ]

"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 vince kraemer [ 30/Mar/09 ]

this is generating questions from folks in the nbj2ee@netbeans.org...

http://www.netbeans.org/servlets/ReadMsg?list=nbj2ee&msgNo=10442

Since SGES v2.1 has shipped, I guess it is time to raise the priority again...

Comment by vince kraemer [ 15/Apr/09 ]

issue filed in NB issue tracker...
http://www.netbeans.org/issues/show_bug.cgi?id=162762.

Any news about this?

Comment by Alexis MP [ 24/May/09 ]

adding myself to CC list

Comment by vince kraemer [ 27/May/09 ]

closed an issue as a dup of the NB issue cited in
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4518#desc5

Comment by vince kraemer [ 27/May/09 ]

This issue is not closed yet. there was a new issue in the nb tracker, that I
closed as a dup of http://www.netbeans.org/issues/show_bug.cgi?id=162762...

Both these NB issues are really just a manifestation of this issue...

Comment by vince kraemer [ 19/Jun/09 ]

Here is another mention of this...
http://forums.java.net/jive/thread.jspa?messageID=352087

Comment by junqian [ 10/Aug/09 ]

This is an often-reported issue in the NetBeans IssueTracker. See
http://www.netbeans.org/issues/show_bug.cgi?id=146212. There are about 10
duplicates in this ticket.

Adding myself to the CC list.

Comment by kumara [ 01/Sep/09 ]

-> llc

Comment by kumara [ 02/Oct/09 ]

Does not apply to GlassFish v3 and hence excluded from tracking list.

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix for v2.1.1

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 07/Oct/10 ]

Excluding these issues from v3.1

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-15400] Stack overflow when referencing bad external resources Created: 31/Dec/10  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: 3.1_dev
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: rsmogura Assignee: naman_mehta
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish v3.1 b35



 Description   

When I try to reference invalid, bad configured external LDAP resource from Web application I got stack overflow exception.

Caused by: com.sun.faces.spi.InjectionProviderException: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Env-Prop: ldap/softperience@Field-Injectable Resource. Class name = eu.softper.common.auth.usermanagment.UserTest Field name=dirContext@java.lang.String@ldap/softperience@@ into class eu.softper.common.auth.usermanagment.UserTest
at org.glassfish.faces.integration.GlassFishInjectionProvider.inject(GlassFishInjectionProvider.java:194)
at com.sun.faces.mgbean.BeanBuilder.injectResources(BeanBuilder.java:205)
... 46 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Env-Prop: ldap/softperience@Field-Injectable Resource. Class name = eu.softper.common.auth.usermanagment.UserTest Field name=dirContext@java.lang.String@ldap/softperience@@ into class eu.softper.common.auth.usermanagment.UserTest
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:698)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:468)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:173)
at org.glassfish.faces.integration.GlassFishInjectionProvider.inject(GlassFishInjectionProvider.java:184)
... 47 more
Caused by: java.lang.StackOverflowError
at java.lang.StringCoding$StringDecoder.decode(StringCoding.java:140)
at java.lang.StringCoding.decode(StringCoding.java:173)
at java.lang.String.<init>(String.java:443)
at java.lang.String.<init>(String.java:515)
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 java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:352)
at com.sun.jndi.ldap.Connection.<init>(Connection.java:187)
at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:118)
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1580)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2652)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:53)
at com.sun.enterprise.resource.deployer.ExternalJndiResourceDeployer.installExternalJndiResource(ExternalJndiResourceDeployer.java:256)
at com.sun.enterprise.resource.deployer.ExternalJndiResourceDeployer.createExternalJndiResource(ExternalJndiResourceDeployer.java:126)
at com.sun.enterprise.resource.deployer.ExternalJndiResourceDeployer.deployResource(ExternalJndiResourceDeployer.java:105)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:90)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:548)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:548)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
<repeat....> at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:548)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)



 Comments   
Comment by juergenschmied [ 23/Mar/12 ]

I have the same error (on 3.1.2) :

23 Mrz 2012 12:33:12,625 FATAL WarnProzessMDB : Es ist ein unbekannter Fehler beim Verarbeiten einer Nachricht aufgetreten.
javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:454)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2547)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1899)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy425.versende(Unknown Source)
at my.package.transport._EJB31_GeneratedWarnFileVersandIntf__Bean_.versende(Unknown Source)
at my.package.WarnProzessMDB.onMessage(WarnProzessMDB.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4180)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5368)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1099)
at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
at $Proxy429.onMessage(Unknown Source)
at my.package.aqRa.inbound.AqJmsActivation$InboundWorker.run(AqJmsActivation.java:343)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:726)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:247)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:449)
... 24 more
Caused by: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:534)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:95)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:724)
... 26 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception beim Versuch, Res-Ref-Env-Property: file/XADisk@org.xadisk.connector.outbound.XADiskConnectionFactory@ resolved as: jndi: file/XADisk@res principal: null@mail: null
No Runtime properties
Database Vendor : null
Create Tables at Deploy : false
Delete Tables at Undeploy : false in class bc7.warn.process.bean.transport.WarnFileVersand durch Injection einzufügen: null
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:703)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:470)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:171)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1694)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:494)
... 28 more
Caused by: java.lang.StackOverflowError
at org.jvnet.hk2.config.ConfigModel$1.get(ConfigModel.java:114)
at com.sun.hk2.component.LazyInhabitant.getClassLoader(LazyInhabitant.java:117)
at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:122)
at com.sun.hk2.component.LazyInhabitant.type(LazyInhabitant.java:99)
at org.jvnet.hk2.config.Dom.domNodeByTypeElements(Dom.java:765)
at org.jvnet.hk2.config.ConfigModel$CollectionNode.get(ConfigModel.java:425)
at org.jvnet.hk2.config.Dom.getter(Dom.java:971)
at org.jvnet.hk2.config.ConfigBean._getter(ConfigBean.java:184)
at org.jvnet.hk2.config.ConfigBean.getter(ConfigBean.java:192)
at org.jvnet.hk2.config.Dom.invoke(Dom.java:921)
at org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
at $Proxy78.getResources(Unknown Source)
at com.sun.enterprise.config.serverbeans.Resources$Duck.getResources(Resources.java:105)
at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:959)
at org.jvnet.hk2.config.Dom.invoke(Dom.java:912)
at org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
at $Proxy78.getResources(Unknown Source)
at com.sun.enterprise.config.serverbeans.Resources$Duck.getResourceByName(Resources.java:157)
at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:959)
at org.jvnet.hk2.config.Dom.invoke(Dom.java:912)
at org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
at $Proxy78.getResourceByName(Unknown Source)
at com.sun.enterprise.connectors.util.ResourcesUtil.isEnabled(ResourcesUtil.java:737)
at com.sun.enterprise.resource.deployer.ConnectorResourceDeployer.createConnectorResource(ConnectorResourceDeployer.java:102)
at com.sun.enterprise.resource.deployer.ConnectorResourceDeployer.deployResource(ConnectorResourceDeployer.java:84)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:90)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
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.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
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.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:221)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:93)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
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)

Easy to reproduce:
Inject a SSB to a MDB where the SSB has a injected Ressource from a second RCA (in my case the XADisk RCA), disable the RCA, fire the MDB.





[GLASSFISH-970] amx AppserverConnectionSource failures return non published class Created: 18/Aug/06  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 970
Tags: 3_1-exclude

 Description   

If I have a Main program using appsrv-ext.jar for AMX usage, then if I enter a
wrong password in this code:

new AppserverConnectionSource(
AppserverConnectionSource.PROTOCOL_RMI, host, 8686, username,
WRONGpassword, null, null);

then I get an exception showing ClassNotFoundException for
"com.sun.enterprise.security.LoginException"

See:

Aug 15, 2006 5:49:14 PM com.sun.appserv.management.client.ProxyFactory getInstance
SEVERE: ProxyFactory.getInstance: Failure trying to create a new ProxyFactory:
java.lang.ClassNotFoundException: "com.sun.enterprise.security.LoginException
(no security manager: RMI class loader disabled)"
sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:375)
sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)



 Comments   
Comment by km [ 01/Feb/07 ]

This is a bit tricky to fix.

Comment by km [ 28/Mar/07 ]

I am not sure how this can be fixed without making rather massive changes.
For one, I think the security exception class should be an exposed interface.

I accept that it is rather embarrassing, but can't do much.

I tend to make it a P4. Do you agree?

Comment by gfbugbridge [ 05/Apr/07 ]

<BT6543236>

Comment by Tom Mueller [ 23/Jun/10 ]

Kedar no longer on project.

Comment by prasads [ 07/Oct/10 ]

Excluding these issues from v3.1

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-15557] server.log must be named server.txt on Windows Created: 13/Jan/11  Updated: 12/Jul/11

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: v2.1
Fix Version/s: None

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

Any edition of the Windows operating system



 Description   

The Windows operating system's Desktop manager is learning a file's content type (Text, JPG, MP3, Word, Excel, etc.) from it's extension (.txt, .jpg, .mp3, .doc, .xls, etc.). So a log file made up from ASCII characters like server.log must be named server.txt to allow opening it without manually selecting a viewer application (here: to automatically open it using NOTEPAD.exe, the system's default text viewer). This is not a big problem, but it is annoying, and it makes GlassFish feel like "not being a good Windows citizen".



 Comments   
Comment by mkarg [ 12/Jul/11 ]

I want to beg you that this issue is getting fixed. It is so annoying that I cannot double click on server.log to get it opened but must always explicitly select NOTEPAD (and NO, I do NOT want all files named ".log" to open with NOTEPAD, as lots of binary files also are postfixed ".log"). Please make GF a good Windows citicen and use the extension to reflect the TYPE, not the USE of the file!





[GLASSFISH-15643] Changing logger setting in admin GUI will generate malformed logging.properties file which cause weird behavior while restarting domain Created: 20/Jan/11  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_dev
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: liu_f_jian Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

Solaris 11 Express x64
JDK 1.6.0_21
Glassfish v3.1_b37, v3.1_b38


Attachments: File logging.properties    

 Description   

After changing logger setting in admin GUI, a malformed logging.properties file is generated in <domain dir>/config directory.

A sample file is in the attachment, please notice line 54, 55.

This malformed logging,properties will cause restarting the domain very slow, even the CLI tells the domain start successfully, the admin console could not be accessed from browser.



 Comments   
Comment by Anissa Lam [ 20/Jan/11 ]

What exactly did you change in the General Logger Setting page ?
Anyway, I debugged and confirm that GUI passes the attributes specified in that page correctly. I don't know why there is an additional line ".level=INFO" created.

However, even though i see this resulting line, I don't see slowness in starting the server and can access GUI without issue.

Assign to logging for evaluation.

Comment by naman_mehta [ 20/Jan/11 ]

.level=INFO is already part of logging.properties file. It's not newly created. I tried the same by changing log level multiple times but couldn't reproduce the same. There is no issue with starting domain.

I had reduced the priority for the issue.

hi liu, Please try one more time and check for the same.

Comment by naman_mehta [ 28/Mar/11 ]

Please reverify the same. Is it reproducible? Do you find any performance issue? If not then please close this issue.

Comment by myfear [ 25/Jan/12 ]

Came across this today, too!
But it's not reproducible

GlassFish Server Open Source Edition 3.1.1 (build 12).

What happened:
1) Start GF
2) open admin gui
3) switch to Configurations / server-config / Logger Settings / Tab Log Levels
4) Change any Logger Name (e.g. javax.enterprise.resource.webcontainer.jsf.config) to any other name: (e.g. net.eisele)
5) "New values successfully saved." but empty page ...
6) logging.properties was empty except the first two lines:

#GlassFish logging.properties list
#Wed Jan 25 21:18:14 CET 2012

7) Server start with asadmin start-domain failed with exception (which btw isn't really helpful here ):

Launching GlassFish on Felix platform
Completed shutdown of GlassFish runtime
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMa
in.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.server.logging.GFFileHandler.postConstruct(GFFileH
andler.java:159)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.
java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreato
r.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.jav
a:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.jav
a:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingIn
habitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantIm
pl.java:76)
at org.jvnet.hk2.component.Habitat$5.get(Habitat.java:701)
at java.util.AbstractList$Itr.next(Unknown Source)
at com.sun.enterprise.server.logging.LogManagerService.postConstruct(Log
ManagerService.java:374)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.
java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreato
r.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.jav
a:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.jav
a:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingIn
habitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantIm
pl.java:76)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.ja
va:229)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartu
p.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.
java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishI
mpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(Glass
FishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(O
SGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(
GlassFishMain.java:117)
... 6 more

Command start-domain failed.

Comment by naman_mehta [ 31/Jan/12 ]

I tried couple of times on latest 3.1.2 workspace but it's going fine for me.

When you get empty page, would you see any error in server.log file?





[GLASSFISH-18183] Download log files - DAS logs not downloaded consistently Created: 13/Jan/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 3.1.2_dev
Fix Version/s: None

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

ogs-3.1.2-b17.zip


Tags: 312_qa

 Description   

DAS log files are downloaded when downloading cluster log files but are not downloaded when downloading standalone instance log files. This behaviour should be consistent - either the DAS log files should always be downloaded or never.






[GLASSFISH-18336] Error starting remote, SSH instance after changing all log levels Created: 08/Feb/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 3.1.2_dev
Fix Version/s: future release

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

DAS on OEL 6 with JDK 7u3, b04
remote instance on Solaris 10 with JDK 7u3, b04
Firefox on Winxp


Attachments: Java Archive File console-common.jar     JPEG File error-starting-instance.JPG     JPEG File logging-error-saving-changes.JPG     Text File logging.properties.das.txt     Text File logging.properties.instance.txt     Text File LoggingHandlers.diff.text     Text File server.log.badfileexception.txt     Text File server.log.das.txt     Text File server.log.instance.txt    
Tags: 312_qa, 312_regression

 Description   

After changing all log levels for a remote instance, on SSH node, to WARNING, instance fails to start with the following error in Admin Console:

An error has occurred
Could not start instance intp on node tuppy (tuppy). Command failed on node tuppy (tuppy): CLI801 Instance is already synchronized Waiting for intp to start ..........Command start-local-instance failed. Error starting instance intp. The server exited prematurely with exit code 1. Before it died, it produced the following output: Launching GlassFish on Felix platform Completed shutdown of GlassFish runtime Exception in thread "main" 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:601) 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. .... msg.seeServerLog

Attaching server.log files.

I have tried it several times with b20 and b21 and it always happens in my setup with a remote instance on an SSH node. I does not happen when instance is on a DCOM node or on localhost. Changing just one or two log levels for an instance on SSH node does NOT trigger this error. However, I'm still logging this as a Major issue, so we at least investigate it, since this is not an unlikely scenario, to set all log levels to warning on a production system.

Steps to reproduce:

1. Create a remote SSH node.
2. Create a standalone instance under the new node and start it.
3. In Admin Console go to instance's configuration, Logger Settings, Log Levels.
4. Select checkboxes for all loggers, WARNING for Log Level drop down and click on Change Level. Then click on Save.
5. Go back to instance page and stop it.
6. Start the instance and the above mentioned error is displayed.



 Comments   
Comment by lidiam [ 08/Feb/12 ]

Once I change log levels to INFO for all loggers, and set com.sun.enterprise.server.logging.GFFileHandler level to ALL, instance starts fine once again. However, if I only change all log levels to INFO, instance still fails to start with the same exception. Please note that there is no "Load Default" button on this page, so user will have hard time finding out what were the default settings (it can be seen in default-conifg).

Comment by naman_mehta [ 08/Feb/12 ]

As per the error looks like logging.properties files are missing some entries on SSH node.

Can you send me logging.properties files from ssh machine?
Have you changed log levels through admin console?
Can you share same machine with me so I can check the same?

Comment by lidiam [ 08/Feb/12 ]

Attaching logging.properties.instance.remote.txt file - this is logging.properties file on the remote SSH node, under <glassfish home>/glassfish/nodes/tuppy/intp/config/intp-config directory.

Comment by lidiam [ 08/Feb/12 ]

I performed all operations from Admin Console, as described in steps to reproduce section. I attached logging.properties for the instance on the remote SSH node - the file is the same as on the DAS system, under domain1/config/intp-config (diff shows no difference). I also sent you an email with the machine information.

Comment by naman_mehta [ 08/Feb/12 ]

logging.properties file is correct...

Have you changed log levels through admin console? Can you share same machine with me so I can check the same? Is it reproducible/occasionally?

Comment by lidiam [ 08/Feb/12 ]

I have changed the log levels back to info, in order to see if instance would start then. I already wrote that all operations were performed through Admin Console, including setting the log levels. Please see the section above that starts with "Steps to reproduce". It is reproducible each time all log levels are set to WARNING.

Comment by naman_mehta [ 08/Feb/12 ]

I tried on my local machine with use of ssh node on another machine on linux but couldn't able to reproduce the same. I tried several times but no success.

Then, I tried on same machine and same setup having this issue filed but after several runs it couldn't be reproducible.

Comment by naman_mehta [ 08/Feb/12 ]

Lidia,

Please try yourself again on same machine by creating new node and new instance. If it's reproducible for you then stop using this machine. Let me know, I will debug same on this machine only by doing remote debug.

Comment by naman_mehta [ 08/Feb/12 ]

I would able to identify the issue: Sometimes logging.properties file is missing entries

Initially logging.properties file contains:
"logging.properties" 69 lines, 3756 characters

now after updating log levels from admin console
"logging.properties" 46 lines, 2285 characters

So missing some properties which is causing failure....

Comment by naman_mehta [ 08/Feb/12 ]

When you change log levels through admin console it's going to update logging.proeprties file on DAS and then trying to replicate on the instance machine. But sometimes we are stopping instance before replication is successful and which corrupts the logging.properties file on remote machine. If you check logging.properties file on DAS it's up to date and corrupted on remote machine.

Now, next time when you trying to start instance it's looking for some properties on startup and which are missing there and so it's not coming up.

Solution is to to avoid catastrophic failure in the absence of a user defined configuration property like com.sun.enterprise.server.logging.GFFileHandler.file.

Comment by lidiam [ 08/Feb/12 ]

I tried the following on newly created instance:

1. Changed all log levels to WARNING, waited 25 seconds after Admin Console reported logging changes saved.
Result: instance started fine.

2. Changed all log levels to INFO, waited 20 seconds after Admin Console reported logging changes saved.
Result: instance started fine.

3. Chagned all log levels to SEVERE - could not save the change with the following error in Admin Console:

An error has occurred
An error occurred during replication Failure: Command set-log-levels failed on server instance inbif: remote failure: Could not set logger levels for inbif-config. Failure: Command set-log-levels failed on server instance inbif: remote failure: Could not set logger levels for inbif-config.

The following exception was in the instance's server.log:

[#|2012-02-08T15:05:16.277-0800|SEVERE|oracle-glassfish3.1.2|null|ThreadID=19;
ThreadName=Thread-2;|Cannot read logging.properties file :
java.io.IOException: Bad file number
at java.io.FileInputStream.readBytes(Native Method)

I'm attaching instance's server.log as server.log.badfileexception.txt.

Comment by lidiam [ 09/Feb/12 ]

It looks like stopping of the instance is NOT the cause of bad logging.properties file being written to the remote machine. This looks like an intermittent problem with writing full logging.properties file to the remote machine. Once the "bad" file is written, I can wait for a minute before restarting server and it is not getting corrected. Here is what I tested:

1. Change all log levels and save.
2. Wait 30 seconds after save.
3. Compare size of logging.properties files on DAS and remote system.
4. Restart instance.

While executing the above, logging.properties file got corrupted on the 4th attempt - size differed between DAS and remote and instance failed to start. I tested further and again hit the issue on the 6th attempt (or 10th, 4 + 6 new attempts). The trouble is that once the instance cannot be started I can only fix it by manually copying logging.properties file from DAS to the instance. Other changes, also to logging properties, don't seem to trigger copying the file over.

Comment by lidiam [ 09/Feb/12 ]

I'm attaching logging.properties files from the time of failure:

t# ls -l logging.p*
rw-rr- 1 j2eetest green 3659 Feb 8 15:36 logging.properties.das
rw-rr- 1 j2eetest green 1278 Feb 8 15:36 logging.properties.instance

Comment by lidiam [ 09/Feb/12 ]

Example of error in Admin Console when logging changes cannot be saved due to corrupted logging.properties file.

Comment by lidiam [ 09/Feb/12 ]

Attaching logging.properties files with txt extension for easier viewing.

Comment by Joe Di Pol [ 09/Feb/12 ]

Workaround is to manually copy the logging.properties from the DAS to the instance that can't start.

Comment by naman_mehta [ 09/Feb/12 ]

set-log-level command has capability to update multiple log levels simultaneously.

Usage of command:
./asadmin set-log-levels --target in5-config javax.enterprise.system.container.cmp=INFO:javax.enterprise.resource.webcontainer.jsf.application=INFO:javax.enterprise.system.ssl.security=INFO

Here, all logger name are : separated.

In this scenario, logging back end code will open logging.properties files once update all log levels as passed and closing logging.properties file. So here all log levels are updated in single file operation.

--------------------------------------------------------------------------------------------------------

In current scenario, when user updates all log level through admin console by selecting all logger names, it passes single logger name and log level to back end code then next time passes another logger name and log level. So if glassfish has 46 loggers it has 46 back end calls and due to that file operation is also becomes multiple of 46 and which causes file related exception in back end code.

Instead of this admin gui can consolidate all log levels with : separated as above and pass to back end code which cause single file operation and it avoids file related exceptions.

Comment by naman_mehta [ 09/Feb/12 ]

One more thing I monitored,

If user changes single log level for admin console then also it passes all logger names and levels to the back end code.

So for single log level updates from GUI also making 46 back end calls to set-log-level command.

Comment by Rebecca Parks [ 09/Feb/12 ]

Added to the 3.1.2 Release Notes:

Description

Changing all log levels on a remote SSH server instance before stopping the instance can cause the instance to fail to restart.

Workaround

Manually copy the logging.properties file from the domain administration server (DAS) to the server instance that won’t restart.

Comment by lidiam [ 09/Feb/12 ]

Now that this issue is understood fully I'm upgrading it to P2, after talking to Sudipa. Since logging.properties file is relatively likely to get corrupted, we should fix this issue for 3.1.2 if another show stopper is found for this release. I'm also reassigning to Admin Console, to evaluate the possible fix proposed by Naman.

Comment by Anissa Lam [ 09/Feb/12 ]

Agree that GUI shouldn't call changing of one log level at a time. Thats bad for performance too. I have fixed that in the trunk for 4.0

Log Message:
------------
Improve performance of GUI when changing log levels and to work around a bug in logging, GLASSFISH-18336
Revisions:
----------
52523
Modified Paths:
---------------
trunk/main/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java

I am attaching the diff for 3.1.2 in case management believe this needs to be in 3.1.2 too.

Comment by Anissa Lam [ 09/Feb/12 ]

Previous comment from Naman says:
"When you change log levels through admin console it's going to update logging.proeprties file on DAS and then trying to replicate on the instance machine. But sometimes we are stopping instance before replication is successful and which corrupts the logging.properties file on remote machine. "

Console code is using the correct API but of course should be more efficient, should call set-log-levels once instead of in a loop. I fixed this in the trunk now. I feel that the console change is just masking the root problem.
Besides triggered by console, will there be other situation that the replication failed affecting logging.properties ?

I am changing this back to logging for Naman to put in the proper fix, maybe by catching the NPE.
Caused by: java.lang.NullPointerException
at com.sun.enterprise.server.logging.GFFileHandler.postConstruct(GFFileHandler.java:162)

Comment by Anissa Lam [ 10/Feb/12 ]

Attached console-common.jar which has the changes in console for 3.1.2.

To test this:
install OGS promoted build 21.
cd <glassfish-install>/glassfish/modules
mv console-common.jar console-common.jar.ORIG
cp <Download>/console-common.jar .

rm -rf <glassfish-install>/glassfish/domains/domain1/osgi-cache

restart domain.

Comment by lidiam [ 10/Feb/12 ]

Tested patch on existing build. It works like a charm. Tried the scenario 10 times and did not see the issue. Also, now log levels update takes less than a second (before it was taking around 12 seconds). I didn't wait at all between logging levels changes and instance restarts and it all worked.

Comment by naman_mehta [ 10/Feb/12 ]

This issue is coming due to replication error or file is not properly updated on remote machine and instance is not able to coming up as some properties are missing. To avoid this we can make following changes,

Index: src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java
===================================================================
— src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java (revision 52453)
+++ src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java (working copy)
@@ -154,13 +154,25 @@
String recordFieldSeparator;
String recordDateFormat;

+ String logFileProperty = "";
+
public void postConstruct() {

LogManager manager = LogManager.getLogManager();
String cname = getClass().getName();

  • String filename = TranslatedConfigView.getTranslatedValue(manager.getProperty(cname + ".file")).toString();
    + if (manager != null) { + logFileProperty = manager.getProperty(cname + ".file"); + }

+ if (logFileProperty == null || logFileProperty.trim().equals(""))

{ + logFileProperty = env.getInstanceRoot().getAbsolutePath() + File.separator + LOGS_DIR + File.separator + + logFileName; + }

+
+ String filename = TranslatedConfigView.getTranslatedValue(logFileProperty).toString();
+
+
File serverLog = new File(filename);
absoluteServerLogName = filename;
if (!serverLog.isAbsolute()) {

Above changes will check for the required property is present or not if not it would create log files under installation directory. And now server will come up and later the new logging.properties file is replicated to the remote machine and which could solve the problem.

This fix is to avoid to avoid catastrophic failure in the absence of a user defined configuration property like com.sun.enterprise.server.logging.GFFileHandler.file. It's just to avoid instance startup error.

Comment by lidiam [ 10/Feb/12 ]

It seems to me that with the above solution we will totally hide the issue, i.e. we will never know if logging.properties file got truncated/corrupted. I think we should at least print a WARNING level message to server.log indicating that there is a problem.

Comment by Anissa Lam [ 11/Feb/12 ]

The changes in GUI to call set-log-levels once for all loglevels has been checked in to 3.1.2 branch with Joe's request.
This should be in 3.1.2 RC4 build.

Log Message:
------------
Improve performance of GUI when changing log levels and to avoid a bug in logging, GLASSFISH-18336.
Revisions:
----------
52545
Modified Paths:
---------------
branches/3.1.2/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java

Comment by Rebecca Parks [ 14/Feb/12 ]

Per Sudipa, removed from Release Notes due to the fix.

Comment by Joe Di Pol [ 14/Feb/12 ]

A work-around was implemented in the console, so this bug is not hitting users anymore. But there is still an NPE in the backend that should be fixed. I'm lowering the priority to P4 since there is limited customer impact.

Comment by naman_mehta [ 20/Feb/12 ]

Added backend changes for 4.0.





[GLASSFISH-18299] Logging does not use MessageFormat unless "{0}" is in log message Created: 01/Feb/12  Updated: 03/Feb/12

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

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

Linux (Ubuntu 11.10)



 Description   

GlassFish 3.1.1 does not use a MessageFormat to format a message passed to java.util.logging.Logger, unless the message contains "

{0}". This is a problem when the message format looks like this:

logger.log(Level.INFO, "Found {0,number} {0,choice,0#matches|1#match|1<matches}.", matches.size());

Notice that the log message contains "{0" but does not contain "{0}

".

It appears the culprit is com.sun.enterprise.server.logging.UniformLogFormatter, which decides whether to apply a MessageFormat to a log message using this test:

if (logMessage.indexOf("

{0}

") >= 0

Contrast this with java.util.logging.Formatter, which uses this:

if (format.indexOf("{0") >= 0 || format.indexOf("{1") >=0 ||
format.indexOf("{2") >=0|| format.indexOf("{3") >=0)

In summary, UniformLogFormatter needs to account for argument placeholders in MessageFormat format strings which apply formatting (as described in the documentation for MessageFormat) rather than just plain toString insertion. The test code in java.util.logging.Formatter does this.



 Comments   
Comment by naman_mehta [ 03/Feb/12 ]

Fixed made for 4.0

Project: glassfish
Repository: svn
Revision: 52424
Author: naman_mehta
Date: 2012-02-03 11:13:01 UTC





[GLASSFISH-17733] asadmin fails to start Domain Admin Server if some module loggers are set to 'FINER' Created: 15/Nov/11  Updated: 20/Dec/16

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

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

Tags: 3_1_2-exclude

 Description   

If some loggers , which log a lot , are set to 'FINER' (f.e. deployment-logger) then it's not possible to start DAS anymore.

grep FINER <domaindir>/config/logging.properties
javax.enterprise.system.tools.deployment.level=FINER
javax.enterprise.system.container.ejb.level=FINER

Output of 'asadmin start-domain' ....

Waiting for dld to start ...........................................Exception in thread "dld-StderrDrainer" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2367)
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130)
at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:415)
at java.lang.StringBuilder.append(StringBuilder.java:132)
at com.sun.enterprise.universal.process.ProcessStreamDrainerWorker.run(ProcessStreamDrainerWorker.java:79)
at java.lang.Thread.run(Thread.java:722)

If I reset the logging levels 'asadmin' will succeed again.

Output of 'asadmin start-domain' ....

Waiting for dld to start ...........................
Successfully started the domain : <domainname>



 Comments   
Comment by Tom Mueller [ 15/Nov/11 ]

Changing to logging category as this appears to be a logging issue.

Comment by naman_mehta [ 30/Nov/11 ]

I tried to reproduce the same but couldn't make it...

I took latest 3.1.2 build and change log level to finer as mention above...

javax.enterprise.system.tools.deployment.level=FINER
javax.enterprise.system.container.ejb.level=FINER

Server start is going fine. No error there. Also, QL is passing 100%.

Did I miss anything? If not, should I close the same?

Comment by Tom Mueller [ 30/Nov/11 ]

This may be related to the applications that are deployed on the server or some other configuration of the server. Hopefully the submitter can provide details about the environment needed to reproduce this.

Comment by naman_mehta [ 01/Dec/11 ]

Provide me the test case to reproduce the same as earliest.

Comment by naman_mehta [ 07/Dec/11 ]

Wouldn't get any reply from the user show excluding for 3.1.2 cycle and reducing the priority as of now.

Comment by bthalmayr [ 08/Dec/11 ]

'asadmin list-applications domain'

lists

  • 15 EARs
  • 35 WARs
  • 2 connectors
Comment by mlebihan [ 19/May/12 ]

I currently have this issue using Glassfish 3.1.2.
Why is this issue tagged 3.1.2-exclude?

Comment by mlebihan [ 19/May/12 ]

I have received this error a second way, and I may have a clue about where it is coming from.

Few days ago, I tried to compile the Glassfish 4.0 and the Glassfish 3.1.2 servers.
I did a wrong thing: I kept my GLASSFISH_HOME variable to my "production" Glassfish 3.1.2 server, the one I use for other ear applications I develop.
the mvn install succeeded for Glassfish 4.0 but not for Glassfish 3.1.2 (for reasons I don't really understand, but its out of the subject).

Later, I attempted to return to my previous work, developping my usual ear, and I started my production Glassfish 3.1.2 server.
I received "your" errors. Out Of Memory, no matter the amount of free memory you give. (I can't put more than 1 Go on my computer).

Then I've done this:
I installed a new version of Glassfish 3.1.2 somewhere and started it, empty. It worked, I have stopped it.
I re-attempted the starting of my production Glassfish 3.1.2 server, the one that was faulty, and it didn't ran. Howerver, instead of receving the out of memory error message, I saw a bunch - but really a bunch! - of messages like:

[#|2012-05-19T10:40:56.495+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|access: access allowed ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")|#]

[#|2012-05-19T10:40:56.495+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Thread.java:1342)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:315)
	at java.security.AccessController.checkPermission(AccessController.java:555)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
	at org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1597)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:805)
	at org.apache.felix.framework.capabilityset.CapabilitySet.coerceType(CapabilitySet.java:573)
	at org.apache.felix.framework.capabilityset.CapabilitySet.compare(CapabilitySet.java:404)
	at org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:248)
	at org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:203)
	at org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:180)
	at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1292)
	at org.apache.felix.framework.resolver.Candidates.populateRevision(Candidates.java:275)
	at org.apache.felix.framework.resolver.Candidates.processCandidates(Candidates.java:469)
	at org.apache.felix.framework.resolver.Candidates.populateRevision(Candidates.java:277)
	at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:158)
	at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:89)
	at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
	at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
	at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
	at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$1.run(OSGiModuleImpl.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:158)
	at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)
	at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:124)
	at com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:111)
	at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:135)
	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:358)
	at com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers(SnifferManagerImpl.java:206)
	at com.sun.enterprise.v3.server.SnifferManagerImpl.getCompositeSniffers(SnifferManagerImpl.java:185)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:603)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
	at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
	at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
	at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
	at com.sun.hk2.component.ConstructorCreator$1.run(ConstructorCreator.java:86)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:83)
	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:253)
	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)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
	at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
|#]

[#|2012-05-19T10:40:56.495+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at java.lang.Thread.dumpStack(Thread.java:1342)|#]

[#|2012-05-19T10:40:56.496+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:315)|#]

[#|2012-05-19T10:40:56.496+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at java.security.AccessController.checkPermission(AccessController.java:555)|#]

[#|2012-05-19T10:40:56.496+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)|#]

[#|2012-05-19T10:40:56.496+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)|#]

[#|2012-05-19T10:40:56.496+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1597)|#]

[#|2012-05-19T10:40:56.496+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at java.security.AccessController.doPrivileged(Native Method)|#]

[#|2012-05-19T10:40:56.496+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:805)|#]

[#|2012-05-19T10:40:56.496+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.capabilityset.CapabilitySet.coerceType(CapabilitySet.java:573)|#]

[#|2012-05-19T10:40:56.496+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.capabilityset.CapabilitySet.compare(CapabilitySet.java:404)|#]

[#|2012-05-19T10:40:56.496+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:248)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:203)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:180)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1292)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.resolver.Candidates.populateRevision(Candidates.java:275)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.resolver.Candidates.processCandidates(Candidates.java:469)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.resolver.Candidates.populateRevision(Candidates.java:277)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:158)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:89)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)|#]

[#|2012-05-19T10:40:56.497+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)|#]

[#|2012-05-19T10:40:56.498+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)|#]

[#|2012-05-19T10:40:56.498+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$1.run(OSGiModuleImpl.java:161)|#]

[#|2012-05-19T10:40:56.498+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at java.security.AccessController.doPrivileged(Native Method)|#]

[#|2012-05-19T10:40:56.498+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:158)|#]

[#|2012-05-19T10:40:56.498+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)|#]

[#|2012-05-19T10:40:56.498+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:124)|#]

[#|2012-05-19T10:40:56.498+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:111)|#]

[#|2012-05-19T10:40:56.498+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:135)|#]

[#|2012-05-19T10:40:56.498+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)|#]

[#|2012-05-19T10:40:56.498+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at org.jvnet.hk2.component.Habitat$5.get(Habitat.java:703)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at java.util.AbstractList$Itr.next(AbstractList.java:358)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers(SnifferManagerImpl.java:206)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.v3.server.SnifferManagerImpl.getCompositeSniffers(SnifferManagerImpl.java:185)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:603)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.ConstructorCreator$1.run(ConstructorCreator.java:86)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at java.security.AccessController.doPrivileged(Native Method)|#]

[#|2012-05-19T10:40:56.499+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:83)|#]

[#|2012-05-19T10:40:56.500+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)|#]

[#|2012-05-19T10:40:56.500+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)|#]

[#|2012-05-19T10:40:56.500+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)|#]

[#|2012-05-19T10:40:56.500+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)|#]

[#|2012-05-19T10:40:56.501+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:253)|#]

[#|2012-05-19T10:40:56.501+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)|#]

[#|2012-05-19T10:40:56.501+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)|#]

[#|2012-05-19T10:40:56.501+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)|#]

[#|2012-05-19T10:40:56.501+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)|#]

[#|2012-05-19T10:40:56.501+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)|#]

[#|2012-05-19T10:40:56.501+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)|#]

[#|2012-05-19T10:40:56.502+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)|#]

[#|2012-05-19T10:40:56.502+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)|#]

[#|2012-05-19T10:40:56.502+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)|#]

[#|2012-05-19T10:40:56.502+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at java.lang.reflect.Method.invoke(Method.java:601)|#]

[#|2012-05-19T10:40:56.502+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)|#]

[#|2012-05-19T10:40:56.502+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|	at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)|#]

[#|2012-05-19T10:40:56.502+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|policy: getPermissions:
	PD CodeSource: (file:/C:/Outils/Programmation/glassfish-3.1.2/glassfish/osgi/felix/bin/felix.jar <no signer certificates>)
	PD ClassLoader: java.net.URLClassLoader@110c2e8
	PD Principals: <no principals>|#]

[#|2012-05-19T10:40:56.503+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|policy: evaluate codesources:
	Policy CodeSource: (file:/C:/Outils/Programmation/glassfish-3.1.2/glassfish/lib/- <no signer certificates>)
	Active CodeSource: (file:/C:/Outils/Programmation/glassfish-3.1.2/glassfish/osgi/felix/bin/felix.jar <no signer certificates>)|#]

[#|2012-05-19T10:40:56.503+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|policy: evaluation (codesource) failed|#]

[#|2012-05-19T10:40:56.503+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|policy: evaluate codesources:
	Policy CodeSource: (file:/C:/Outils/Programmation/glassfish-3.1.2/glassfish/modules/- <no signer certificates>)
	Active CodeSource: (file:/C:/Outils/Programmation/glassfish-3.1.2/glassfish/osgi/felix/bin/felix.jar <no signer certificates>)|#]

[#|2012-05-19T10:40:56.503+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|policy: evaluation (codesource) failed|#]

[#|2012-05-19T10:40:56.504+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|policy: evaluate codesources:
	Policy CodeSource: (file:/C:/Outils/Programmation/glassfish-3.1.2/glassfish/osgi/felix/bin/- <no signer certificates>)
	Active CodeSource: (file:/C:/Outils/Programmation/glassfish-3.1.2/glassfish/osgi/felix/bin/felix.jar <no signer certificates>)|#]

[#|2012-05-19T10:40:56.504+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-2;|policy: evaluate principals:
	Policy Principals: []
	Active Principals: []|#]

I had no other choice than starting for the new clean Glassfish 3.1.2 server I have installed.

I believe that these messages complaining about unsigned jars could be the cause of the out of memory messages coming on great number, and could broke the ProcessStreamDrainerWorker.





[GLASSFISH-18932] Default value is not set for resources.mail-resource Created: 24/Jul/12  Updated: 20/Dec/16

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

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

Windows 7


Attachments: PNG File GUI.png    

 Description   

The default value is not set correctly for the following values.

resources.mail-resource.test.store-protocol-class
resources.mail-resource.test.transport-protocol-class

1. Create a new JavaMail Session. For example, open the GUI and enter the following values.

  • JNDI Name: test
  • Mail Host: test
  • Default User: test
  • Default Sender Address: test@test.com
  • Click Save

2.Open command prompt and enter as follows. Error message is displayed and the default value is not set. (Bug)

C:\>asadmin set resources.mail-resource.test.store-protocol-class=
remote failure: Could not change the attributes: Constraints for this MailResource configuration hav
e been violated: on property [ storeProtocolClass ] violation reason [ must be a valid Java Class Na
me ]
Constraints for this MailResource configuration have been violated: on property [ storeProtocolClass
 ] violation reason [ must be a valid Java Class Name ]
Command set failed.

C:\>asadmin set resources.mail-resource.test.transport-protocol-class=
remote failure: Could not change the attributes: Constraints for this MailResource configuration hav
e been violated: on property [ transportProtocolClass ] violation reason [ must be a valid Java Clas
s Name ]
Constraints for this MailResource configuration have been violated: on property [ transportProtocolC
lass ] violation reason [ must be a valid Java Class Name ]
Command set failed.

3.When the following value is set, the default value is set automatically. (Working as expected)

C:\>asadmin set resources.mail-resource.test.store-protocol=pop3
resources.mail-resource.test.store-protocol=pop3
Command set executed successfully.

C:\>asadmin set resources.mail-resource.test.store-protocol=
resources.mail-resource.test.store-protocol=
Command set executed successfully.

C:\>asadmin get resources.mail-resource.test.store-protocol
resources.mail-resource.test.store-protocol=imap
Command get executed successfully.

The same problem occurs when GUI is used as well.
1.Open the GUI.
2.Open JavaMail Sessions > test which has been created in the previous step.
3.Remove all characters from Store Protocol Class.
4.Click Save.
5.The error is displayed . See the attached file.



 Comments   
Comment by Bill Shannon [ 24/Jul/12 ]

Reassigning to connector team, who I believe owns these resources.

The property values do need to be a class name, but the properties
should be allowed to be unset. Setting the property value to the
empty string isn't the same as unsetting it, so maybe this should be
closed as "not a bug". But I don't know if there is a way to
unset one of these properties so maybe setting it to the empty string
should have that effect.

Comment by Jagadish [ 03/Aug/12 ]

transferring to Naman for investigation





[GLASSFISH-18584] "description" elements in glassfish-resources.xml not moved to "description" fields in domain.xml Created: 31/Mar/12  Updated: 07/Jan/13

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

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

All


Tags: configuration, description, glassfish-resources, resources

 Description   

For application/module resources files (glassfish-resources.xml) located in either the "META-INF" or "WEB-INF" directories of war, ear, or ejb projects, the DTD at:
http://glassfish.org/dtds/glassfish-resources_1_5.dtd

Specifies that the "description" must be a subelement of many of the elements (not an attribute). Specifically the "property" element has a description subelement possible.

However, the domain.xml file requires that the description be an attribute. This relates to issue GLASSFISH-16630 which is marked as "Won't fix". If we accept that we will not fix this because it causes problems migrating configuration from glassfish 2.x to 3.x, then at least when a project is deployed that has application/module resources, the "description" element should be copied into the "description" attribute.

One of the great benefits of the new portable JNDI namespaces and application resource files, you can now modify an application/module resource inside the of the Glassfish Admin site without redeploying or packaging the application. However, it gets very confusing when your configuration properties do not have a description associated with them.



 Comments   
Comment by Tom Mueller [ 24/Dec/12 ]

This appears to be deployment related, so assigning to the deployment category.

Comment by Hong Zhang [ 26/Dec/12 ]

The resource team owns glassfish-resources.xml, assign to Jagadish for evaluation

Comment by Jagadish [ 04/Jan/13 ]

Transferring to Naman for investigation.
It looks like we do seem to handle "description" element of glassfish-resources.xml for jdbc resource but not for other resource types.

Comment by naman_mehta [ 07/Jan/13 ]

I tried on the latest workspace and this bug is not reproducible. I can find description is mapped to domain.xml.

e.g.

<jdbc-resource pool-name="java:app/TestPool" description="This is the default pool." jndi-name="java:app/jdbc/TestDB"></jdbc-resource>
<mail-resource host="localhost" description="This is the mail resorce." jndi-name="java:app/mail/csjdb1" from="xtecuan@gmail.com" user="xtecuan"></mail-resource>

I am attaching the sample .war file with test code. Just try to deploy the same and verify this bug.

Comment by naman_mehta [ 07/Jan/13 ]

Couldn't find option for attachment here so sent as separate email.





[GLASSFISH-19001] More than the maximum number of characters or invalid characters can be entered for asadmin create-javamail-resource Created: 14/Aug/12  Updated: 20/Dec/16

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

Type: Bug Priority: Trivial
Reporter: tak09 Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

More than maximum number of characters or invalid characters can be entered for Admin GUI.
1.Open admin GUI. http://localhost:4848
2.Select Resources > JavaMail Sessions from the tree.
3.Click New button to open New Java Mail Session.
4.Enter invalid characters or more than 256 characters in each field.
5.Click OK.

Similarly, more than the maximum number of characters or invalid characters can be entered for asadmin create-javamail-resource.
1.Enter invalid characters or more than 256 characters for asadmin create-javamail-resource.
2.A new resource is created with invalid characters or more than maximum characters.



 Comments   
Comment by Bill Shannon [ 14/Aug/12 ]

I think the JCA team is responsible for this admin command.

Comment by Jagadish [ 16/Aug/12 ]

Transferring to Naman for investigation





[GLASSFISH-18734] Do not use System.out.println() in production code Created: 16/May/12  Updated: 16/May/12

Status: Open
Project: glassfish
Component/s: logging, OSGi
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Harald Wellmann Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A couple of GlassFish messages always show up on my console even when logging is turned off. The following messages should be suppressed or be converted to proper log messages:

./core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/GlassFishMainActivator.java:196: System.out.println("Provisioning options are " + provisioningOptions);
./core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/EmbeddedOSGiGlassFishRuntime.java:114: System.out.println("Completed shutdown of GlassFish runtime");
./core/logging/src/main/java/com/sun/enterprise/server/logging/LogManagerService.java:600: System.out.println("Completed shutdown of Log manager service");

(Line numbers refer to the 3.1.2 source tree.)






Generated at Mon Feb 27 07:38:25 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.