[GLASSFISH-18407] Remote EJBs fail with ClassCastException in embeddable Glassfish Created: 24/Feb/12  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_dev
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: vins4java Assignee: Bhavanishankar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive glassfish-test-arquillian.zip    
Tags: 3_1-exclude, 3_1-fishcat, 3_1-release-note-added, 3_1-release-notes, 3_1_1-approved, 3_1_1-next

 Description   

I think I've found a specification violation in the embeddable Glassfish project. My apologies if it turns out that this is not the case, but I've taken the liberty of setting the priority to Major because I don't see any wiggling out of this one.

Here's what the specification has to say about business interfaces of stateless session beans in section 4.9.7:

"If the business interface is a remote business interface, the argument and return values must be of valid types for RMI/IIOP. The remote business interface is not required or expected to be a java.rmi.Remote interface."

My business interface is declared thusly:

public interface AppealTypeManager extends DAO<Long, AppealType>

{ public Collection <? extends AppealType> findAllAppealTypes(final PagingControl pagingControl); }

(Note the lack of @Remote, and the lack of "extends Remote".)

My bean class is declared thusly:

@Stateless//(name = "AppealTypeManager")
@TransactionAttribute(TransactionAttributeType.REQUIRED)
@Remote(AppealTypeManager.class)
public class AppealTypeManagerBean extends AbstractDAO<Long, AppealType, AppealTypeEntity> implements AppealTypeManager

{ // ...etc. }

I look up a reference to the remote business interface like this:

final Context c = new InitialContext();
final AppealTypeManager a = (AppealTypeManager)c.lookup("java:global/test-classes/AppealTypeManagerBean");

When I deploy my EJB module to embeddable Glassfish, I get the following error upon lookup:

javax.naming.NamingException: Lookup failed for 'java:global/test-classes/AppealTypeManagerBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.jenzabar.ngp.ia.designation.api.AppealTypeManager [Root exception is java.lang.ClassCastException]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:525)
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.jenzabar.junit.ejb.dbunit.mem.GlassfishEmbeddedStrategy.getBean(GlassfishEmbeddedStrategy.java:126)
at com.jenzabar.junit.ejb.dbunit.mem.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:98)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:145)
at org.apache.maven.surefire.Surefire.run(Surefire.java:104)
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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1017)
Caused by: javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.jenzabar.ngp.ia.designation.api.AppealTypeManager [Root exception is java.lang.ClassCastException]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:434)
at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:559)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:521)
... 34 more
Caused by: java.lang.ClassCastException
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:262)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$12.read(DynamicMethodMarshallerImpl.java:353)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java)
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.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:422)
... 38 more
Caused by: java.lang.ClassCastException: Object is not of remote type java.rmi.Remote
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:254)
... 50 more

Again, the specification does not require a remote business interface to extend java.rmi.Remote, but it would appear that the Glassfish embedded runtime thinks it's necessary.



 Comments   
Comment by vins4java [ 24/Feb/12 ]

this is a clone of http://java.net/jira/browse/GLASSFISH-15775
I've reopened it because I saw another user ("vasilievip") asked to reopen it but he had no answer.
We have the same problem with the latest build of glassfish-embedded-all (version 3.1.1) available for maven users.

Note:
In order reproduce the bug, I ran the original attachment issued by original issuer ("ljnelson") and set the following section into pom.xml.

<repositories>
<repository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Maven Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public-jboss/</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</repository>
<repository>
<id>jboss-deprecated-public-repository-group</id>
<name>JBoss Deprecated Public Maven Repository Group</name>
<url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</repository>
</repositories>

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 drivera [ 01/May/13 ]

I'm having a similar problem under 3.1.2.2 final, with the difference that the EJB's are being deployed in OSGi bundles.

The logs show the bundles deploying correctly, and the @OSGiService injection decoration from the OSGI-CDI bridge API helps find the EJB properly, but I too get this exception:

java.lang.ClassCastException: Object is not of remote type java.rmi.Remote
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:254)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$12.read(DynamicMethodMarshallerImpl.java:353)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java)
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.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:421)
at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:556)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:514)
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.ejb.EjbNamingReferenceManagerImpl.resolveEjbReference(EjbNamingReferenceManagerImpl.java:186)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$EjbReferenceProxy.create(ComponentEnvManagerImpl.java:1109)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:776)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:744)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:169)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:498)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:599)
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 org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:130)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:157)
at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:131)
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:153)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:293)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:637)
at org.jboss.weld.el.AbstractWeldELResolver.lookup(AbstractWeldELResolver.java:127)
at org.jboss.weld.el.AbstractWeldELResolver.getValue(AbstractWeldELResolver.java:96)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:188)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:103)
at com.sun.el.parser.AstValue.getValue(AstValue.java:179)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at org.primefaces.component.dashboard.Dashboard.getModel(Dashboard.java:101)
at org.primefaces.component.dashboard.DashboardRenderer.encodeMarkup(DashboardRenderer.java:56)
at org.primefaces.component.dashboard.DashboardRenderer.encodeEnd(DashboardRenderer.java:41)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1764)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1757)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:402)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)





[GLASSFISH-17144] Missing dependency in maven-embedded-glassfish-plugin Created: 03/Aug/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2, 4.0

Type: Bug Priority: Major
Reporter: ljnelson Assignee: Bhavanishankar
Resolution: Fixed Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-fishcat, embedded

 Description   

Setting up the maven-embedded-glassfish-plugin according to http://blogs.oracle.com/alexismp/entry/glassfish_embedded_and_javadb_embedded results in a WARNING spit to the console complaining about a missing OSGI class (ServiceException). A thread in the Glassfish forums (http://www.java.net/forum/topic/glassfish/glassfish/glassfish-embedded-all-v311-b11-could-not-instantiate-service-class-orgglassfishosgicdiimplosgis) details the issue as well as a workaround.



 Comments   
Comment by Bhavanishankar [ 03/Aug/11 ]

Please ignore this WARNING message. This message has no consequences. Also, no need to add OSGi artifact to dependencies, just ignore the stacktrace.

Comment by toomanyryans [ 04/Aug/11 ]

To clarify, I experience this with 'glassfish-embedded-all'. I'm not using 'maven-embedded-glassfish-plugin'.

Also, I assume you mean ignore the stacktrace for now (until it's cleaned up), right?

Comment by Bhavanishankar [ 04/Aug/11 ]

Yes, I mean ignore the stacktrace...

Comment by Bhavanishankar [ 14/Nov/11 ]

This has been fixed in both 3.1.2 and trunk.





[GLASSFISH-16200] Common Tasks: Broken Doc Links Created: 13/Mar/11  Updated: 19/Dec/16  Resolved: 26/Apr/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Tags: 3_1-approved, 3_1-fishcat

 Description   

The Documentation links on the Common Tasks welcome page are broken. They all link or redirect to http://www.oracle.com/pls/topic/error.



 Comments   
Comment by Harald Wellmann [ 13/Mar/11 ]

As I cannot reopen GLASSFISH-15663, I created this clone.

With Glassfish 3.1 (the release, aka b43), the links on the Admin Console start page are broken again.

The URLs listed by Paul Davies in GLASSFISH-15663 seem to have changed again. I get the same error message when directly pointing my browser at these URLs.

Comment by Anissa Lam [ 13/Mar/11 ]

Request Paul to follow up on this.
This was from the latest email from Paul when i requested him to double check the doc link.

==================================
Hi Anissa,

I have cross-checked the URLs that I gave you with the URLs in the svn diff output in the comment that you added to the bug and I can confirm that they are correct.

I have much greater confidence in these URLs as they were generated automatically by our link management system and match the URLs that will be in the Preface of all the books when they're published on OTN.

I only wish that I had had this information when I gave you the original URLs.

Regards,
-Paul

On 01/26/11 23:03, Anissa Lam wrote:
>
> Component: admin_gui
> Issue: http://java.net/jira/browse/GLASSFISH-15663
>
> I have once again updated the doc link in the common task page according to the new info thats provided by the doc team. There is no way to verify the link is correct. Request Paul to review the link again.
>
> thanks
> Anissa.





[GLASSFISH-16074] Deployer#deploy() sometimes returns null Created: 22/Feb/11  Updated: 19/Dec/16  Resolved: 29/May/11

Status: Closed
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ljnelson Assignee: Bhavanishankar
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File bug.log    
Tags: 3_1-fishcat, 3_1_1-scrubbed

 Description   

(Note that 3.1-b41 is the latest embedded version; not sure why.)

Sometimes a deployment using the embedded API returns null. I am using code like this:

final Deployer deployer = this.glassfish.getDeployer();
assertNotNull(deployer);

final ScatteredArchive sa = new ScatteredArchive("test-classes", ScatteredArchive.Type.JAR, this.beanClassClasspathRoot);
this.deployedApplication = deployer.deploy(sa.toURI());

this.beanClassClasspathRoot evaluates to (in my case): /Users/ljnelson/Projects/ngp/ngp-dao-ejb/target/test-classes

It is a directory, it exists, and it contains all classes necessary for my EJB module.

sa.toURI() evaluates to file:/var/folders/Xd/XdAtuoEzHdOh7AR5tSGFJ++++TI/-Tmp-/test-classes.jar

The (monstrous) log, when Level.FINE is enabled, says only this:

PlainTextActionReporterFAILUREDescription: deploy AdminCommandError occurred during deployment: null. Please see server.log for more details.
[name=test-classes

Then null is returned from the deploy() method.

I cannot reliably reproduce this, so I expect that eyeball debugging will be necessary.

Despite this oddity, my test completes normally. That is, I am able to look up and run tests on my EJB.



 Comments   
Comment by ljnelson [ 22/Feb/11 ]

I've attached the output of running my test with the global log level set to FINEST.

Comment by ljnelson [ 22/Feb/11 ]

I tried supplying it with a -name option (i.e. deploy(sa.toURI(), "-name", "test-classes")) but that didn't help.

Comment by Bhavanishankar [ 21/May/11 ]

This looks like a specific issue.

Under normal circumstances I can not reproduce this issue.

Please attach a testcase for me to reproduce. Otherwise I won't be able to fix this issue.

Comment by Bhavanishankar [ 29/May/11 ]

When the deployment fails, deploy() method will return null. You need enable deployment logging and see why it fails.

This does not look like a issue to me.

Comment by ljnelson [ 30/May/11 ]

How do I turn on deployment logging, given that I thought I had?

Comment by Bhavanishankar [ 30/May/11 ]

Please refer my blog http://weblogs.java.net/blog/bhavanishankar/archive/2010/12/15/changing-log-levels-embedded-glassfish

Comment by marina vatkina [ 31/May/11 ]

Laird, does your test include CDI? There are cases (that I do not know how to determine) when ScatteredArchive created from EJB module with CDI returns null on deploy. EJB devtests with CDI do not produce this error.

Comment by ljnelson [ 31/May/11 ]

Honestly don't remember (this was February, after all). I doubt it, however.





[GLASSFISH-15946] EclipseLink regression: ManyToOne target, which extends a MappedSuperclass, fails Created: 10/Feb/11  Updated: 19/Dec/16  Resolved: 11/Feb/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1_dev
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: ljnelson Assignee: tware
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-fishcat, eclipselink, jpa, persistence

 Description   

I am posting this bug here to track the EclipseLink bug I filed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=336879

This is present in EclipseLink 2.2.0-SNAPSHOT, which is the version used by Glassfish by default. I want to make sure that Glassfish 3.1 final incorporates a fix here. We have hundreds of these mappings deployed today and they work just fine in older versions of EclipseLink.



 Comments   
Comment by Chris Kasso [ 11/Feb/11 ]

This appears to be more of an edge case. Two workarounds exist. See:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=336879

for details.

Comment by Chris Kasso [ 11/Feb/11 ]

I'm closing this as won't fix since we will not fix this for 3.1. The underlying issue is represented by:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=336879

and will be picked up in a future release of GlassFish.





[GLASSFISH-15939] SentinelInputStream spits warnings to console; can't be silenced Created: 10/Feb/11  Updated: 19/Dec/16  Resolved: 07/Jun/11

Status: Resolved
Project: glassfish
Component/s: classloader, embedded
Affects Version/s: 3.1_dev
Fix Version/s: None

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

Tags: 3_1-exclude, 3_1-fishcat

 Description   

I have an EJB that is abusing the EJB specification by doing things like classloading and file access. It is not my choice.

It uses an instance of JBoss' Drools project. Drools at one point reads the filesystem to find the rules file. At that point, the rules file is compiled.

During rules compilation, a getResourceAsStream() call is made. Actually, one is made by the Eclipse compiler that ships as part of Drools for all kinds of internal problems, like type resolution.

For each one of these calls, something called the SentinelInputStream barfs a whole pile of stack to the console. It is listed as a WARNING.

I am running into this issue while running unit tests using the embeddable Glassfish classes. I do not know if the issue is fundamental to classloading or the embedded container, so I've listed both in the components section above.

My java.util.logging config file is set up to be at the INFO level. Nevertheless the stack is shown. Over and over and over again. Thousands upon thousands of times. I am aware, again, that this bean should be using a resource adapter instead, and that is part of my plans. For now, I just need to shut the silly thing up.

Here is a sample output:

WARNING: Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace
java.lang.Throwable
at com.sun.enterprise.loader.ASURLClassLoader$SentinelInputStream.<init>(ASURLClassLoader.java:1230)
at com.sun.enterprise.loader.ASURLClassLoader.getResourceAsStream(ASURLClassLoader.java:878)
at org.drools.rule.CompositeClassLoader.getResourceAsStream(CompositeClassLoader.java:86)
at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.isPackage(EclipseJavaCompiler.java:280)
at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:222)
at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:204)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:97)
at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:101)
at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:835)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:117)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypesFor(BinaryTypeBinding.java:916)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getExactMethod(BinaryTypeBinding.java:715)
at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.getExactMethod(SourceTypeBinding.java:842)
at org.eclipse.jdt.internal.compiler.lookup.Scope.findExactMethod(Scope.java:771)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getImplicitMethod(Scope.java:1824)
at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:431)
at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:344)
at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:344)
at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:186)
at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:444)
at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:191)
at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1096)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1184)
at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:535)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:743)

There may be an easy way to shut this off, but I don't know what it is. No other logging messages appear from Glassfish.



 Comments   
Comment by ljnelson [ 10/Feb/11 ]

Drools CompositeClassLoader is here in case it helps: http://grepcode.com/file/repository.jboss.org/maven2/org.drools/drools-core/5.0.0.M5/org/drools/rule/CompositeClassLoader.java

Comment by ljnelson [ 10/Feb/11 ]

Turning off the logging level for javax.enterprise fixes this issue. Thanks to both Bhavani and Tim Quinn for help here.





[GLASSFISH-15837] jndi.properties not set when using embedded glassfish Created: 04/Feb/11  Updated: 19/Dec/16  Resolved: 05/Feb/11

Status: Closed
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ljnelson Assignee: Bhavanishankar
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-fishcat

 Description   

To be fair, I'm not sure this is a bug so much as something that deserves to be explained.

When you use the maven-embedded-glassfish-plugin, you connect to the running Glassfish instance by doing:

new InitialContext();

Obviously for this to work a jndi.properties has to be on the classpath somewhere. Merely using the maven-embedded-glassfish-plugin is not sufficient.

There needs to be an as-easy-as-possible way to have "new InitialContext()" Just Work.



 Comments   
Comment by Bhavanishankar [ 05/Feb/11 ]

The tests are run in surefire plugin. In the test you are doing

new InitialContext()

For that to work, the surefire test will require a jndi provider specified via jndi.properties in its classpath.

I don't see this as an issue with glassfish plugin.

Comment by Bhavanishankar [ 05/Feb/11 ]

It might be worth mentioning that, including glassfish-embedded-all as a project dependency with <scope>test</scope> is all that is needed to get everything working here.

Comment by ljnelson [ 06/Feb/11 ]

Right. That seems a little heavyweight, though. Is there a "thinner" "lighter" dependency I should use? Or is there a way for the plugin to somehow shove a jndi.properties onto the classpath somehow?

Comment by Sanjeeb Sahoo [ 06/Feb/11 ]

You have at least two choices:
a) Just pass a properties object containing
java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory
to new InitialContext().
b) Add jndi.properties to your application.





[GLASSFISH-15836] @Remote EJBs involving inheritance cause CORBA serialization error in embedded Glassfish Created: 04/Feb/11  Updated: 19/Dec/16  Resolved: 11/Feb/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_dev
Fix Version/s: 3.1

Type: Bug Priority: Major
Reporter: ljnelson Assignee: Bhavanishankar
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GZip Archive glassfish-15836-1.0-SNAPSHOT-src.tar.gz     GZip Archive glassfish-15836-1.0-SNAPSHOT_v2.tar.gz     Zip Archive marina.zip     Text File run.log.txt     Text File stack.txt    
Tags: 3_1-exclude, 3_1-fishcat

 Description   

I have a (Serializable) business interface (SimpleStateless).

I have a class that implements it but which is not an EJB of any kind (SimpleStatelessBean).

I have a class that extends SimpleStatelessBean (SimpleStatelessBeanExtension). It is annotated as @Stateless(name="Extension") and @Remote.

When this small module is tested with the maven-embedded-glassfish-plugin, a CORBA serialization error occurs. If you remove the inheritance (and adjust annotations accordingly), everything works fine.

(In the attached test case please note that the interesting bits are all in src/test/java, not src/main/java. The attached test case as written will only function when http://java.net/jira/browse/GLASSFISH-15835 is fixed.)

Bhavani is already working on this.



 Comments   
Comment by ljnelson [ 04/Feb/11 ]

The stack, in case it matters, and for those too impatient to run the test case. Note that the stack appears to be in the core Glassfish componentry, not the embedded stuff:

<pre>
org.omg.CORBA.BAD_PARAM: WARNING: IOP00100006: Class com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate is not Serializable vmcid: SUN minor code: 6 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy122.notSerializable(Unknown Source)
at com.sun.corba.ee.impl.orbutil.ORBUtility.throwNotSerializableForCorba(ORBUtility.java:783)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_abstract_interface(CDROutputStream_1_0.java:697)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_abstract_interface(CDROutputObject.java:545)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAbstractObject(Util.java:493)
at com.sun.corba.ee.impl.io.IIOPOutputStream.writeObjectField(IIOPOutputStream.java:771)
at com.sun.corba.ee.impl.io.IIOPOutputStream.outputClassFields(IIOPOutputStream.java:846)
at com.sun.corba.ee.impl.io.IIOPOutputStream.defaultWriteObjectDelegate(IIOPOutputStream.java:245)
at com.sun.corba.ee.impl.io.IIOPOutputStream.outputObject(IIOPOutputStream.java:614)
at com.sun.corba.ee.impl.io.IIOPOutputStream.simpleWriteObject(IIOPOutputStream.java:196)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueInternal(ValueHandlerImpl.java:235)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueWithVersion(ValueHandlerImpl.java:216)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:180)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.callWriteValue(CDROutputStream_1_0.java:852)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.writeRMIIIOPValueType(CDROutputStream_1_0.java:837)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:962)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:930)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:976)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:706)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_value(CDROutputObject.java:527)
at com.sun.corba.ee.impl.io.IIOPOutputStream.writeObjectField(IIOPOutputStream.java:775)
at com.sun.corba.ee.impl.io.IIOPOutputStream.outputClassFields(IIOPOutputStream.java:846)
at com.sun.corba.ee.impl.io.IIOPOutputStream.defaultWriteObjectDelegate(IIOPOutputStream.java:245)
at com.sun.corba.ee.impl.io.IIOPOutputStream.outputObject(IIOPOutputStream.java:614)
at com.sun.corba.ee.impl.io.IIOPOutputStream.simpleWriteObject(IIOPOutputStream.java:196)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueInternal(ValueHandlerImpl.java:235)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueWithVersion(ValueHandlerImpl.java:216)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:180)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.callWriteValue(CDROutputStream_1_0.java:852)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.writeRMIIIOPValueType(CDROutputStream_1_0.java:837)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:962)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:976)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_value(CDROutputObject.java:521)
at com.sun.corba.ee.impl.corba.TCUtility.marshalIn(TCUtility.java:157)
at com.sun.corba.ee.impl.corba.AnyImpl.write_value(AnyImpl.java:627)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_any(CDROutputStream_1_0.java:627)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_any(CDROutputObject.java:489)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAny(Util.java:366)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.write(DynamicMethodMarshallerImpl.java:307)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.writeResult(DynamicMethodMarshallerImpl.java:489)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:178)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
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)
Feb 4, 2011 11:46:11 AM com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator handleFullLogging
WARNING: IOP01000001: Missing local value implementation
org.omg.CORBA.NO_IMPLEMENT: WARNING: IOP01000001: Missing local value implementation vmcid: SUN minor code: 1 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy122.missingLocalValueImpl(Unknown Source)
at com.sun.corba.ee.impl.io.FVDCodeBaseImpl.implementation(FVDCodeBaseImpl.java:113)
at com.sun.org.omg.SendingContext._CodeBaseImplBase._invoke(_CodeBaseImplBase.java:64)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
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: java.lang.ClassNotFoundException: ljnelson.glassfish.embedded.bug._EJB31_GeneratedSimpleStatelessBeanExtensionIntf__Bean_ (no security manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:375)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:202)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:135)
at com.sun.corba.ee.impl.util.JDKBridge.loadClassM(JDKBridge.java:319)
at com.sun.corba.ee.impl.util.JDKBridge.loadClass(JDKBridge.java:228)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.loadClass(Util.java:640)
at com.sun.corba.ee.impl.util.RepositoryId.getClassFromType(RepositoryId.java:577)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.getClassFromType(ValueHandlerImpl.java:373)
at com.sun.corba.ee.impl.io.FVDCodeBaseImpl.implementation(FVDCodeBaseImpl.java:105)
... 12 more
</pre>

Comment by ljnelson [ 07/Feb/11 ]

Thanks for your hard work on all these related issues. I was wondering what kind of progress had been made here.

Comment by ljnelson [ 07/Feb/11 ]

This is a false alarm.

As it turns out, @Remote isn't the problem. Inheritance is the problem.

If SimpleStatelessBeanExtension is annotated with @Stateless, and extends the POJO SimpleStatelessBean, and if SimpleStatelessBean implements SimpleStateless, this exception will also occur.

Comment by ljnelson [ 07/Feb/11 ]

The attached test case, glassfish-15836-1.0-SNAPSHOT-src.tar.gz, reproduces this error with as few external concerns as possible.

The previous test case should be deleted.

Comment by marina vatkina [ 07/Feb/11 ]

It's probably still a Remote issue - I've just updated 2 test cases (v2/appserv-tests/devtests/ejb/ejb31/embedded/modulewithlibs & v2/appserv-tests/devtests/ejb/ejb31/embedded/twomoduleswithlibs) to which I added a base pojo class which implements an interface. If nothing else is changed, there is no problem.

What's a bit strange though is that if I mark the interface as @Local, the bean seems to be treated as a non-interface bean (but that's a different problem)

Comment by marina vatkina [ 07/Feb/11 ]

@Local interface on a pojo superclass works fine (the printed JNDI name is not correct)

Comment by ljnelson [ 07/Feb/11 ]

Well, wait, now; do I understand you correctly to be saying that the "middle" class, when annotated, works OK? Because my test case deliberately does NOT annotate the middle class, and in my real-world scenario, I only want the "grandchild" to be annotated.

Comment by marina vatkina [ 07/Feb/11 ]

I didn't go that far away in history . My test has a parent and a child, with an interface placed on a parent.

Comment by ljnelson [ 07/Feb/11 ]

OK, so long as the test case to this bug eventually passes. I'll be VERY curious to learn what the root issue is....

Comment by Nazrul [ 07/Feb/11 ]

Since this did not make it into RC2, excluding from 3.1 count.

Comment by ljnelson [ 08/Feb/11 ]

Marina, I cannot make the attached test case pass by doing any of the following:

1. Removing @Remote from BusinessInterfaceSLSB
2. Putting @Local on BusinessInterfaceSLSB
3. Removing @Local and @Remote from BusinessInterfaceSLSB, putting @Local on BusinessInterface

Could you kindly make the required adjustment to the attached test case, and attach it again so that I can see how you worked around this bug?

Comment by marina vatkina [ 08/Feb/11 ]

This is the modified version of the test that uses @Local on the child (according to the EJB spec section 4.9.2.1 the interfaces must be declared on the bean itself), and using embeddable EJB container API with a static-shell.jar. I moved things around a little bit, and made it a simple Java test that (sorry) I compiled and ran manually.

Comment by marina vatkina [ 08/Feb/11 ]

I meant to say that the attached test works fine.

Comment by ljnelson [ 08/Feb/11 ]

Yes, but please note that it does NOT work fine when run via the embedded plugin.

Thanks for the work required for the extra attachment.

Comment by marina vatkina [ 08/Feb/11 ]

Did you try with the same changes to the SimpleStatelessBeanExtension?

Comment by ljnelson [ 08/Feb/11 ]

Well, I deleted that test case (see http://java.net/jira/browse/GLASSFISH-15836?focusedCommentId=301960&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_301960), so the one that is attached doesn't even include SimpleStatelessBeanExtension.

Anyway, yes, I ran the attached test case after adding @Local(BusinessInterface.class) to BusinessInterfaceSLSB.java, and got a CORBA serialization error.

I will (again) delete the attached test case and re-attach a version annotated in the way that you describe.

Comment by ljnelson [ 08/Feb/11 ]

This attachment is the latest test case and hopefully incorporates your suggested workarounds. Unfortunately the test still fails.

Comment by ljnelson [ 08/Feb/11 ]

I will also attach the stack that results from running the attached test case as is.

Comment by ljnelson [ 08/Feb/11 ]

I have just attached the stack trace that results from running the attached test case.

To run the attached test case, just gunzip/tar xf it, cd into the root directory, and run mvn clean install. Tested with Maven 3.0.2.

Comment by smsiebe [ 09/Feb/11 ]

Verified test case glassfish-15836-1.0-SNAPSHOT errors on test.

Apache Maven 3.0 (r1004208; 2010-10-04 07:50:56-0400)
Java version: 1.6.0_16
Java home: C:\Sun\SDK\jdk\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows"

Comment by Bhavanishankar [ 10/Feb/11 ]

In the current test case you have attached viz., glassfish-15836-1.0-SNAPSHOT-src.tar.gz, you are deploying a local EJB using the maven-embedded-glassfish-plugin and trying to look up that EJB from your JUnit test which runs in surefire-plugin. Since the plugins run on their own classloader, you will not be able to do the look up of the local EJB in your JUnit test.

The original test case you had attached was with remote EJB and was a correct test case. Could you please attach it again?

Comment by ljnelson [ 10/Feb/11 ]

Will do immediately; thanks.

Comment by ljnelson [ 10/Feb/11 ]

Hallelujah; that worked. b05 of the embedded plugin works and resolves this issue.

(Now to figure out how I'm going to test local EJBs without using the plugin...if you have an idea on how I could test local EJBs WITH the plugin I'm all ears. Do I need to go back to using the embeddable Glassfish container directly?)

Comment by Bhavanishankar [ 10/Feb/11 ]

For the local EJBs, v3/tests/embedded/maven-plugin/localejbs should help? Let me know otherwise.

Also, for remote EJBs, could you please attach the working test case?

Comment by Bhavanishankar [ 11/Feb/11 ]

This works fine with 3.1-b05 of the plugin (i.e., 3.1-b41)

Changing @Local(BusinessInterface.class) to @Remote(BusinessInterface.class) in BusinessInterfaceSLSB.java is necessary.

I attach the modified test and the successful run log.

Comment by Scott Fordin [ 24/Mar/11 ]

Does this need to be Release Noted?

Comment by Scott Fordin [ 23/May/11 ]

In the absence of additional information and the fact that this bug is closed and fixed in 3.1, I'm thinking that this no longer needs to be included in the Release Notes.





[GLASSFISH-15835] No way to inject artifacts into maven-embedded-glassfish-plugin classpath Created: 04/Feb/11  Updated: 19/Dec/16  Resolved: 04/Feb/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_dev
Fix Version/s: 3.1

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

Attachments: GZip Archive glassfish-15835-1.0-SNAPSHOT-src.tar.gz    
Tags: 3_1-fishcat

 Description   

(Bhavani is already working on this; please make sure this is assigned to him.)

The maven-embedded-glassfish-plugin has the capability of pointing to an external config file (domain.xml), but if that domain.xml refers to-for example-a JDBC connection pool that requires a JDBC database driver, then it is impossible to get the database driver's jar onto the classpath of the embedded Glassfish instance.

Bhavani supplied me with a patch that fixes this problem, but the fix needs obviously to make it into the plugin core.



 Comments   
Comment by Bhavanishankar [ 04/Feb/11 ]

Fix has been checked in.

Comment by ljnelson [ 07/Feb/11 ]

Hi, Bhavani; what build is this fix part of? b41, I hope?

Comment by Bhavanishankar [ 07/Feb/11 ]

The changes were part of the plugin. So, the upcoming 3.1-b05 version of the plugin should have it (current 3.1-SNAPSHOT should already have the fix).

Comment by ljnelson [ 07/Feb/11 ]

Bhavani, we may have to reopen this one; not sure.

3.2-SNAPSHOT of the plugin prints the following:

[INFO] — maven-embedded-glassfish-plugin:3.2-SNAPSHOT:start (default) @ junit-ejb-dbunit-mem —
Created New Bootstrap ClassLoader. ServerId = embedded, ClassPaths =
ClassPath Element : file:/Users/ljnelson/.m2/repository/org/glassfish/extras/glassfish-embedded-all/3.1-b39/glassfish-embedded-all-3.1-b39.jar
ClassPath Element : file:/Users/ljnelson/.m2/repository/org/glassfish/maven-embedded-glassfish-plugin/3.2-SNAPSHOT/maven-embedded-glassfish-plugin-3.2-SNAPSHOT.jar

You'll notice that h2 is not part of this list. When we were working on diagnosing this problem, the locally patched 3.2-SNAPSHOT file you sent me printed an additional ClassPath element that (when I had h2 in my dependencies section) also printed h2 as a classpath element.

Now, what's odd is that in my test case (which you have, I believe), h2 is found and located, even with this output. I confirm this by looking up a datasource directly and getting a connection from it:

final DataSource ds = (DataSource)context.lookup("java:global/jdbc/H2Test");
ds.getConnection();

...where obviously I've set up H2Test in my domain.xml file properly.

However, in my real-world example, which also includes a JPA persistence unit, EclipseLink cannot find the H2 driver. So, to recap, a straight DataSource lookup and connection retrieval works fine, but internal JPA operations (setting up the EntityManagerFactory, it looks like) fail.

Here's a sample stack:

Feb 7, 2011 2:50:03 PM com.sun.gjc.common.DataSourceObjectBuilder getDataSourceObject
SEVERE: jdbc.exc_cnfe_ds
java.lang.ClassNotFoundException: org.h2.jdbcx.JdbcDataSource
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:180)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:172)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at com.sun.gjc.common.DataSourceObjectBuilder.getDataSourceObject(DataSourceObjectBuilder.java:283)
at com.sun.gjc.common.DataSourceObjectBuilder.constructDataSourceObject(DataSourceObjectBuilder.java:112)
at com.sun.gjc.spi.ManagedConnectionFactory.getDataSource(ManagedConnectionFactory.java:1290)
at com.sun.gjc.spi.DSManagedConnectionFactory.getDataSource(DSManagedConnectionFactory.java:148)
at com.sun.gjc.spi.DSManagedConnectionFactory.createManagedConnection(DSManagedConnectionFactory.java:101)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getUnpooledConnection(ConnectorConnectionPoolAdminServiceImpl.java:699)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnection(ConnectorConnectionPoolAdminServiceImpl.java:1602)
at com.sun.enterprise.connectors.ConnectorRuntime.getConnection(ConnectorRuntime.java:584)
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl$MyDataSource.getConnection(ConnectorResourceAdminServiceImpl.java:277)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:126)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:94)
at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:330)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:291)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connect(DatasourceAccessor.java:418)
at org.eclipse.persistence.sessions.server.ConnectionPool.buildConnection(ConnectionPool.java:167)
at org.eclipse.persistence.sessions.server.ExternalConnectionPool.startUp(ExternalConnectionPool.java:130)
at org.eclipse.persistence.sessions.server.ServerSession.connect(ServerSession.java:484)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.login(DatabaseSessionImpl.java:640)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:235)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:394)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:185)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:242)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:230)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.doJava2DB(PersistenceUnitLoader.java:373)
at org.glassfish.persistence.jpa.JPADeployer$2.visitPUD(JPADeployer.java:423)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:475)
at org.glassfish.persistence.jpa.JPADeployer.iterateInitializedPUsAtApplicationPrepare(JPADeployer.java:453)
at org.glassfish.persistence.jpa.JPADeployer.event(JPADeployer.java:377)

I will adapt my test case to this bug and attach it when I've got it suitably isolated.

Comment by ljnelson [ 07/Feb/11 ]

Please see the attached test case which proves that this bug needs to be reopened.

H2 is found on the classpath when you do a direct DataSource lookup from an InitialContext, but it is NOT found by the EclipseLink internals. My suspicion is that whatever classpath you set up did not get propagated to the loader that EclipseLink uses.

Comment by Bhavanishankar [ 07/Feb/11 ]

As I had mentioned in the previous comment, you should try with 3.1-b05 or 3.1-SNAPSHOT of the maven plugin. Not sure why you are using 3.2-SNAPSHOT.

Comment by ljnelson [ 08/Feb/11 ]

Well, you had sent me a patched version of 3.2-SNAPSHOT; I figured that the "real" 3.2-SNAPSHOT would have the fix.

Additionally, 3.1-b05 was not available yesterday.

The good news is that 3.1-b05 IS available today, and the test case now runs. Thanks for your work.

Comment by chrisatpinguin [ 21/Apr/11 ]

Hi,

I know this issue is closed, but I try to use the embedded-gf-plugin with a jdbc Resource for DB2. So I need to add the driver jars. But how do I have to do that? Could someone please give me a hint or show me an example of the plugin configuration.





[GLASSFISH-15775] Remote EJBs fail with ClassCastException in embeddable Glassfish Created: 31/Jan/11  Updated: 20/Dec/16  Resolved: 30/May/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1_dev, 4.0

Type: Bug Priority: Major
Reporter: ljnelson Assignee: Bhavanishankar
Resolution: Fixed Votes: 13
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive glassfish-test-arquillian.zip    
Tags: 3_1-exclude, 3_1-fishcat, 3_1-release-note-added, 3_1-release-notes, 3_1_1-approved, 3_1_1-next

 Description   

I think I've found a specification violation in the embeddable Glassfish project. My apologies if it turns out that this is not the case, but I've taken the liberty of setting the priority to Major because I don't see any wiggling out of this one.

Here's what the specification has to say about business interfaces of stateless session beans in section 4.9.7:

"If the business interface is a remote business interface, the argument and return values must be of valid types for RMI/IIOP. The remote business interface is not required or expected to be a java.rmi.Remote interface."

My business interface is declared thusly:

public interface AppealTypeManager extends DAO<Long, AppealType>

{ public Collection <? extends AppealType> findAllAppealTypes(final PagingControl pagingControl); }

(Note the lack of @Remote, and the lack of "extends Remote".)

My bean class is declared thusly:

@Stateless//(name = "AppealTypeManager")
@TransactionAttribute(TransactionAttributeType.REQUIRED)
@Remote(AppealTypeManager.class)
public class AppealTypeManagerBean extends AbstractDAO<Long, AppealType, AppealTypeEntity> implements AppealTypeManager

{ // ...etc. }

I look up a reference to the remote business interface like this:

final Context c = new InitialContext();
final AppealTypeManager a = (AppealTypeManager)c.lookup("java:global/test-classes/AppealTypeManagerBean");

When I deploy my EJB module to embeddable Glassfish, I get the following error upon lookup:

javax.naming.NamingException: Lookup failed for 'java:global/test-classes/AppealTypeManagerBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.jenzabar.ngp.ia.designation.api.AppealTypeManager [Root exception is java.lang.ClassCastException]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:525)
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.jenzabar.junit.ejb.dbunit.mem.GlassfishEmbeddedStrategy.getBean(GlassfishEmbeddedStrategy.java:126)
at com.jenzabar.junit.ejb.dbunit.mem.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:98)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:145)
at org.apache.maven.surefire.Surefire.run(Surefire.java:104)
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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1017)
Caused by: javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.jenzabar.ngp.ia.designation.api.AppealTypeManager [Root exception is java.lang.ClassCastException]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:434)
at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:559)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:521)
... 34 more
Caused by: java.lang.ClassCastException
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:262)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$12.read(DynamicMethodMarshallerImpl.java:353)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java)
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.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:422)
... 38 more
Caused by: java.lang.ClassCastException: Object is not of remote type java.rmi.Remote
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:254)
... 50 more

Again, the specification does not require a remote business interface to extend java.rmi.Remote, but it would appear that the Glassfish embedded runtime thinks it's necessary.



 Comments   
Comment by Bhavanishankar [ 31/Jan/11 ]

This seems to be an EJB container (or may be naming) issue. Hence re-categorizing.

It can also be easily reproducible by running v2/appserv-tests/devtests/ejb/ejb31/embedded/remote

Comment by ljnelson [ 01/Feb/11 ]

This bug is present back through build 33; prior to that the API changed.

(Of course it looks from the signature of the devtest you're talking about that this goes back to Glassfish 2?)

"Forum" discussion here: http://www.java.net/forum/topic/glassfish/glassfish/glassfish-embedded-specification-violati

Comment by ljnelson [ 01/Feb/11 ]

This bug seems to have something to do with http://java.net/jira/browse/EMBEDDED_GLASSFISH-119, or rather both of them probably have the same underlying problem.

It is my understanding that javax.ejb.embeddable.EJBContainer is under no obligation to support @Remote EJBs, and that org.glassfish.embeddable.* MUST (or at least is intended to) support @Remote EJBs.

Comment by marina vatkina [ 01/Feb/11 ]

Bhavani, please take a look: changes for rev 38343 & 38344 caused this regression. If you think that EJB container needs to adjust for these changes, it'd be helpful to know what it should be aware of. I do not see anything suspicious about the CLs used in the EJBUtils.lookupRemote30BusinessObject.

Comment by Bhavanishankar [ 03/Feb/11 ]

Marina, the change revs you are referring to seem like the changes related to OSGi.
IMO that can not be the cause for this. Why do you think otherwise?

Comment by marina vatkina [ 03/Feb/11 ]

Bhavani, ejb31/embedded/remote passes with rev 38342 and fails with the ClassCastException: Object is not of remote type java.rmi.Remote with rev 38344.

Comment by Nazrul [ 07/Feb/11 ]

Since this did not make it into RC2, excluding from 3.1 count.

Comment by Sanjeeb Sahoo [ 07/Feb/11 ]

This is a Thread context class loader issue. GlassFish.start() sets the context class loader to an internal class loader and forgets to reset it after the call is complete. This is why user's classes can no longer be loaded using the context class loader in the thread that starts the server. Bhavani & I have discussed this and it will be addressed soon.

"A possible work around is to set the context class loader before looking up the remote EJB." e.g.,

GlassFish gf = GlassFishRuntime.bootstrap().newGlassFish();
gf.start();
gf.getDeployer().deploy(myapp);
ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
try

{ Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); new InitialContext().lookup(myEJB); }

finally

{ Thread.currentThread().setContextClassLoader(oldCl); }
Comment by Bhavanishankar [ 07/Feb/11 ]

Just added a devtest under v3/tests/embedded/ejb/remoteejb which follows the workaround.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Scott Fordin [ 13/Apr/11 ]

Does this still need to be included in the 3.1 Release Notes? If so, I need more information.

Comment by Scott Fordin [ 17/May/11 ]

Went with what information I had. Added issue to 3.1 Known Issues section of 3.1-3.1.1 Release Notes.

Comment by Bhavanishankar [ 27/May/11 ]

Why fix this issue in 3.1.1?

> This is issue that is directly reported by community.

Which is the targeted build of 3.1.1 for this fix?

> b07

Do regression tests exist for this issue?

> Yes – embedded devtests/fidelity tests.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

> Regular QA tests should be run. No new test is required. Embedded devtest will take care of verifying the fix.

Comment by Bhavanishankar [ 30/May/11 ]

Adding 3.2 also as the fixVersion

Comment by vasilievip [ 05/Aug/11 ]

Bug still exists on GF 3.1.1, please reopen.
Please find attached testcase.

Comment by jyrkip [ 27/Sep/13 ]

Happens on embedded 4.0 too.





[GLASSFISH-15769] Regression: Weaving attempted in Glassfish embedded even though supposedly disabled Created: 31/Jan/11  Updated: 19/Dec/16  Resolved: 04/Feb/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Tags: 3_1-approved, 3_1-fishcat

 Description   

Weaving is apparently disabled-or at least that's the intent-in Glassfish embedded.

However, when I use the embeddable Glassfish APIs, documented at http://embedded-glassfish.java.net/nonav/apidocs/, it appears that weaving is attempted.

I have an EJB project set up with a persistence unit in it. So, some classes are EJB interfaces, others are EJB implementations, and others are entity classes. There is a META-INF/persistence.xml file in there. javax.ejb.embeddable.EJBContainer deploys this "archive" fine.

I've recently switched over to using the Glassfish embeddable APIs instead, since they are more robust (they support remote EJBs among other things). I've made no other changes.

At test time, I get the exception message detailed by this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=323403

That is, EclipseLink 2.2.0 is attempting to invoke a weaving-supplied method, even though weaving is disabled.

I suspect that something about the way weaving is "disabled" is not in fact fully disabling it.

In point of fact, I would like weaving to be ON. But I understand that this is an issue with an embedded API.

I can work around this issue if I explicitly set weaving to be off in my persistence.xml file:

<property name="eclipselink.weaving" value="false"/>

...but I'd rather not do that.



 Comments   
Comment by Mitesh Meswani [ 03/Feb/11 ]

Weaving was always disabled in embedded mode to guard against use cases where entity classes are touched (and hence loaded) by the app before transformers get installed. JPADeployer relied on serverEnvironment.isEmbedded() to determine if it is being run in embedded mode. Embedded implementation has recently changed to not answer true for serverEnvironment.isEmbedded() causing the regression. After discussions, it seems instead of always disabling weaving, a more flexible approach would be to enabled it by default and give user an option to explicitly disable it for embedded. Following diffs implements the change

Index: src/main/java/org/glassfish/persistence/jpa/JPADeployer.java
===================================================================
— src/main/java/org/glassfish/persistence/jpa/JPADeployer.java (revision 44872)
+++ src/main/java/org/glassfish/persistence/jpa/JPADeployer.java (working copy)
@@ -42,6 +42,7 @@

import com.sun.appserv.connectors.internal.api.ConnectorRuntime;
import com.sun.enterprise.deployment.*;
+import com.sun.enterprise.module.bootstrap.StartupContext;
import com.sun.logging.LogDomains;
import org.glassfish.api.deployment.DeployCommandParameters;
import org.glassfish.api.event.EventListener;
@@ -84,6 +85,9 @@
private ServerEnvironmentImpl serverEnvironment;

@Inject
+ private volatile StartupContext sc = null;
+
+ @Inject
private Events events;

@Inject
@@ -196,7 +200,13 @@
@Override void visitPUD(PersistenceUnitDescriptor pud, DeploymentContext cont
ext) {
if(referencedPus.contains(pud)) {
boolean isDas = isDas();

  • ProviderContainerContractInfo providerContainerContractInfo = serverEnvironment.isEmbedded() ?
    +
    + // While running in embedded mode, it is not possible to guarantee that entity classes are not loaded by the app classloader before transformers are installed
    + // If that happens, weaving will not take place and EclipseLink will throw up. Provide users an option to disable weaving by passing the flag.
    + // Note that we enable weaving if not explicitly disabled by user
    + boolean weavingEnabled = Boolean.valueOf(sc.getArguments().getProperty("org.glassfish.persistence.embedded.weaving.enabled", "true"));
    +
    + ProviderContainerContractInfo providerContainerContractInfo = weavingEnabled ?
    new EmbeddedProviderContainerContractInfo(context, connectorRuntime, isDas) :
    new ServerProviderContainerContractInfo(context, connectorRuntime, isDas);
    PersistenceUnitLoader puLoader = new PersistenceUnitLoader(pud, providerContainerContractInfo);
Comment by Mitesh Meswani [ 03/Feb/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Is a regression of functionality from prior release.
  • With this issue present, if an app needs to disable weaving for embedded, the app's persistence.xml needs to be changed. This is quite inconvenient for unit test scenarios (The main use case for embedded)

How often does it happen? (Frequency)

  • For any app that needs to disable weaving

How much effort is required to fix it? (Cost)

  • The fix is available and is attached in previous comment

What is the risk of fixing it? (Risk)

  • Minimal to no risk. The fix is localized to embedded use case. I have verified in debugger that nothing is changed for non embedded case.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • Work around is to modify persistence.xml to explicitly disable weaving. This makes using embedded for unit testing inconvenient

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • Yes

How long has the bug existed in the product?

  • Not more than a month

Do regression tests exist for this issue?

  • No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • The standard QE test suit against derby. I have already run them with these changes.

When will a tested fix be ready for integration?

  • It is available now.
Comment by Mitesh Meswani [ 03/Feb/11 ]

Checked in the code branch rev 44890, trunk rev 44889

Comment by Mitesh Meswani [ 03/Feb/11 ]

Assigning to docs to document the property "org.glassfish.persistence.embedded.weaving.enabled" in Embedded guide

Comment by Sanjeeb Sahoo [ 03/Feb/11 ]

I am not convinced by the change. There seem to be an assumption made about embedded which is not true. Why can't weaving be disabled outside embedded mode? Similarly, what happens when weaving has not disabled in embedded mode using this system property, but it has been explicitly disabled using persistence.xml? Are we loosing out any functionality by not using EmbeddedProviderContractInfo? Or, is it just a matter of name here?

Comment by Mitesh Meswani [ 03/Feb/11 ]

What do you mean by weaving disabled outside embedded mode?

> what happens when weaving has not disabled in embedded mode using this system property, but it has been explicitly disabled using persistence.xml?
It will be disabled.

>Are we loosing out any functionality by not using EmbeddedProviderContractInfo? Or, is it just a matter of name here?
No. It is just matter of name. EmbeddedProviderContractInfo currently just provides isWeavingDisabled(). Once the trunk opens up, I am inclined towards removing the class with some refactoring.

Comment by marina vatkina [ 03/Feb/11 ]

I'm confused... ServerEnvironmentImpl.isEmbedded() returns true in static-shell run of the EJB Timer Service...

Comment by marina vatkina [ 04/Feb/11 ]

All JPA tests in embedded ejb devtests failed - see http://hudson-sca.us.oracle.com/job/ejb-devtests-v3/281/

Comment by Mitesh Meswani [ 04/Feb/11 ]

Checked in 44918 in trunk and 44919 in branch.
The check in disables weaving for embedded EJB container case as was before. The status now is:
-Weaving is enabled by default when GlassFish Emedded API is used. It can be disabled by specifying property "org.glassfish.persistence.embedded.weaving.enabled" as "false"
-Weaving is disabled for embedded EJB container use case.

This behavior is not yet stable and can be changed in future versions of GlassFish.

Comment by ljnelson [ 04/Feb/11 ]

Thanks for your hard work.

Comment by Sanjeeb Sahoo [ 04/Feb/11 ]

Replying to Mitesh's response:

> What do you mean by weaving disabled outside embedded mode?
What this means is for whatever reason, someone may like to disable weaving in regular glassfish - e.g., someone wants to measure benefits of weaving, but they don't want to change their persistence.xmls to set the property. In such a case, the new system property can be very handy.

>> what happens when weaving has not disabled in embedded mode using this system property, but it has been explicitly disabled using persistence.xml?
> It will be disabled.
That's the desired behavior.

>> Are we loosing out any functionality by not using EmbeddedProviderContractInfo? Or, is it just a matter of name here?
> No. It is just matter of name. EmbeddedProviderContractInfo currently just provides isWeavingDisabled(). Once the trunk opens up, > I am inclined towards removing the class with some refactoring.

I look forward to this improvement to improve clarity in the code.

Thanks.

Comment by ljnelson [ 10/Feb/11 ]

Please also see http://java.net/jira/browse/GLASSFISH-13688





[GLASSFISH-15764] ScatteredArchive is present in wrong package Created: 31/Jan/11  Updated: 19/Dec/16  Resolved: 31/Jan/11

Status: Closed
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_dev
Fix Version/s: None

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

Tags: 3_1-fishcat

 Description   

Something is up with the embedded API.

From various forum posts and whatnot I gather that the official, maintained 3.1 embeddable API is documented here: http://embedded-glassfish.java.net/nonav/apidocs/

You will notice that here there is a class called ScatteredArchive in the org.glassfish.embeddable.archive package.

However, in the glassfish-embedded-all 3.1-SNAPSHOT jar artifact, ScatteredArchive appears to be a different class, and is located in the (obsolete?) org.glassfish.embedded.api package.

There is an awful lot of outdated incorrect information floating around out there; I'm no longer sure what is official and what is not.



 Comments   
Comment by ljnelson [ 31/Jan/11 ]

Workaround is to add org.glassfish.common:scattered-archive-api:jar in any pom.xml that currently uses glassfish-embedded-all.

Comment by ljnelson [ 31/Jan/11 ]

Looks like glassfish-embedded-all 3.1-b39 is OK though. Maybe the 3.1-SNAPSHOT is ancient/out of date/unsupported...?

Comment by Snjezana Sevo-Zenzerovic [ 31/Jan/11 ]

Moving to appropriate subcategory.

Comment by Bhavanishankar [ 31/Jan/11 ]

You are referring to the right javadocs.

I just downloaded http://download.java.net/maven/glassfish/org/glassfish/extras/glassfish-embedded-all/3.1-SNAPSHOT/glassfish-embedded-all-3.1-SNAPSHOT.jar, and I see that the ScatteredArchive is correctly packaged:

jar tvf glassfish-embedded-all-3.1-SNAPSHOT.jar |grep scatteredarchive | grep embeddable
1293 Mon Jan 31 15:43:16 IST 2011 org/glassfish/embeddable/archive/ScatteredArchive$Type.class
3206 Mon Jan 31 15:43:16 IST 2011 org/glassfish/embeddable/archive/ScatteredArchive.class

However, I recommend either use 3.1-b39 or 3.2-SNAPSHOT

Comment by Bhavanishankar [ 31/Jan/11 ]

Just to add, there might have been a problem with the repository for a short duration during the time you have downloaded 3.1-SNAPSHOT, but now it looks all fine.





[GLASSFISH-15663] Common Tasks: Broken Doc Links Created: 23/Jan/11  Updated: 19/Dec/16  Resolved: 27/Jan/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Attachments: HTML File 2011-01-31-19-46-install-summary.html    
Tags: 3_1-approved, 3_1-fishcat

 Description   

The Documentation links on the Common Tasks welcome page are broken. They all link or redirect to http://www.oracle.com/pls/topic/error.



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

The link points to 3.1 doc set is correct. But according to the doc team, the page will not come alive till 3.1 ships. I don't need this arrangement either.

Transfer to 'doc' team. They can verify the link one more time and mark resolve.

Doc links for 3.1
commonTasks.doc.qstart=http://www.oracle.com/pls/topic/lookup?ctx=821-2432
commonTasks.doc.adminGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2416
commonTasks.doc.devGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2418
commonTasks.doc.deployGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2417

Comment by Paul Davies [ 24/Jan/11 ]

If engineering feels uneasy about linking to documentation that will not be live until the product is released, all I can suggest is that the links be removed from the software.

Comment by Paul Davies [ 26/Jan/11 ]

After checking again with the doc tools team, I have discovered that the URLs that I was originally given were incorrect:

The correct URLs are as follows:

commonTasks.doc.qstart=http://www.oracle.com/pls/topic/lookup?ctx=821-2432&id=sjsaseeqsg
commonTasks.doc.adminGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2416&id=sjsaseeag
commonTasks.doc.devGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2418&id=sjsaseedg
commonTasks.doc.deployGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2417&id=sjsaseeadg

Note that the targets of these corrected URLs will not be live until the product ships and will continue to return an error until then.

Comment by Paul Davies [ 26/Jan/11 ]

Assigned to owner of admin_gui for fixing.

Comment by Anissa Lam [ 26/Jan/11 ]

How bad is its impact? (Severity)
Very severe. User will not be able to get to the documentation from admin conole.

How often does it happen? (Frequency)
Whenever user clicks the doc link in the common task page.

How much effort is required to fix it? (Cost)
1 hour

What is the risk of fixing it? (Risk)
changing this link is not risky, it is in the i18n string file.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No workaround.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes

Index: core/src/main/resources/org/glassfish/admingui/core/Strings.properties
===================================================================
— core/src/main/resources/org/glassfish/admingui/core/Strings.properties (revision 44647)
+++ core/src/main/resources/org/glassfish/admingui/core/Strings.properties (working copy)
@@ -400,10 +400,11 @@

  1. change the doc link to the localized copy if there is any
    -commonTasks.doc.qstart=http://www.oracle.com/pls/topic/lookup?ctx=821-2432
    -commonTasks.doc.adminGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2416
    -commonTasks.doc.devGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2418
    -commonTasks.doc.deployGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2417
    +commonTasks.doc.qstart=http://www.oracle.com/pls/topic/lookup?ctx=821-2432&id=sjsaseeqsg
    +commonTasks.doc.adminGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2416&id=sjsaseeag
    +commonTasks.doc.devGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2418&id=sjsaseedg
    +commonTasks.doc.deployGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2417&id=sjsaseeadg
    +
  2. end Common Tasks keys

#common

Comment by Anissa Lam [ 27/Jan/11 ]

Committed revision 44741.
Revision: 44741
Author : anilam
Date : Jan 27, 2011 8:49:41 AM
GLASSFISH-15663. Fix the link to the unbundled doc on common task page.

Approve: Anissa
Reviewer: Paul Davies.

Comment by stephanj [ 01/Feb/11 ]

The glassfish install summary HTML file shows many links to http://docs.sun.com/doc/820-7690 which are broken.

Comment by scatari [ 01/Feb/11 ]

Paul,
Can u provide us with the updated URL for Install Guide(online)? Are we not setting redirects for these links?

Thanks

Comment by Anissa Lam [ 01/Feb/11 ]

This bug has been resolved, and not related to installation summary HTML file at all.
I have opened http://java.net/jira/browse/GLASSFISH-15782 for that.





[GLASSFISH-15662] Admin Console: Wrong message on JMS Ping Created: 23/Jan/11  Updated: 19/Dec/16  Resolved: 26/Jan/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Tags: 3_1-approved, 3_1-fishcat

 Description   

Go to Admin Console | Configurations | default-config | Java Message Service and click on Ping.

A yellow message banner appears:

Expected message: Ping succeeded
Actual message: New values successfully saved.

Besides, the page title should read Java Message Service (not JMS Service) to match the tree item in the left-hand panel.



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

I am changing this to a P3, and would like Jason to take a look.
We should give feedback correctly to user whether the Ping success or Fail.

Comment by Harshad Vilekar [ 24/Jan/11 ]

Note: JMS ping incorrect message is specific to "default-config". It shows correct message "Ping Succeeded" under cluster-config and server-config.

Comment by Jason Lee [ 26/Jan/11 ]

Attempting to ping the JMS broker for the default config doesn't make sense, as there's no server (and, hence, no broker) associated with the config, so there's nothing to ping. That being so, I'm removing the ping button from the default-config page.

How bad is its impact? (Severity)
Very minor. The issue here is simply misleading or confusing feedback, which can lead to quality perception issues.

How often does it happen? (Frequency)
Every time

How much effort is required to fix it? (Cost)
Very little

What is the risk of fixing it? (Risk)
Almost none

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Perhaps. As explained, the use of this button on the default-config page doesn't make sense, so the "workaround" is probably "Don't do that!"

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
It wouldn't hurt, but I can't imaging this is a common problem.

Svn diff:

Index: admingui/jms-plugin/src/main/resources/org/glassfish/jms/admingui/Strings.properties
===================================================================
— admingui/jms-plugin/src/main/resources/org/glassfish/jms/admingui/Strings.properties (revision 44710)
+++ admingui/jms-plugin/src/main/resources/org/glassfish/jms/admingui/Strings.properties (working copy)
@@ -65,7 +65,7 @@

  1. JMS Service
    #
    jms.ResourcesPageTitle=JMS Resources
    -jms.Title=JMS Service
    +jms.Title=Java Message Service
    jms.PageHelp=General properties for the Java Message Service (JMS) service apply only to the application server's default JMS provider, GlassFish Message Queue. All other messaging providers that are plugged into the application server via resource adapters can be configured through the Connector Resources screens.
    jms.Type=Type:
    jms.TypeHelp=Whether JMS Service is on local or remote system
    Index: admingui/jms-plugin/src/main/resources/jmsService.jsf
    ===================================================================
      • admingui/jms-plugin/src/main/resources/jmsService.jsf (revision 44710)
        +++ admingui/jms-plugin/src/main/resources/jmsService.jsf (working copy)
        @@ -85,6 +85,7 @@
        <sun:title id="propertyContentPage" title="$resource {i18njms.jms.Title}

        " helpText="$resource

        {i18njms.jms.PageHelp}

        ">
        #include "/common/shared/editPageButtons.inc"
        <sun:button id="pingButton" text="$resource

        {i18njms.jms.Ping}

        "
        + rendered="#

        {pageSession.configName != 'default-config'}

        "
        onClick="return submitAndDisable(this, '$resource

        {i18n.button.Processing}

        ');" >
        <!command
        prepareSuccessfulMsg();

Comment by sirajg [ 26/Jan/11 ]

Changes look good

Comment by Jason Lee [ 26/Jan/11 ]

Fix committed (r44724)





[GLASSFISH-15661] Garbage text in Admin Console Created: 23/Jan/11  Updated: 19/Dec/16  Resolved: 23/Jan/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Tags: 3_1-apporved, 3_1-fishcat

 Description   

Go to:

Admin Console | Configurations | default-config | EJB Container | EJB Settings | Commit Options | Option B:

This item is labelled with:

AAAAAThe container caches a ready instance between transactions, ...

By the way, there's Option B and Option C, but what about Option A?



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

This 'AAAAA' is probably accidentally left behind during debugging. We should fix this.

How bad is its impact? (Severity)
No Impact. But it is very embarrassing and unprofessional to have this on the screen.

How often does it happen? (Frequency)
Everytime when user goes to the EJB Settings page, they will see this.

How much effort is required to fix it? (Cost)
min. just remove the 'AAAAA' from the static text.

What is the risk of fixing it? (Risk)
no risk.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No workaround, user will always see this.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
no.

svn diff:
~/Awork/V3/v3/admingui/ejb-lite 39) svn diff
Index: src/main/resources/configuration/ejbContainerGeneral.jsf
===================================================================
— src/main/resources/configuration/ejbContainerGeneral.jsf (revision 44647)
+++ src/main/resources/configuration/ejbContainerGeneral.jsf (working copy)
@@ -93,7 +93,7 @@
<sun:radioButton id="optB" name="commitOptGrp" label="$resource

{i18n_ejbLite.ejbSettings.optB}

" selected="#

{pageSession.valueMap['commitOption']}" selectedValue="B"
onClick="document.getElementById('form1:option').value='B';"
/>
- <sun:helpInline id="optBHelpText" style="padding: 4pt" style="font-size: 8pt" text="AAAAA$resource{i18n_ejbLite.ejbSettings.optBHelp}"/>
+ <sun:helpInline id="optBHelpText" style="padding: 4pt" style="font-size: 8pt" text="$resource{i18n_ejbLite.ejbSettings.optBHelp}"/>
"<br />
<sun:radioButton id="optC" name="commitOptGrp" label="$resource{i18n_ejbLite.ejbSettings.optC}" selected="#{pageSession.valueMap['commitOption']}

" selectedValue="C"
onClick="document.getElementById('form1:option').value='C';"

Comment by Anissa Lam [ 23/Jan/11 ]

To answer the question about commit-option. There is only option B and option C ever since v2.
Here is the dtd for v2, and the config bean in v3 follows the same.

<!ATTLIST ejb-container
...
commit-option (B | C) "B"
session-store CDATA #IMPLIED
>

Comment by Anissa Lam [ 23/Jan/11 ]

Project: glassfish
Repository: svn
Revision: 44678
Author: anilam
Date: 2011-01-24 04:44:44 UTC
Link:

Log Message:
------------
GLASSFISH-15661. Remove the text 'AAAAA' in the helptext which is left behind from debugging.

Approve: Anissa
Reviewer: Srini

Revisions:
----------
44678

Modified Paths:
---------------
trunk/v3/admingui/ejb-lite/src/main/resources/configuration/ejbContainerGeneral.jsf





[GLASSFISH-15660] [Regression] Ambiguous dependencies for Session Beans Created: 23/Jan/11  Updated: 19/Dec/16  Resolved: 26/Jan/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1_dev
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Harald Wellmann Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 10.04, JDK 1.6.0_22


Attachments: File cdi-bug.war     File GLASSFISH-15660.diff    
Issue Links:
Duplicate
duplicates GLASSFISH-15682 Programmatically injection of Statefu... Resolved
Tags: 3_1-approved, 3_1-fishcat, 3_1-regression

 Description   

There seems to be a new bug in the latest version of Weld: Session beans from CDI-enabled EJB JARs are registered twice, both as sessions beans and as managed beans, causing exceptions of the following kind:

Caused by: org.jboss.weld.exceptions.AmbiguousResolutionException:
WELD-001318 Cannot resolve an ambiguous dependency between
[Managed Bean [class com.blogspot.hwellmann.cdi.InjectedService] with qualifiers [@Any @Default],
Session bean [class com.blogspot.hwellmann.cdi.InjectedService with qualifiers [@Any @Default]; local interfaces are [InjectedService]]

Simple example to reproduce the problem:

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

package com.blogspot.hwellmann.cdi;

import javax.ejb.Stateless;

@Stateless
public class InjectedService {

public void doSomething()

{ System.out.println("********* injected method *********"); }

}

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

package com.blogspot.hwellmann.cdi;

import javax.annotation.PostConstruct;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.inject.Inject;

@Singleton
@Startup
public class ClientService {

@Inject
private InjectedService injected;

@PostConstruct
public void execute()

{ injected.doSomething(); }

}

Build a service.jar with these two classes, adding an empty META-INF/beans.xml.
Then build an almost empty WAR, containing this service.jar in WEB-INF/lib.

The WAR fails to deploy with the above exception. The problem does not occur when the two classes are directly in WEB-INF/classes and not in an embedded JAR.

This is a regression from 3.1-b33 where the same WAR can be deployed successfully.



 Comments   
Comment by Harald Wellmann [ 23/Jan/11 ]

Attached example WAR to reproduce the problem.

Comment by Sivakumar Thyagarajan [ 25/Jan/11 ]
  • 3.1 Change Control related questionnaire
  • How bad is its impact? (Severity)
    Is a regression of functionality or performance available in a prior release
  • How often does it happen? (Frequency)
    Rarely
  • How much effort is required to fix it? (Cost)
    Fix available and attached in issue
  • What is the risk of fixing it? (Risk)
    Not significant. I ran CDI devtests, TCK, other test scenarios to ensure that there are no regressions.
  • Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
    Yes, the application can be re-packaged such that the EJBs are bundled in the WAR instead of the bundled library under WEB-INF/lib
  • If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
    Yes.
Comment by Sivakumar Thyagarajan [ 25/Jan/11 ]

Analysis:

  • EJBs bundled within the bundled library in the WAR (jar in WEB-INF/lib) was represented as EJBs of the WAR BDA to Weld. The EJBs were represented as Bean classes in the WEB-INF/lib jar BDA. So, Weld understood the EJB as both a ManagedBean and an EJB, and hence deployment failed with an Ambiguous Resolution exception.

Fix involved ensuring that the WEB-INF/lib jar BDA has the EJB Class represented as EJBs and the Bean classes of that BDA.

Comment by Sivakumar Thyagarajan [ 25/Jan/11 ]

Proposed diff to fix the issue.

Comment by Chris Kasso [ 25/Jan/11 ]

Approved for 3.1

Comment by Harald Wellmann [ 25/Jan/11 ]

Thanks for fixing this so quickly! Just a small note on the patch: I don't know about official Glassfish policies, but I'd rather use log.debug() instead of System.out.println(), or simply delete these statments, if they were just intended for testing the fix.

Comment by Sivakumar Thyagarajan [ 26/Jan/11 ]

Harald: Yes the system.outs were just debug statements for testing the fix. I would convert them to property log statements prior to the commit.

Comment by Sivakumar Thyagarajan [ 26/Jan/11 ]

Fixed as part of
$ svn commit .
Sending weld-integration/src/main/java/org/glassfish/weld/BeanDeploymentArchiveImpl.java
Sending weld-integration/src/main/java/org/glassfish/weld/BeanManagerNamingProxy.java
Sending weld-integration/src/main/java/org/glassfish/weld/WeldDeployer.java
Sending weld-integration/src/main/java/org/glassfish/weld/ejb/EjbDescriptorImpl.java
Sending weld-integration/src/main/java/org/glassfish/weld/services/JCDIServiceImpl.java
Transmitting file data .....
Committed revision 44711.





[GLASSFISH-15659] Documentation/HTML problems on default localhost:8080 landing page Created: 22/Jan/11  Updated: 24/Jan/11  Resolved: 24/Jan/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ljnelson Assignee: Paul Davies
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-fishcat

 Description   

The default landing page at http://localhost:8080 has all kinds of references to Sun, sun.com, etc.

It also has a copyright date of 2009.



 Comments   
Comment by Paul Davies [ 24/Jan/11 ]

On build 38 of GlassFish Server 3.1, the page is correct.





[GLASSFISH-15658] improve error message for create-jdbc-connection-pool failure Created: 22/Jan/11  Updated: 20/Dec/16  Resolved: 30/May/11

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

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

Windows 2003, Glassfish 3.1b38, Java 6.0.21


Tags: 3_1-exclude, 3_1-fishcat, 3_1_1-approved

 Description   

I have an installation script that I use to set up a connection pool I need. It looks like this:

call %GLASSFISH_HOME%\bin\asadmin.bat create-jdbc-connection-pool --datasourceclassname=com.mysql.jdbc.jdbc2.optional.MysqlDataSource --restype=javax.sql.DataSource --description "A JDBC connection pool providing access to the LEAD database." --property User=lead:Password=youwish:DatabaseName=lead:Port=3306:ServerName=localhost "LEAD Connection Pool"

This runs fine on Glassfish 3.1b19.

In Glassfish 3.1b38, I get the following error:

remote failure: JDBC connection pool LEAD Connection Pool creation failed. javax.validation.ConstraintViolationException: Constraints for this JdbcConnectionPool configuration have been violated: on property [ name ] violation reason [ must match "[\p

{L}\p{N}_][\p{L}

\p

{N}

-_\./;:#]*" ]
Command create-jdbc-connection-pool failed.



 Comments   
Comment by ljnelson [ 22/Jan/11 ]

(The obvious workaround is to eliminate spaces from the pool name.)

Comment by Tom Mueller [ 22/Jan/11 ]

The original script should have never worked - it was a bug that it did, because spaces are not allowed in connection pool names. Recently, changes were put in to validate the names for connection pools.

The bug here is actually that there is an undesirable error message in this case that shows the regular expression that is used to constrain the connection pool name. This bug should be used to fix that error message.

For information about creating a better error message for this, see:
http://wikis.sun.com/display/GlassFish/GlassFish+Bean+Validation+Error+Message+Internationalization

Marking this as 3.1 exclude because this fix is not needed for 3.1

Comment by Shalini [ 23/May/11 ]

Marking the issue to be fixed in 3.1.1

Comment by scatari [ 24/May/11 ]

Approved for 3.1.1.

Comment by Shalini [ 30/May/11 ]

Whenever a create-jdbc-connection-pool command fails with a ConstraintValidationException, a better error message is introduced by adding a message and payload to the @Pattern annotation.

Fixed in 3.1.1 :

Sending admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/LocalStrings.properties
Sending admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/ResourcePool.java
Transmitting file data ..
Committed revision 47187.

Fixed in trunk :

Sending admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/LocalStrings.properties
Sending admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/ResourcePool.java
Transmitting file data ..
Committed revision 47188.





[GLASSFISH-14832] REGRESSION: Build 30 cannot deploy @SessionScoped; build 29 deploys it fine Created: 21/Nov/10  Updated: 19/Dec/16  Resolved: 20/Dec/10

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 3.1_dev

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

Operating System: All
Platform: All
URL: http://www.java.net/forum/topic/glassfish/glassfish/weld-problems-b30-0


Issue Links:
Duplicate
is duplicated by GLASSFISH-13650 Jersey NullPointerException, problem ... Resolved
Issuezilla Id: 14,832
Status Whiteboard:

weld-int-required

Tags: 3_1-fishcat, weld-int-required

 Description   

Forum discussion:
http://www.java.net/forum/topic/glassfish/glassfish/weld-problems-b30-0

Briefly: .ear file with a .war file in it. .war file has beans.xml in its
WEB-INF directory. There's a Vaadin Application class in WEB-INF/classes. This
setup has deployed fine in Glassfish 3.1 for months.

Build 30 dies with a stack trace indicating that Weld/CDI can't find the Vaadin
application class:

[#|2010-11-21T13:24:25.060-0500|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=193;_ThreadName=http-thread-pool-8080(3);|StandardWrapperValve[LEADServlet]:
PWC1406: Servlet.service() for servlet LEADServlet threw exception
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to
resolve any beans for Types: [class com.foo.bar.FooApplication]; Bindings:
[@javax.enterprise.inject.Default()]
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:779)
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:78)
at com.foo.bar.VaadinServlet.getNewApplication(VaadinServlet.java:61)
at
com.vaadin.terminal.gwt.server.AbstractApplicationServlet.createApplication(AbstractApplicationServlet.java:940)
at
com.vaadin.terminal.gwt.server.AbstractApplicationServlet.findApplicationInstance(AbstractApplicationServlet.java:768)
at
com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:431)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)

b29 deploys the application fine with no changes.



 Comments   
Comment by Sivakumar Thyagarajan [ 30/Nov/10 ]

This looks like a WELD 1.1.0.BETA2 issue during bean resolution. The actual NPE is logged by the web container using the IAS logger and hence not available. The NPE is shown in the server log if you replace the programmatic lookup of the bean with a normal injection of the baen.

I have filed https://jira.jboss.org/browse/WELD-761 to track this.

Comment by Sivakumar Thyagarajan [ 20/Dec/10 ]

The underlying issue, WELD-761, was fixed in Weld 1.1.0.CR2 and after the integration of CR2, this scenario was verified to have been fixed.





[GLASSFISH-14626] Adding JVM option erases all the others Created: 11/Nov/10  Updated: 19/Dec/16  Resolved: 15/Nov/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_dev

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

Operating System: All
Platform: All


Issuezilla Id: 14,626
Tags: 3_1-fishcat

 Description   

Go to admin console
Go to default-config (or server-config; doesn't matter)
Choose JVM options tab
Add JVM option
(I used -ea, as I like to see assertions during development)
Press save
Observe that all other options present have disappeared

b28 and b29



 Comments   
Comment by ljnelson [ 11/Nov/10 ]

domain.xml reflects the change as well

Comment by Anissa Lam [ 11/Nov/10 ]

I looked at the code, it removes all the current JVM option first, and then add back everything seen
in the page. (there is definitely improvement that can be made in this).

Since the 2nd item in the list is
-XX:MaxPermSize=192m
REST cannot handle that, and error results, preventing it to add back all the other option. Thus,
resulting only the newly added one. If the newly added one also has a colon in it, you won't see
that either.

REST needs to be fixed to take in ":", transfer to rest.

Jason, here is how to reproduce the problem:

I created a new config called AAA, so i don't mess up my server-config.
Just go to Configurations -> New and create a new AAA config.

endpoint=http://localhost:4848/management/domain/configs/config/AAA/java-config/jvm-
options
payload: target=AAA, -XX:MaxPermSize=192m

Comment by Alexis MP [ 12/Nov/10 ]

cc

Comment by Jason Lee [ 12/Nov/10 ]

The REST endpoint DOES clear all jvm-options then save what's provided, behavior which is consistent, I think, with the theory of REST. This page should make a single call to the endpoint to
save the options, passing everything that needs to be saved. If we'd like to be able to leave existing and add new options, I think the route to go is PUT, which may need to be implemented.

Making one call for each option to be added is bound to be expensive, so the endpoint (again, in keeping with REST "theory", more or less) replaces what's there with what is passed in. This
also helps avoid multiple calls to delete what's no longer needed (i.e., the client need not worry about what to delete and what to save. It simply needs to send the current state, and the REST
endpoint does The Right Thing). Individual deletes are, of course, still supported, as that's still a valid use case.

As things stand now, I think this is a console bug. The GUI handler needs to be fixed. Reassigning.

Comment by Anissa Lam [ 12/Nov/10 ]

My point is: REST CANNOT take in ":" as name of the jvm-option.

What i am seeing is that: calling the following endpoint
"http://localhost:4848/management/domain/configs/config/AAA/java-config/jvm-options"
will ADD the specified payload to the java-config. NOT replacing it as you stated.
I like this better, and i think this is correct.

However, the main issue is: REST CANNOT take in ":" (colon) to be part of the jvm-option name.

The request failed if the name of the option contains a ":",
Please try saving the jvm-option: -XX:MaxPermSize=152m
I see the GUI code puts -XX:MaxPermSize as the key , and 152m as the value. in the payload.

and get the following response:

{data=

{message=JVM option MaxPermSize=192m is invalid because it does not start with a '-', exit_code=FAILURE}

, responseBody=

{"message":"JVM option MaxPermSize=192m is invalid because it does not start with a '-'","exit_code":"FAILURE"}

, responseCode=200}

Please show us how to setup the payload for saving
<jvm-option>-XX:MaxPermSize=-152m</jvm-option>

Comment by Jason Lee [ 12/Nov/10 ]

OK. I misspoke. The jvm-options end point doesn't clear then add, though I think it should. The colon
issue is unrelated and should be split out into a separate issue.

Comment by Jason Lee [ 12/Nov/10 ]

After discussing this with Anissa on IRC, here's the plan: I will modify the jvm-options to support the following behavior:

GET - return all JVM options
POST - clear all options and save only what the client sends
PUT - leave existing options and add what the client sends
DELETE - Clear all existing options

For now, I'll reclaim this issue while I rework the endpoint. Once that's done, I'll reassign to Srini and the admingui to update the code on the console.

Comment by Jason Lee [ 15/Nov/10 ]

I have committed the fix to the REST side, implementing the HTTP verbs as described. Reassigning to the
console to fix the handler.

Comment by Anissa Lam [ 15/Nov/10 ]

I will fix this since this is very high priority

Comment by Anissa Lam [ 15/Nov/10 ]

Fix should be in 11/16 nightly.





[GLASSFISH-14622] Update center: click on Available Updates, processing... hangs Created: 11/Nov/10  Updated: 19/Nov/10  Resolved: 19/Nov/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: not determined

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

Operating System: All
Platform: All


Issuezilla Id: 14,622
Tags: 3_1-fishcat

 Description   

Installed build 28. Launched admin console. Went to Update Tool. Looked at
the first tab for a while. Then clicked on Available Updates.

The "Processing..." overlay came up and stayed there forever. No errors in the
log file.



 Comments   
Comment by ljnelson [ 11/Nov/10 ]

Somewhat more alarmingly, after I then reloaded http://localhost:4848 in that
same browser tab, my Mac crashed. What are you using to do the lightbox effect?

Browser is Firefox 3.6.12 on a MacBook Pro.

Comment by Jason Lee [ 11/Nov/10 ]

Can you give more details on "your Mac crashed"? I've tested the "processing" feature on my Mac using the
latest Chrome, Safari, and Firefox and haven't seen any crashing.

I'll look into adding a way to close the dialog.

Comment by ljnelson [ 11/Nov/10 ]

Sure. I got the equivalent of a blue screen of death: a grayed out screen (that
oddly took a long time to draw and was (coincidentally?) the same color as the
lightbox effect, with a message telling me I needed to hold down the power key
on my Mac to restart it.

I'll see if I can reproduce it; it may have, of course, been transient.

Comment by Jason Lee [ 11/Nov/10 ]

That sounds like a Mac kernel panic and is very unlikely (I would hope to be related to the Admin
Console.

Comment by ljnelson [ 11/Nov/10 ]

Yep; can't reproduce. The only reason I reported it was because it happened (a)
so immediately after the click and (b) featured so many of the same colors that
I thought perhaps something about the lightbox effect was blowing Firefox away.
Oh well, false alarm I guess.

Comment by Nazrul [ 19/Nov/10 ]

Console hangs due to how we establish connection with Update Center. Closing as
a duplicate of issue 14667

      • This issue has been marked as a duplicate of 14667 ***




[GLASSFISH-14585] EJBContainer#createEJBContainer() fails if spaces in module path Created: 10/Nov/10  Updated: 15/Nov/10  Resolved: 15/Nov/10

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: ljnelson Assignee: marina vatkina
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


Attachments: Zip Archive it14585.zip    
Issuezilla Id: 14,585
Tags: 3_1-fishcat

 Description   

I have a Hudson build that was failing all my EJB tests, whereas they all ran
fine on my machine.

Racked my brain, and then renamed the job so that the job name--and hence one of
the directories in the path--no longer had spaces in it.

After this point, EJB tests ran fine. Looks like EJBContainerImpl can't deal
with paths to the modules that it deploys with spaces in them.



 Comments   
Comment by Bhavanishankar [ 15/Nov/10 ]

Transferring to Marina.

Comment by marina vatkina [ 15/Nov/10 ]

I can't reproduce it. I'll attach a test case that I used

Comment by marina vatkina [ 15/Nov/10 ]

Created an attachment (id=5473)
the test





[GLASSFISH-14544] MissingResourceException during EJBContainer#createEJBContainer() when -Djavax.net.ss.xxx is not present in domain.xml Created: 09/Nov/10  Updated: 19/Dec/16  Resolved: 28/Nov/10

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

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

Operating System: All
Platform: All
URL: http://www.java.net/forum/topic/glassfish/glassfish/ejbcontainer-logging-during-creation


Issue Links:
Dependency
depends on GLASSFISH-14601 GlassFishORBManager handling of Proce... Resolved
Issuezilla Id: 14,544
Tags: 3_1-fishcat

 Description   

Forum discussion:
http://www.java.net/forum/topic/glassfish/glassfish/ejbcontainer-logging-during-creation

Let me start by saying that it may very well be the case that remote EJB testing
with an embedded container is not supposed to be supported. However, it works
fine with glassfish-embedded-all v3.0.1-b02 (no typos).

I have some JUnit tests running that do an EJBContainer#createEJBContainer()
call. This fails if @Remote-annotated EJBs are present on the classpath.

I even went so far as to generate a partial ejb-jar.xml at test time that
selectively "fakes" "localness" for such EJBs by writing out:

<?xml version="1.0"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" version="3.1">
<enterprise-beans>
<session>
<ejb-name>TheRemoteBean</ejb-name>
<remote/>
<local>HisRemoteInterface</local>
</session>
</enterprise-beans>
</ejb-jar>

In such cases, with logging turned waaaaay up, I get the following stack snippet:

Nov 9, 2010 1:09:38 PM com.sun.logging.LogDomains$1 log
FINE: .initORB->:
Nov 9, 2010 1:09:38 PM com.sun.logging.LogDomains$1 log
FINE: Setting orb initial port to 3700
Nov 9, 2010 1:09:38 PM com.sun.logging.LogDomains$1 log
FINE: Setting orb initial host to 192.168.1.112
Nov 9, 2010 1:09:38 PM com.sun.hk2.component.AbstractWombImpl get
FINER: created object com.sun.grizzly.config.dom.SslInjector@1c4f8ea3
Nov 9, 2010 1:09:38 PM com.sun.hk2.component.AbstractWombImpl inject
FINER: injection starting on com.sun.grizzly.config.dom.SslInjector@1c4f8ea3
Nov 9, 2010 1:09:38 PM com.sun.hk2.component.AbstractWombImpl inject
FINER: injection finished on com.sun.grizzly.config.dom.SslInjector@1c4f8ea3
Nov 9, 2010 1:09:38 PM com.sun.hk2.component.AbstractWombImpl get
FINER: created object com.sun.enterprise.iiop.security.IIOPSSLUtilImpl@3df67efb
Nov 9, 2010 1:09:38 PM com.sun.hk2.component.AbstractWombImpl inject
FINER: injection starting on
com.sun.enterprise.iiop.security.IIOPSSLUtilImpl@3df67efb
Nov 9, 2010 1:09:38 PM com.sun.hk2.component.AbstractWombImpl inject
FINER: injection finished on
com.sun.enterprise.iiop.security.IIOPSSLUtilImpl@3df67efb
Nov 9, 2010 1:09:38 PM com.sun.logging.LogDomains$1 log
SEVERE: iiop.init_exception
java.lang.RuntimeException: java.util.MissingResourceException: Can't find
resource for bundle java.util.PropertyResourceBundle, key iiop.cannot_find_keyalias
at
com.sun.enterprise.iiop.security.IIOPSSLUtilImpl.getKeyManagers(IIOPSSLUtilImpl.java:115)
at
org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.init(IIOPSSLSocketFactory.java:246)
at
org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.<init>(IIOPSSLSocketFactory.java:148)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at com.sun.corba.ee.impl.orb.ParserTable$4.operate(ParserTable.java:757)
at com.sun.corba.ee.impl.orb.NormalParserAction.apply(NormalParserAction.java:62)
at com.sun.corba.ee.spi.orb.PropertyParser.parse(PropertyParser.java:84)
at com.sun.corba.ee.spi.orb.ParserImplBase.init(ParserImplBase.java:77)
at com.sun.corba.ee.impl.orb.ORBDataParserImpl.<init>(ORBDataParserImpl.java:493)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:561)
at com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:696)
at com.sun.corba.ee.impl.orb.ORBImpl.setParameters(ORBImpl.java:683)
at com.sun.corba.ee.spi.osgi.ORBFactory.initialize(ORBFactory.java:107)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:580)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:263)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:120)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:187)
at
com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:818)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:566)
at
com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:155)
at
com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:149)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:105)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:284)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:98)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:175)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:239)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:437)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:243)
at
org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:193)
at
org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:142)
at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:135)
at
org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:132)

I am not sure why Glassfish is even attempting to create an ORB here, as by
rights there shouldn't be any remote EJBs in here (with my stupid override hack).

Perhaps hk2 is simply going by annotations to decide whether to build the ORB or
not (I really have no idea; just grasping at straws here)?

(I'd like to tag this issue with the 3.1-fishCAT keyword; not sure how to do that.)



 Comments   
Comment by Bhavanishankar [ 09/Nov/10 ]

transferring to security (as per marina's suggestion)

Comment by Nithya Ramakrishnan [ 10/Nov/10 ]

The stack trace suggests that this could be a duplicate of issue 14398. We made a fix for 14398. Could
you please check if the error here reappears after the fix?

Comment by ljnelson [ 10/Nov/10 ]

Will do.

Bear in mind from the forum discussion
(http://www.java.net/forum/topic/glassfish/glassfish/ejbcontainer-logging-during-creation)
that one person commented that even if the ResourceBundle key were present,
things would probably still break.

My question is: what about remote EJBs causes SSL to get invoked? That is, why
does everything work when it's just local beans? I think it will turn out that
the root cause is deeper than a simple key missing from a ResourceBundle.

Comment by marina vatkina [ 10/Nov/10 ]

Check if changes for 14572
(https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=25226)
solve the problem

Comment by ljnelson [ 10/Nov/10 ]

No:

SEVERE: Exception while invoking class org.glassfish.ejb.startup.EjbDeployer
load method
java.lang.RuntimeException: EJB Container initialization error
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:246)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:284)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:98)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:175)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:239)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:437)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:243)
at
org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:193)
at
org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:142)
at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:135)
at
org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:132)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)

[snipped JUnit portion of stack]

Caused by: java.lang.RuntimeException: IIOP Protocol Manager initialization
failed. Possible cause is that ORB is not available in this embedded container,
or server instance is running and required ports are in use
at
com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:821)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:566)
at
com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:155)
at
com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:149)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:105)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
... 45 more
Caused by: java.lang.RuntimeException: Orb initialization erorr
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:148)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:187)
at
com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:818)
... 50 more
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:621)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:263)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:120)
... 52 more
Caused by: java.lang.NullPointerException
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:595)

Comment by marina vatkina [ 10/Nov/10 ]

Another bug

Comment by ljnelson [ 10/Nov/10 ]

Would love to help; checked out source code from
https://svn.dev.java.net/svn/glassfish-svn/trunk/v3/ but cannot find
GlassfishORBManager.java.

Comment by marina vatkina [ 10/Nov/10 ]

./orb/orb-iiop/src/main/java/org/glassfish/enterprise/iiop/impl/GlassFishORBManager.java

gmsClient is created if 'processType == ProcessType.Server', but accessed 'if(
processType.isServer() )'. Try replacing the former with the latter (isServer()
includes embedded).

Comment by ljnelson [ 10/Nov/10 ]

I believe that works, in conjunction with the domain.xml fix.

(Now EclipseLink 2.2, apparently roped in by glassfish-embedded-all
3.1-SNAPSHOT, is barking at a join column that works fine under EclipseLink
2.1..., but that's not your problem any more )

Comment by marina vatkina [ 10/Nov/10 ]

We suppress weaving (unless I'm unaware of the recent changes) in embedded mode

  • can it be something that is affected by that?
Comment by ljnelson [ 10/Nov/10 ]

No; nice thought, though.

EclipseLink 2.1.1 (our current version) has no problem with a @JoinTable that
contains a @JoinColumn as one of its inverseJoinColumns that references a column
that is actually mapped by an entity at the root of an inheritance hierarchy.

That is:

A (maps id column)

B (inherits from A using JPA inheritance)
(defines unidirectional @OneToMany with a @JoinTable to C) --> C

The @JoinTable tries to set up a join table whose two columns are BID and CID.
Then its inverseJoinColumns attribute is set up so that in the "B" case, the
join table is supposed to reference the "id" column that is actually defined in A.

In EclipseLink 2.1.1 this worked.

In EclipseLink 2.2, the presence of that referencedColumnName="id" causes
EclipseLink to blow up. (Well, it causes Glassfish 3.1-SNAPSHOT to blow up,
because it can't predeploy the persistence unit as part of the EJB testing I'm
doing.)

If I remove the (happily redundant) referencedColumnName="id" attribute ("id" is
the primary key column in question, so I don't actually need to specify it; the
default is actually exactly the same), everything works fine.

I've put out an email on the EclipseLink list about this; for all I know there's
some sort of spec misreading on my part here (actually on my colleague's), so
we'll see.

Anyway, once I get rid of this problem, Glassfish embedded EJB testing works
again for local and remote beans, as near as I can tell.

Comment by marina vatkina [ 10/Nov/10 ]

Great! I'm changing the subject line so that the security team knows what their
problem is. ORB changes will have a separate issue

Comment by ljnelson [ 10/Nov/10 ]

I am getting this WARNING from the container; please bear in mind that I'm
running this against a patched 3.1-SNAPSHOT as of this morning, so who knows
what state this Frankenstein is in at the moment:

INFO: ra.stop-successful
connection OBJ Name = null
Nov 10, 2010 4:55:58 PM com.sun.logging.LogDomains$1 log
WARNING: Exception while dispatching an event
javax.management.RuntimeOperationsException: Exception occurred trying to
unregister the MBean
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:347)
at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:506)
at
org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.shutdown(JMXStartupService.java:195)
at
org.glassfish.admin.mbeanserver.JMXStartupService.shutdown(JMXStartupService.java:146)
at
org.glassfish.admin.mbeanserver.JMXStartupService.access$000(JMXStartupService.java:87)
at
org.glassfish.admin.mbeanserver.JMXStartupService$ShutdownListener.event(JMXStartupService.java:115)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:425)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:90)
at org.glassfish.api.embedded.Server.stop(Server.java:562)
at org.glassfish.ejb.embedded.EJBContainerImpl.stop(EJBContainerImpl.java:245)
at
org.glassfish.ejb.embedded.EJBContainerImpl.forceClose(EJBContainerImpl.java:196)
at org.glassfish.ejb.embedded.EJBContainerImpl.close(EJBContainerImpl.java:175)

Comment by marina vatkina [ 10/Nov/10 ]

Ignore - it's https://glassfish.dev.java.net/issues/show_bug.cgi?id=14408

Comment by kumarjayanti [ 19/Nov/10 ]

I think it is fixed by Nithya. Can you confirm from the latest builds if this problem still persists.

Note: i am referring to java.util.MissingResourceException: Can't find

Comment by marina vatkina [ 19/Nov/10 ]

To see the message, ORB fix needs to be rolled back

Comment by Nithya Ramakrishnan [ 28/Nov/10 ]

The missing message for the key was added to the resources. The following exception will not be seen anymore:

java.util.MissingResourceException: Can't find
resource for bundle java.util.PropertyResourceBundle, key iiop.cannot_find_keyalias





[GLASSFISH-14419] Excessive memory requirements Created: 04/Nov/10  Updated: 19/Dec/16  Resolved: 20/Dec/10

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: 3.1_dev

Type: Bug Priority: Major
Reporter: Harald Wellmann Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux
URL: http://hwellmann.blogspot.com/2010/11/cdi-major-risk-factor-in-java-ee-6.html


Issuezilla Id: 14,419
Status Whiteboard:

weld-int-required

Tags: 3_1-fishcat

 Description   

In addition to the memory leaks occurring on application redeployment (see
#12368), Weld requires excessive amounts of memory even for a moderately sized
application.

My WAR (using Wicket+EJB+JPA) running on Glassfish 3.1-b26 requires about 400 MB
heap memory. The Eclipse Memory Analyzer reveals that almost 200 MB are occupied
by instances of org.jboss.weld.introspector.weld.jlr.WeldClassImpl.

Downgrading my application to Java EE 5 style injections with @EJB instead of
@Inject, I could cut the memory usage of my application by 50 %.

Other projects may have different priorities, but for me, this is a severe
quality issue which made me stop using CDI altogether, until this issue is solved.



 Comments   
Comment by Sivakumar Thyagarajan [ 10/Nov/10 ]

We have been working with the Weld team to making improvements around memory
usage of Weld. This is being addressed in their current 1.1 release. We had
integrated an initial build of 1.1 earlier in GF3.1 and had some improvements.
We plan to integrate Weld 1.1.0.Beta2 in the next couple of days and it also has
changes in the generated proxies and their classloading which should result in
lesser footprint. Your blog is also being discussed in weld-dev [1] and I see
more analysis and activity around reducing the footprint further.

[1] http://lists.jboss.org/pipermail/weld-dev/2010-November/002707.html

Comment by Sivakumar Thyagarajan [ 19/Nov/10 ]

Marking this as weld-int-required as we need fixes in the Weld side for this.

Comment by Sivakumar Thyagarajan [ 19/Nov/10 ]

Marking this as 3.1_ms08, as hopefully we would have the 1.1.RC1 by then.

Comment by Harald Wellmann [ 18/Dec/10 ]

In 3.1-b33, the heap usage of Weld has gone done down drastically. See http://hwellmann.blogspot.com/2010/12/update-on-memory-issues-in-glassfish.html.

Maybe there's still some room for improvement, but this is a big step forward.

Comment by Sivakumar Thyagarajan [ 20/Dec/10 ]

GFb33 had an older version of Weld (1.1.0.Beta2), but we did fix a couple of GF side memory leaks (GLASSFISH-14803 and GLASSFISH-14801).

However Weld 1.1.0.CR1 has made a lot of progress in the performance, memory footprint and startup time fronts. Here is a snippet from the Weld 1.1.0.CR1 release http://in.relation.to/Bloggers/Weld110CR1AndCDITCK102
– snippet from Weld 1.1.0.CR1 release notes –

  • Performance improvements (around 40% on the previous release, meaning Weld performs as well as, or better than other CDI implementations and other DI engines in our tests)
  • Startup time improvements (around 20 times faster in extreme cases)
  • More improvements in memory usage, with more planned for 1.2.0 (we're aiming at 1k per class deployed)
    • snippet from Weld 1.1.0.CR1 release notes –

A bunch of these fixes were made in https://github.com/stuartwdouglas/core/commits/memoryUsage and later merged into trunk. This is their biggest "feature" in 1.1.0.CR1. We integrated Weld 1.1.0.CR2 today into GF3.1 trunk and don't see any obvious memory leaks yet.

With your comment in GLASSFISH-15266, I also see that you don't see any major memory leak issues in the Weld/CDI integration and so I am closing this issue. Please reopen a new bug if you still see any new CDI related issues. Thanks again for filing this issue.





[GLASSFISH-14383] Impossible to deploy Hudson .war file on Windows 2008 r2 Created: 03/Nov/10  Updated: 11/Nov/10  Resolved: 11/Nov/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: not determined

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

Operating System: other
Platform: All
URL: http://www.java.net/forum/topic/glassfish/glassfish/glassfish-31b26-asadmin-deploy-hudsonwar-classnotfoundexception


Issuezilla Id: 14,383
Tags: 3_1-fishcat

 Description   

Steps to reproduce:
1. Get a Windows 2008 r2 64 bit virtual running on Xeon (don't know how many of
these attributes are required)
2. Install 64-bit JVM.
2.1 Install Glassfish v3.1b26.
3. asadmin create-service
4. net start domain1
5. Download copy of Hudson from hudson-ci.org
(http://hudson-ci.org/latest/hudson.war).
6. asadmin deploy hudson.war
7. Observe that nothing happens for over 10 minutes while the CPU spikes to 50%
and the memory usage continues to climb. server.log does not fill up with anything.
8. Observe asadmin time out.



 Comments   
Comment by ljnelson [ 03/Nov/10 ]

This also happens with the GUI deployment.

Comment by Hong Zhang [ 03/Nov/10 ]

Assign to web team to take a look. For hudson.war (30 MB and lots of libraries
in WEB-INF/lib), the WebApplication.start takes a long time (see the forum
thread for more details).

Comment by ljnelson [ 03/Nov/10 ]

To be clear: it doesn't take a long time, it never happens. And then something
inside Glassfish half-thinks that Hudson is deployed.

This is now confirmed on Windows 2008 r2 64-bit and at least Debian 64-bit. I
would urge that the status move to NEW.

If it's a Hudson problem I'm sure Kohsuke would love to know about it.

Comment by ljnelson [ 03/Nov/10 ]

(Tagging this issue as 3.1-fishcat per
http://wikis.sun.com/display/GlassFish/FishCAT2010SecHalf)

Comment by ljnelson [ 03/Nov/10 ]

Related Hudson bug, in case it turns out to be something that they're doing:
http://issues.hudson-ci.org/browse/HUDSON-7994

Comment by rjdkolb [ 04/Nov/10 ]

Hi Laird,
Unable to reproduce in GlassFish 3.0.1.
Deployed in 16 seconds on Ubuntu Linux 10.04 64bit Java 1.6.0_22
[#|2010-11-04T14:15:34.812+0200|INFO|glassfish3.0.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=25;_ThreadName=Thread-1;|hudson
was successfully deployed in 16,194 milliseconds.|#]

Able to reproduce in GlassFish 3.0.1 b25 (sorry for the old build)
It has been deploying for over 10 minutes with high CPU usage.

Comment by ljnelson [ 04/Nov/10 ]

To be clear, I was reporting Glassfish 3.1 build 26; I assume that your
reference to 3.0.1 is a typo.

Comment by rjdkolb [ 04/Nov/10 ]

Not a typo.
Hudson deploys in 16 seconds in 3.0.1

In GlassFish 3.1 b25 and now b27 it has a very long deploy.
Actually got a timeout of 600 seconds.
No response from Domain Admin Server after 600 seconds.
The command is either taking too long to complete or the server has failed.
Please see the server log files for command status.
Command deploy failed.

As Hong says, may be an issue they already know about : WebApplication.start

Comment by Harald Wellmann [ 04/Nov/10 ]

I can confirm this problem with Glassfish 3.1-b27, b26, b24 and b12 on 64 bit
Ubuntu 10.04, JDK 1.6.0_22.

With 3.0.1, hudson.war deploys successfully within a few seconds.

Comment by Santiago Pericas-Geertsen [ 05/Nov/10 ]

It's reproducible on Solaris x86 with JDK 1.6.0_16, so it does not appear to be platform
dependent. The problem seems related to the initialization of Jasper's TldScanner which is called
from StandardContext.callServletContainerInitializers(). There's code that attempts to read a
manifest from a JAR file that seems get into a loop. Working on trying to find out which JAR is
causing the problem. CCing Kin-man.

Comment by Santiago Pericas-Geertsen [ 05/Nov/10 ]

It's reproducible.

Comment by kchung [ 09/Nov/10 ]

Fixed in revision 1279. The fix should be in the next V3.1 promoted build, b28.

Thanks Santiago for help in locating the source of the problem.

Comment by ljnelson [ 09/Nov/10 ]

Thanks for the work, everyone.

Comment by Harald Wellmann [ 11/Nov/10 ]

Just tested the fix in b28. hudson.war now deploys within a few seconds. Thanks!





[GLASSFISH-14375] create security-realm cannot handle config as target Created: 03/Nov/10  Updated: 19/Dec/16  Resolved: 08/Nov/10

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

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

Operating System: All
Platform: All


Issuezilla Id: 14,375
Tags: 3_1-fishcat

 Description   

This is reported by FishCat member Richard Kolb.
I can reproduce the problem. Even if specified "default-config" as target, the realm will be created
to "server-config". After checking with Security and Tom, I was told to file a bug. Here it is.

To reproduce:

%asadmin create-auth-realm --classname com.sun.enterprise.security.auth.realm.file.FileRealm –
target default-config --property file=/tmp/keyfile:jaas-context=fileRealm MyRealm
Did not find any suitable instances for target default-config; command executed on DAS only

Command create-auth-realm executed successfully.

%asadmin list-auth-realms server-config
admin-realm
file
certificate
MyRealm

Command list-auth-realms executed successfully.

list-auth-realms also ignored "default-config" and report whats in "server-config".

%asadmin list-auth-realms default-config
Did not find any suitable instances for target default-config; command executed on DAS only
admin-realm
file
certificate
MyRealm

Command list-auth-realms executed successfully.



 Comments   
Comment by kumarjayanti [ 08/Nov/10 ]

fixed





[GLASSFISH-14267] Realm: Cannot set default realm in GlassFish 3.1 b 25 Created: 28/Oct/10  Updated: 19/Dec/16  Resolved: 05/Dec/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_dev

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

Operating System: All
Platform: Linux


Issuezilla Id: 14,267
Tags: 3_1-fishcat

 Description   

I created a new realm in GlassFish 3.1 b 25
Went to configurations -> server config -> Security
selected my new realm and clicked save.
(The save does not save)

The admin GUI shows :
org.jvnet.hk2.config.ValidationException: Validation Failed: is not of data
type: java.lang.Boolean

Server log :
[#|2010-10-28T10:39:31.219+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|java.util.logging.ErrorManager:
5: Error in extracting Name Value Pairs|#]

[#|2010-10-28T10:39:31.220+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|java.lang.NullPointerException|#]

[#|2010-10-28T10:39:31.221+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
at
com.sun.enterprise.server.logging.UniformLogFormatter.getNameValuePairs(UniformLogFormatter.java:208)|#]

[#|2010-10-28T10:39:31.221+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
at
com.sun.enterprise.server.logging.UniformLogFormatter.uniformLogFormat(UniformLogFormatter.java:276)|#]

[#|2010-10-28T10:39:31.221+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
at
com.sun.enterprise.server.logging.UniformLogFormatter.format(UniformLogFormatter.java:161)|#]

[#|2010-10-28T10:39:31.221+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
at java.util.logging.StreamHandler.publish(StreamHandler.java:179)|#]

[#|2010-10-28T10:39:31.222+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)|#]

[#|2010-10-28T10:39:31.222+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
at java.util.logging.Logger.log(Logger.java:458)|#]

[#|2010-10-28T10:39:31.222+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
at java.util.logging.Logger.doLog(Logger.java:480)|#]

[#|2010-10-28T10:39:31.222+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
at java.util.logging.Logger.log(Logger.java:544)|#]

[#|2010-10-28T10:39:31.222+0200|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
at
org.glassfish.admingui.common.handlers.RestApiHandlers.parseResponse(RestApiHandlers.java:277)|#]



 Comments   
Comment by srinik76 [ 28/Nov/10 ]

Tested the case with the latest source code. Not able to reproduce.

Comment by rjdkolb [ 30/Nov/10 ]

I am able to reproduce on 3.1 B30

I start a new GlassFish 3.1 B30

Went to configurations -> server config -> Security
selected admin realm and clicked save.

Got this exception :
org.jvnet.hk2.config.ValidationException: Validation Failed: is not of data type: java.lang.Boolean

Server.log is :
[#|2010-11-30T14:07:41.635+0200|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=16;_ThreadName=Thread-1;|RestResponse.getResponse() failed. endpoint = 'http://localhost:4848/management/domain/configs/config/default-config/security-service'; attrs = '

{mappedPrincipalClass=null, auditEnabled=null, defaultRealm=admin-realm, anonymousRole=AttributeDeprecated, defaultPrincipalPassword=null, defaultPrincipal=null, jacc=default, activateDefaultPrincipalToRoleMapping=null, auditModules=default}'; RestResponse: {"message":"org.jvnet.hk2.config.ValidationException: Validation Failed: is not of data type: java.lang.Boolean","exit_code":"FAILURE"}"|#]

[#|2010-11-30T14:09:03.499+0200|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=16;_ThreadName=Thread-1;|RestResponse.getResponse() failed. endpoint = 'http://localhost:4848/management/domain/configs/config/default-config/security-service'; attrs = '{mappedPrincipalClass=null, auditEnabled=null, defaultRealm=file, anonymousRole=AttributeDeprecated, defaultPrincipalPassword=null, defaultPrincipal=null, jacc=default, activateDefaultPrincipalToRoleMapping=null, auditModules=default}'; RestResponse: {"message":"org.jvnet.hk2.config.ValidationException: Validation Failed: is not of data type: java.lang.Boolean","exit_code":"FAILURE"}"|#]

[#|2010-11-30T14:11:24.852+0200|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=16;_ThreadName=Thread-1;|RestResponse.getResponse() failed. endpoint = 'http://localhost:4848/management/domain/configs/config/default-config/security-service'; attrs = '{mappedPrincipalClass=null, auditEnabled=null, defaultRealm=admin-realm, anonymousRole=AttributeDeprecated, defaultPrincipalPassword=null, defaultPrincipal=null, jacc=default, activateDefaultPrincipalToRoleMapping=null, auditModules=default}

'; RestResponse:

{"message":"org.jvnet.hk2.config.ValidationException: Validation Failed: is not of data type: java.lang.Boolean","exit_code":"FAILURE"}

"|#]

Comment by rjdkolb [ 30/Nov/10 ]

Able to reproduce in Build 31 as well.
I don't seem to be able to re-open this issue, so I hope it does not fall off the radar.
(someone, please re-open)

Comment by srinik76 [ 01/Dec/10 ]

Reopening the issue

Comment by shaline [ 01/Dec/10 ]

I used the nightly dated 12/01, and was able to reproduce.
After installation, and start domain, I launched Console, and I selected server-config/security/realms/admin-realm/ and just hit the SAVE button, without actually adding any new values to the realm. In the Console it showed "new values saved succesfully". but in the server.log, the below Exception is seen:
[#|2010-12-01T12:10:47.137-0800|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=15;_ThreadName=Thread-1;|Realm admin-realm successfully deleted.|#]

[#|2010-12-01T12:10:47.224-0800|SEVERE|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|Exception while processing config bean changes :
java.lang.RuntimeException: com.sun.enterprise.security.auth.realm.NoSuchRealmException: Realm admin-realm does not exists.
at com.sun.enterprise.security.SecurityConfigListener.authRealmDeleted(SecurityConfigListener.java:268)
at com.sun.enterprise.security.SecurityConfigListener$1.handleRemoveEvent(SecurityConfigListener.java:173)
at com.sun.enterprise.security.SecurityConfigListener$1.changed(SecurityConfigListener.java:140)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:315)
at com.sun.enterprise.security.SecurityConfigListener.changed(SecurityConfigListener.java:118)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:376)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:366)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:256)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:254)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.sun.enterprise.security.auth.realm.NoSuchRealmException: Realm admin-realm does not exists.
at com.sun.enterprise.security.auth.realm.Realm.getInstance(Realm.java:484)
at com.sun.enterprise.security.auth.realm.Realm.unloadInstance(Realm.java:409)
at com.sun.enterprise.security.SecurityConfigListener.authRealmDeleted(SecurityConfigListener.java:266)
... 13 more

#]
Comment by srinik76 [ 03/Dec/10 ]

[#|2010-12-03T15:53:27.617+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=17;_ThreadName=Thread-1;|Realm admin-realm successfully deleted.|#]

[#|2010-12-03T15:53:27.622+0530|SEVERE|glassfish3.1|null|_ThreadID=17;_ThreadName=Thread-1;|Exception while processing config bean changes :
java.lang.RuntimeException: com.sun.enterprise.security.auth.realm.NoSuchRealmException: Realm admin-realm does not exists.
at com.sun.enterprise.security.SecurityConfigListener.authRealmDeleted(SecurityConfigListener.java:268)
at com.sun.enterprise.security.SecurityConfigListener$1.handleRemoveEvent(SecurityConfigListener.java:173)
at com.sun.enterprise.security.SecurityConfigListener$1.changed(SecurityConfigListener.java:140)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:315)
at com.sun.enterprise.security.SecurityConfigListener.changed(SecurityConfigListener.java:118)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:376)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:366)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:256)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:254)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.sun.enterprise.security.auth.realm.NoSuchRealmException: Realm admin-realm does not exists.
at com.sun.enterprise.security.auth.realm.Realm.getInstance(Realm.java:484)
at com.sun.enterprise.security.auth.realm.Realm.unloadInstance(Realm.java:409)
at com.sun.enterprise.security.SecurityConfigListener.authRealmDeleted(SecurityConfigListener.java:266)
... 13 more

#]

[#|2010-12-03T15:53:27.636+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=17;_ThreadName=Thread-1;|SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]

The exception logged is happening because of delete operation.

Even when we do a delete operation of a realm the above message is logged. Error with delete operation.

Tried the following command in asadmin

-bash-3.00# ./asadmin delete-auth-realm test
Command delete-auth-realm executed successfully.

I get the following exception

[#|2010-12-03T15:56:38.635+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=17;_ThreadName=Thread-1;|Realm test successfully deleted.|#]

[#|2010-12-03T15:56:38.637+0530|SEVERE|glassfish3.1|null|_ThreadID=17;_ThreadName=Thread-1;|Exception while processing config bean changes :
java.lang.RuntimeException: com.sun.enterprise.security.auth.realm.NoSuchRealmException: Realm test does not exists.
at com.sun.enterprise.security.SecurityConfigListener.authRealmDeleted(SecurityConfigListener.java:268)
at com.sun.enterprise.security.SecurityConfigListener$1.handleRemoveEvent(SecurityConfigListener.java:173)
at com.sun.enterprise.security.SecurityConfigListener$1.changed(SecurityConfigListener.java:140)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:315)
at com.sun.enterprise.security.SecurityConfigListener.changed(SecurityConfigListener.java:118)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:376)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:366)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:256)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:254)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.sun.enterprise.security.auth.realm.NoSuchRealmException: Realm test does not exists.
at com.sun.enterprise.security.auth.realm.Realm.getInstance(Realm.java:484)
at com.sun.enterprise.security.auth.realm.Realm.unloadInstance(Realm.java:409)
at com.sun.enterprise.security.SecurityConfigListener.authRealmDeleted(SecurityConfigListener.java:266)
... 13 more

#]
Comment by srinik76 [ 03/Dec/10 ]

Raised a Issue 14973 - Deleting a realm returns successfully but logs a exception in the server.log
under security

Comment by srinik76 [ 05/Dec/10 ]

14973 issue fix is checked in so closing the issue.





[GLASSFISH-14243] Admin console should not open outgoing network connections by default Created: 27/Oct/10  Updated: 19/Oct/12

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

Type: Improvement Priority: Major
Reporter: Harald Wellmann Assignee: Anissa Lam
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 14,243
Tags: 3_1-fishcat

 Description   

Glassfish admin console should not open any outgoing network connections by
default. It should do so only on an opt-in basis.

In production environments, outgoing network connections are typically blocked
by firewalls. Starting the admin console in a controlled environment may cause
error messages or inacceptable delays. The user is currently left without a clue
how to stop Glassfish from opening connections.

AFAIK the current workaround for this problem is to set
com.sun.enterprise.tools.admingui.NO_NETWORK and to delete the console update
plug-in (see #12432).

This is not acceptable from a usability point of view. Besides, NO_NETWORK is a
bit of a misnomer: if you set it to true, the update plugin will still try to
open a network connection.

Proposal:

Admin console opens with a startup screen:

Would you like to see community news on this screen? ( ) Yes (X) No
(Requires network connectivity to http://.....)

Would you like to check for updates on startup? ( ) Yes (X) No
(Requires network connectivity to http://.....)

Show this message on startup. (X) Yes ( ) No

In addition, there should be a new entry in the navigation menu for controlling
outgoing network connections.



 Comments   
Comment by Anissa Lam [ 27/Oct/10 ]

Thanks for the suggestion.
We will at least ensure that if NO_NETWORK is specified, that the console will not check for any
update.
Will try to implement the rest for 3.1 if time permits.
thanks.

Comment by Anissa Lam [ 19/Oct/12 ]

The NO_NETWORK variable has been honored in couple release.
Target the rest for future-release.





[GLASSFISH-14209] [3.1-fishcat] Creating Oracle database pool on admin gui causes strange warnings Created: 26/Oct/10  Updated: 19/Dec/16  Resolved: 01/Nov/10

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: v3.0.1
Fix Version/s: 3.1_dev

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

Operating System: All
Platform: Linux


Issuezilla Id: 14,209
Tags: 3_1-fishcat

 Description   

installed a new platform independent GlassFish 3.1 b25
copied Oracle JSBC driver to glassfish/domains/domain1/lib/
create Pool via admin interface

(The error seems cosmetic)

Got messages in the log like :
[#|2010-10-26T14:07:32.923+0200|WARNING|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|Unprocessed
event : UnprocessedChangeEvent

{PropertyName=property, OldValue = GlassFishConfigBean.org.jvnet.hk2.config.types.Property, NewValue = null, Source = GlassFishConfigBean.com.sun.enterprise.config.serverbeans.JdbcConnectionPool}

,
reason = Error while handling Remove event., when = 1288094852923|#]

[#|2010-10-26T14:07:32.930+0200|SEVERE|glassfish3.1|LogStrings.org.glassfish.javaee.services|_ThreadID=15;_ThreadName=Thread-1;|RAR9606:
Error while handling Remove event.|#]


After this it says 'Restart required' in the admin interface



 Comments   
Comment by Anissa Lam [ 26/Oct/10 ]

The msg is not from the console. Transfer to backend team.

Comment by Jagadish [ 27/Oct/10 ]

-> ms7

Comment by Jagadish [ 31/Oct/10 ]

->jr158900

Comment by Jagadish [ 01/Nov/10 ]

FIX INFORMATION :

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=24907
svn log -v -r 42353

Fix will be available in 2nd November 2010 nightly / 3.1 promoted build 27

Comment by Jagadish [ 01/Nov/10 ]

Whenever a property is added/changed/removed, this exception was seen which is
fixed now.





Generated at Wed Mar 29 15:57:47 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.