[GLASSFISH-19145] NPE in JavaMail connector unit tests Created: 12/Oct/12  Updated: 12/Oct/12  Resolved: 12/Oct/12

Status: Closed
Project: glassfish
Component/s: jca
Affects Version/s: 4.0_b56_ms5
Fix Version/s: 4.0_b57

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


 Description   

I've noticed this stack trace in the build on 10/11 under "Building Connector (glue) for GlassFish JavaMail Support 4.0-SNAPSHOT":

java.lang.NullPointerException
at
org.glassfish.resourcebase.resources.util.BindableResourcesHelper.validateBindableResourceForDuplicates(BindableResourcesHelper.java:128)

at
org.glassfish.resources.admin.cli.CustomResourceManager.isValid(CustomResourceManager.java:145)

I don't know fow how long it was there - it might be a coincidence that I noticed



 Comments   
Comment by naman_mehta [ 12/Oct/12 ]

Made required changes and did check-in for the same.





[GLASSFISH-19131] Improve session management in CsrfPreventionFilter Created: 05/Oct/12  Updated: 10/Oct/12  Resolved: 10/Oct/12

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 4.0_b57

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


 Description   

Improve session management in CsrfPreventionFilter
Need to port the following Tomcat changes to GlassFish
http://svn.apache.org/viewvc?view=revision&revision=1393071



 Comments   
Comment by Shing Wai Chan [ 10/Oct/12 ]

glassfish~svn:56293





[GLASSFISH-19126] AssertionError while executing asadmin osgi command Created: 05/Oct/12  Updated: 06/Oct/12  Resolved: 06/Oct/12

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0_b56_ms5
Fix Version/s: 4.0_b57

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

Attachments: Text File GLASSFISH-19126.patch    

 Description   

Start the server with assertion enabled. e.g, you can do this:

java -ea -jar glassfish/modules/glassfish.jar

Now run:
asadmin osgi
You will see
remote failure: java.lang.AssertionError
Command osgi failed.

Server.log contains the following exception:

[#|2012-10-05T13:31:53.445+0530|SEVERE|44.0|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1349424113445;_LevelValue=1000;|Exception in command execution : java.lang.AssertionError
java.lang.AssertionError
at org.apache.felix.gogo.runtime.threadio.ThreadIOImpl.setStreams(ThreadIOImpl.java:100)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:104)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.glassfish.osgi.cli.remote.OSGiShellCommand.execute(OSGiShellCommand.java:257)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:549)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:570)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1450)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:118)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1760)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1710)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:469)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:251)
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.jersey.server.model.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:80)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:107)
at org.glassfish.jersey.server.model.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:146)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:80)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:304)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:299)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:90)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:198)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:316)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:174)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:747)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:306)
at org.glassfish.admin.rest.adapter.RestAdapter$1.service(RestAdapter.java:327)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:189)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:825)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)

#]


 Comments   
Comment by Sanjeeb Sahoo [ 05/Oct/12 ]

I have put in a fix like this in svn rev #56275. I think we need similar fix in some other place as well. I have to wait for Ancoron to confirm. So, I am not resolving the bug yet although I have committed the following fix which fixes the issue I was encountering.
diff --git a/nucleus/osgi-platforms/osgi-cli-remote/src/main/java/org/glassfish/osgi/cli/remote/OSGiShellCommand.java b/nucleus/osgi-platforms/osgi-cli-remote/src/main/java/org/
index b062144..e148ad7 100644
— a/nucleus/osgi-platforms/osgi-cli-remote/src/main/java/org/glassfish/osgi/cli/remote/OSGiShellCommand.java
+++ b/nucleus/osgi-platforms/osgi-cli-remote/src/main/java/org/glassfish/osgi/cli/remote/OSGiShellCommand.java
@@ -253,7 +253,7 @@ public class OSGiShellCommand implements AdminCommand, PostConstruct {
if("asadmin-osgi-shell".equals(cmdName))

{ out.println("gogo"); }

else

{ - CommandSession session = cp.createSession(null, out, err); + CommandSession session = cp.createSession(System.in, out, err); session.execute(cmd); session.close(); }
Comment by ancoron [ 05/Oct/12 ]

I think, System.in could break real interactive commands as it could block forever. I currently don't know any of the official ones, but users might have already implemented some.

Therefore, I'd rather go with a slightly different approach by using a "fake" InputStream which always says that it doesn't have data and doesn't block (attached patch GLASSFISH-19126.patch).

In case the System.in is already being handled properly in a different way inside the GlassFish runtime this patch is not required.

Comment by Sanjeeb Sahoo [ 06/Oct/12 ]

Integrated patch from Ancoron in svn rev #56296.





[GLASSFISH-19119] better GenericListCommand Created: 29/Sep/12  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b57
Fix Version/s: 4.0_b57

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


 Description   

The GenericListCommand is used with config beans that use the @Listing annotation. Currently, it only prints the "key" field for each bean in the collection. This issue is for enhancing the GenericListCommand to support:

  • additional options: --long, --header, and --output
  • additional columns with --long output for each of the attributes and other methods
  • an annotation for selecting duck typed methods to output and to specify additional data for the columns
  • properties in the output for use by the ReST interface


 Comments   
Comment by Tom Mueller [ 01/Oct/12 ]

Implemented on the trunk in revision 56203.





[GLASSFISH-19117] jsr109-impl module is always getting started Created: 29/Sep/12  Updated: 11/Oct/12  Resolved: 11/Oct/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b56_ms5
Fix Version/s: 4.0_b57

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

Tags: spo

 Description   

I noticed jsr109-impl module is getting activated and this is causing the whole web service stack to get resolved at startup time.
I think the reason behind this that we have config beans which have been become part of this module in svn rev #48478.

See GLASSFISH-17656 for why we should not have config beans in implementation modules.



 Comments   
Comment by Lukas Jungmann [ 11/Oct/12 ]

http://java.net/projects/glassfish/sources/svn/revision/56397
http://java.net/projects/glassfish/sources/svn/revision/56398





[GLASSFISH-19116] IllegalStateException when framework extension bundle is uninstalled. Created: 29/Sep/12  Updated: 22/Nov/12  Resolved: 29/Sep/12

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0_b56_ms5
Fix Version/s: 4.0_b57

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


 Description   

To reproduce:
Start and stop GlassFish once so that the osgi cache is populated.
rm one framework extension bundle like modules/webservices-extra-jdk-packages.jar
Start GlassFish.
You shall see:
Launching GlassFish on Felix platform
29 Sep, 2012 12:21:29 PM BundleProvisioner createBundleProvisioner
INFO: clazz = class com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner
29 Sep, 2012 12:21:29 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 264 installed from /space/ss141213/WS/gf/trunk/appserver/distributions/glassfish/target/stage/glassfish3/glassfish/modules/webservices-extra-jdk-packages.jar
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: org.glassfish.embeddable.GlassFishException: java.lang.IllegalStateException: Invalid BundleContext.
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.java:169)
at org.glassfish.embeddable.GlassFishRuntime._bootstrap(GlassFishRuntime.java:157)
at org.glassfish.embeddable.GlassFishRuntime.bootstrap(GlassFishRuntime.java:110)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:112)
... 6 more
Caused by: java.lang.IllegalStateException: Invalid BundleContext.
at org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514)
at org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:173)
at com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.getBundle(BundleProvisioner.java:392)
at com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.startBundles(BundleProvisioner.java:216)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.java:158)
... 9 more
Error stopping framework: java.lang.NullPointerException
java.lang.NullPointerException
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:203)

Recently a user called Alex raised it in forum as well.



 Comments   
Comment by Sanjeeb Sahoo [ 29/Sep/12 ]

Revisions:
----------
56185

Modified Paths:
---------------
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/BundleProvisioner.java

Diffs:
------
Index: trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/BundleProvisioner.java
===================================================================
— trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/BundleProvisioner.java (revision 56184)
+++ trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/BundleProvisioner.java (revision 56185)
@@ -312,6 +312,9 @@
continue;
}
try {
+ if (isFrameworkExtensionBundle(bundle))

{ + setSystemBundleUpdationRequired(true); + }

bundle.uninstall();
noOfUninstalledBundles++;
removeBundle(jar);

Comment by LeoInside [ 22/Nov/12 ]

Hi Sanjeeb,

I am new to Glassfish and seeing exactly same issue on our server..

Can you please let me know how this fix can be implemented?..

Thanks in advance..





[GLASSFISH-19105] Symbolic link present in application deletes contents recursively after update or redeploy Created: 25/Sep/12  Updated: 28/Sep/12  Resolved: 28/Sep/12

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

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

RHEL5, GF3.1.2.2


Attachments: Java Archive File 19105_patch.jar    

 Description   

If I create a symbolic link inside my application after deployment. Any Update or Deploy will delete all the contents through the Symbolic Link.

Steps to Reproduce:

1)Deploy Application
2)Create SymLink to an outside directory
3)Update or Redeploy Application
4)Verify all contents of the outside directory are gone.

I am unable to move to a different version currently, but this does not happen in previous versions.



 Comments   
Comment by Hong Zhang [ 25/Sep/12 ]

Thanks for filing the issue! As I replied to the email thread, the fix was checked into the GF 4.0 (trunk).

Will it work if I provide you a private patch for 3.1.* (send you an updated class which you could apply to a jar in your installation directory)?

I can also talk to the sustaining team to see if they can include the fix in the next 3.1.2 dot/patch release, but not too sure when the next release will come out and if they can include this fix...

Comment by smcgrath82 [ 25/Sep/12 ]

Yes I can apply the patch to the jar.

Thanks!

Comment by Hong Zhang [ 26/Sep/12 ]

I have attched the patch jar for 3.1.2 code base in the issue. Please following the steps below and let me know how things work out.
1. Extract the patch jar I attached to the issue.
2. Use the extracted com/sun/enterprise/deploy/shared/FileArchive* classes to update the deployment-common.jar in
your GlassFish installation modules directory $GF_INSTALL/modules (you can save a copy of the original jar before you update).
3. (Re)start server.

Comment by Hong Zhang [ 28/Sep/12 ]

This issue was fixed in GF 4.0 trunk.





[GLASSFISH-19099] [REGRESSION] Wrong <transaction-service> match causes transaction manager to be started on DAS Created: 22/Sep/12  Updated: 11/Oct/12  Resolved: 11/Oct/12

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b55
Fix Version/s: 4.0_b57

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


 Description   

Since <transaction-service> is removed in server-config, the wrong value is read by the code that was fine before



 Comments   
Comment by marina vatkina [ 24/Sep/12 ]

Reassigning to admin to fix in modularity code or put back <transaction-service> into server-config (threansaction service elements are different for server-config)

Comment by Masoud Kalali [ 27/Sep/12 ]

Elements back in the domain.xml, would you verify.

Comment by marina vatkina [ 28/Sep/12 ]

Yes. It's fine now

Comment by Masoud Kalali [ 11/Oct/12 ]

Fixed by putting bag the element in domain.xml





[GLASSFISH-18804] ejb timer with dayOfWeek Sunday depends on locale Created: 13/Jun/12  Updated: 16/Oct/12  Resolved: 16/Oct/12

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b57

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

Attachments: Java Source File TimerTester.java    

 Description   

With some locales the next timeout for dayOfWeek Sunday is wrong.

I've created a simple application to show the problem. Attached the singleton, just drop in a javaee6 project, and deploy.

The application iterates over all available locale, and
1. set this locale as default
2. create a timer for every sunday.
3. log the time of the next timeout.

Runnig today (Wednesday) i got this output.

INFO: Every Sunday in ms_MY starts with 2012.06.24 12:00
INFO: Every Sunday in ar_QA starts with 2012.06.17 12:00
INFO: Every Sunday in is_IS starts with 2012.06.24 12:00
INFO: Every Sunday in fi_FI starts with 2012.06.24 12:00
INFO: Every Sunday in pl starts with 2012.06.24 12:00
INFO: Every Sunday in en_MT starts with 2012.06.17 12:00
...
...
INFO: Every Sunday in en_PH starts with 2012.06.17 12:00
INFO: Every Sunday in et_EE starts with 2012.06.24 12:00
INFO: Every Sunday in el_CY starts with 2012.06.24 12:00
INFO: Every Sunday in hu starts with 2012.06.24 12:00
INFO: Every Sunday in fr_FR starts with 2012.06.24 12:00



 Comments   
Comment by marina vatkina [ 16/Oct/12 ]

I can't reproduce the error. I've just added a unit test derived from the singleton that you attached: http://java.net/projects/glassfish/sources/svn/content/trunk/main/nucleus/common/common-util/src/test/java/org/glassfish/common/util/timer/TimerScheduleTest.java?rev=56503.

In the unit test, I was able to use the "from-date" as the Sunday, Oct 14th, 2012 (instead of waiting for the Sunday to run the test). The unit test passed on all locales (including explicit "en_PH"). Can you try it on your machine? It's part of the trunk and the TimerSechedule was almost completely moved to a common location to be available for other components, but the code that calculates the next timeout is the same.

As it'll now run as part of every build, let's see if it breaks for anybody else...

Comment by kumm [ 16/Oct/12 ]

Checked the test. It works on my machine too, but i've tweaked a bit.
With a small change i was able the reproduce the bug.

Changed lines 79,80:

Date fromDate = new Date(112, 9, 16, 10, 35);
Date timeoutDate = new Date(112, 9, 21, 12, 0);

Got:

ERROR - Expected date: Sun Oct 21 12:00:00 CEST 2012 Got date: Sun Oct 28 12:00:00 CET 2012 in Locale: es_PE

Comment by marina vatkina [ 16/Oct/12 ]

Thank you. It does seem like a JDK bug, when setting Calendar.DAY_OF_WEEK to 1 (Sunday), in es_PE it jumps to the next week. Using Locale.ENGLISH to create the calendar seems to fix it.

Comment by marina vatkina [ 16/Oct/12 ]

Fixed with:

Sending common-util/src/main/java/org/glassfish/common/util/timer/TimerSchedule.java
Sending common-util/src/test/java/org/glassfish/common/util/timer/TimerScheduleTest.java
Transmitting file data ..
Committed revision 56530.





[GLASSFISH-18390] Incorrect ResourceBundle key causes errors when deploying via REST interface Created: 21/Feb/12  Updated: 16/Oct/12  Resolved: 16/Oct/12

Status: Resolved
Project: glassfish
Component/s: i18n
Affects Version/s: 3.1.1, 3.1.2_b23, 4.0_b24
Fix Version/s: 4.0_b57

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


 Description   

The class org.glassfish.persistence.jpa.JPAJava2DBProcessor (part of the persistence/jpa-connector artifact in 3.x and the persistence/jpa-container artifact in trunk) references a message key named "Java2DBProcessorHelper.nondefaultprovider" - however, the key defined in the resource bundle in persistence/common is "JPAJava2DBProcessor.nondefaultprovider".

When an application (using a non-default persistence provider) is deployed via the REST interface, the following stack trace is generated:

[#|2012-02-21T15:44:00.541-0500|SEVERE|glassfish3.1.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=18;_ThreadName=Thread-2;|Can't find resource for bundle java.util.PropertyResourceBundle, key Java2DBProcessorHelper.nondefaultprovider
java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key Java2DBProcessorHelper.nondefaultprovider
at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
at java.util.ResourceBundle.getString(ResourceBundle.java:334)
at org.glassfish.persistence.common.I18NHelper.getMessage(I18NHelper.java:105)
at org.glassfish.persistence.common.I18NHelper.getMessage(I18NHelper.java:123)
at org.glassfish.persistence.common.Java2DBProcessorHelper.getI18NMessage(Java2DBProcessorHelper.java:695)
at org.glassfish.persistence.common.Java2DBProcessorHelper.logI18NWarnMessage(Java2DBProcessorHelper.java:669)
at org.glassfish.persistence.jpa.JPAJava2DBProcessor.isJava2DbPU(JPAJava2DBProcessor.java:207)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:190)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:119)
at org.glassfish.persistence.jpa.JPADeployer$1.visitPUD(JPADeployer.java:214)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:483)
at org.glassfish.persistence.jpa.JPADeployer.createEMFs(JPADeployer.java:221)
at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:167)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:872)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:410)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:202)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:195)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:321)
at org.glassfish.admin.rest.resources.TemplateListOfResource.post(TemplateListOfResource.java:180)
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.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:184)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]


 Comments   
Comment by Mitesh Meswani [ 16/Oct/12 ]

Fixed with rev 56536





[GLASSFISH-18086] incorrect manifest classpath in javaee.jar Created: 25/Dec/11  Updated: 10/Oct/12  Resolved: 10/Oct/12

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0_b16
Fix Version/s: 4.0_b57

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

Tags: 3_1_x-exclude

 Description   

Can't find javax.servlet classes while using javaee.jar, so this bug must be caused by the maven artifact id change of api jars. Pl. fix all the affected classpath.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 10/Oct/12 ]

This has been fixed back in February, resolving the issue.





[GLASSFISH-6712] IMQ RollingFileOutputStream lacks delete permission on log dir Created: 05/Nov/08  Updated: 02/Nov/12  Resolved: 02/Nov/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 9.1peur2
Fix Version/s: 4.0_b57

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

Operating System: All
Platform: All


Issuezilla Id: 6,712

 Description   

Hi,

I encounter an issue while using a JMS ConnectionFactory from a web service.
Here is the stack trace:

[#|2008-11-05T14:18:25.356+0100|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=25;_ThreadName=Timer-27;_RequestID=4c18bb66-ae84-4bae-851e-c28b8764b042;|
java.security.AccessControlException: access denied (java.io.FilePermission
/opt/SUNWappserver/domains/domain1/imq/instances/imqbroker/log/log_9.txt delete)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkDelete(SecurityManager.java:990)
at java.io.File.delete(File.java:902)
at
com.sun.messaging.jmq.io.RollingFileOutputStream.rolloverFile(RollingFileOutputStream.java:332)
at
com.sun.messaging.jmq.io.RollingFileOutputStream.write(RollingFileOutputStream.java:293)
at
com.sun.messaging.jmq.io.RollingFileOutputStream.write(RollingFileOutputStream.java:279)
at
com.sun.messaging.jmq.util.log.FileLogHandler.publish(FileLogHandler.java:248)
at com.sun.messaging.jmq.util.log.Logger.publish(Logger.java:543)
at com.sun.messaging.jmq.util.log.Logger.log(Logger.java:792)
at
com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectConnection.logConnectionInfo(IMQDirectConnection.java:447)
at
com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectConnection.logConnectionInfo(IMQDirectConnection.java:429)
at
com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectConnection.setConnectionState(IMQDirectConnection.java:421)
at
com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectConnection.authenticate(IMQDirectConnection.java:127)
at
com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.createDirectConnection(IMQDirectService.java:325)
at
com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.createConnection(IMQDirectService.java:419)
at
com.sun.messaging.jms.ra.DirectConnectionFactory._createConnectionId(DirectConnectionFactory.java:424)
at
com.sun.messaging.jms.ra.DirectConnectionFactory._createConnection(DirectConnectionFactory.java:547)
at
com.sun.messaging.jms.ra.ManagedConnection.<init>(ManagedConnection.java:190)
at
com.sun.messaging.jms.ra.ManagedConnectionFactory.createManagedConnection(ManagedConnectionFactory.java:213)
at
com.sun.enterprise.resource.ConnectorAllocator.createResource(ConnectorAllocator.java:136)
at
com.sun.enterprise.resource.AbstractResourcePool.createSingleResource(AbstractResourcePool.java:891)
at
com.sun.enterprise.resource.AbstractResourcePool.createResourceAndAddToPool(AbstractResourcePool.java:1752)
at
com.sun.enterprise.resource.AbstractResourcePool.resizePool(AbstractResourcePool.java:1399)
at
com.sun.enterprise.resource.AbstractResourcePool$Resizer.run(AbstractResourcePool.java:1532)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)

#]

I guess RollingFileOutputStream should use AccessController.doPrivileged() to
manipulate log files.

Best regards,

Laurent.



 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 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 jigang [ 02/Nov/12 ]

This issue can not be reproduced,I start a single server of GF and deploy an application that sends messages to the Queue using 100 threads.
Make sure that enabled security manager and configured the size and the number of server.log files.

Steps to reproduce

1.Start a single sever of GF.
asadmin start-domain domain1
2.Create the necessary resources for the application,a connection pool and a queue.
asadmin create-jms-resource --target server --restype javax.jms.ConnectionFactory jmsra/xaqcf
asadmin create-admin-object --raname jmsra --target server --restype javax.jms.Queue jmsra/queue
3.Configure the size and the number of server.log file.
asadmin set-log-attributes --target=server com.sun.enterprise.server.logging.GFFileHandler.maxHistoryFiles=4
asadmin set-log-attributes --target=server com.sun.enterprise.server.logging.GFFileHandler.rotationLimitInBytes=1000
4.Enabled security manager
asadmin create-jvm-options -Djava.security.manager
5.Deploy application
asadmin deploy --name application_name application_path
6.Restart server
asadmin restart-domain domain1
7.Send messages to Queue using multiple threads and check the server.log
In order to check log, you can bypass set-log-levels subcommand to set the log level for one or more loggers.

Whether creates new resource or removes invalid resource handles in the pool while resizing the pool, the maxHistory of the server.log is always 4 and there is no AccessControlException.





Generated at Sat Apr 25 15:26:32 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.