[GLASSFISH-18407] Remote EJBs fail with ClassCastException in embeddable Glassfish Created: 24/Feb/12  Updated: 01/May/13

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_b39
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-16385] Firefox 4.0 does not work for the Admin Console Targeting dialogs Created: 19/Apr/11  Updated: 25/Jul/11  Due: 19/Apr/11  Resolved: 19/Apr/11

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

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

Attachments: JPEG File ff5_gf_console_issue.jpg    
Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

Firefox 4.0 does not work for the Administration Console Targeting dialogs. All other web pages display correctly.

"Targeting dialogs" refer to those dialogs in which two adjacent columns of options are displayed, one for "Available Targets" and the other for "Selected Targets." A user can select the desired options and move them from one column to other.

For example, such a dialog can be displayed by navigating to the Resources->JDBC->JDBC Resources-><resource-name>->Target page and then clicking Manage Targets. The resulting Manage Resource Targets page will not be displayed correctly in Firefox 4.0. Specifically, the CSS page formatting is not rendered, leaving just plain text and no layout.

Workaround

None. This is a rendering issue in Firefox 4.0. Other browsers and earlier versions of Firefox do not exhibit this behavior.



 Comments   
Comment by Scott Fordin [ 19/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Anissa Lam [ 18/Jul/11 ]

FF4 is EOL'ed and is not a supported browser.

FF5 has replaced FF4, and we have tested Console works fine in FF5.

Comment by Thorsten Gilfert [ 25/Jul/11 ]

I get the same issue with FireFox 5 (Win Vista) too. See attached screenshot.





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

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

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

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

 Description   

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

/*

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

    catch (Exception ex)

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

    return resultDoc;
    }

Example error:

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

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



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

The workaround is easy:

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

Comment by Bobby Bissett [ 04/Mar/11 ]

Patch, take 1.

Comment by Bobby Bissett [ 04/Mar/11 ]

This is fixed in revision 45411.

Comment by Scott Fordin [ 15/Mar/11 ]

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

Comment by Bobby Bissett [ 15/Mar/11 ]

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

Comment by Scott Fordin [ 15/Mar/11 ]

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

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

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

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

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

Comment by Bobby Bissett [ 16/Mar/11 ]

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

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

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

Comment by Scott Fordin [ 08/Apr/11 ]

Added topic to 3.1 Upgrade Guide.

Comment by Scott Fordin [ 13/Apr/11 ]

Also added issue to 3.1 Release Notes.





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

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

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

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

 Description   

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

Please refer to defects 7023434 and 7023307 for additional detail.

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

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

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

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

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

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



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

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

Comment by sirajg [ 04/Mar/11 ]

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

Workaround 1 :

kill the process running prtfru, for example:

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

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

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

Workaround 3:

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

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

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

Comment by tecknobabble [ 04/Mar/11 ]

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

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

Comment by tecknobabble [ 04/Mar/11 ]

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

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

Comment by Scott Fordin [ 04/Mar/11 ]

Added issue to 3.1 Release Notes.

Comment by sirajg [ 04/Mar/11 ]

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

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

Comment by Anissa Lam [ 04/Mar/11 ]

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





[GLASSFISH-16094] On Windows the first time pkg.bat or updatetool.bat is run they may echo garbage Created: 24/Feb/11  Updated: 26/Apr/11  Resolved: 15/Mar/11

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

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

Issue Links:
Dependency
depends on UPDATECENTER2-2176 Windows bootstub wrapper script has e... In Progress
Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes

 Description   

On Windows if you don't install the Update Center via the installer, the first time you run pkg.bat (or updatetool.bat) the scripts echo a bunch of stuff before prompting the user asking them if they would like to install the software. Things work, it's just ugly.



 Comments   
Comment by Joe Di Pol [ 24/Feb/11 ]

This is caused by a bad "@echo on" statement in the pkg.bat bootstrap wrapper script. One work-around is to remove the echo statement (immediately after the copyright block), but more likely is the users should just ignore the garbage.

This is covered by UC issue UPDATECENTER2-2176 and we may want to mention it in the GlassFish release notes.

Comment by Scott Fordin [ 15/Mar/11 ]

Added topic to 3.1 Release Notes. Will appear in next doc set refresh.

Comment by Joe Di Pol [ 26/Apr/11 ]

This will be fixed in the product when uc2.3.4-B53 is picked up, which is planned for GlassFish 3.1.1





[GLASSFISH-16067] 3.1 GlassFish installer takes longer to bootstrap Update Center than in 3.0.1 Created: 21/Feb/11  Updated: 02/Dec/11  Resolved: 15/Jun/11

Status: Resolved
Project: glassfish
Component/s: update_center
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b08, 4.0

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

Issue Links:
Dependency
depends on UPDATECENTER2-2175 Bootstrapper performance regression f... In Progress
Status Whiteboard:

Flagging for release notes. There is no workaround (although not using a proxy server, if possible, can improve performance).

If the user wishes to confirm the download process is making progress they can look in "glassfish3/.org.opensolaris,pkg/download/<number>" and verify that the number of files is increasing over time.

Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_1-approved

 Description   

On my MacBook it takes the 3.1 installer about 4m30s to bootstrap the Update Center (go from 41% to 69%). With 3.0.1 it takes about 1m30s. This is likely caused by a performance regression in UC 2.3.3. See issue UPDATECENTER2-2175

This was with the Unix installer, B43 web profile.



 Comments   
Comment by Joe Di Pol [ 23/Feb/11 ]

The times in the description where using a network proxy. When I removed the proxy the time improved to 3m30s – a bit of an improvement.

Comment by Joe Di Pol [ 22/Mar/11 ]

A fix that improves the performance has been checked into Update Center (see linked bug). We will integrate this for 3.2.

Comment by Scott Fordin [ 12/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Joe Di Pol [ 20/Apr/11 ]

A fix for UPDATECENTER2-2175 was integrated in UC 2.3.4-B53. This will be picked up for GlassFish 3.1.1.

That fix significantly speeds up downloaded performance over what is in UC 2.3.3/GF 3.1 (over twice as fast), but is still not as fast as UC 2.3.2/3.0.1 on most networks.

Comment by Nazrul [ 21/Apr/11 ]

We should integrate the current UC fix (UC issue 2175) in 3.1.1

Comment by Joe Di Pol [ 22/Apr/11 ]

Assigning to Snjezana to pick up UC 2.3.4,0-53 in the GlassFish build.

Comment by scatari [ 06/Jun/11 ]

Pre-approving this fix for 3.1.1.

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

Fixed in 3.1.1 b08 and the trunk since updated pkg-client.jar has been integrated.





[GLASSFISH-16066] set-web-context-param, set-web-env-entry man pages: incorrect case for --ignoredescriptoritem option Created: 21/Feb/11  Updated: 30/Jun/11  Resolved: 30/Jun/11

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

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

Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

The case of the --ignoredescriptoritem option of the set-web-context-param and set-web-env-entry subcommands has been changed from camel case to all lowercase. However, the man pages for these subcommands have not been updated to reflect this change and still list the option as --ignoreDescriptorItem.



 Comments   
Comment by Paul Davies [ 03/Mar/11 ]

Reassigned to writer who will fix it in 3.2. As this issue is tagged for inclusion in the release notes, the issue need not be assigned to the release notes writer.

Comment by Scott Fordin [ 24/Mar/11 ]

Added topic to 3.1 Release Notes. Added "3_1-release-note-added" tag.

Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in the 3.1.1 bundled docs

Comment by Paul Davies [ 30/Jun/11 ]

Fix committed in revision 47759.





[GLASSFISH-16061] could not find Factory: javax.faces.context.FacesContextFactory Created: 21/Feb/11  Updated: 17/May/11  Resolved: 11/May/11

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1_b43
Fix Version/s: None

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

Linux, Seam 3


Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

On running my JSF/Seam 3 application (using netbeans), the application startup fails with the message:

WARNING: StandardWrapperValve[FacesServlet]: PWC1382: Allocate exception for servlet FacesServlet
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory

I have to undeploy my application, restart glassfish, and re-deploy my application (sometimes several times) to get this problem to go away.

This problem is intermittent.

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

Stack trace:

WARNING: StandardWrapperValve[FacesServlet]: PWC1382: Allocate exception for servlet FacesServlet
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:815)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:317)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:253)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1439)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1071)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:189)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)



 Comments   
Comment by rogerk [ 21/Feb/11 ]

Can you provide a war for this app?

Comment by bleathem [ 21/Feb/11 ]

I'll see if I can put together a simplified war that exhibits this behaviour.

Comment by rogerk [ 21/Feb/11 ]

Simplified app would be nice. I know that there are probably a lot of libraries with a Seam3 aopp.

Comment by rogerk [ 21/Feb/11 ]

Simplified app would be nice. I know that there are probably a lot of libraries with a Seam3 aopp.

Comment by rogerk [ 21/Feb/11 ]

Tagging until more information is available.

Comment by bleathem [ 22/Mar/11 ]

I can now reproduce this behaviour, and I have a workaround, with a small caveat.

I cannot run my app with the weld-osgi-bundle.jar provided with glassfish, so I replace it with the latest weld-osgi-bundle snapshot.

The error comes up consistently in my sample app, and I can make it consistently going away by adding the following to my web.xml:

<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

I can provide you with the sample app if this information is not enough to go on.

Comment by rogerk [ 23/Mar/11 ]

Are you saying your app was not configured to go through the FacesServlet?

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by rogerk [ 11/May/11 ]

Closing as I have not heard back from reporter and this appears to be a configuration issue - in addition the reporter has workaround for config issue.

Comment by bleathem [ 16/May/11 ]

This issue is sporadic issue, and is observed when a JSF application does not register the Faces Servlet in the web.xml.

com.sun.faces.config.FacesInitializer will attempt to initialize the JSF Servlet, which normally works fine, except when Seam Faces is included in the application, which also tries to initialize the Servlet.

This bug is not deterministic due to the random ordering of listeners by Glassfish.

For more information, please see the corresponding issue in SeamFaces:
https://issues.jboss.org/browse/SEAMFACES-163

Comment by Scott Fordin [ 17/May/11 ]

Added issue to 3.1 Known Issues section of the 3.1-3.1.1 Release Notes.





[GLASSFISH-16048] Application info page: status not show correctly and virtual servers changes not saved. Created: 18/Feb/11  Updated: 22/Jun/11  Resolved: 18/Feb/11

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

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

Issue Links:
Duplicate
is duplicated by GLASSFISH-16054 Regression: Status showed incorrectly... Resolved
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

I just notice 2 issues in application information page after application is deployed.
This only occurs in DAS ONLY environment.

  • The status checkbox is always unchecked regardless whether the application is enabled or disabled. The display is wrong.
  • Changing the list of virtual servers is not persisted.

The display for the status was not correct is a regression i introduced when fixing GLASSFISH-15848.
Not able to save the virtual servers is due to the capitalization of the attribute variable. I believe the issue has been there for a while.



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

The issue has been fixed in the trunk,

Sending appEdit.layout
Transmitting file data .
Committed revision 45179.
==================

We want to release note this to provide a workaround for user.
User will only see this issue when there is NO clusters or standalone instances created in the domain.

  • For the status of the application, always look at the applications table that lists out the applications. The status is correctly displayed there, and user can use this table to change the status as well.
  • To change the virtual server for the deployed application, use the CLI set command.

use the following CLI to see the info:

%asadmin get server.application-ref.<APPLICATION_NAME>.*

and set command to change the list of virtual servers for this application.

%asadmin set server.application-ref.<APPLICATION_NAME>.virtual-servers=<list-of-vs-separated-by-comman>

example of get :
%asadmin get server.application-ref.hello

examples of set:
%asadmin set server.application-ref.hello.virtual-servers=server,myVS
or
%asadmin set server.application-ref.hello.virtual-servers=myVS

Comment by Anissa Lam [ 18/Feb/11 ]

Fixed in the trunk.

Comment by Scott Fordin [ 12/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by shaline [ 22/Jun/11 ]

Verified on promoted b08.





[GLASSFISH-16044] appclient in cygwin passing extra empty string Created: 17/Feb/11  Updated: 07/Apr/11  Resolved: 30/Mar/11

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

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

Windows, Cygwin


Attachments: File AppClientTest.ear     Java Archive File AppClientTestClient.jar    
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1windows

 Description   

When running appclient on a windows machine with cygwin, the appclient is passing an extra empty String to the program arguments.

But when running on command line in windows doesnt show that problem.

See below:

Linux run:
===========
sreekanth@spidy:~/NetBeansProjects/AppClientTest$ asadmin deploy --retrieve dist --force=true dist/AppClientTest.ear
Authentication failed with password from login store: /home/sreekanth/.asadminpass
Enter admin password for user "admin">
Application deployed with name AppClientTest.
Command deploy executed successfully.
sreekanth@spidy:~/NetBeansProjects/AppClientTest$ appclient -client dist/AppClientTestClient.jar Arguments length is :0
sreekanth@spidy:~/NetBeansProjects/AppClientTest$

Window Run:
===========

aroot@bigapp-x2250-1 /cygdrive/c/ha/tmp-sree
$ /cygdrive/c/ha/glassfish3/glassfish/bin/asadmin deploy --retrieve . --force=true AppClientTest.ear
Application deployed with name AppClientTest.
Command deploy executed successfully.

aroot@bigapp-x2250-1 /cygdrive/c/ha/tmp-sree
$ /cygdrive/c/ha/glassfish3/glassfish/bin/appclient -client AppClientTestClient.jar
Arguments length is :1



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

Sreekanth,

Please contact me directly via e-mail so I can arrange to investigate this on your system.
Thanks.

Comment by Tim Quinn [ 20/Feb/11 ]

I have reproduced this issue on a Windows system with cygwin installed.

Investigating.

Comment by Tim Quinn [ 21/Feb/11 ]

We are excluding this from 3.1.

It seems to be due to an interaction between the way the CLIBootstrap class generates the java command for launching the app client and how the cygwin shell parses the command into arguments. There is currently a trailing blank in the generated command line. This is not an issue in other environments, but cygwin in this case seems to treat the blank as a separator in front of an empty argument.

Users who have app clients that process a variable number of arguments and run those clients on Windows using cygwin should be aware of this issue. One workaround would be to make sure the client deals correctly with an empty argument.

Comment by Tim Quinn [ 14/Mar/11 ]

Release notes info:

Summary: Using cygwin on Windows, the app client container (ACC) passes an extra empty-string argument to the client's main method. This might result in the app client throwing an index-out-of-range exception if the client does not guard itself against empty argument values.

Workarounds (reiterating from the Feb. 21. comment):
1. If your client works with a variable number of arguments make sure that it protects itself against empty argument values.

2. Avoid using cygwin on Windows for clients that cannot be made to guard against an empty argument value.

Comment by Tim Quinn [ 17/Mar/11 ]

Fix checked in:

Project: glassfish
Repository: svn
Revision: 45605
Author: tjquinn
Date: 2011-03-17 18:03:10 UTC
Link:

Log Message:
------------
Fix for 16044

Under cygwin on Windows, a trailing blank on the generated java command line was parsed as an empty additional command-line argument and passed as such to the client.

This change causes the generated java command to no longer contain an extra trailing blank.

Tests: QL, deployment devtests, cygwin on Windows test

Revisions:
----------
45605

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

Comment by Tim Quinn [ 24/Mar/11 ]

The earlier fix causes problems when the user enters JVM options on the appclient command line. There is a missing space between the user-provided JVM options and some JVM options which CLIBootstrap adds to the generated java command line.

Comment by Scott Fordin [ 24/Mar/11 ]

Added topic to 3.1 Release Notes. Added "release note added" tag.

Comment by Tim Quinn [ 30/Mar/11 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 45773
Author: tjquinn
Date: 2011-03-30 15:57:40 UTC
Link:

Log Message:
------------
Additional refinement for fix to 16044

This change resolves a problem in which user-specified JVM options were not separated from other options by a space. It also cleans up the earlier fix logic a bit and adds some javadoc for some methods.

Tests: QL, deployment devtests, cygwin on Windows test

Revisions:
----------
45773

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





[GLASSFISH-16040] ReleaseNotes: document Restar Required issues Created: 17/Feb/11  Updated: 08/Jul/11  Resolved: 18/Mar/11

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

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

Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

This is an umbrella bug for documenting numerous issues with Restart Required. Please find the details in the following query:

http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10358

Each bug in the query should be documented in Release Notes for 3.1.



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

Added issue to 3.1 Release Notes.

Comment by Anissa Lam [ 14/Mar/11 ]

I am re-opening this issue so that the next doc refresh can have the correct summary.
Currently, it says:

"Description
There are a number of functions in that you can perform through the GlassFish Server
Administration Console. These functions require a server restart, but the Administration
Console does not correctly convey this."

This is not quite correct. It is saying that the Admin Console does not show the correct information to user, when in fact, the information that console shown is correct. It is that the backend or each of the components in the bug list doesn't specify that restart is required.
In order word, even if user is using CLI to look at the status, eg. list-domains or list-instances to check if instance need restart, they will see the wrong information.

So, i think the wording should be changed to reflect the issue more accurately.

Comment by Scott Fordin [ 18/Mar/11 ]

Reworded issue description. Added ulinks to umbrella issues.

Comment by Scott Fordin [ 24/Mar/11 ]

Added "release note added" tag.

Comment by lidiam [ 08/Jul/11 ]

Verified in Release Notes for 3.1 release.





[GLASSFISH-16037] create-jvm-options subcommand options incorrectly parsed by asadmin Created: 17/Feb/11  Updated: 07/Apr/11  Resolved: 18/Feb/11

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

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

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

The asadmin utility is incorrectly interpreting options of the create-jvm-options subcommand as asadmin utility options. As a result, an attempt to create an option, for example -Xrs, fails:

asadmin> create-jvm-options -Xrs
Non-boolean option: X, not allowed in argument: -Xrs
Usage: asadmin [-H|--host <host(default:localhost)>]
[-p|--port <port(default:4848)>] [-u|--user <user(default:admin)>]
[-W|--passwordfile <passwordfile>]
[t|-terse[=<terse(default:false)>]]
[s|-secure[=<secure(default:false)>]]
[e|-echo[=<echo(default:false)>]]
[I|-interactive[=<interactive(default:true)>]]
[?|-help[=<help(default:false)>]]
create-jvm-options [command-specific options]
Command create-jvm-options failed.

The usage message appears to be in the style of a v2 usage message. In GlasFish 3, asadmin utility options are not provided in the usage message.

To workaround this problem, run the create-jvm-options command in single mode specifying at least one asadmin utility option, for example:

dashost$ asadmin --host dashost create-jvm-options -Xrs
Created 1 option(s)
Command create-jvm-options executed successfully.



 Comments   
Comment by Bill Shannon [ 18/Feb/11 ]

Missed one case in the special cases for commands that treat unknown
options as operands.

Also, some asadmin hidden commands had short option names, which was
further confusing things. I'm removing the short names for the hidden
options.

Comment by Scott Fordin [ 24/Mar/11 ]

Added topic to 3.1 Release Notes. Added "release note added" tag.





[GLASSFISH-16025] Domain.xml: setting protocol.http-listener-1.http.max-connections set in 1 or -1 Created: 16/Feb/11  Updated: 13/Dec/11  Resolved: 13/Dec/11

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1_b38
Fix Version/s: 3.1.1

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

Windows XP


Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

Hi there,

with old documentaton for GF 3.0.1 I found that :

"http.max-connections property (optional) Specifies the maximum number of requests that can be pipelined until the connection is closed by the server. Set this property to 1 to disable HTTP/1.0 keep-alive, as well as HTTP/1.1 keep-alive and pipelined until the connection is closed by the server. A value of 0 means requests are always rejected. A value of -1 sets no limit to the number of keep-alive connections. "

Now I use the GF 3.1 (build 42) and I set protocol.http-listener-1.http.max-connections set into 1 and seems that connections are not closed(they are keep-alive). Is such behaviour correct?

When I set into -1, all connections are closed, but I am expecting to see them alive.

Could anybody explain how this setting works now for version 3.1?

Thank you



 Comments   
Comment by oleksiys [ 21/Feb/11 ]

it's a bug.

Workaround is following:

-1 is not working as unlimited, please use some big number up to Integer.MAX_VALUE.
1 - will let you process 1 keep-alive request, and close the connection after processing 2nd request on the same connection
0 - will disable keep-alive for the connection

Comment by Scott Fordin [ 13/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by oleksiys [ 13/Dec/11 ]

mark as fixed





[GLASSFISH-15987] Display Restart Required when a system-property which is referenced by a jvm-option is changed Created: 15/Feb/11  Updated: 07/Apr/11  Resolved: 17/Mar/11

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

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

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Restart Required should also appear in Admin Console and 'asadmin list-domains' when a change is made to the system-property which is referenced by a jvm-option. In the code we need to
check if the system property is changed and referenced by a jvm-options
and show the Restart Required.

For example in server-config:

1) Create a system property
<system-property name="JVM_HEAP_SIZE" value="1090m"></system-property>

2) Change jvm option to use system property
<jvm-options>-Xmx$

{JVM_HEAP_SIZE}

</jvm-options>

3) Restart GlassFish

4) Change system property value for JVM_HEAP_SIZE

5) Upper left of Admin Console does not show Restart Required
asadmin list-domains does not show 'requires restart'

Checked on v2.1.1, that changing a system-property referenced by a jvm-option, show restart required in asadmin list-domains (The Admin Console doesn't display):

C:\glassfish-v2.1.1-b31g\glassfish\bin>asadmin list-domains
domain1 requires restart
Command list-domains executed successfully.



 Comments   
Comment by Jennifer Chou [ 15/Feb/11 ]

I checked in v2.1.1 that even a change to a system property that's not referenced by anything else, will trigger a restart required to be displayed.

C:\glassfish-v2.1.1-b31g\glassfish\bin>asadmin list-domains
domain1 requires restart
Command list-domains executed successfully.

So in the code, we can just check whether a system property is changed and trigger a restart required state.

Comment by Chris Kasso [ 16/Feb/11 ]

We have a collection of "Restart Required" issues that remain unresolved in 3.1. This likely warrants an umbrella Release Note item which addresses the more general problems we are seeing in this area. Here's a query that identifies many of the existing "Restart Required" issues:

http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10358

Comment by Tom Mueller [ 01/Mar/11 ]

The root cause of this problem is that when a system property change is made, the GenericJavaConfigListener class does not take into account that some JVM options, such as -Xmx, might be depending on the value of a system property, so the system property change event is not returned from GenericJavaConfigListener as an UnprocessedChangeEvent, so the UnprocessedConfigListener doesn't pick it up to set the restart required flag.

The processing of the JVM options, including resolution of property values, occurs within the launcher, which is executed by asadmin, not the server (specifically in the GFLauncher class when it calls TokenResolver). There is no record kept of what tokens were resolved, or where they came from.

Considering this a bit deeper, the token resolution that occurs for JVM options uses as its sources the following:

1. the shell environment, e.g., "export a=b"
2. values in the asenv.conf or asenv.bat file
3. values passed via -Da=b as specified in the asadmin script
4. system-properties in the domain.xml (server, config, and domain)
5. JVM options (-Da=b in the jvm-options in the domain.xml)
6. profiler properties (from the domain.xml)

If any of these change such that the JVM options would be recalculated for the instance, then a restart-required should be triggered. For example, if the asenv.conf file or asadmin file is edited, or the user changes their environment. The server cannot detect changes in the latter, but it could be looking at those files. This bug is only about changes to system-properties in the domain.xml, but it does raise the question of what else should be checked too.

The suggested fix for this bug is to modify the GenericJavaConfigListener class so that it looks at the token that are referenced by the JVM options, and if the value of a token changes, then the change should be returned as an UnprocessedChangeEvent. This will require making GenericJavaConfigListener listen for system property change notifications.

Comment by Scott Fordin [ 07/Mar/11 ]

Added issue to 3.1 Release Notes as part of "Restart Required" umbrella issue.

Comment by Tom Mueller [ 08/Mar/11 ]

This isn't actually fixed yet.

Comment by Tom Mueller [ 17/Mar/11 ]

Fixed in revision 45608 on the trunk.

If a system-property is referenced by a JVM option, any change to that any system property with that name will cause a restart-required, even if the actual value did not change. For example, consider this:

<domain>
<system-property name="foo" value="bar"/>
<servers>
<server config-ref="server-config">
<system-property name="foo" value="baz"/>
</server>
</servers>
<configs>
<config name="server-config">
<java-config>
<jvm-options>-Dabc=$

{foo}

</jvm-options>
</java-config>
</config>
</configs>
</domain>

If you then do:
asadmin create-system-property --target domain foo=xyz

This will trigger the restart-required flag, even though the <server> value is really overriding the value for foo, so when the server restarts, the value of the abc property won't change.

If this really bothers you, please file another issue.

However, the fix that is checked in fixes the problem from the initial description.

Comment by Scott Fordin [ 18/Mar/11 ]

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

Comment by Scott Fordin [ 24/Mar/11 ]

Added "3_1-release-note-added" tag.





[GLASSFISH-15986] Column APPLICATIONID is missing from bundled sql scripts for ejb timer table creation. Created: 15/Feb/11  Updated: 13/Apr/11  Resolved: 04/Mar/11

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

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

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

In 3.1, the bundled timer table creation sql scripts are missing column APPLICATIONID.

sony@nila:/home2/sony/builds/glassfish3/glassfish/lib/install/databases$ cat ejbtimer_derby.sql
CREATE TABLE EJB_TIMER_TBL (
CREATIONTIMERAW BIGINT NOT NULL,
BLOB BLOB(2G),
TIMERID VARCHAR(255) NOT NULL,
CONTAINERID BIGINT NOT NULL,
OWNERID VARCHAR(255),
STATE INTEGER NOT NULL,
PKHASHCODE INTEGER NOT NULL,
INTERVALDURATION BIGINT NOT NULL,
INITIALEXPIRATIONRAW BIGINT NOT NULL,
LASTEXPIRATIONRAW BIGINT NOT NULL,
SCHEDULE VARCHAR(255),
CONSTRAINT PK_EJB_TIMER_TBL PRIMARY KEY (TIMERID)
) ;



 Comments   
Comment by marina vatkina [ 15/Feb/11 ]

I'm not sure how this could happen, but all but one .sql files are missing this column. The sql files are for the user as a ref point, or to be able to create the table themselves. By default EJB Timer service creates the table on the 1st deploy.

Fixing the files won't affect the execution.

Comment by marina vatkina [ 15/Feb/11 ]

Fixed on trunk with rev 45149

Comment by Scott Fordin [ 04/Mar/11 ]

Need more information to add to notes.

Comment by Scott Fordin [ 04/Mar/11 ]

Added issue to 3.1 Release Notes.

Comment by Scott Fordin [ 24/Mar/11 ]

Added "3_1-release-note-added" tag.





[GLASSFISH-15985] NullPointerException when accessing OSGi web application Created: 15/Feb/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Resolved
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1_b38, 3.1_b41 , 3.1_b42
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: chaoslayer Assignee: Ed Burns
Resolution: Fixed Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File dummy-web.war     Text File message.txt     Text File server-3.1-b36.log     Text File server-3.1-b37.log    
Status Whiteboard:

jsf_2_1_1

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Deployment of the web application works fine:

INFO: Installed /srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Started bundle: file:/srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Started bundle: file:/srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Expanded at file:/tmp/osgiapp6345962157332461681/
INFO: SEC1002: Security Manager is OFF.
INFO: SEC1010: Entering Security Startup Service
INFO: SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
INFO: SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
INFO: SEC1011: Security Service(s) Started Successfully
INFO: WEB0169: Created HTTP listener [http-listener-1] on host/port [0.0.0.0:8080]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [admin-listener] on host/port [0.0.0.0:4848]
INFO: WEB0171: Created virtual server [server]
INFO: WEB0171: Created virtual server [__asadmin]
INFO: WEB0172: Virtual server [server] loaded default web module []
INFO: Portable JNDI names for EJB DummySingleton : [java:global/org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT/DummySingleton, java:global/org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT/DummySingleton!org.glassfish.osgi.web.dummy.DummySingletonLocal]
INFO: WELD-000900 $

{parsedVersion (osgiVersion}

)
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: total number of classes with faces annotation = 0
INFO: Total number of available updates : 0
INFO: Initializing Mojarra 2.1.0 (FCS 2.1.0-b11) for context '/dummy-web'
INFO: Faces Config uris excluding the ones named as faces-config.xml = []
INFO: Facelet Config uris = [embeddedjar:bundle://252.0:0/WEB-INF/lib/prettyfaces-jsf2-3.2.0.jar!/META-INF/ocpsoft-pretty-faces.taglib.xml]
INFO: PrettyFilter starting up...
INFO: PrettyFilter initialized.
INFO: WEB0671: Loading application [org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT] at [/dummy-web]
INFO: Registered ServletContext as a service with properties:

{osgi.web.symbolicname=org.glassfish.osgi.dummy-web, osgi.web.version=1.0.0.SNAPSHOT, osgi.web.contextpath=/dummy-web}


INFO: deployed bundle org.glassfish.osgi.dummy-web [252] at file:/tmp/osgiapp6345962157332461681/

...but when I try to access it via HTTP:

SEVERE: WebModule[/dummy-web]PWC1321: Error invoking requestInitialized method on ServletRequestListener com.ocpsoft.pretty.faces.config.PrettyConfigListener
java.lang.NullPointerException
at com.sun.faces.application.ServletContextSensitiveSingletonStore.<init>(ServletContextSensitiveSingletonStore.java:83)
at com.sun.faces.application.ApplicationFactoryImpl.getApplication(ApplicationFactoryImpl.java:92)
at com.ocpsoft.pretty.faces.util.FacesFactory.getApplication(FacesFactory.java:31)
at com.ocpsoft.pretty.faces.config.PrettyConfigListener.requestInitialized(PrettyConfigListener.java:34)
at org.apache.catalina.core.StandardContext.fireRequestInitializedEvent(StandardContext.java:4551)
at org.apache.catalina.core.StandardHostValve.preInvoke(StandardHostValve.java:626)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

attached a test case (dummy-web.war).

I've tested this against b33, b36, b38, b41, and b42. Up to b36 all was fine, starting with b41 the above exception is being thrown.

In b38, the behavior was even more strange:

^^ ???

...HTTP access returned a 404 (expected after those lines), but a OSGi bundle "refresh" yield this:

INFO: Expanded at file:/tmp/osgiapp8864019535236458366/
INFO: Deleted /tmp/osgiapp8864019535236458366
SEVERE: Failed while deploying bundle org.glassfish.osgi.dummy-web [369]
INFO: Removed bundle 369 against context path /dummy-web
WARNING: Failed to deploy bundle org.glassfish.osgi.dummy-web [369]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.osgi.dummy-web [369] failed because of following reason: Failed while deploying bundle org.glassfish.osgi.dummy-web [369] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [369] ], root cause: Application name org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT is already in use. Please pick a different name.
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [369] ], root cause: Application name org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT is already in use. Please pick a different name.
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
... 10 more



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

This is an OSGi jsf web application.
There are two issues here:
(1) The first access of OSGi web application have NPE.
(2) There is a problem in redeployment of OSGi web application.

Assign to jsf team to investigate (1).

Comment by rogerk [ 15/Feb/11 ]

Assigning to Ed as prior commit may be the cause.

Comment by Ed Burns [ 15/Feb/11 ]

Does the server configuration in which this bug manifests use clusters or virtual servers?

Comment by Ed Burns [ 15/Feb/11 ]

Because this is an OSGi web application, I assume I must deploy it with "--type osgi" correct?

Comment by Ed Burns [ 15/Feb/11 ]

I can reproduce the problem.

Here is the log output.

Comment by Ed Burns [ 15/Feb/11 ]

By omitting the --type osgi argument from the deployment, this causes the problem to not manifest. Of course, it is a real bug, but it is not a blocker for 3.1.

Comment by chaoslayer [ 15/Feb/11 ]

I usually deploy those WABs using the .../autodeploy/bundles/ Felix FileInstall watch directory.

Apart from that I disagree by excluding this for the 3.1 release because it is a real regression and OSGi/JavaEE is a real target for GlassFish 3.1 and we already use it (currently with b36) just short before our application release.

As there are numerous issues resolved since b36 regarding stability/performance and bugfixes we are seriously looking forward to use a later build and hopefully switch to the final release.

However, this bug would completely block us doing so and we'll have to live with workarounds/hacks.

Comment by Sanjeeb Sahoo [ 16/Feb/11 ]

Can anyone tell me which check-in caused this regression? It is sad that we have caused a regression in builds just prior to release of 3.1.

Comment by chaoslayer [ 16/Feb/11 ]

Just tested the b37 and even that one is affected by this problem.

I've attached two log files for comparison both with felix log level set to DEBUG in order to see, if that's a wiring problem, but doesn't seem so.

Log files:

  • server-3.1-b36.log - OK
  • server-3.1-b37.log - FAIL
Comment by chaoslayer [ 16/Feb/11 ]

Well, as the "FacesContext.getCurrentInstance()" returns "null" (introduced by Mojarra 2.1-b10), I just thought about adding a custom faces-config (stored in a file "META-INF/weld.faces-config.xml") with the following content:

<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">
<factory>
<application-factory>org.glassfish.weld.jsf.WeldApplicationFactory</application-factory>
</factory>

</faces-config>

...and now it works. So basically it seems, that FacesContext.setCurrentInstance is not called unless I provide a specific application factory class, weird...

...a little debugging against a 3.1-b41 with mojarra 2.1-b11 yield the following:

Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at FacesContext.java:845.
User program running

...so the "FacesContext.setCurrentInstance()" is always called after the call to "FacesContext.getCurrentInstance()" is issued by the ServletContextSensitiveSingletonStore which is obviously the wrong order things should happen.

Using the custom *.faces-config.xml file I see the following invocations:

Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running

...which seems totally correct.

Comment by chaoslayer [ 21/Feb/11 ]

Any progress on this one?

Comment by Ed Burns [ 02/Mar/11 ]

Ok, I see the same problem, even today.

Investigating further.

Comment by Ed Burns [ 03/Mar/11 ]

Committed to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationFactoryImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/application/InjectionApplicationFactory.java
Deleting jsf-ri/src/main/java/com/sun/faces/application/ServletContextSensitiveSingletonStore.java
Sending jsf-ri/src/main/java/com/sun/faces/application/WebappLifecycleListener.java
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
Adding jsf-test/GLASSFISH-15985
Adding jsf-test/GLASSFISH-15985/build.xml
Adding (bin) jsf-test/GLASSFISH-15985/dummy-web.war
Sending jsf-test/build.xml
Transmitting file data ........
Committed revision 8887.

Comment by Ed Burns [ 04/Mar/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationFactoryImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/application/InjectionApplicationFactory.java
Deleting jsf-ri/src/main/java/com/sun/faces/application/ServletContextSensitiveSingletonStore.java
Sending jsf-ri/src/main/java/com/sun/faces/application/WebappLifecycleListener.java
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
Adding jsf-test/GLASSFISH-15985
Adding jsf-test/GLASSFISH-15985/build.xml
Adding (bin) jsf-test/GLASSFISH-15985/dummy-web.war
Sending jsf-test/build.xml
Transmitting file data ......
Committed revision 8899.

Comment by Sanjeeb Sahoo [ 04/Mar/11 ]

This bug needs to remain opened until a version of mojarra containing the fix is integrated.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Ed Burns [ 08/Apr/11 ]

Integrated into GlassFish 3.1.1

Comment by Scott Fordin [ 13/Apr/11 ]

Release Note still needed?

Comment by Ed Burns [ 14/Apr/11 ]

Release notes are only needed if you are writing releasenotes for 3.1.

Comment by Scott Fordin [ 14/Apr/11 ]

Thanks. I go back to my previous comment then: I need more info to include these in the 3.1 Release Notes. Specifically, a concise description and workaround.

Comment by Scott Fordin [ 12/May/11 ]

Added topic to 3.1 Known Issues section of the 3.1-3.1.1 Release Notes. Not convinced I have all the information I need. For example, not clear to me what the downsides are to omitting --type osgi from the deploy subcommand. Also not clear what the implications are, if any, when deploying from an autodeploy directory or the Admin Console.





[GLASSFISH-15975] lazy-init attribute missing from admin console Edit IIOP Listener page Created: 14/Feb/11  Updated: 19/Sep/14

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

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

There isn't any way to view or edit the lazy-init setting for the IIOP listener from the admin console.



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

This sounds like a new attribute added in iiop-listener, not sure if this is since 3.0 or 3.1.
The module owner should have contacted GUI regarding this change so that it can be incorporated in the GUI page.

When looking at config-api, I see that there is only get() method, but not set() for this attribute
@Attribute(defaultValue="false", dataType=Boolean.class)
String getLazyInit();

Is this a read-only attribute ?
Please confirm or fix this. Transfer to 'orb'.

Comment by Tom Mueller [ 14/Feb/11 ]

The IiopListener config bean has the following code:

/**

  • Sets the value of lazyInit property
    *
  • Specify is this listener should be started as part of server startup or not
    *
  • @param value true if the listener is to be started lazily; false otherwise
    */
    void String(boolean value);

It looks like this "String" method was supposed to be a "setLazyInit" method - maybe a typo?

Comment by Ken Cavanaugh [ 14/Feb/11 ]

This was added in 3.0. I'm not sure who was working on the IiopListener class at that
point, but it belongs to the orb now. I think Tom's comment is correct, and
the method should be

void setLazyInit( boolean value )

This is probably not worth fixing this late in 3.1. I'm marking this issue for inclusion
in the release notes.

I think it's probably OK for 3.1, because I don't think there is much need to change the default
value.

Comment by Anissa Lam [ 14/Feb/11 ]

>> I think it's probably OK for 3.1, because I don't think there is much need to change the default
value.

Do you mean the default value or out-of-box value ? They are different.
And is there a reason why default value is different than out-of-box value ? This is always very confusing to user when this happen.

Comment by Ken Cavanaugh [ 14/Feb/11 ]

I don't know what the difference is between default and out-of-the-box.
I just know that I always see lazy-init="true" for the orb-listener-1
IIOP listener in the config.xml file.

Comment by Tom Mueller [ 14/Feb/11 ]

Default is the value that is in the config bean Java source code, in this case "false".

Out-of-the-box is the value that is in the domain.xml template file, in this case "true" for orb-listener-1 and "false" for SSL and SSL_MULTIAUTH.

If a user clicks "New" in the admin console or runs the create-iiop-listener command (which also doesn't provide any way to set lazy-init), the user gets the default value, i.e., "false".

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Tom Mueller [ 24/Mar/11 ]

For the release notes:

The problem is that a user cannot set the lazy-init value for an IIOP listener from either the console or the CLI. Note that even the asadmin "set" command cannot be used to change the value. The only way to workaround this issue is to edit the domain.xml file directly. The domain.xml file may have:

<iiop-listener port="3700" id="orb-listener-1" address="0.0.0.0" lazy-init="true"></iiop-listener>

In this case, the lazy-init value can be changed to false.

Or, the domain.xml file may have:

<iiop-listener port="3700" id="orb-listener-1" address="0.0.0.0"></iiop-listener>

Here, the default value of false is in effect. To change it to true, add:

lazy-init="true"

to the iiop-listener element.

Comment by Scott Fordin [ 24/Mar/11 ]

Added topic to 3.1 Release Notes. Removed "need more info" tag, added "release note added" tag.

Comment by Nazrul [ 21/Apr/11 ]

Given that there is no way to manage lazy-init attribute using CLI and GUI, it would be useful to consider fixing this issue during 3.1.1

Comment by scatari [ 23/Jun/11 ]

Any GUI change in 3.1.1 requires recertification for 508 compliance that is too late to consider. Marking for next release.

Comment by Anissa Lam [ 23/Jun/11 ]

Before it gets to GUI, the backend needs to be fixed first.
No one has fixed the config bean code to allow setting of the value. I still see:

  /**
     * Sets the value of lazyInit property
     *
     * Specify is this listener should be started as part of server startup or not
     *
     * @param value true if the listener is to be started lazily; false otherwise
     */
    void String(boolean value);

Until this is fixed, GUI can't do anything.
When the above is fixed, then this can be assigned to GUI to add the UI.

Comment by Tom Mueller [ 07/Feb/13 ]

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





[GLASSFISH-15929] man-page-review umbrella issue Created: 09/Feb/11  Updated: 24/Mar/11  Due: 13/Feb/11  Resolved: 16/Feb/11

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

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

Issue Links:
Dependency
depends on GLASSFISH-15958 man page: webtier CLIs Resolved
depends on GLASSFISH-15877 man-page-review : remove the section ... Resolved
depends on GLASSFISH-15878 man-page-review : create-jdbc-connect... Resolved
depends on GLASSFISH-15879 man-page-review : note about resource... Resolved
depends on GLASSFISH-15962 Man page for update-node-config is wr... Resolved
depends on GLASSFISH-3198 Synopsis for asadmin help create-cust... Resolved
depends on GLASSFISH-15485 Error in man pages for restart-local-... Resolved
depends on GLASSFISH-15564 create-http-health-checker man page e... Resolved
depends on GLASSFISH-15566 change-master-password --help has wro... Resolved
depends on GLASSFISH-15867 documentation of create-system-proper... Resolved
depends on GLASSFISH-15872 man-page : flush-connection-pool, pin... Resolved
depends on GLASSFISH-15873 man-page-review : delete-resource-ada... Resolved
depends on GLASSFISH-15874 man-page-review : delete-connector-re... Resolved
depends on GLASSFISH-15875 man-page-review : list-admin-objects,... Resolved
depends on GLASSFISH-15876 man-page-review : list-connector-reso... Resolved
depends on GLASSFISH-15919 man-page-review: jms CLIs Resolved
depends on GLASSFISH-15956 man page: remove --upgrade option fro... Closed
depends on GLASSFISH-15947 Remove --upgrade from start-local-ins... Resolved
Tags: 3_1-approved, 3_1-release-note-added, 3_1-release-notes

 Description   

Raising an umbrella issue for the man pages of various commands for Bugswat review. Please refer the "depends on" issues list.



 Comments   
Comment by Paul Davies [ 11/Feb/11 ]

This bug is the umbrella bug for all man page fixes for the RC 3 build. I have increased the priority to ensure that it is approved for integration in RC 3.

Comment by Paul Davies [ 11/Feb/11 ]

How bad is its impact? (Severity)
The fix needs to occur now because the issue:

  • Is likely to generate a customer support call
  • Significantly impacts the operation of a primary release driver feature
  • Is an in-your-face issue that will touch the majority of users

How often does it happen? (Frequency)
Every time a user requests help on an affected subcommand.

How much effort is required to fix it? (Cost)
Approx 4 writer days (3 writers working 1 day each on the fixes, + 1 day for integration and testing)

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

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes - deliver the fixes only in the version that is published on the web.The workaround could be employed by an end user but only if the user is aware of the workaround.

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?
The errors were introduced in this release.

Do regression tests exist for this issue?
N/A

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
QuickLook would be sufficient for this purpose.

When will a tested fix be ready for integration?
Before the RC 3 build is started.

Comment by Chris Kasso [ 11/Feb/11 ]

Approved for RC3.

Comment by Chris Kasso [ 11/Feb/11 ]

These changes will not be localized for 3.1 thus users in non-EN locales will continue to see the incorrect man pages. The release notes should direct these users to the unbundled versions of the man pages for the corrections.

Comment by Paul Davies [ 13/Feb/11 ]

For the 3.1 branch, change is committed in revision 45101.

Comment by Paul Davies [ 16/Feb/11 ]

For the trunk, the fix is committed in revision 45163.

Comment by Scott Fordin [ 24/Mar/11 ]

Added topic to 3.1 Release Notes. Added "3_1-release-note-added" tag.





[GLASSFISH-15909] New Grizzly integration required for http://java.net/jira/browse/GRIZZLY-970 Created: 09/Feb/11  Updated: 13/Apr/11  Resolved: 03/Mar/11

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1_b41
Fix Version/s: None

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

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

See http://java.net/jira/browse/GRIZZLY-970 for details.

I've checked the web container code and have found similar logic which I will fix along with the grizzly integration.



 Comments   
Comment by Ryan Lubke [ 09/Feb/11 ]

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

  • Impacts product security

How often does it happen? (Frequency)

  • anytime a specially crafted header is sent to the web container

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

  • minimal

What is the risk of fixing it? (Risk)

  • minimal

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

  • none

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

How long has the bug existed in the product?

  • It's a JVM issue that's been around for some time. The issue has just recently started getting a lot of press.

Do regression tests exist for this issue?

  • in Grizzly, not in glassfish.

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

  • N/A

When will a tested fix be ready for integration?

  • 2/9/2011
Comment by Chris Kasso [ 09/Feb/11 ]

Oracle has issued the following sec alert on this issue:

http://blogs.oracle.com/security/2011/02/security_alert_for_cve-2010-44.html

If the customer upgrades to Java Runtime Environment 6 update 24 when it is released they will no longer be vulnerable to this issue. Information about this vulnerability along with how to mitigate it should be included in the Release Notes.

The fixed version of Grizzly should be incorporated in the first patch released for GF 3.1.

Comment by Scott Fordin [ 03/Mar/11 ]

Added issue to 3.1 Release Notes.





[GLASSFISH-15865] @DSD defined in EJBs bundled in a .war is not available for JPA during prepare() phase. Created: 05/Feb/11  Updated: 13/Apr/11  Resolved: 13/Apr/11

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

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

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Following use-case/application setup results in @DSD not found.

a) @DSD defined in an EJB bundled in a .war
+
b) JPA is also in the .war and JPA depends on the @DSD exported by the EJB.

In the above application setup, @DSD is not available during "prepare()" phase for JPA to create tables.
The @DSD is available after deployment.



 Comments   
Comment by Jagadish [ 05/Feb/11 ]

Workaround for 3.1 :

JPA can lookup only app scoped ("java:app") DSDs and so they can be defined in the enclosing .war's web.xml/application.xml/Servlet instead of defining in the EJB.

Fix for 3.2 is made available :
svn log -v -r 44940
Modified Paths:
---------------
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/DataSourceDefinitionDeployer.java

Comment by Scott Fordin [ 24/Mar/11 ]

Need more info to add to 3.1 Release Notes.

Comment by Jagadish [ 31/Mar/11 ]

Consider the following application layout :

EJBs are bundled in the .war and the Servlet in the .war makes use of JPA (Persistence Unit).
@DSD (DataSourceDefinition) is defined in the EJB.
If the Persistence Unit depends on @DSD defined in EJB, it will not be available in the above setup (ie., EJBs bundled in .war).

Workaround would be to define the DataSourceDefinition in web.xml/application.xml/Servlet instead of defining it in the EJB.

Comment by Jagadish [ 07/Apr/11 ]

Transferring to Scott for making appropriate docs changes for 3.1 (if any).
Scott : Please close this issue if its already taken care of.

Comment by Jagadish [ 07/Apr/11 ]

setting version as 3.1 as docs changes are needed only for 3.1 and not for 3.2

Comment by Scott Fordin [ 13/Apr/11 ]

Added issue to 3.1 Release Notes.





[GLASSFISH-15809] JSF PhaseListener executed for each virtual host Created: 02/Feb/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Resolved
Project: glassfish
Component/s: jsf
Affects Version/s: v3.0.1
Fix Version/s: 3.1.1_b01

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

We're running GlassFish 3.0.1 with JSF 2.1.0b11 on Windows 2007/7 64-bit.


Attachments: Text File 20110217-1558-i_gf_15809.patch     Text File 20110222-1610-i_gf_15809.patch     Text File i_gf_15809-workaround.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-1907 need to create a dev test for multipl... Closed
Status Whiteboard:

jsf_2_1_1

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

We recently spend 2 months changing from JSF 1.2 to 2.0 and GlassFish 2 to 3.0.1. When we were finish with the conversion and ready to go live, we realised that JSF and virtual servers doesn't work together at all on GlassFish 3.0.1 with JSF 2.0. Luckily, this happened on January 27, 2011, the same day that JSF 2.1.0b11 became available with this fix included: http://java.net/jira/browse/GLASSFISH-11984. Otherwise we would have been completely screwed.

However, it didn't take many hours online, before we realised that something was horrible wrong. We have 6 virtual servers in addition to the default. We can't run with less than that. The problem is that all of our PhaseListeners are now executed one time per virtual server for a total of 7 times per request. And not just ours. PhaseListeners included in other projects, such as PrettyFaces, as well.

The problem has forced us to roll back to GF 2 and our 2 months old code once again.



 Comments   
Comment by Ed Burns [ 04/Feb/11 ]

The lack of a dev test bites us again.

Comment by Ed Burns [ 04/Feb/11 ]

Checking out the 2.1.0 branch now.

svn checkout https://svn.java.net/svn/mojarra~svn/branches/MOJARRA_2_1X_ROLLING mojarra-MOJARRA_2_1X_ROLLING

Sheetal, make sure you do the same.

Comment by Ed Burns [ 04/Feb/11 ]

Thankfully, Sheetal's patch for JAVASERVERFACES-1907 looks pretty good. I'm making a couple of small changes to ease the process of iteratively developing a reproducer for this issue (15809) and I'll attach that as a patch to 1907.

Comment by Ed Burns [ 04/Feb/11 ]

I'm going to attempt a workaround along the following lines. Provide a lifecyclefactory that decorates the original one and ensures there is one instance of each kind of lifecycle type per ServletContext.

Comment by Ed Burns [ 05/Feb/11 ]

Still getting the kinks worked out of JAVASERVERFACES-1907, working around little league practices.

Comment by Ed Burns [ 07/Feb/11 ]

After fixing JAVASERVERFACES-1907, I have a solid, automatable, reproducer for this issue.

container.name=glassfishV3.1_no_cluster

ant container.start
ant -Dinstance.numbers=1,2,3,4,5,6 create.virtual.servers
cd jsf-ri/systest-per-webapp
ant -Dcreate-virtual-servers=false -Dinstance.numbers=1,2,3,4,5,6 -Dapplication=replace-lifecycle install-virtual-server
ant -Dcreate-virtual-servers=false -Dinstance.numbers=1,2,3,4,5,6 -Dapplication=replace-lifecycle test-virtual-server
This shows the phaseListener getting called 6 times.

The workaround, which I will produce now, is to provide a custom LifecycleFactory instance that correctly handles the virtual server case.

Comment by Ed Burns [ 07/Feb/11 ]

I will write up the workaround and post it in the bug report.

Comment by Ed Burns [ 08/Feb/11 ]

Workaround description in plain text.

Comment by Ed Burns [ 17/Feb/11 ]

Snapshot, in progress.

Comment by Ed Burns [ 22/Feb/11 ]

snapshot. ClusterTest fails:

Running com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase
Testsuite: com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 3.38 sec
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 3.38 sec

Testcase: testSimpleObject took 3.103 sec
FAILED
null
junit.framework.AssertionFailedError
at com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase.assertSimpleObjectOutput(ClusterNoAgressiveSessionDirtyingTestCase.java:115)
at com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase.testSimpleObject(ClusterNoAgressiveSessionDirtyingTestCase.java:84)
at com.sun.faces.htmlunit.AbstractTestCase.runTest(AbstractTestCase.java:628)

About to stop container.

Comment by Ed Burns [ 22/Feb/11 ]

Small but fundamental change to FactoryFinder http://java.net/jira/browse/GLASSFISH-15809

The root cause of our virtual server woes is an invalid assumption
FactoryFinder has made since its first commit. The assumption. There
is a 1:1 mapping between ServletContext and web-app ClassLoader. This
assumption is not valid in the case of virtual servers. In a deployment
with N virtual servers, there are N ServletContexts for each web-app
ClassLoader. According to Shing-wai, this is not a bug, and I agree
with him.

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/FactoryFinder.java

  • Instead of having the FactoryManagerCache use ClassLoader alone as the
    key for the FactoryManager instances, use a new class,
    FactoryManagerCacheKey that combines the ClassLoader with the
    ServletContext instance. I had to be careful to handle the case when
    FacesContext.getCurrentInstance() returns null.

M jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java

  • When an app is undeployed, release its factories, which will cause
    them to be removed from the FactoryManagerCache.

M jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.javaM jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java
M jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java
M jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java
M jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java
M jsf-ri/build.xml

  • add deploy target

M jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java
M jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java

  • test changes to verify 15809 is fixed.

M lib/jsf-extensions-test-time.jar

  • Fix a bug in MockFacesContext that doesn't actually release the threadlocal.

SECTION: Diffs
----------------------------
Index: jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java
===================================================================
— jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java (revision 8870)
+++ jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java (working copy)
@@ -117,16 +117,16 @@
request.setAttribute("reqScopeName", "reqScopeValue");
response = new MockHttpServletResponse();

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java
    ===================================================================
      • jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java (revision 8870)
        +++ jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java (working copy)
        @@ -164,18 +164,18 @@
        request.setAttribute("reqScopeName", "reqScopeValue");
        response = new MockHttpServletResponse();

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ Map map = new HashMap();
+ externalContext.setRequestParameterMap(map);
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • Map map = new HashMap();
  • externalContext.setRequestParameterMap(map);
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java
    ===================================================================
      • jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java (revision 8870)
        +++ jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java (working copy)
        @@ -124,16 +124,16 @@
        request.setAttribute("reqScopeName", "reqScopeValue");
        response = new MockHttpServletResponse();

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java
    ===================================================================
      • jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java (revision 8870)
        +++ jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java (working copy)
        @@ -142,16 +142,16 @@
        pageContext.initialize(servlet, request, response, null,
        true, 1024, true);

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ externalContext.setRequestParameterMap(new HashMap());
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • externalContext.setRequestParameterMap(new HashMap());
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/main/java/javax/faces/FactoryFinder.java
    ===================================================================
      • jsf-api/src/main/java/javax/faces/FactoryFinder.java (revision 8870)
        +++ jsf-api/src/main/java/javax/faces/FactoryFinder.java (working copy)
        @@ -67,6 +67,8 @@
        import java.lang.reflect.Constructor;
        import java.net.URL;
        import java.net.URLConnection;
        +import java.util.Set;
        +import javax.faces.context.FacesContext;

/**
@@ -680,8 +682,8 @@
*/
private static final class FactoryManagerCache {

  • private ConcurrentMap<ClassLoader,Future<FactoryManager>> applicationMap =
  • new ConcurrentHashMap<ClassLoader, Future<FactoryManager>>();
    + private ConcurrentMap<FactoryManagerCacheKey,Future<FactoryManager>> applicationMap =
    + new ConcurrentHashMap<FactoryManagerCacheKey, Future<FactoryManager>>();

// ------------------------------------------------------ Public Methods
@@ -689,8 +691,10 @@

private FactoryManager getApplicationFactoryManager(ClassLoader cl) {

+ FactoryManagerCacheKey key = new FactoryManagerCacheKey(cl, applicationMap);
+
while (true) {

  • Future<FactoryManager> factories = applicationMap.get(cl);
    + Future<FactoryManager> factories = applicationMap.get(key);
    if (factories == null) {
    Callable<FactoryManager> callable =
    new Callable<FactoryManager>() {
    @@ -702,7 +706,7 @@

FutureTask<FactoryManager> ft =
new FutureTask<FactoryManager>(callable);

  • factories = applicationMap.putIfAbsent(cl, ft);
    + factories = applicationMap.putIfAbsent(key, ft);
    if (factories == null) { factories = ft; ft.run(); @@ -717,14 +721,14 @@ ce.toString(), ce); }
  • applicationMap.remove(cl);
    + applicationMap.remove(key);
    } catch (InterruptedException ie) {
    if (LOGGER.isLoggable(Level.FINEST)) { LOGGER.log(Level.FINEST, ie.toString(), ie); }
  • applicationMap.remove(cl);
    + applicationMap.remove(key);
    } catch (ExecutionException ee) { throw new FacesException(ee); }

    @@ -735,14 +739,89 @@

public void removeApplicationFactoryManager(ClassLoader cl)

{ + FactoryManagerCacheKey key = new FactoryManagerCacheKey(cl, applicationMap); - applicationMap.remove(cl); + applicationMap.remove(key); }

} // END FactoryCache

+ private static final class FactoryManagerCacheKey {
+ private ClassLoader cl;
+ private Object context;

+ private static final String KEY = FactoryFinder.class.getName() + "." ++ FactoryManagerCacheKey.class.getSimpleName();
+
+ public FactoryManagerCacheKey(ClassLoader cl,
+ Map<FactoryManagerCacheKey,Future<FactoryManager>> factoryMap) {
+ this.cl = cl;
+ FacesContext facesContext = FacesContext.getCurrentInstance();
+ if (null != facesContext) {
+ Map<String, Object> appMap = facesContext.getExternalContext().getApplicationMap();
+ Object val = appMap.get(KEY);
+ if (null == val)

{ + context = new Long(System.currentTimeMillis()); + appMap.put(KEY, context); + }

else

{ + context = val; + }

+ } else {
+ // We don't have a FacesContext.
+ // Our only recourse is to inspect the keys of the
+ // factoryMap and see if any of them has a classloader
+ // equal to our argument cl.
+ Set<FactoryManagerCacheKey> keys = factoryMap.keySet();
+ FactoryManagerCacheKey match = null;
+ for (FactoryManagerCacheKey cur : keys) {
+ if (this.cl.equals(cur.cl)) {
+ match = cur;
+ if (null != match)

{ + LOGGER.log(Level.WARNING, "Multiple JSF Applications found on same ClassLoader. Unable to safely determine which FactoryManager instance to use. Defaulting to first match."); + }

+ }
+ }
+ if (null != match)

{ + this.context = match.context; + }

+ }
+ }
+
+ private FactoryManagerCacheKey() {}
+
+ @Override
+ public boolean equals(Object obj) {
+ if (obj == null)

{ + return false; + }
+ if (getClass() != obj.getClass()) { + return false; + }

+ final FactoryManagerCacheKey other = (FactoryManagerCacheKey) obj;
+ if (this.cl != other.cl && (this.cl == null || !this.cl.equals(other.cl)))

{ + return false; + }
+ if (this.context != other.context && (this.context == null || !this.context.equals(other.context))) { + return false; + }

+ return true;
+ }
+
+ @Override
+ public int hashCode()

{ + int hash = 7; + hash = 97 * hash + (this.cl != null ? this.cl.hashCode() : 0); + hash = 97 * hash + (this.context != null ? this.context.hashCode() : 0); + return hash; + }

+
+
+
+
+ }
+
+
/**

  • Maintains the factories for a single web application.
    */
    Index: jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java
    ===================================================================
      • jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java (revision 8870)
        +++ jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java (working copy)
        @@ -235,7 +235,9 @@

// invoke the FactoryConfigProcessor
FactoryConfigProcessor fcp = new FactoryConfigProcessor(false);
+ InitFacesContext initContext = new InitFacesContext(sc);
fcp.process(sc, new DocumentInfo[]

{new DocumentInfo(d, null)});
+ initContext.release();

// now get an FacesContext instance from the Factory and ensure
// no injection occured.
@@ -264,7 +266,9 @@
// process the document. This should cause the the InjectionFacesContextFactory
// to be put into play since there is more than one FacesContextFactory // being configured
+ initContext = new InitFacesContext(sc);
fcp.process(sc, new DocumentInfo[]{new DocumentInfo(d, null)}

);
+ initContext.release();

// get the FacesContextFactory instance. The top-level factory should
// be the InjectionFacesContextFactory.
Index: jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
===================================================================
— jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java (revision 8870)
+++ jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java (working copy)
@@ -348,6 +348,7 @@
ApplicationAssociate.setCurrentInstance(null);
// Release the initialization mark on this web application
ConfigManager.getInstance().destory(context);
+ FactoryFinder.releaseFactories();
if (initContext != null)

{ initContext.release(); }

Index: jsf-ri/build.xml
===================================================================
— jsf-ri/build.xml (revision 8870)
+++ jsf-ri/build.xml (working copy)
@@ -700,7 +700,7 @@

<target name="passthru">

  • <ant antfile="build-tests.xml" target="execute.cactus.tests"
    + <ant antfile="build-tests.xml" target="passthru"
    inheritAll="true">
    <property name="force.no.cluster" value="true" />
    </ant>
    @@ -715,6 +715,14 @@

</target>

+ <target name="deploy">
+ <ant antfile="build-tests.xml" target="deploy"
+ inheritAll="true">
+ <property name="force.no.cluster" value="true" />
+ </ant>
+
+ </target>
+
<target name="prepare.cactus.webapp">
<ant antfile="build-tests.xml" target="prepare.test.webapp"/>
</target>
Index: jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java
===================================================================
— jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java (revision 8870)
+++ jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java (working copy)
@@ -43,6 +43,7 @@
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
+import java.util.Map;

public class SimplePhaseListener implements PhaseListener {

@@ -57,8 +58,12 @@

public void beforePhase(PhaseEvent event)

{ - event.getFacesContext().getExternalContext().getRequestMap().put("beforePhase", - "beforePhase"); + Map<String, Object> requestMap = + event.getFacesContext().getExternalContext().getRequestMap(); + String message = requestMap.containsKey("beforePhase") ? + requestMap.get("beforePhase").toString() : ""; + requestMap.put("beforePhase", + message + " beforePhase"); event.getFacesContext().getExternalContext().getRequestMap().put("lifecycleImpl", event.getSource()); }

Index: jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java
===================================================================
— jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java (revision 8870)
+++ jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java (working copy)
@@ -128,7 +128,10 @@

public void testReplaceLifecycle() throws Exception

{ HtmlPage page = getPage("/faces/test.jsp"); - assertTrue(-1 != page.asText().indexOf("beforePhase")); + String pageText = page.asText(); + assertTrue(-1 != pageText.indexOf("beforePhase")); + // Ensure the phaseListener is only called once. + assertTrue(!pageText.matches("(?s).*beforePhase.*beforePhase.*")); }

Index: lib/jsf-extensions-test-time.jar
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream

Comment by Jason Lee [ 23/Feb/11 ]

The changes look good to me.

r=jdlee

Comment by Ed Burns [ 23/Feb/11 ]

Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Sending jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java
Sending jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java
Sending jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java
Sending jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java
Sending jsf-ri/build.xml
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
Sending jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java
Sending jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java
Sending jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java
Sending lib/jsf-extensions-test-time.jar
Transmitting file data ...........
Committed revision 8871.

Comment by Ed Burns [ 23/Feb/11 ]

add jsf_2_1_1 to status whiteboard

Comment by tedgoddard [ 22/Mar/11 ]

The following WARNING is seen when visiting the first page in an application running on Tomcat:

Mar 22, 2011 4:35:49 PM javax.faces.FactoryFinder$FactoryManagerCacheKey <init>
WARNING: Multiple JSF Applications found on same ClassLoader.  Unable to safely determine which FactoryManager instance to use. Defaulting to first match.

It has no functional impact.

Comment by Scott Fordin [ 24/Mar/11 ]

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

Comment by Ed Burns [ 08/Apr/11 ]

Integrated into GlassFish 3.1.1

Comment by Scott Fordin [ 12/May/11 ]

Still need a more concise workaround.

Comment by Scott Fordin [ 17/May/11 ]

Added issue to 3.1 Known Issues section of 3.1-3.1.1 Release Notes. In the absence of a more concise workaround, I linked to the i_gf_15809-workaround.txt file that is attached to this issue.

Comment by bjornstenfeldt [ 26/Sep/11 ]

I'm finding it rather frustrating that I'm now getting around 1000 lines of "Multiple JSF Applications found on same ClassLoader. Unable to safely determine which FactoryManager instance to use. Defaulting to first match." in my log, every single second. Maybe a context-param in web.xml to disable this warning?

Comment by Ed Burns [ 26/Sep/11 ]

Hello Björn,

I am sincerely sorry for your frustration.

Is it acceptable to request that you modify your logging configuration, as described in <http://wikis.sun.com/display/GlassFish/JavaServerFacesRI#JavaServerFacesRI-HowcanIturnonlogging%3F> to prevent that logging message from being displayed?

Specifically, modify your logging.properties like this:

— logging.properties 2011-07-19 21:42:46.000000000 -0400
+++ logging_GLASSFISH-15809.properties 2011-09-26 11:40:23.000000000 -0400
@@ -113,3 +113,4 @@
javax.enterprise.system.ssl.security.level=INFO
ShoalLogger.level=CONFIG
org.eclipse.persistence.session.level=INFO
+javax.faces.level=INFO

Does that help?

Comment by bjornstenfeldt [ 27/Sep/11 ]

It will definitely fix it (javax.faces.level=SEVERE), but I worry that it might disables a lot of other information or warnings too, which is why I've been hesitating to use this method.

Comment by Ed Burns [ 27/Sep/11 ]

I can assure you that even though a logger such as javax.faces seems very "low level", there are very few log messages controlled by that logger. The vast majority of JSF related log messages are in the javax.enterprise.resource.webcontainer.jsf and sub loggers.

Comment by bjornstenfeldt [ 28/Sep/11 ]

Alright, I'll give it a chance.





[GLASSFISH-15775] Remote EJBs fail with ClassCastException in embeddable Glassfish Created: 31/Jan/11  Updated: 27/Sep/13  Resolved: 30/May/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_b39
Fix Version/s: 3.1.1_b07 , 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-15763] [UB][regression] jpaRLCreateEMF failure on sybase Created: 31/Jan/11  Updated: 02/Dec/11  Resolved: 13/Apr/11

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

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

Solaris and Linux


Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

jpaRLCreateEMF failure on sybase
glassfisg-3.1-b39.zip

StandardWrapperValve[JpaServlet]:
PWC1406: Servlet.service() for servlet JpaServlet threw exception javax.persistence.PersistenceException:
Exception [EclipseLink-7197] (Eclipse Persistence Services - 2.2.0.v20110114-r8831):
org.eclipse.persistence.exceptions.ValidationException Exception Description:
Null or zero primary key encountered in unit of work clone [[JpaBean id=0, name=JpaBean]], primary key [0].
Set descriptors IdValidation or
the "eclipselink.id-validation" property. at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:747)

The test passed on derby with v3.1 b39.
The test passed on sybassdd with b3.0 b64.



 Comments   
Comment by sherryshen [ 31/Jan/11 ]

To reproduce the failure:
set env with referece of
http://agni-1.us.oracle.com/JSPWiki/Wiki.jsp?page=V31CoreInstruction
where db info is in workspace
appserver-sqe/build-config/sybase_datadirect.properties
To run test,
cvs co appserver-sqe/bootstrap.xml
cd $SPS_HOME
ant -f bootstrap.xml co-ejb
ant start-domain
ant sybase-setup
cd pe/ejb/ejb30/war/jpaRLCreateEMF
ant sybasedd all

The clinet output shows:

[java] WS HOME appserver-sqe
[java] url=http://localhost:8080/RLCreateEMF/index.jsp
[java] url=http://localhost:8080/RLCreateEMF/jpa
[java] Unexpected return code: 500
.....
[java] -----------------------------------------
[java] - EJB3-RLCreateEMF-WAR-J2DB:jsp: PASS -
[java] - EJB3-RLCreateEMF-WAR-J2DB:servlet: FAIL -

server.log with FINE EL is saved in
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build39/dbtest/server.log.fine.jpaRLCreateEMF
which gives sybase info.
[#|2011-01-31T10:25:54.468-0800|INFO|glassfish3.1|
javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=104;_ThreadName=Thread-1;|
[EL Config]: 2011-01-31 10:25:54.467-ServerSession(32895865)-Connection(22292204)
--Thread(Thread[http-thread-pool-8080(4),5,grizzly-kernel])
--Connected: jdbc:datadirect:sybase://jsepc11.east.sun.com:5000;CATALOGOPTIONS=2;CONNECTIONRETRYDELAY=1;BULKLOADBATCHSIZE=1000;DATABASENAME=;MAXPOOLEDSTATEMENTS=0;PROGRAMID=0000016a;TRUSTSTOREPASSWORD=;VALIDATESERVERCERTIFICATE=true;CODEPAGEOVERRIDE=;CONNECTIONRETRYCOUNT=5;ENABLEBULKLOAD=false;BATCHPERFORMANCEWORKAROUND=false;INITIALIZATIONSTRING=;FAILOVERPRECONNECT=false;WORKSTATIONID=;RESULTSETMETADATAOPTIONS=0;CLIENTUSER=;QUERYTIMEOUT=0;FAILOVERGRANULARITY=nonAtomic;HOSTNAMEINCERTIFICATE=;APPLICATIONNAME=;JAVADOUBLETOSTRING=false;LOADLIBRARYPATH=;IMPORTSTATEMENTPOOL=;ALTERNATESERVERS=;ERRORBEHAVIOR=Exception;ENCRYPTIONMETHOD=NoEncryption;ACCOUNTINGINFO=;CONVERTNULL=1;TRUSTSTORE=;JDBCBEHAVIOR=1;FAILOVERMODE=connect;AUTHENTICATIONMETHOD=UserIdPassword;LOGINTIMEOUT=0;LONGDATACACHESIZE=2048;LOADBALANCING=false;PREPAREMETHOD=storedProcIfParam;TRANSACTIONMODE=explicit;USEALTERNATEPRODUCTINFO=false;WORKAROUNDS=0;INSENSITIVERESULTSETBUFFERSIZE=2048;PACKETSIZE=0;CLIENTHOSTNAME=;SERVICEPRINCIPALNAME=;SELECTMETHOD=direct
User: dbo
Database: SQL Server Version: Adaptive Server Enterprise/15.5/EBF 17218 SMP/P/NT (IX86)/Windows 2003/ase155/2391/32-bit/OPT/Mon Nov 09 14:18:14 2009
Driver: Sybase Version: 4.2.0.017715 (F044224.U015808)

#]
Comment by sherryshen [ 01/Feb/11 ]

I used dd driver from sqe v3.0 fcs branch.
I adjusted sqe trunk db properties according to sqe branch

http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build39/dbtest/sybase_datadirect.properties.diff

! db.driver=com.sun.sql.jdbc.sybase.SybaseDriver
! db.class=com.sun.sql.jdbcx.sybase.SybaseDataSource
! db.xaclass=com.sun.sql.jdbcx.sybase.SybaseDataSource
! db.url=jdbc:sun:sybase://$

{db.host}

:$

{db.port}

;SID=$

{db.sid}

;PrepareMethod=direct

Then, I ran tests with sqe trunk and v3.1 build 39, and tests passed.
server.log gives driver version.
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build39/dbtest/server.log.sybasedd.v30driver
[#|2011-02-01T10:32:20.730-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|
_ThreadID=99;_ThreadName=Thread-1;|[EL Config]: 2011-02-01 10:32:20.73-ServerSession(3243394)Connection(31389825)-Thread(Thread[http-thread-pool-8080(1),5,
grizzly-kernel])--Connected: jdbc:sun:sybase://jsepc11.east.sun.com:5000;CATALOGOPTIONS=2;CONNECTIONRETRYDELAY=1;BULKLOADBATCHSIZE=1000;DATABASENAME=;MAXPOOLEDSTATEMENTS=0;PROGRAMID=0000016a;TRUSTSTOREPASSWORD=;VALIDATESERVERCERTIFICATE=true;CODEPAGEOVERRIDE=;CONNECTIONRETRYCOUNT=5;ENABLEBULKLOAD=false;INITIALIZATIONSTRING=;FAILOVERPRECONNECT=false;WORKSTATIONID=;RESULTSETMETADATAOPTIONS=0;CLIENTUSER=;QUERYTIMEOUT=0;FAILOVERGRANULARITY=nonAtomic;HOSTNAMEINCERTIFICATE=;CATALOGINCLUDESSYNONYMS=true;APPLICATIONNAME=;JAVADOUBLETOSTRING=false;LOADLIBRARYPATH=;IMPORTSTATEMENTPOOL=;ALTERNATESERVERS=;ERRORBEHAVIOR=Exception;ENCRYPTIONMETHOD=NoEncryption;ACCOUNTINGINFO=;CONVERTNULL=1;TRUSTSTORE=;JDBCBEHAVIOR=1;FAILOVERMODE=connect;AUTHENTICATIONMETHOD=UserIdPassword;LOGINTIMEOUT=0;LONGDATACACHESIZE=2048;PREPAREMETHOD=direct;LOADBALANCING=false;TRANSACTIONMODE=explicit;USEALTERNATEPRODUCTINFO=false;SID=cts5;WORKAROUNDS=0;INSENSITIVERESULTSETBUFFERSIZE=2048;PACKETSIZE=0;CLIENTHOSTNAME=;SERVICEPRINCIPALNAME=;SELECT METHOD=direct
User: dbo
Database: Adaptive Server Enterprise Version: Adaptive Server Enterprise/15.5/EBF
17218 SMP/P/NT (IX86)/Windows 2003/ase155/2391/32-bit/OPT/Mon Nov 09 14:18:14 2009
Driver: Sybase Version: 4.0.016204 (040313.014801)

Comment by sherryshen [ 01/Feb/11 ]

Mitesh and I recalled that this is an old doc issue.
http://java.net/jira/browse/GLASSFISH-2431

Tests passed with new driver 4.2 and v3.1 b39 after
adjusting db properties.
RCS file: /m/jws/appserver-sqe/build-config/sybase_datadirect.properties,v

! db.url=jdbc:datadirect:sybase://$

{db.host}:${db.port}
— 9,15 ----
! db.url=jdbc:datadirect:sybase://${db.host}

:$

{db.port}

;PrepareMethod=direct

Comment by sherryshen [ 01/Feb/11 ]

Transfer this bug to docs.
Please verify if it is in RN.

Enclosed is the note from Mitesh
for reference.

When using Data direct driver with Basely, if you are trying to insert
an entity that uses GenerationType.IDENTITY, it will fail. This is
because Datadirect driver creates a stored procedure for every
parameterized prepared statement. Please set property
PrepareMethod=direct on the corresponding datasource to change this
behavior and workaround this issue.

Comment by Scott Fordin [ 13/Apr/11 ]

Added issue to 3.1 Release Notes.





[GLASSFISH-15724] Glassfish Installer does not update MQ config file (imqenv.conf) with values Created: 27/Jan/11  Updated: 07/Apr/11  Resolved: 03/Mar/11

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

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

All


Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, glassfish-3-1, install, messagequeue

 Description   

Glassfish Installer does not update MQ config file (imqenv.conf) with values (for example, JDK HOME dir). This would be useful when MQ is run independent of glassfish.

I think the earlier versions of glassfish installers updated this file with Jdk home and other values.

Appropriate workaround would be to update the imqenv.conf file (located under MQ_HOME/etc directory) manually.



 Comments   
Comment by scatari [ 27/Jan/11 ]

3.x installers haven't done this configuration required for MQ. Anyway this is too late to fix in 3.1, if its a requirement then we will address this in 3.2.

Comment by scatari [ 27/Jan/11 ]

Not sure if this is a possible release note candidate. If the MQ team feels that way, please do bring to "docs" team's attention.

Comment by mathim [ 03/Mar/11 ]

provide more info to doc team

Comment by Jill Sato [ 03/Mar/11 ]

Optionally for release notes (nice to have):
------------------------------------------

MQ executables will use the 'java' in the user's PATH.
The user can also specify another Java Runtime by setting
IMQ_DEFAULT_JAVAHOME in the imqenv.conf file.

On Unix (e.g.)
IMQ_DEFAULT_JAVAHOME=/usr/jdk/jdk1.6.0

On Windows (e.g.)
IMQ_DEFAULT_JAVAHOME=c:\path\to\jdk

Comment by Scott Fordin [ 03/Mar/11 ]

Issue added to 3.1 Release Notes.

Comment by Scott Fordin [ 24/Mar/11 ]

Added "3_1-release-note-added" tag.





[GLASSFISH-15721] "injection points in one bean deployment archive cannot be satisfied by a bean in a separate bean archive, even when they are from libraries in the same module (web archive)" Created: 27/Jan/11  Updated: 18/Jul/11  Resolved: 09/Jun/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1_b39
Fix Version/s: 3.1.1_b05

Type: Bug Priority: Critical
Reporter: stuartdouglas Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 20
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File weld-osgi-bundle.jar    
Issue Links:
Duplicate
duplicates GLASSFISH-15906 CDI resolver issues Resolved
is duplicated by GLASSFISH-15888 CDI not working well on Glassfish v3.... Resolved
is duplicated by GLASSFISH-15794 JAX-RS injection broken for library @... Resolved
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1_1-review

 Description   

The Bean Deployment Archive visibility graph does not correctly implement the spec.

Beans in WEB-INF/lib are made availible to beans in WEB-INF/classes, however the converse is not true (i.e. beans is WEB-INF/classes cannot be injected into WEB-INF/lib injection points), and beans in one jar in WEB-INF/lib cannot be injected into beans in a different jar in WEB-INF/lib.

According to the CDI and EE6 Platform spec both of these should work.

https://svn.dev.java.net/svn/glassfish-svn/trunk/v3/web/weld-integration/src/main/java/org/glassfish/weld/DeploymentImpl.java



 Comments   
Comment by mojavelinux [ 27/Jan/11 ]

Two tests have been prepared to demonstrate cases when beans within the same bean archive are not visible to each other.

https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/TypeVisibilityForExtensionInNonBeanArchiveTest.java
https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/TypeVisibilityWithinBeanArchiveTest.java

These tests can be run from the root of the Solder project as follows:

mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest
mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest

These tested use the new Arquillian GlassFish adapter created by Jason Porter and based on the GlassFish REST API.

Comment by Sivakumar Thyagarajan [ 01/Feb/11 ]

Investigation in progress. It appears to be an issue with the way Weld handles accessibility of cyclic references among BeanDeploymentArchives. I have requested the help of Weld engineering team to understand this better, and will update this issue.

Comment by Sivakumar Thyagarajan [ 02/Feb/11 ]

This issue occurs because of the way Weld handles cyclic references among BDAs. I have raised https://issues.jboss.org/browse/WELD-846 to track the Weld side change needed to fix this issue. We will integrate the next available release of Weld that provides a fix for this issue in the next update release of GlassFish 3.1.

Release note/Workaround:
Until then the application could be repackaged such that either:

  • Beans in WEB-INF/classes are not used/injected in classes bundled in WEB-INF/lib/*.jar
  • All Beans are available as part of WEB-INF/classes [ie collapse the bundled library in WEB-INF/lib/*.jar into WEB-INF/classes].
Comment by Sivakumar Thyagarajan [ 11/Feb/11 ]

FWIW, Weld has fixed the root issue https://github.com/stuartwdouglas/core/tree/WELD-846 in their trunk and this scenario would work again once we integrate the Weld 1.2.0.Beta distribution when it becomes available.

I also tried this scenario against a local build of Weld trunk(attached the weld-osgi-bundle.jar that I used at http://java.net/jira/secure/attachment/44919/weld-osgi-bundle.jar , place this under $INSTALL_ROOT/modules and restart the domain to reproduce this).

Comment by mimik789 [ 11/Feb/11 ]

I tested provided weld-osgi-bundle.jar in GF3 b_41 (web), and also in latest nightly build - as described in guidliness https://issues.jboss.org/browse/WELD-846 (in exception to that I have to remove content from arquillian.xml config file for jboss - without that test can't be executed, and that I need to replace test with integration-test).
ie:
1/
mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest

2/
mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest

first test (TypeVisibilityWithinBeanArchiveTest) passes OK

but second test (TypeVisibilityForExtensionInNonBeanArchiveTest) FAIL with:

org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [BeanClassToRegister] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.solder.test.compat.AnotherBeanClassToRegister.collaborator]. Possible dependencies [[Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default]]]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:139)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:162)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:385)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:371)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:394)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:190)
...

having same issue?

Comment by vostok [ 16/Feb/11 ]

I'm experiencing a lot of problems in 3.1 versions with my modular project using CDI. It works great (despite CDI memory leaks issues, manually fixed) with 3.0.1 but I cannot deploy it with 3.1 RCs!

Tags: 3_1-exclude 3_1-release-notes

^

----- Solving this bug is being excluded from 3.1 final???

Comment by eratzlaff [ 16/Feb/11 ]

It would be nice to have this bug fix for glassfish 3.1 release.

Comment by mimik789 [ 21/Feb/11 ]

You may be interested with this good news:
http://seamframework.org/Community/SeamFacesPersistenceServletCatchProduceNullPointerException#comment149620

for lazy guys and girls: I'm attaching fixed weld-core.jar (weld-osgi-bundle.jar) built from:
https://github.com/stuartwdouglas/core/tree/WELD-859

Comment by DiegoCoronel [ 10/Mar/11 ]

The jar attached does not resolved my problem. I deleted osgi-cache after change the jar and it does not worked.
My war classes cant inject my jar classes.

It works fine in glassfish 3.0.1 final.

In my specific case i have this scenary

myWebModule.war
– MyJarProject1.jar (depends:MyFramework, myWebModule.war)
– MyJarProject2.jar (depends:MyFramework, MyJarProject1, myWebModule.war)
– MyFramework.jar (depends:myWebModule.war)

where all jar modules depends on war because they inject EntityManager that is produced by war because it does not worked if jar produce EntityManager.

Comment by mojavelinux [ 21/Mar/11 ]

Here's an updated test case:

https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/visibility/VisibilityOfBeanInWebModuleFromBeanManagerInBeanLibraryTest.java

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Nazrul [ 21/Apr/11 ]

It would be useful to look into this issue for 3.1.1

Comment by vrcollins [ 05/May/11 ]

I am in the same boat as vostok. I am able to get everything working fine in glassfish 3.0.1. I am using glassfish 3.1 with build 43. I have replaced the weld-osgi-bundle.jar file with the one in this ticket. I am getting the same errors.

Comment by toomanyryans [ 10/May/11 ]

I think I've been running into this bug. Assume I have two .jars:

WEB-INF/lib/jarA
WEB-INF/lib/jarB

If jarB is dependent on jarA, is it possible they could get scanned in a different order depending on the system I'm deploying to? Specifically, embedded Glassfish on Windows vs normal Glassfish on Linux?

I noticed that Glassfish 3.1.1-b04 is using Weld 1.1.1.Final and it fixes my problem. The Weld issue mentioned here (WELD-846) was fixed for 1.1.1.Final, so I think this maybe resolved in Glassfish 3.1.1-b04+. It may be worth testing again if you're watching this issue.

Comment by Scott Fordin [ 17/May/11 ]

Added issue to 3.1 Known Issues section in 3.1-3.1.1 Release Notes.

Comment by scatari [ 24/May/11 ]

Fix expected by first week of June.

Comment by Sivakumar Thyagarajan [ 09/Jun/11 ]

This issue has been fixed since the integration of Weld 1.1.1.Final (that fixes root cause WELD-846) into GlassFish 3.1.1(b4+) and GlassFish trunk.

Through svn revision 47397, I have also added the following developer tests to cover this scenario
javaee-integration/cdi-servlet-3.0-annotation-with-web-inf-lib/

Comment by cbarragan [ 14/Jul/11 ]

As for Glassfish 3.1.1b11 I think the issue might not be solved, although my problem differs from the original issue.

I have an EAR with an ejb module and some jars in the lib directory.
A dependency in a class that resides in the lib directory cannot be satisfied. This dependency should be solved by a class in my ejb module, but it seems that the class in the ejb module is not visible to the class in the lib directory. Is this another issue? If so, is there an issue related to this problem?

Comment by Sivakumar Thyagarajan [ 18/Jul/11 ]

@cbarragan:

As per section 5.1 of the CDI 1.0 specification:
"In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."

In the scenario you had mentioned above: as the EJB module class is not required to be accessible to a jar in the lib directory, the bean class is not available for injection.





[GLASSFISH-15709] [UB]Accessing encoded URLS throws 403: Forbidden Created: 27/Jan/11  Updated: 07/Jul/11  Resolved: 07/Jul/11

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

Type: Bug Priority: Major
Reporter: Jothir Ganesan Assignee: Rebecca Parks
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008 + Oracle Webserver 7u9


Attachments: HTML File 15709.html     File number-app.war    
Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

When I deploy and access the attached app (with encoded URL in it) on Oracle webserver 7 in Windows 2008, there is a 403 returned.

Message seen in errorlog:

for host 10.133.185.48 trying to POST /number-app/TestServlet;jsessionid=397220419959d2534f99f2c71bd4:KsK-;jreplica=instance105;jsessionidversion=2f6e756d6265722d6170, uri-clean reports: CORE4393: malformed path: /number-app/TestServlet;jsessionid=397220419959d2534f99f2c71bd4:KsK-;jreplica=instance105;jsessionidversion=2f6e756d6265722d617070:0

Message from access log:

10.133.185.48 - - [26/Jan/2011:23:03:54 -0800] "GET /number-app/TestServlet HTTP/1.1" 200 500
10.133.185.48 - - [26/Jan/2011:23:03:54 -0800] "POST /number-app/TestServlet;jsessionid=6485c8ea4f94b014d8efd798e7f1:W6zw;jreplica=instance104;jsessionidversion=2f6e756d6265722d617070:0 HTTP/1.1" 403 142

Attached the app used in the test.



 Comments   
Comment by sonymanuel [ 27/Jan/11 ]

To reproduce the issue :

Disable cookies in the browser
Deploy the app to the cluster and export the lb config to web server instance.
Access http://<webserver host>:<webserver port>/number-app/TestServlet

Comment by kshitiz_saxena [ 27/Jan/11 ]

This request is rejected by web server itself and throws forbidden error. This has nothing to do with load-balancer plugin.

May be this is an issue with web server or some configuration issue. Will try to get some information from web server team.

Comment by kshitiz_saxena [ 01/Feb/11 ]

This issue is caused by web server fix for not allowing uri having ":" in its value. As a workaround, you need to change following entry in obj.conf :
Replace :
PathCheck fn="uri-clean"

With :
<Client type="~magnus-internal/lbplugin">
PathCheck fn="uri-clean"
</Client>

This will not call uri-clean for requests being serviced by GlassFish load-balancer plugin.

Please note this change is only needed for url-rewriting case.

Assigning to documentation team to capture it in load-balancer documentation and release note this issue.

Comment by Scott Fordin [ 11/Feb/11 ]

Looking at the comments here, is this really a load balancer issue? Or, to ask a different question, is this solely a Release Notes issue in the LB section, or does the topic need to be added to the HAAG?

Comment by Scott Fordin [ 17/Mar/11 ]

Second request: I still need more information to document this issue.

Comment by Scott Fordin [ 16/May/11 ]

Upon further examination, I believe this is only a Release Notes issue. I've added the issue to the 3.1-3.1.1 Release Notes, and removed the "need more info" tag.

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.

Comment by Paul Davies [ 07/Jul/11 ]

This issue affects the Release Notes, which is an unbundled document. Therefore, the fix for this issue is not related to any build. I have set the Fix Version to 3.1.1.

The attached file contains the fix. This fix will be published in the next library update.

Comment by Paul Davies [ 07/Jul/11 ]

According to the comments on this issue, the fix affects only the Release Notes. As the Release Notes have been updated to describe this issue, this issue is now fixed. The update is in the attached file and will be published in the next library update.





[GLASSFISH-15645] [UB][RM-HA] [to-be-release-noted] RM InOrder Delivery mode tests do not work correctly. Created: 20/Jan/11  Updated: 24/Mar/11  Resolved: 17/Mar/11

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

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

Issue Links:
Dependency
depends on GLASSFISH-15828 [Test Issue] On some GF-HA functional... Open
depends on WSIT-1521 HA RM in-order test clients do not wo... Open
Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

The following Issue needs to be release noted for GF 3.1:
http://java.net/jira/browse/WSIT-1521

This affects GF HA. Reliable Messaging, InOrder Delivery mode has not been tested with HA (not supported).



 Comments   
Comment by sonymanuel [ 24/Jan/11 ]

Changing to docs.

Comment by Scott Fordin [ 25/Feb/11 ]

Need more information to document in Release Notes.

Comment by varunrupela [ 01/Mar/11 ]

It needs to be release noted that GlassFish HA does not support Webservices that use Reliable Messaging in InOrder Delivery mode.

Do let us know if any specific information is required.

Comment by Scott Fordin [ 03/Mar/11 ]

Yes, please. 1) More detail about problem. 2) Any workarounds?

Comment by varunrupela [ 07/Mar/11 ]

What needs to be release noted is that "The Metro Reliable Messaging in InOrder Delivery mode has not been tested for High-Availability and thus is not a supported feature."

  • The feature may be working but has not been tested and hence not supported. Thus there isn't a need to mention workarounds.
Comment by Scott Fordin [ 17/Mar/11 ]

Added topic to Restrictions and Deprecated Functionality section of 3.1 Release Notes. I added it to this section rather than the Known Issues section because it seems to be more of a restriction than a bug, per se.

Comment by Scott Fordin [ 24/Mar/11 ]

Added "3_1-release-note-added" tag.





[GLASSFISH-15633] Admin Console: intermittent Blank Screen Created: 20/Jan/11  Updated: 29/Mar/13  Resolved: 29/Mar/13

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

Type: Bug Priority: Minor
Reporter: Harshad Vilekar Assignee: Jason Lee
Resolution: Cannot Reproduce Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File admin-console-blank-b37.jpg     JPEG File admin-gui-blank-help-screen.jpg    
Tags: 3_1-release-note-added, 3_1-release-notes, 3_1_1-review

 Description   

Admin GUI sometimes simply displays "blank screen". The bottom status bar of the browser window says "Done".

Workaround:

  • To refresh Help screen - Click on Admin Console Help button.
  • To refresh main browser window, click Shift - Reload.

This is seen (once in a while) on some screens - including Console Main Screen, Help Windows and sometimes "restart required" details screen.

I bumped into this again today. Screen shot for blank help window (b38) and blank main window (b37) attached.

I've seen this with OEL5 and Solaris 10 (Firefox 3.6.10). Sometimes, there is exception thrown in the server log (not sure if it's related). see below.

=========================
[#|2011-01-20T15:21:56.347-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=123;_ThreadName=Thread-1;|SEC1011: Security Service(s) Started Successfully|#]

[#|2011-01-20T15:21:57.971-0800|INFO|oracle-glassfish3.1|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=21;_ThreadName=Thread-52;|Initializing Mojarra 2.1.0 (FCS b10) for context ''|#]

[#|2011-01-20T15:21:58.073-0800|INFO|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=22;_ThreadName=admin-thread-pool-4848(5);|Listening to REST requests at context: /management/domain|#]

[#|2011-01-20T15:21:57.971-0800|INFO|oracle-glassfish3.1|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=21;_ThreadName=Thread-1;|Initializing Mojarra 2.1.0 (FCS b10) for context ''|#]

[#|2011-01-20T15:21:58.073-0800|INFO|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=22;_ThreadName=Thread-1;|Listening to REST requests at context: /management/domain|#]

[#|2011-01-20T15:22:00.782-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=123;_ThreadName=Thread-52;|WEB0671: Loading application [__admingui] at [/]|#]

[#|2011-01-20T15:22:00.784-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=123;_ThreadName=Thread-52;|CORE10010: Loading application __admingui done in 8,244 ms|#]

[#|2011-01-20T15:22:00.785-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=123;_ThreadName=Thread-52;|The Admin Console application is loaded.|#]

[#|2011-01-20T15:22:00.782-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=123;_ThreadName=Thread-1;|WEB0671: Loading application [__admingui] at [/]|#]

[#|2011-01-20T15:22:00.784-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=123;_ThreadName=Thread-1;|CORE10010: Loading application __admingui done in 8,244 ms|#]

[#|2011-01-20T15:22:00.785-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=123;_ThreadName=Thread-1;|The Admin Console application is loaded.|#]

[#|2011-01-20T15:22:03.788-0800|WARNING|oracle-glassfish3.1|org.apache.catalina.connector.Request|_ThreadID=22;_ThreadName=admin-thread-pool-4848(5);|PWC4011: Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called|#]

[#|2011-01-20T15:22:03.788-0800|WARNING|oracle-glassfish3.1|org.apache.catalina.connector.Request|_ThreadID=22;_ThreadName=Thread-1;|PWC4011: Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called|#]

[#|2011-01-20T15:22:13.379-0800|INFO|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=22;_ThreadName=admin-thread-pool-4848(5);|Admin Console: Initializing Session Attributes...|#]

[#|2011-01-20T15:22:13.379-0800|INFO|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=22;_ThreadName=Thread-1;|Admin Console: Initializing Session Attributes...|#]

[#|2011-01-20T15:22:14.814-0800|WARNING|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=23;_ThreadName=Thread-61;|Cannot create update center Image for /export/home/glassfish3; Update Center functionality will not be available in Admin Console|#]

[#|2011-01-20T15:22:14.814-0800|WARNING|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=23;_ThreadName=Thread-1;|Cannot create update center Image for /export/home/glassfish3; Update Center functionality will not be available in Admin Console|#]

[#|2011-01-20T15:32:05.647-0800|WARNING|oracle-glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=86;_ThreadName=admin-thread-pool-4848(2);|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.reset(ResponseFacade.java:369)
at com.sun.faces.context.ExternalContextImpl.responseReset(ExternalContextImpl.java:821)
at com.sun.faces.context.ExceptionHandlerImpl.throwIt(ExceptionHandlerImpl.java:251)
at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:141)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:396)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2011-01-20T15:32:05.647-0800|WARNING|oracle-glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=86;_ThreadName=Thread-1;|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.reset(ResponseFacade.java:369)
at com.sun.faces.context.ExternalContextImpl.responseReset(ExternalContextImpl.java:821)
at com.sun.faces.context.ExceptionHandlerImpl.throwIt(ExceptionHandlerImpl.java:251)
at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:141)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:396)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

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

Please note that this is an intermittent issue. Not always reproducible.

Please document this - if root cause is not identified in time for 3.1 release.



 Comments   
Comment by Harshad Vilekar [ 20/Jan/11 ]

Update: Steps to duplicate the exception:
press the "Help" button more than once with a short pause.

Comment by Chris Kasso [ 20/Jan/11 ]

This is not a P3 issue. It is being downgraded to P4.

If Anissa finds a simple fix we can still consider it for 3.1.

If a fix can not be found then we can cover this issue in the Release Notes.

If the blank screen can be reproduces in more mainstream scenarios please upgrade the bug to a higher priority.

Comment by Harshad Vilekar [ 26/Jan/11 ]

Looks like Blank screen and IllegalStateException are two separate issues.

Created http://java.net/jira/browse/GLASSFISH-15692 for tracking:
"PWC1406: Servlet.service() for servlet FacesServlet threw exception java.lang.IllegalStateException"

Comment by shaline [ 26/Jan/11 ]

I see this blank screen as well , and cannot consistently reproduce. While working in GUI, if we restart the domain in CLI, and click reload button in the browser, sometimes I see this blank screen, and always have to do "shift + reload" to launch the Console.
But I do not see any Exceptions in the server.log

Comment by lidiam [ 16/Feb/11 ]

I consistently see this issue in Firefox on Windows XP after changing Glassfish version, e.g. removing old one and unzipping new distribution. Have to select clearing cache, cookies, form and search history and active logins in order to get the GUI displayed (and sometimes repeatedly). Recently noticed that in Firefox the default "Time range to clear" is "Last hour". Changed to "Today" and I can at least get the Console displayed again.

Comment by Scott Fordin [ 13/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Nazrul [ 20/Apr/11 ]

Are we able to reproduce this? If yes, we should look into it for 3.1.1. Getting blank screens is not a good user experience.

Comment by Nazrul [ 21/Apr/11 ]

Few people raised this issue today. It would be good to take a look a this issue during 3.1.1

Comment by Anissa Lam [ 21/Apr/11 ]

Getting help from Jason

Comment by Jason Lee [ 22/Apr/11 ]

I am unable to reproduce this scenario. Are there consistent/reliable steps to reproduce?

Comment by guyost [ 22/Aug/11 ]

Hello,
I don't know if have this problem or not.
I'm using Glassfish 3.1.1 on Windows Server 2008 32bit.

I started getting this problem few days ago :

  • I connect to www.kyuubibarre.com:4848 to access the console, immediatly after starting the domain
  • Since it's the first time, the messages shows something like thats "Console is loading..."
  • After few seconds, the message shows "Console is loaded, if this page doesn't reload, please reload manually" (not sure of the exact text... but I think you know what I mean)

Then nothing happens. So I reload the page, and I get a blank page.
I tried to clear the cache of my browser, I even change browser, and even computer...
Nothing changes.

I tried to access the login page manually : www.kyuubibarre.com:4848/login.jsf ==> blank page again.

I restarted the domain, the same scenario happens.

In the server log file, the last line I have is :
The Admin Console application is loaded
And then, nothing.

The application deployed on this server are correctly working.

I have different domain instances, all applications on all domains are working well, but all admin consoles show a blank page.

If you need more details, just ask me. I will provide what you need to solve it.

Comment by kpasgma [ 20/Mar/12 ]

I am having the same issue as guyost. The only way I can fix it is to restart the complete server.

Comment by thomask [ 23/May/12 ]

I was having the same issue; however, I am unsure whether this will help as it was not on an install nor was it intermittant.

I NEVER had this problem until I updated my secutiry settings in my domain's server settings node. I am new to GlassFish and may have just used it incorrectly. The issue I think was due to me setting 'Default Principa'l which I had set to "admin", I had also created some user groups and users with the same name as those groups under the file realm. When I removed the settings the problem disappeared.

Though, I cannot recreate the problem but have noticed that when I orignally created groups and users that users were automatically being assigned to all groups? If this is useless delete me!

Comment by ssemmandarobert [ 28/Feb/13 ]

Hello, I am facing this issue and i have no work around, even after i reload in the page in the browser same issue. How did you solve it ? Keep in mind i have not updated or installed any new glassfish server, all i did was to restart the domain via command line when the window admin console was still logged in. I have cleared my browser cache and history . Thanx

Comment by Anissa Lam [ 01/Mar/13 ]

Which GlassFish version are you using ? This bug was filed against 3.1, and I haven't seen this for a long time.
If you are using 3.1, can up upgrade to later release ?
which browser are you using ? can you try another browser ?

Comment by Jason Lee [ 29/Mar/13 ]

We have been unable to reproduce this issue. If this issue recurs, please reopen the bug with steps to reproduce.





[GLASSFISH-15571] Create Resource Adapter Config is throwing an exception if jms is already started Created: 14/Jan/11  Updated: 19/Sep/14

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

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

Tags: 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_2-exclude

 Description   

Start the JMS. In GUI, try to create a resource adapter config using jmsra and thread pool as "http-thread-pool".
It is throwing an exception in the server log.

Steps to reproduce the issue :

1)./bin/asadmin jms-ping
2) In GUI, create a resource adapter config with resource adapter name as jmsra and thread pool as http-thread-pool. Then, it throws an exception.

Exception in server log :

[#|2011-01-14T14:55:14.369+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.work|_ThreadID=333;_ThreadName=Thread-2;|Thread-pool [ http-thread-pool ] not found|#]

[#|2011-01-14T14:55:14.370+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.work|_ThreadID=333;_ThreadName=Thread-2;|An error occurred during instantiation of the work manager for resource-adapter [ jmsra ]
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException
at com.sun.enterprise.connectors.work.CommonWorkManager.<init>(CommonWorkManager.java:118)
at com.sun.enterprise.connectors.work.WorkManagerFactory.createWorkManager(WorkManagerFactory.java:125)
at com.sun.enterprise.connectors.work.WorkManagerFactory.getWorkManagerProxy(WorkManagerFactory.java:196)
at com.sun.enterprise.connectors.ConnectorRuntime.getWorkManagerProxy(ConnectorRuntime.java:1129)
at com.sun.enterprise.connectors.BootstrapContextImpl.initializeWorkManager(BootstrapContextImpl.java:161)
at com.sun.enterprise.connectors.BootstrapContextImpl.<init>(BootstrapContextImpl.java:103)
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundResourceAdapter.java:126)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.init(ActiveInboundResourceAdapterImpl.java:90)
at com.sun.enterprise.connectors.ActiveRAFactory.instantiateActiveResourceAdapter(ActiveRAFactory.java:135)
at com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:106)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:211)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:345)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.reCreateActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:541)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.addResourceAdapterConfig(ResourceAdapterAdminServiceImpl.java:494)
at com.sun.enterprise.connectors.ConnectorRuntime.addResourceAdapterConfig(ConnectorRuntime.java:1195)
at com.sun.enterprise.resource.deployer.ResourceAdapterConfigDeployer.deployResource(ResourceAdapterConfigDeployer.java:86)
at com.sun.enterprise.resource.deployer.ResourceAdapterConfigDeployer.redeployResource(ResourceAdapterConfigDeployer.java:117)
at org.glassfish.javaee.services.ResourceManager$PropertyChangeHandler.handleChangeEvent(ResourceManager.java:378)
at org.glassfish.javaee.services.ResourceManager$PropertyChangeHandler.changed(ResourceManager.java:328)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:329)
at org.glassfish.javaee.services.ResourceManager.changed(ResourceManager.java:275)
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.corba.ee.spi.orbutil.threadpool.NoSuchThreadPoolException
at org.glassfish.enterprise.iiop.util.S1ASThreadPoolManager.getThreadPool(S1ASThreadPoolManager.java:217)
at com.sun.enterprise.connectors.work.CommonWorkManager.<init>(CommonWorkManager.java:111)
... 29 more



 Comments   
Comment by Jagadish [ 14/Jan/11 ]

ThreadPoolManager.getThreadPool() seems to throw the exception.

ThreadPoolManager only has "thread-pool-1" when the method "getThreadPool" is called.

Transferring to Ken for further investigation.

Steps to reproduce :

asadmin jms-ping
asadmin create-resource-adapter-config --threadpoolid http-thread-pool jmsra

will show the reported exception in server.log

Comment by Ken Cavanaugh [ 14/Jan/11 ]

It looks like the issue may be in S1ASThreadPoolManager (which is in orb/orb-connector).
This class has a static initializer that reads the ThreadPool config data from
the iiop service and network listener config beans. But there is no way to
add a new ORB threadpool after the initial configuration is read.

It is also not clear to me from the test case how you expect "http-thread-pool" to be created.
Is this an ORB threadpool or a Grizzly threadpool? GF 3.1 has TWO distinct threadpool implementations currently.
Which one does create-resource-adapter-config expect to use?
How does the http-thread-pool get created if it does not already exist?

I am excluding this from 3.1 because I cannot investigate it or fix it before
the RC1 deadline. It is not even clear if this is something that should be fixed at this point.

Comment by Jagadish [ 17/Jan/11 ]

Hi Ken,

> It looks like the issue may be in S1ASThreadPoolManager (which is in orb/orb-connector).
> This class has a static initializer that reads the ThreadPool config data from
> the iiop service and network listener config beans. But there is no way to
> add a new ORB threadpool after the initial configuration is read.

Yes, whenever we create a thread-pool, we restart the server.

> It is also not clear to me from the test case how you expect "http-thread-pool" to be created.
> Is this an ORB threadpool or a Grizzly threadpool?
Connector container uses ORB thread pool (work) API and hence its always ORB thread pool.
> GF 3.1 has TWO distinct threadpool implementations currently.
> Which one does create-resource-adapter-config expect to use?
ORB thread pool.
In GlassFish 2.x and before, a resource-adapter can use any of the configured thread-pools in the system.

> How does the http-thread-pool get created if it does not already exist?
http-thread-pool configuration is present in a all domains by default.

> I am excluding this from 3.1 because I cannot investigate it or fix it before
> the RC1 deadline. It is not even clear if this is something that should be fixed at this point.

I am able to create a new thread pool, restart server, configure the resource-adapter to use new thread pool successfully. However, I do not see http-thread-pool and admin-thread-pool in the list of thread pools of S1ASThreadPoolManager. Is this by design ?
If it is by design, probably we should document it.

eg: Following thread-pools are grizzly thread pools and will not be available for ORB thread pool clients/users.
http-thread-pool, admin-thread-pool

I am adding '3_1-release-notes' tag to the issue so that it is documented/release-noted.

Could you please provide appropriate documentation changes for the same ?

Comment by Jagadish [ 17/Jan/11 ]

Update : I see that IIOPUtils exluding thread-pools that are used by http-listener (network-listener) while initializing ORB thread-pools.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Jagadish [ 31/Mar/11 ]

There are two thread pool implementations from GlassFish 3.0 ie., grizzly based thread-pool and ORB based thread-pool.

"create-resource-adapter-config" takes a thread-pool id as parameter which is based on ORB thread-pool.
Also refer, create-thread-pool command to create new thread-pools.

ORB thread-pool, when initialized will verify whether an "thread-pool" is used by grizzly and will initialize the thread-pool only if grizzly is already not using the configuration.

So, there need to be a documentation stating that ORB thread pool manager will exclude any defined thread-pool configuration in the system if its already used by grizzly thread pool manager.

Comment by Scott Fordin [ 13/Apr/11 ]

Added issue to 3.1. Release Notes.

Comment by Nazrul [ 21/Apr/11 ]

It would be useful to look into this issue during 3.1.1

Comment by scatari [ 25/Jun/11 ]

Marking it as to be considered after 3.1.1.

Comment by Tom Mueller [ 07/Feb/13 ]

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





[GLASSFISH-15558] Caching JMS session in a session bean causes errors when invoked by a MDB when under load Created: 13/Jan/11  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 3.1_b37
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ServerLog.odt     Zip Archive TransactionTests.zip    
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

This issue was originally reported by a user on the GlassFish developer list. Here is the thread:
http://www.java.net/forum/topic/glassfish/glassfish/jms-and-transaction-issue

The issue can be summarised as follows: a MDB consumes a message from an inbound queue, updates a database then invokes a session bean which sends a message to an outbound queue. If 40 messages are placed on the inbound queue then we see a variety of messages in the server log (see that thread), including this one:

625+0000|SEVERE|glassfish3.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=36;_ThreadName=Thread-1;|commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:950872495901869318 and onePhase:false due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsserver.util.BrokerException: Bad transaction state transition. Cannot perform operation COMMIT_TRANSACTION(46) (XAFlag=0x0:TMNOFLAGS) on a transaction in state COMPLETE(4).|#]

The error occurs ONLY if the session bean caches its JMS connection, session and producer in a field of the bean. This is valid, though it is contrary to the conventional practice which is to create the connection, use it, and close the connection every time the session bean is invoked. If these objects are not cached then this bug is NOT seen. This bug therefore has a workaround.

The issue can be reproduced using JMS only (i.e. not using a database), though to see exactly the same errors as the user reported it is necessary to force the use of two-phase commits.

A simple NetBeans application is attached which demonstrates the issue. This consists of a Enterprise Application "TransactionTests" which is composed of a ejb application "TransactionTests-ejb" and a web application "TransactionTests-war".

Steps to reproduce:

1. Install the latest version of GlassFish 3.1 (I used build 37)
2. Before starting GlassFish, edit domain.xml to set the JVM option -Dimq.jmsra.isSameRMAllowed=false . This is needed to force two-phase transactions to be used. (If this is not done the application will still fail but you will get different errors).
3. Use NetBeans to build the application (which is an ear cotaining an ejb and a web app) and deploy it in GlassFish.
4. Visit http://localhost:8080/TransactionTests-war/ and click on "Run MDB Test 1". This causes a servlet to send 40 messages to the inbound queue.
5. Inspect the server log for errors



 Comments   
Comment by Nigel Deakin [ 13/Jan/11 ]

The attached file ServerLog.odt is an extract from the server log, which includes logging in DirectXAResource and in the application.

Note particularly Thread 36 (highlighted in green) and Thread 51 (highlighted in red). This suggests that the session bean instance used by thread 36 was reused by thread 51 after the business method returned but before the MDB returned and the transaction was committed. This meant that the same JMS session object was being used by two threads at the same time, which caused the error.

(Full disclosure: to create this logging a modified version of MQ was used with all use to System.out() in DirectXAResource changed to use JDK logging. This was necessary to ensure that such log messages were reported using the correct thread)

Comment by Nigel Deakin [ 14/Jan/11 ]

This behaviour is also seen in GlassFish 2.1.1, so this is not a regression. There's also a workaround (and the workaround is generally considered better practice than the problem case). So this bug doesn't need to be fixed now, so setting the 3_1-exclude tag.

Comment by Nigel Deakin [ 14/Jan/11 ]

Have created documentation bug
http://java.net/jira/browse/GLASSFISH-15579
to record this in the release note for 3.1.

Comment by Paul Davies [ 14/Jan/11 ]

For the GlassFish 3.1 release notes add the following information:

A stateless session bean should not save JMS connections or sessions in fields of the bean. Applications that do so may encounter errors.

To avoid this issue, if a stateless session bean's business method requires the use of a JMS connection and session then the business method should create the JMS connection and session, use it to send or receive messages, and then close the connection and session before returning. This is GlassFish issue 15558.

Comment by theodor.richard [ 14/Jan/11 ]

I'm the user who initially reported this issue on the mailing list. A problem with not caching the connection is that the maximum number of connections is reached quickly. I'm seeing the following exceptions in the log when sending 50 messages in a for loop, i.e. the method that acquires and releases the JMS connection is invoked 50 times in a row:

com.sun.messaging.jms.JMSException: MQRA:DCF:allocation failure:createConnection:Error in allocating a connection. Cause: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.

My max connection pool size has the default size of 32.

Comment by Nigel Deakin [ 17/Jan/11 ]

@theodor.richard: If you believe that managed connections are not being returned correctly to the pool (and this isn't because your pool simply isn't big enough), then please log this as a separate issue or raise it on the user list. Please keep this issue for discussions of the effect of caching the connection, session and producer.

Comment by Nigel Deakin [ 25/Jan/11 ]

Analysis of the test case shows that the cause of the problem is that the container is reusing the session bean instance (and hence the connection's XAResource instance) after the business method has returned but before the transaction has been committed.

It is legal for the container to reuse the stateless session bean instance before the transaction has been committed: the EJB spec, section 4.7 "Stateless Session Beans" states that "the container may interleave requests from multiple transactions to the same instance".

However doing so causes errors in the JMSRA resource adapter, because it is designed on the basis that the same XAResource instance is used for start, end, prepare and commit and that the instance will not be reused until the transaction is committed or rolled back.

That is a breach of the JCA 1.5 spec, which states in section 7.3.2.1 "Implementation" that "A transaction manager can use any XAResource instance (if it refers to the proper resource manager instance) to initiate transaction completion. The XAResource instance used during the transaction completion process need not be the one initially enlisted with the transaction manager for this transaction"

This has been logged as internal (bugs.sun.com) bug 7014537.

Comment by jthoennes [ 14/Apr/11 ]

Hello Nigel,

as we heavily use that kind of scenario, I would like to ask whether this issue will be fixed for 3.1.1
without raising a service request.

A quick answer is highly appreciated.

Thanks, Jörg

Comment by Nigel Deakin [ 14/Apr/11 ]

This is currently scheduled for 3.2, though, as always, I can't make commitments as to the contents of future releases.

If you have a support licence and this issue is causing a problem them please contact your support representative (and let me know you've done so) since this would definitely affect the priority we give to fixing it.

Nigel

Comment by jthoennes [ 14/Apr/11 ]

In reply to comment #9:
> If you have a support licence and this issue is causing a problem them please
> contact your support representative (and let me know you've done so) since this
> would definitely affect the priority we give to fixing it.

Thanks, Nigel. Yes, we have a support contract. What do you need if I file a service request on My Oracle Support (MOS).
Do you have access to the service requests submitted?

Cheers, Jörg

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Nazrul [ 21/Apr/11 ]

It would be good to take a look at this issue for 3.1.1

Comment by Nigel Deakin [ 03/May/11 ]

@jthoennes - Yes, please file an issue with Oracle support as you suggest. There is a separate engineering team to resolve customer issues, so raising it with support increases the resources available to address this issue.

Comment by Nigel Deakin [ 03/May/11 ]

I have reviewed this bug for 3.1.1 and decided not to fix it in that version for the following reasons:

  • This bug is in older versions of GlassFish (including GlassFish 2.1.1) and so is not a regression
  • There is a workaround (see earlier comment)
  • The fix would require significant changes to the XAResource implementation classes in the JMSRA resource adapter. In addition to the work involved it would require a lot of testing to be sure that it does not introduce a regression. 3.2 will have much more testing than 3.1.1 and so, given that this is an old bug which has a workaround, I would like to defer fixing this bug until 3.2 so it can be properly tested.

Removing the 3_1_1-review tag.

@jthoennes - note that if you raise this issue with Oracle support this will still be reviewed by Oracle sustaining.

Comment by jthoennes [ 27/May/11 ]

Filed Oracle Service Request "SR 3-3705874175: Resolve GLASSFISH-15558 for Glassfish 3.1.1" for this issue.

Comment by marina vatkina [ 16/Nov/11 ]

Re EJB container behavior: In our current implementation, bean instances are returned to pool at the end of method invocation. If we were to to delay it till the termination of tx, we would need more instances because transaction can last much longer than a single method invocation.

Comment by Nigel Deakin [ 14/Dec/11 ]

Adding 3_1_2-exclude tag. Excluding from 3.1.2 for the same reason it was excluded from 3.1.1 (see my comment above).





[GLASSFISH-15505] [UB]docs: need to represent partial Connector Architecture Specification support in Web Profile Created: 10/Jan/11  Updated: 29/Mar/11

Status: In Progress
Project: glassfish
Component/s: webpages
Affects Version/s: None
Fix Version/s: None

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

Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

Raising this issue based on the forum discussion :
http://www.java.net/forum/topic/glassfish/glassfish/unsupported-features-displayed-glassfish

In section titled "Java EE 6 standards" of Release Notes (3.1) please make the following changes.
Also applicable for the following pages :
http://glassfish.java.net/downloads/3.0.1-final.html
http://glassfish.java.net/downloads/v3-final.html

  • In the row for "Connector Architecture 1.6", indicate yes against web
    profile but with an footnote that indicates "Standalone Connector 1.6
    Container only". Against Full Profile, retain the current value.


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

Added 3_1-release-notes tag for tracking purposes.

Comment by Scott Fordin [ 25/Mar/11 ]

Updated table in 3.1 Release Notes, and added "3_1-release-note-added" tag. Reassigned to Paul Davies because I don't own the public Web pages for which the change also needs to be made. Paul may know who owns these pages. If not, to whom should this issue be reassigned?

Comment by Paul Davies [ 29/Mar/11 ]

Reassigned to alexismp, who is responsible for the GF site web pages.

Comment by Alexis MP [ 29/Mar/11 ]

Taking over the issue but missing some context (the forum link is now a 404).
Are you saying 3.0.1 and 3.0 download pages need to be changed but not http://glassfish.java.net/downloads/3.1-final.html ?
The table rows maps to IPS packages installed in the distro. Which connector package is in the Web profile distro?





[GLASSFISH-15482] Domain fails to stop after console loaded (with secure admin enabled) Created: 07/Jan/11  Updated: 15/Apr/11  Resolved: 10/Jan/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b36
Fix Version/s: None

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

S11/x86


Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

Server fails to stop when in secure admin mode and Console has been loaded.

To reproduce this problem:

1) Install b36
2) start-domain
3) enabled-secure-admin
4) stop-domain
5) start-domain
6) load Admin Console
7) stop-domain

In step 7 asadmin will report:

ouch: ./asadmin stop-domain
CLI306 Warning - server is not running.
Command stop-domain executed successfully.

and the following will be in the server log:

[#|2011-01-07T11:46:15.563-0800|WARNING|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=24;_ThreadName=admin-thread-pool-4848(5);|processorTask.exceptionSSLcert
javax.net.ssl.SSLHandshakeException: renegotiation is not allowed
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:621)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:667)
at com.sun.grizzly.util.SSLUtils.doPeerCertificateChain(SSLUtils.java:559)
at com.sun.grizzly.filter.SSLReadFilter.doPeerCertificateChain(SSLReadFilter.java:340)
at com.sun.grizzly.ssl.SSLProcessorTask.action(SSLProcessorTask.java:153)
at com.sun.grizzly.tcp.Request.action(Request.java:430)
at com.sun.grizzly.tcp.http11.GrizzlyRequest.getAttribute(GrizzlyRequest.java:835)
at com.sun.grizzly.tcp.http11.GrizzlyRequest.getUserPrincipal(GrizzlyRequest.java:1834)
at com.sun.enterprise.v3.admin.AdminAdapter.authenticate(AdminAdapter.java:266)
at com.sun.enterprise.v3.admin.AdminAdapter.authenticate(AdminAdapter.java:309)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:218)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]

[#|2011-01-07T11:46:15.569-0800|SEVERE|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=24;_ThreadName=admin-thread-pool-4848(5);|service exception
java.lang.RuntimeException: ClientAbortException: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:254)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: ClientAbortException: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:439)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.flush(GrizzlyOutputBuffer.java:405)
at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.flush(GrizzlyOutputStream.java:140)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:251)
... 17 more
Caused by: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.grizzly.util.SSLOutputWriter.flushChannel(SSLOutputWriter.java:98)
at com.sun.grizzly.ssl.SSLOutputBuffer.flushChannel(SSLOutputBuffer.java:138)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:398)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:376)
at com.sun.grizzly.http.ProcessorTask.action(ProcessorTask.java:1236)
at com.sun.grizzly.ssl.SSLProcessorTask.action(SSLProcessorTask.java:164)
at com.sun.grizzly.tcp.Response.action(Response.java:268)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:434)
... 20 more

#]

[#|2011-01-07T11:46:45.592-0800|WARNING|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=22;_ThreadName=admin-thread-pool-4848(4);|processorTask.exceptionSSLcert
javax.net.ssl.SSLHandshakeException: renegotiation is not allowed
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:621)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:667)
at com.sun.grizzly.util.SSLUtils.doPeerCertificateChain(SSLUtils.java:559)
at com.sun.grizzly.filter.SSLReadFilter.doPeerCertificateChain(SSLReadFilter.java:340)
at com.sun.grizzly.ssl.SSLProcessorTask.action(SSLProcessorTask.java:153)
at com.sun.grizzly.tcp.Request.action(Request.java:430)
at com.sun.grizzly.tcp.http11.GrizzlyRequest.getAttribute(GrizzlyRequest.java:835)
at com.sun.grizzly.tcp.http11.GrizzlyRequest.getUserPrincipal(GrizzlyRequest.java:1834)
at com.sun.enterprise.v3.admin.AdminAdapter.authenticate(AdminAdapter.java:266)
at com.sun.enterprise.v3.admin.AdminAdapter.authenticate(AdminAdapter.java:309)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:218)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]

[#|2011-01-07T11:46:45.594-0800|SEVERE|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=22;_ThreadName=admin-thread-pool-4848(4);|service exception
java.lang.RuntimeException: ClientAbortException: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:254)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: ClientAbortException: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:439)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.flush(GrizzlyOutputBuffer.java:405)
at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.flush(GrizzlyOutputStream.java:140)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:251)
... 17 more
Caused by: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.grizzly.util.SSLOutputWriter.flushChannel(SSLOutputWriter.java:98)
at com.sun.grizzly.ssl.SSLOutputBuffer.flushChannel(SSLOutputBuffer.java:138)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:398)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:376)
at com.sun.grizzly.http.ProcessorTask.action(ProcessorTask.java:1236)
at com.sun.grizzly.ssl.SSLProcessorTask.action(SSLProcessorTask.java:164)
at com.sun.grizzly.tcp.Response.action(Response.java:268)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:434)
... 20 more

#]


 Comments   
Comment by Tom Mueller [ 07/Jan/11 ]

This appears to be due to running with a JDK that is less than version 1.6.0_22.
Can you please check this?

Comment by Nazrul [ 10/Jan/11 ]

This is most likely due to JDK update 22 issue. Lowering the priority. If we have a problem with update 22, please raise the priority.

Comment by Chris Kasso [ 10/Jan/11 ]

I was using 21. I upgraded to 23 and the problem is not reproducible. I've marked this issues with 3_1-release-notes to ensure we stress that bad things can happen in update 21 or earlier is used. (I suspect this is already stressed in the docs).

Comment by Scott Fordin [ 15/Apr/11 ]

Issue added to 3.1 Release Notes.





[GLASSFISH-15456] [UB]Release note security permissions required for CDI applications Created: 06/Jan/11  Updated: 25/Mar/11  Resolved: 25/Mar/11

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

Type: Task Priority: Major
Reporter: Sivakumar Thyagarajan Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

Please release note the following for 3.1 See GLASSFISH-15078 [1] for more information.

CDI-enabled Java EE applications that are deployed in a GF3.1 domain/cluster, which has security manager enabled, have to add the following Permissions for the deployed application. Adding permissions for an application is described in http://docs.sun.com/app/docs/doc/820-7695/beabz?l=en&a=view

grant codeBase "file:$

{com.sun.aas.instanceRoot}/applications/[ApplicationName]" {
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

For example, for a CDI application, say foo.war, add the following permissions to server.policy, restart domain/cluster and then deploy and use the application.

grant codeBase "file:${com.sun.aas.instanceRoot}

/applications/foo" {
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

These additional Permissions are not needed when the security manager is disabled.

[1] http://java.net/jira/browse/GLASSFISH-15078?focusedCommentId=174564&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_174564



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

Not really a bug but a task.
Reassigned to Release Notes owner.
Prefixed summary with [UB] to denote that the issue affects unbundled documentation.

Comment by Scott Fordin [ 11/Feb/11 ]

Will add topic to 3.1 Release Notes.

Comment by Scott Fordin [ 25/Feb/11 ]

Believe this was added to 3.1 Security Guide.

Comment by Scott Fordin [ 25/Mar/11 ]

Actually, it was not added to the Security Guide, so I've added it to the 3.1 Release Notes, and added the "3_1-release-note-added" tag.





[GLASSFISH-15441] [UB]org.osgi.framework.BundleException during shutdown after upgrade Created: 05/Jan/11  Updated: 24/Mar/11  Resolved: 03/Mar/11

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

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

Solaris 10 Sparc


Attachments: Text File server.log     Text File upgrade.log     Text File upgrade.log    
Tags: 3_1-release-note-added, 3_1-release-notes, 3_1-upgrade

 Description   

During asupgrade to upgrade a V2.1.1 developer profile with a deployed webapp I am seeing the following error
from upgrade.log (full log added as attachment):

asadmin: Error while starting bundle: file:/sun/glassfishv2.1.1/glassfish3/glassfish/modules/autostart/org.apache.felix.bundlerepository.jar: org.osgi.framework.BundleException: Cannot start bundle org.apache.felix.bundlerepository [244] because its start level is 1, which is greater than the framework's start level of 0.
asadmin: org.osgi.framework.BundleException: Cannot start bundle org.apache.felix.bundlerepository [244] because its start level is 1, which is greater than the framework's start level of 0.
asadmin: at org.apache.felix.framework.Felix.startBundle(Felix.java:1690)
asadmin: at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
asadmin: at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1136)
asadmin: at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1122)
asadmin: at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1115)
asadmin: at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:433)
asadmin: at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:241)



 Comments   
Comment by Tom Mueller [ 05/Jan/11 ]

Bobby, can you please take a look at this to figure out where this belongs?

Comment by Bobby Bissett [ 05/Jan/11 ]

Art,

Can you give me more info on this? What build are you trying, and is there any info about the app?

Comment by Bobby Bissett [ 05/Jan/11 ]

All the upgrade tests are passing – does the server still work after you see this?

Comment by adf59 [ 05/Jan/11 ]

Build tested was latest nightly glassfish bundle dated jan 5.

The server starts up fine and the helloworld web
app is reachable.

I just happen to see this error during the asupgrade and filed the bug.

I upgraded a developer profile with HelloWorldApp deployed.

Comment by Bobby Bissett [ 05/Jan/11 ]

It took me several tries to reproduce this, and now I can't reproduce again. I suspect that those warnings are always happening, but there is a timing issue with whether or not they're logged.

Can you attach the server log also?

Comment by adf59 [ 05/Jan/11 ]

It happens consistently with me. I am on a Solaris 10 Sparc system.

I am attaching the server.log.

Comment by adf59 [ 05/Jan/11 ]

server.log and upgrade.log attached.

Comment by Bobby Bissett [ 05/Jan/11 ]

I've had to go to the dev list about this one:
http://java.net/projects/glassfish/lists/dev/archive/2011-01/message/38

Art, since this happens every time for you, can you start/stop the domain and see if you see the same error?

Comment by Bobby Bissett [ 05/Jan/11 ]

Since this happens during a shutdown, and doesn't affect startup or use of the app server after the upgrade, I'm downgrading this to a P4. But I'd still like to find out what it means and whether it needs to be fixed or documented.

Comment by adf59 [ 05/Jan/11 ]

A stop and start of server does not show anything unusual. Everything looked fine. It appears you see this during the upgrade.

Comment by Bobby Bissett [ 13/Jan/11 ]

Am moving this over to docs. I've been talking with Richard Hall about this, and there's a chance it could be fixed by Sahoo. When I get more information, I'll attach it here. If the situation stays the same, then we should document that in some cases users will see these errors at the end of an upgrade. It happens during shutdown of the server and doesn't affect anything else.

I don't know if it's material for the upgrade guide, release notes, etc.

Comment by Bobby Bissett [ 13/Jan/11 ]

I've heard from Sahoo that the issue won't be fixed for 3.1. GLASSFISH-15519 captures the error messages and explanation. This issue affects the server whenever it's started with the --verbose flag. Because the --upgrade flag implies the --verbose flag, that's why we're seeing it at the end of upgrades.

So this information may need to be documented somewhere more general than some upgrade-specific documentation.

(Side note: these error messages have always been present, but only showed up recently due to logging changes.)

Comment by Bobby Bissett [ 09/Feb/11 ]

Changing summary from:

asadmin error during asupgrade of a developer profile with deployed app

to:

org.osgi.framework.BundleException during shutdown after upgrade

Comment by Scott Fordin [ 11/Feb/11 ]

Not sure if this should go in the Release Notes or in the Upgrade Guide proper. Any opinions?

Comment by Bobby Bissett [ 11/Feb/11 ]

I guess the release notes make more sense. It doesn't always happen, which is good, so I'm hoping no one even sees it on nice, fast production systems.

Comment by Scott Fordin [ 03/Mar/11 ]

Added topic to 3.1 Release Notes.

Comment by Scott Fordin [ 24/Mar/11 ]

Added "3_1-release-note-added" tag.





[GLASSFISH-15429] Modifying keyfile path in a newly created config does not properly list the users Created: 04/Jan/11  Updated: 16/Nov/11

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 3.1_ms07
Fix Version/s: future release

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

Issue Links:
Dependency
blocks GLASSFISH-15406 Unable to edit custom admin-realm in ... Closed
Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

1. asadmin copy-config default-config new-config
2. asadmin get new-config.security-service.auth-realm.admin-realm.property.file
new-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
3. asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.
4. file /tmp/v3/admin-keyfile is not currently created.
5. asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
6. cat /tmp/v3/admin-keyfile
test;

{SSHA256}mjyhJFWxU8xUnGMY5bt+ngwj3tf6v6yOTKB7DgGKJUu6Neky/GVOsQ==;asadmin
user1;{SSHA256}

rImtlHJuqi6AMSypIUyBdcs2CUEPQq3pIEHSEsndYQmhBl4ZBT+fJA==;user1
<user test is properly added to admin-keyfile under /tmp/v3 as expected.>
8. asadmin list-file-users --authrealmname admin-realm new-config
user1
Command list-file-users executed successfully.
<Expected is test,user1 but it lists user1 which it takes from $

{instance_root}

/domains/domain1/config/keyfile but it should list from /tmp/v3/admin-keyfile>

The list-file-users needs to be fixed to list from /tmp/v3/admin-keyfile



 Comments   
Comment by kumarjayanti [ 04/Jan/11 ]

Srini,

Either there is no bug or you have not given me the complete set of steps. With the steps that you provided it is not clear how the user :"user1" is already present in the /tmp/v3/admin-keyfile.

Also are you using the latest builds. Here are the steps that i executed and i see no problems

1.)

$ ./asadmin start-domain
Waiting for domain1 to start ..........
Successfully started the domain : domain1
domain Location: /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/domains/domain1
Log File: /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

2.)
$ ./asadmin copy-config default-config new-config

Command copy-config executed successfully.

3)
$ ./asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.

4)
$ mkdir /tmp/v3
$ > /tmp/v3/admin-keyfile

5)
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

6)
$ cat /tmp/v3/admin-keyfile
test;

{SSHA256}

H0J8mMtMJp1BcPynsBqyDw8r0WWI30796BaFrsdmei3eBh3YDILKKg==;asadmin

7)
$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
Command list-file-users executed successfully.

8)
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config user1
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

9)
$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
user1
Command list-file-users executed successfully.

Comment by kumarjayanti [ 04/Jan/11 ]

Cannot reproduce. Make sure you are using the very latest glassfish build. And please provide the exact steps to reproduce.

I will try some other combination in the meantime to see if i can reproduce anything like what u mention.

Comment by srinik76 [ 04/Jan/11 ]

I have not created the file. As per the requirement do we need to create the file.

If not created we see this problem.

Comment by kumarjayanti [ 04/Jan/11 ]

The Keyfile needs to be created physically and ideally this should be done before even the set command is executed to change the keyfile property.

That said, if the keyfile is not created then when i test purely from CLI i do not get the problem you see. I see the create-file-user fails.

Comment by Anissa Lam [ 04/Jan/11 ]

It is the responsibility of the user to create the keyfile ( I hope the documentation specifies that) or the security code should be smart enough to detect that the keyfile doesn't exist and create that for the user.
GUI should NOT create the keyfile.

As commented in GLASSFISH-15406, there is error given if the keyfile doesn't exist.
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
remote failure: Adding User test to file realm admin-realm failed.
Command create-file-user failed.

GUI should show the error to the user.
However, there is no reason given to the user WHY the creation failed. It should tell user that the keyfile doesn't exist. Thus I am re-opening this bug but downgrading it. The error message needs to be clear.

Comment by srinik76 [ 04/Jan/11 ]

Tested with the latest build, create-file-user fails with following message

asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
remote failure: Adding User test to file realm admin-realm failed. /tmp/v3/admin-keyfile (No such file or directory)
/tmp/v3/admin-keyfile (No such file or directory)

list-file-users also should report that /tmp/v3/admin-keyfile is not found, but it lists the user (admin)

asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.

Comment by kumarjayanti [ 05/Jan/11 ]

Anissa Said :
----------

GUI should show the error to the user.
However, there is no reason given to the user WHY the creation failed. It should tell user that the keyfile doesn't exist. Thus I am re-opening this bug but downgrading it. The error message needs to be clear.

--------

I checked the code and the CLI command tried to do the following :
report.setMessage(
localStrings.getLocalString("create.file.user.useraddfailed",
"Adding User

{0}

to the file realm

{1}

failed",
userName, authRealmName) + " " + localalizedErrorMsg);
report.setActionExitCode(ActionReport.ExitCode.FAILURE);
report.setFailureCause(e);

It appears when the Message is set it takes priority over setFailureCause in the admin framework. I can remove the setMessage for the next release. Or if you think it is important for you since this message has to be displayed in the GUI then please reopen the bug and i will ask for approval.

I see a similar problem with list-file-users as well where it sets all the 3 items on the report object and hence the message that was set takes priority and that message is currently not very good.

I can fix both of them as part of this. The question is would you like messages fixed for V3.1.

Comment by srinik76 [ 05/Jan/11 ]

Reopening issue after discussing with kumar.

Now from the security side it will check for the keyfile existence while listing file users.

Comment by kumarjayanti [ 05/Jan/11 ]

1) How bad is its impact? (Severity)
While we are unable to reproduce it by pure CLI operations it appears GUI seems to observe some incorrect file-user listing in this case. Also the message log for the Failure can be improved to indicate the real cause.

2) How often does it happen? (Frequency)
This will occur only when keyfile of a file-realm points to a non-existent File.

3) How much effort is required to fix it? (Cost)
Minor : the fix is to add a check for non-existent keyfile and throw an error.

4) What is the risk of fixing it? (Risk)

None (does not affect the Runtime). GUI wants these enhancements.

Comment by Anissa Lam [ 05/Jan/11 ]

Approved.

Comment by kumarjayanti [ 05/Jan/11 ]

fixed

Comment by srinik76 [ 05/Jan/11 ]

Fix works fine, but when the key file is created

list-file-users should report none, but lists admin user.

Waiting for comments from kumar to reopen the issue.

Comment by srinik76 [ 06/Jan/11 ]

After changing the key file and restarting the server, it works fine.

Comment by srinik76 [ 06/Jan/11 ]

Comments from Kumar in email

Hi Srini, Anissa,

I think i understand what is happening.

1. default-config is copied as new-config
2. Now the admin-realm is selected in the GUI from this new-config
3. Its KeyFile property is changed to some XYZ and the change is saved. Using an asadmin set-command
4. A physical XYZ file is created
5. Now again ManageUsers is clicked on the admin-realm of new-config
5.1. At this time ListFileUsers command still shows the original admin user that is part of the admin-realm in default-config

Is this a correct description of the issue ?. If that is true then yes that can happen.

1. Step 2 loads the admin-realm in the Backend.
2. Setp 3 modifies the property of the realm in the Config-Layer
3. Backend is not informed of this change. And since the new-config is not the running config of the Server (DAS) the ConfigListener Mechanism (which is in place) does not come into picture. So the backend realm is never updated.
4. ListFileUsers command which executes as part of step (5) above does a refresh of the keyfile contents but it never goes back to the config-layer to see if the keyfile has changed. And it does not make sense for ListFileUsers to do that (checking for changes to the realm definition in config-layer). Things would have worked if it did that but really the syncing between Config-Layer and Backend should have happened when step (3) above invoked the "asadmin set" command to modify the keyfile property.

There are 4 solutions :

1. I can provide a new hidden command which has to be executed by GUI whenever they do a asadmin set on any realm (and file-realm in particular). This command would then try to sync the Config change made by the set to the backend. For some realms this inplace update cannot be performed for-example

  • if it is an LDAPRealm of the active server config and there are applications currently using that realm and the set command tries to modify the URL of the LDAP server or the base-dn of the LDAPRealm. Such changes will require a RESTART of the Application Server.

2. Fix ListFileUsers to re-read the config-layer. Not a good idea and not the right fix.

3. GUI can indicate after the set-command that Appserver should be restarted.

4. GUI should not use an asadmin set to modify the keyfile location. Instead it should delete the existing Realm and create a New Realm with modified properties.

Let me know which approach would be best for V3.1.

regards,
kumar

Waiting for Anissa's comments to decide what approach (1 out of 4 suggested by kumar) to be taken for the solution.
Anissa/Kumar, Can I reopen the bug?

Comment by kumarjayanti [ 06/Jan/11 ]

I am also not sure if a Property change in realm (using asadmin set) in an active server config will cause the Config Change Event which can be received by a registered ConfigListener.

Comment by Anissa Lam [ 06/Jan/11 ]

As i understand it, only GUI user sees this problem. CLI user will not have such an issue. Correct me if i am wrong. But i just tried using CLI to do all the steps and list-file-user reports the correct list.
So, what exactly is missing in GUI code, compared to CLI, that causes this error in GUI only ? I want to understand this, and that maybe how we should fix it.

The corresponding steps in CLI works perfectly fine, and list-file-user is reporting the list of users from the new key file correctly.

~ 1) asadmin copy-config default-config TEST-config
Command copy-config executed successfully.
~ 2)
~ 2) asadmin list-file-users --authrealmname admin-realm server-config
admin
Command list-file-users executed successfully.
~ 3)
~ 3)
~ 3) asadmin get configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file
configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
Command get executed successfully.
~ 4)
~ 4) asadmin set configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=/tmp/keyFile
configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=/tmp/keyFile
Command set executed successfully.
~ 5)
~ 5)
~ 5) touch /tmp/keyFile
~ 6)
~ 6) asadmin list-file-users --authrealmname admin-realm TEST-config
Command list-file-users executed successfully.
~ 7)
~ 7)

Comment by Anissa Lam [ 06/Jan/11 ]

Re-open issue as this is still under active discussion and GUI depends on the fix.

Comment by kumarjayanti [ 06/Jan/11 ]

Your step two :
~ 2) asadmin list-file-users --authrealmname admin-realm server-config

should be changed to

2) asadmin list-file-users --authrealmname admin-realm TEST-config

and IMO that will reproduce the problem in CLI

Comment by kumarjayanti [ 06/Jan/11 ]

I retested after implementing solution 1. Here is the output :

$ ./asadmin start-domain
Waiting for domain1 to start ..........
Successfully started the domain : domain1
domain Location: /Users/vbkumarjayanti/Downloads/glassfish3/glassfish/domains/domain1
Log File: /Users/vbkumarjayanti/Downloads/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

$ ./asadmin copy-config default-config new-config
Command copy-config executed successfully.

$ ./asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.

$ ./asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/mykeyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/mykeyfile
Command set executed successfully.

$ ./asadmin __synchronize-realm-from-config --realmname admin-realm new-config
Synchronization of Realm admin-realm from Configuration Successful.
Command __synchronize-realm-from-config executed successfully.

$ ./asadmin list-file-users --authrealmname admin-realm new-config
Command list-file-users executed successfully.

$ cat /tmp/mykeyfile

$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
Command list-file-users executed successfully.

Comment by kumarjayanti [ 06/Jan/11 ]

The new hidden command will set RESTART required if the change was done to an active server config

$ ./asadmin set server-config.security-service.auth-realm.file.property.file=/tmp/mykeyfile
server-config.security-service.auth-realm.file.property.file=/tmp/mykeyfile
Command set executed successfully.

$ ./asadmin __synchronize-realm-from-config --realmname file server-config
Restart required for configuration updates to active server realm: file.
Command __synchronize-realm-from-config executed successfully.

And here is how the code in the command sets the information required for GUI for a restart. I picked up this code from :

core/kernel/src/main/java/com/sun/enterprise/v3/admin/GetRestartRequiredCommand.java

private void setRestartRequired(ActionReport report) {
report.setActionExitCode(ActionReport.ExitCode.SUCCESS);
ActionReport.MessagePart mp = report.getTopMessagePart();

Properties extraProperties = new Properties();
Map<String, Object> entity = new HashMap<String, Object>();
mp.setMessage(_localStrings.getLocalString("RESTART_REQUIRED",
"Restart required for configuration updates to active server realm:

{0}

.",
new Object[]

{realmName}

));
entity.put("restartRequired","true");
extraProperties.put("entity", entity);
((ActionReport) report).setExtraProperties(extraProperties);
}

Comment by kumarjayanti [ 06/Jan/11 ]

checked in the Partial Fix which will make the GUI work.

GUI has to invoke the new hidden command whenever an asadmin set is invoked on any realm.

The CLI this bug still remains if someone does the following sequence of operations :

1. asadmin copy-config default-config new-config
2. asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.
3. asadmin get new-config.security-service.auth-realm.admin-realm.property.file
new-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
4. asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.
5. create the physical keyfile at /tmp/v3/admin-keyfile

After doing these steps, the following command will give a wrong answer :

1. asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.

This is because the asadmin set command in step-4 above updates the Configuration Layer but does not update the Backend Realm which was loaded while executing step 2. So the list command will continue to list the user admin which was present in the original realm's keyfile (one that it was referring to before the set command changed it).

Summary of the CLI Bug : If an asadmin set command is executed to change a realm-property for a realm that was loaded by the backend (due to an earlier CLI command targeted at the realm) , then the realm continues to behave as if the set command was not executed. The workaround is to restart Appserver after a set command has been used to change a property of an already loaded realm.

Comment by Scott Fordin [ 15/Apr/11 ]

Issue added to 3.1 Release Notes.





[GLASSFISH-15424] [BigApps] [STRESS] ~17 occurences of "EOFException" warnings coming from JMS Created: 03/Jan/11  Updated: 19/Sep/14  Due: 18/Jan/11

Status: Reopened
Project: glassfish
Component/s: jms
Affects Version/s: 3.1_b34
Fix Version/s: 4.1

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

Attachments: Text File eof-issue.log     File server.log-instance101-24x1-gf-b37    
Issue Links:
Dependency
blocks GLASSFISH-15423 [STRESS] [BigApps] [Umbrella-Issue] 2... Closed
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1_1-scrubbed, 3_1_2-exclude, 3_1_2-release-note-added, 3_1_2-release-notes

 Description   

See parent issue 15423 for details of the BigApps run that causes this issue to appear in the server logs. A server log that shows the issue has been attached.



 Comments   
Comment by Satish Kumar [ 04/Jan/11 ]

This is a bug in MQ. See http://java.net/jira/browse/MQ-72 for the corresponding MQ issue. Amy Kang is currently working on it and based on her feedback, a fix for this issue will be a part of the next MQ integration ...

Comment by varunrupela [ 04/Jan/11 ]

Satish,

This is a different issue from the MQ-72 issue. The log is attached to the issue. We need to check on the cause for the log.

Comment by Satish Kumar [ 04/Jan/11 ]

As I had mentioned in my earlier comment, I suspect this issue may be caused due to http://java.net/jira/browse/MQ-72.

Lowering the priority of this issue to Minor as discussed with Varun. We will need to have a re-look at this once MQ-72 is fixed and then decide if any further action is required here or if we can close this issue.

Comment by Satish Kumar [ 05/Jan/11 ]

Bumping-up the priority to Major based on Nazrul's feedback.

We plan to leave this issue open until the fix for MQ 72 has been integrated and the stress tests have been run again and observe if the exceptions are reappearing in the new test run.

Comment by Nazrul [ 10/Jan/11 ]

Please confirm if MQ-72 resolved this problem.

Comment by varunrupela [ 12/Jan/11 ]

The issue continues to exist in build 37.

Comment by varunrupela [ 13/Jan/11 ]

Added one of the instance's server log after a 24x1 run of the same scenario.

Comment by Satish Kumar [ 13/Jan/11 ]

Assigning this issue to Nigel as per our discussion this evening...

Comment by Nigel Deakin [ 14/Jan/11 ]

These messages

[#|2011-01-13T11:14:06.600+0530|WARNING|glassfish3.1|javax.jms|_ThreadID=29;_ThreadName=Thread-1;|[I500]: Caught JVM Exception: java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes.|#]

are warning messages. No errors or other messages were seen and there are no reports of the application behaving unexpectedly other than these messages.

Other users have reported receiving these messages periodically in earlier versions of MQ. There is a discussion here:
http://markmail.org/message/hh2ejjuxp5mo6njp#query:+page:1+mid:rumu3mg7unqbgm25+state:results
to which MQ team members responded.

This warning message is logged by the MQ client thread that is reading messages from a socket connected to the broker. (Note that even though the broker is embedded, since the broker is clustered, the client uses TCP to connect to the broker). The exception suggests that the client had received a "zero-length packet" from the broker. This message is often seen when the broker has failed, though this is not the case here. In that email discussion the MQ technical lead speculates that it is "probably a side effect of destination limits or TTL" and suggests that if there are no other problems the messages can be ignored.

Note that after this exception has been logged the client will attempt to recover the connection and carry on. This appears to have been the case here since no further messages were logged.

This is just a warning message, and is logged as such. Arguably GlassFish should never log warnings, but to suppress it might cause useful information to be lost if there are other problems. So it is proposed to close this bug as "not being a bug".

Comment by varunrupela [ 17/Jan/11 ]

Based on the analysis, the issue can be waived for GF 3.1. The issue should remain open as it appears in GF build 37 and as the MQ team will fix it in the long-term. It is useful to keep this issue open as opposed to creating a new one, since it contains quite some information around the bug.

Comment by Nigel Deakin [ 17/Jan/11 ]

Adding 3_1-exclude 3_1-release-notes tags. Note that this issue now only concerns the EOFExceptions and no other messages.

The release note should mention that very occasionally WARNING messages "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" may be observed in the server log. If no other messages or exceptions are logged at the same time in either the server or broker logs these messages may be ignored.

Comment by varunrupela [ 18/Jan/11 ]

set the target release

Comment by easarina [ 18/Jan/11 ]

Was used b38 01/14. richAccess + SSL stress test on Win 2008 machines. Saw multiple "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" warnings in server.log files. Was used jdk 1.6.0_23, 64 bit.

Comment by Nigel Deakin [ 19/Jan/11 ]

Updated summary to make it clear that it relates to warning messages, not exceptions.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes. Is a release note still necessary?

Comment by Nigel Deakin [ 25/Mar/11 ]

Please add the following text (which I gave in my comment on 17 Jan) to the release note:

Issue 15424: Very occasionally WARNING messages "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" may be observed in the server log. If no other messages or exceptions are logged at the same time in either the server or broker logs these messages may be ignored.

Nigel

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Nigel Deakin [ 14/Dec/11 ]

Excluding from 3.1.2 for the same reason it was excluded from 3.1.1. It should continue to be mentioned in the release note.

Comment by Rebecca Parks [ 24/Jan/12 ]

If it's in the 3.1.1 Release Notes, it's carried over to 3.1.2 unless it's fixed in 3.1.2. There's no need to flag it for 3.1.2.

Comment by Nigel Deakin [ 15/Feb/13 ]

In accordance with the project triage guidelines this is not needed for 4.0 and so has been deferred until 4.0.1. Setting "fix version" accordingly.





[GLASSFISH-14547] Mysql ping fails when additional properties are not deleted Created: 09/Nov/10  Updated: 24/Feb/12

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

Type: Improvement Priority: Major
Reporter: shaline Assignee: Shalini
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: XML File domain.xml    
Issuezilla Id: 14,547
Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

Build used: GFV3.1 nightly dated: 11/7
OS: Windows XP
Browser: IE8

When we keep all the additional properties for the Mysql pool ,and the values
for user, password and url fields, the ping fails. When we delete these
additional properties and keep only the User,Password and url properies, the
ping succeeds.

steps:
Copy mysql-connector-java-5.1.7-bin.jar to domain1/lib/ext and restart.
Create a JDBC connection pool as below:
datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlDataSource"
res-type="javax.sql.DataSource"
name="MyPool">
"url" value="jdbc:mysql://asqe-core2.sfbay.sun.com:3306/dbsmpl1"
"Password" value="dbpassword"
"User" value="dbuser"

Keep all the additional properties intact, and try Ping. it fails. delete them
and try ping again, it succeeds.



 Comments   
Comment by Anissa Lam [ 09/Nov/10 ]

Can you let us know what are the additional props and its value when the ping failed for you ?
If you do the ping through CLI, doees it work for you ?

Comment by shaline [ 09/Nov/10 ]

Created an attachment (id=5387)
domain.xml

Comment by Anissa Lam [ 09/Nov/10 ]

thanks for domain.xml.
Can you ping successfully using CLI ?

Comment by shaline [ 09/Nov/10 ]

ping fails even in CLI since the additional properties are added from admin
console. If we remove the additional properties , then ping succeeds even in
console,and CLI.

Comment by Anissa Lam [ 10/Nov/10 ]

those properties are whats given to us from backend. transferring to 'jdbc' for evaluation.

Comment by sumasri [ 11/Nov/10 ]

Transferring it to backend team.

Comment by Jagadish [ 11/Nov/10 ]

This behavior has been there since Application Server 8.x

Please refer issue 549 , there was a detailed discussion about MySQL driver
exposing all these attributes.
GlassFish will not have a control over these properties.

The only option we had was to make GUI show the standard properties and then in
another tab showing all properties.

StandardProperties =

{ "databaseName", "serverName", "port", "networkProtocol", "user", "password", "roleName", "datasourceName" }

;

Marking this as RFE.

As long as the user follows the documented list of properties (docs of
GlassFish), it works fine.
http://docs.sun.com/app/docs/doc/820-7692/gbsor?l=en&a=view

Anissa, let me know if its possible to change admin console screen to show
standard properties first (atleast for MySQL case alone) and then based on the
request from user, show all other properties, I can work on providing an API
which can be called by console.

Also refer the issue 3475 (enhancement)

Comment by Anissa Lam [ 11/Nov/10 ]

Its too late now to make this kind of UI change.
We can think about this after 3.1
thanks.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Shalini [ 23/Mar/11 ]

When a ping is done with all the properties mentioned in the domain.xml(attached) for mysql-pool, the following error message is got.

Ping failed Exception - Access denied to execute this method : setLargeRowSizeThreshold Please check the server.log for more details.

Workaround is to provide only the standard list of properties documented. The standard properties are "databaseName", "serverName", "port", "networkProtocol", "user", "password", "roleName", "datasourceName".

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Shalini [ 25/Apr/11 ]

This is an RFE and could be addressed in 3.2. The solution for this is tricky as in, if only the standard properties are listed for all jdbc drivers, the user would have to look into the jdbc driver vendor documentation for the available properties and set each one of them by typing it manually. Its much easier to delete the properties that cause a failure before trying a ping rather than adding lot of properties manually.

Comment by Nazrul [ 24/Feb/12 ]

Configuring a MySQL pool needs just these 6 properties, may be even a few less.

<property name="URL" value="jdbc:mysql://127.0.0.1:3306/blahr"></property>
<property name="portNumber" value="3306"></property>
<property name="databaseName" value="blah"></property>
<property name="serverName" value="blah.dyndns.org"></property>
<property name="user" value="blah"></property>
<property name="password" value="xxx"></property>

Currently, we show a long list of properties. It would be good if we can show standard properties for all JDBC drivers to make user experience better. We may display the entire set of properties introspected from JDBC driver in advanced tab.





[GLASSFISH-13873] If TS resource had been changed, tables are not created after server restart Created: 07/Oct/10  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Attachments: Text File server.log     File timersession.ear    
Issuezilla Id: 13,873
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Build 23 10/07. Solaris 10 Sparc. Installed thid build on one machine. Created a
cluster with two instances. Then started a cluster. After that executed:
#!/usr/bin/perl
require "./conf.pl";

$out=`$S1AS_HOME/bin/asadmin start-database`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin set
configs.config.c1-config.ejb-container.ejb-timer-service.timer-datasource=jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin list-instances`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
================================================================

The appclient was executed successfully.

Then I've reinstalled everything and executed such sequence of the commands:
===================================================
#!/usr/bin/perl
require "./conf.pl";

$out=`$S1AS_HOME/bin/asadmin start-database`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
$out=`$S1AS_HOME/bin/asadmin undeploy --target c1 timersession`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin set
configs.config.c1-config.ejb-container.ejb-timer-service.timer-datasource=jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin list-instances`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
================================================

In this case not only seconf execution of the appclient totally failed, but also
second deployment failed.

I believe, if once TS did not start successfully and it is not running, then
during next invoke, has be to cleaned everything and TS should be started again.
I've restarted cluster, db, domain, tried to undeploy an app and deploy it
again, but it did not help. So only a full uninstall helps to clean everything.
I've attached timersession.ear and in1 server.log.



 Comments   
Comment by easarina [ 07/Oct/10 ]

Created an attachment (id=5096)
timersession.ear

Comment by easarina [ 07/Oct/10 ]

Created an attachment (id=5097)
in1 server.log

Comment by marina vatkina [ 07/Oct/10 ]

As this would be something we didn't provide before, making it an RFE for the
next release.

Comment by easarina [ 07/Oct/10 ]

I believe, that for this release has to be provided at least a work around. I.e.
if first time TS did not start, how to clean everything and make it start next
time without reinstalling the glassfish.

Comment by marina vatkina [ 07/Oct/10 ]

You need to restart the DAS as well

Comment by easarina [ 07/Oct/10 ]

As I've wrote I've restarted DAS, cluster, DB. But it did not help.

Comment by marina vatkina [ 08/Oct/10 ]

This is what's going on:

The 1st time you started, TS was (absolutely fine) deployed to jdbc/__TimerPool,
so after restart, even though the code figured out that it's a different
resource, the file marker left behind said it's a load, not a deploy.

May be the file should contain the last (all?) resources TS was deployed to...

Comment by easarina [ 08/Oct/10 ]

When was added glassfish3/glassfish/domains/domain1/generated/ejb-timer-service-
app, the second deployment/appclient execution were OK. I.e. such sequence of
commands worked:
===================================================
#!/usr/bin/perl
require "./conf.pl";

$out=`$S1AS_HOME/bin/asadmin start-database`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve .
./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
$out=`$S1AS_HOME/bin/asadmin undeploy --target c1 timersession`;
print $out;
$out=`rm -rf $S1AS_HOME/domains/domain1/generated/ejb-timer-service-app`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-domain`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-domain`;
print $out;
$out=`$S1AS_HOME/bin/asadmin set
configs.config.c1-config.ejb-container.ejb-timer-service.timer-
datasource=jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin list-instances`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve .
./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
========================================================

But it doesn't work without stop-domain/start-domain.

I believe this sequence of the commands has to work without a domain restating.

Comment by marina vatkina [ 17/Nov/10 ]

Let's RN for this release that if the EJB Timer resource was changed after the
EJB Timer Service was started on a previous resource, a) DAS needs to be
restarted if any automatic timers are to be deployed, and b) unless the EJB
Timer table is created manually, the marker file
glassfish3/glassfish/domains/domain1/generated/ejb-timer-service-app needs to be
removed as well.

Please reassign it back to ejb-container after it is documented

Comment by Paul Davies [ 17/Nov/10 ]

Added 3.1-release-notes keyword to ensure that this issue is documented in the
RN and reset the subcomponent and owner.

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.





[GLASSFISH-13774] Win. Deployment with contextroot: Application [] contains no valid components Created: 03/Oct/10  Updated: 26/Jul/11  Resolved: 11/Mar/11

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

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

Operating System: All
Platform: All


Attachments: File bookstore.war     Text File derby.bookstore.sql     Text File server.log    
Issue Links:
Duplicate
is duplicated by GLASSFISH-13773 Win. Deployment with contextroot: The... Resolved
Related
is related to GLASSFISH-17094 deployment of war files packaged in e... Resolved
Issuezilla Id: 13,774
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Promoted b22, Win7 machine. On this machine was created a cluster with two
instances. The deployment with contextroot to the cluster, i.e.:
asadmin deploy --target <cluster> --contextroot temp --name qwerty1, failed for
several apps with such messages (see bellow). The same command did not create
any issues on Mac, Linux, Solaris. I've attached an app.

=====================================================================
DEPLOY WITH CONTEXT bookstore
[#|2010-10-03T16:33:07.208-
0700|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.serv
er|_ThreadID=15;_ThreadName=Thread-1;|Exception while deploying the app
[qwerty1]|#]

[#|2010-10-03T16:33:07.212-
0700|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deplo
yment.admin|_ThreadID=15;_ThreadName=Thread-1;|Exception while deploying the app
[qwerty1] : Application [] contains no valid components|#]

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



 Comments   
Comment by Hong Zhang [ 03/Oct/10 ]

I don't see the attached app, is it the same one as in issue 13773?

Tim: can you take a look at this as it only happens on windows? Thanks!

Comment by easarina [ 03/Oct/10 ]

For this app were created such resources:

$S1AS_HOME/bin/asadmin create-jdbc-connection-pool --target $CLUSTER --property
User=BOOKSTORE:Password=BOOKSTORE:dataBaseN
ame=DerbyDB:serverName=localhost:portNumber=1527 --restype javax.sql.DataSource
--datasourceclassname org.apache.derby.jdbc
.ClientDataSource bookstorePool
$S1AS_HOME/bin/asadmin create-jdbc-resource --target $CLUSTER --connectionpoolid
bookstore-pool jdbc/BookDB

Comment by easarina [ 03/Oct/10 ]

Created an attachment (id=5054)
bookstore.war

Comment by easarina [ 03/Oct/10 ]

Created an attachment (id=5055)
derby.bookstore.sql

Comment by Tim Quinn [ 04/Oct/10 ]

Hi, Elena.

Do you happen to know if this happens on Windows XP also? That's the type of
Windows system I have access to.

I will try it myself soon; I just wondered if you already knew. Thanks.

Comment by Tim Quinn [ 04/Oct/10 ]

Setting expected target milestone to MS 7.

Comment by easarina [ 04/Oct/10 ]

I've reproduced this issue on XP machine.

Comment by easarina [ 26/Oct/10 ]

Re-run the test on Win7 against b25 10/25. Did not see this issue.

Comment by easarina [ 28/Oct/10 ]

Did not see this issue for b26

Comment by easarina [ 18/Nov/10 ]

Run the same test on Win 2008 machine. (I have two Win 2008 machines). I've run
the test at least 10 times, using b30. For both machines just one time this
exception was not seen. In all other cases. This exection wax seen for:

1) SingletonCMT

org.glassfish.api.admin.CommandException: remote failure: Error occurred during
deployment: Exception while deploying the app [qwerty1] : Application []
contains no valid components. Please see server.log for more details.
Command deploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application with name
[qwerty1] is not deployed
Command redeploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application qwerty1
is not deployed on this target [my-c1]
Command undeploy failed.

2) bookstore

org.glassfish.api.admin.CommandException: remote failure: Error occurred during
deployment: Exception while deploying the app [qwerty1] : Application []
contains no valid components. Please see server.log for more details.
Command deploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application with name
[qwerty1] is not deployed
Command redeploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application qwerty1
is not deployed on this target [my-c1]
Command undeploy failed.

3) SLSBNICMT
org.glassfish.api.admin.CommandException: remote failure: Error occurred during
deployment: Exception while deploying the app [qwerty1] : Application []
contains no valid components. Please see server.log for more details.
Command deploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application with name
[qwerty1] is not deployed
Command redeploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application qwerty1
is not deployed on this target [my-c1]
Command undeploy failed.

See, for example, hudson job:

http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/49/

Comment by easarina [ 01/Dec/10 ]

I've run a deployment test against nightly build 31 11/30 on Win 2008 machine. See the results of the run under:

http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/56/artifact/appserver-sqe/reports/pe-pe/amd64_JED-ASQE-21_Windows_NT/html/summaryreport.html

The deployment of several apps:
SLSBNICMT
SingletonCMT
bookstore

failed with this message.

Comment by Tim Quinn [ 03/Dec/10 ]

This is some of the server.log output Elena sent to us (thanks, Elena).

[#|2010-11-30T19:34:47.639-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-1;|Exception while deploying the app [qwerty1]|#]

[#|2010-11-30T19:34:47.639-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-1;|Application [] contains no valid components
java.lang.IllegalArgumentException: Application [] contains no valid components
at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:77)
at com.sun.enterprise.deployment.Application.visit(Application.java:1764)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:794)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:273)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.open(ApplicationArchivist.java:228)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.open(ApplicationArchivist.java:80)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:179)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:92)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:825)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:767)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1061)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1257)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1246)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:449)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:216)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2010-11-30T19:34:47.643-0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=17;_ThreadName=Thread-1;|Exception while deploying the app [qwerty1] : Application [] contains no valid components|#]

Comment by Tim Quinn [ 03/Dec/10 ]

Using an up-to-date workspace I have been working with a Windows 7 system. I have not yet been able to reproduce the problem. It might be because I am using a fast system that does not show the race condition Elena has encountered. Still looking.

Comment by Tim Quinn [ 03/Dec/10 ]

I think part of the reason I might not see the same error is that the provisioned system I am using to test is virtual with a single virtual CPU.

Considering this is a race condition it might appear only in a multi-CPU/multi-core environment.

Elena, is your testing on a multi-CPU/multi-core system?

Comment by easarina [ 03/Dec/10 ]

The last time I saw this issue on such Win 2008 machine
Processor: AMD Opteron (tm) Processor 154 2.80 GHz
RAM 2.00 GB
System Type: 64-bit OS.

I saw this issue during hudson runs, I'm not sure that it is easy to reproduce this issue manually.

Comment by Hong Zhang [ 06/Dec/10 ]

I could not reproduce the problem with bookstore.war on the windows machine where we reproduced issue 13775.

As you said, this problem might only happen during hudson runs. It will be very hard to look into the problem if we can only reproduce the problem with running the whole test suite. It will be great if you can narrow it down to a small set of the steps for us to look into it.

One question, during the hudson run where this is reproducible, after the whole test suite finished (I assume all applications will be undeployed at that point), what's left behind in the domains/domain1/applications directory?

Also you mentioned two other applications also having this problem:
SLSBNICMT and SingletonCMT. Can you attach the archives for them? Want to see if we have any luck reproduce the problem with these other two applications.

Comment by easarina [ 07/Dec/10 ]

I've tried to narrow the issue. I've run the tests many times with a small subsets of the archives on Win 2008 against latest b31 and b32. I was able to reproduce the issue one time, please see:

http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/66/

In this run also was presented an issue http://java.net/jira/browse/GLASSFISH-13773, it happened with table-generatorApp.

All archives, that were used in this run, can be checked out from appserver-sqe/pe/deployment_v3/archives

Comment by easarina [ 07/Dec/10 ]

I've reproduced the issue one more time with the same small set of apps on another Win 2008 machine, please see:
http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/77/

Again along with bug http://java.net/jira/browse/GLASSFISH-13773.

Comment by easarina [ 08/Dec/10 ]

DAS server.log file from http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/78/ execution.

Comment by Tim Quinn [ 13/Dec/10 ]

Here is the underlying problem.

1. A deployment of (for example) RosterApp.ear using "--name qwerty1" leaves a locked JAR file here:

applications/qwerty1/RosterApp_war/WEB-INF/lib/RosterAppEjb.jar

2. A later deployment of another app (for example bookstore.war) also using "--name qwerty1" fails because the ArchivistFactory.getPrivateArchivistsFor(ReadableArchive) method (line 131) checks composite archivists first. Although there is no std or runtime DD for an EAR present in the expanded directory, the ApplicationArchivist.postHandles method sees the left-over RosterApp_war directory (which could not be deleted because of the locked JAR contained within) and concludes that the app is an EAR and so returns true.

Later on, the validation fails because this is not in fact an EAR.

Comment by Tim Quinn [ 13/Dec/10 ]

I have some changes in my workspace which resolve the immediate problem I've described earlier. The presence of unused "leftover" JARs in the applications/appName directory no longer confuses GlassFish about what kind of archive it really is.

Now that the code goes beyond that point different problems have emerged. For example, after deploying the embeddable-embeddedApp.ear, disabling it, and enabling it, an attempt to deploy it with --force=true fails with errors resolving persistence units. This is the result of some of the JARs in the applications/appName directory being locked.

I have in my workspace some further changes that seem to relieve that problem. But it is too late to run the necessary tests to make sure these changes would not break anything.

My feeling had been that the original problem might be one we could live with. It happens only on Windows and only if the user deploys different types of applications in succession using the same application name.

But this new problem I have discovered causes problems in a much more common case: redeployment of an EAR with persistence units (on Windows). We should consider this for milestone 8.

Comment by Tim Quinn [ 15/Dec/10 ]

I am marking this to be fixed in 3.2; I do not think it rises to meet the criteria for fixing in 3.1.

  • Impacts product security (no)
  • Represents a CTS failure (no)
  • Is a regression of functionality or performance available in a prior release (no)
  • Introduces an incompatibility (no)
  • Likely to generate a customer support call (possible but relatively unlikely)
  • Significantly impacts the operation of a primary release driver feature (no)
  • An in-your-face issue that will touch the majority of users (no)

All of the following must occur to trigger this problem:

  • OS is Windows.
  • One (or more) JAR files in the expanded applications/appName directory are locked as part of deployment or accessing the application, so that the JAR(s) are not removed during undeployment.
  • The same or another application is later deployed with the same name.
  • The new application does not contain the previously-locked JAR file in the same location.
  • Some code in GlassFish searches all JARs in the application for some reason (e.g., annotation detection, persistence unit searching, sniffer work to identify the type of application).

Elena's very good test case revealed this problem by reusing the same application name when deploying different apps of different types. Because JARs from the earlier app were locked and remained behind, this confused various parts of GlassFish in different ways.

I have a working fix in my workspace. I plan to check the changes in for 3.2 rather than 3.1 Several classes that are affected are ones that are used in many places in GlassFish (FileArchive, for one) and because the bug is relatively rare the risk outweighs the benefit for a 3.1 fix.

Comment by Tim Quinn [ 26/Jan/11 ]

Issue 15691 is a duplicate of this one, at least in some respects.

The general deployment changes will work around such problems, but I have reassigned 15691 to the web container team for them to look at for 3.2 to eliminate the underlying cause.

Comment by Tim Quinn [ 03/Feb/11 ]

Fix checked in (trunk).

Project: glassfish
Repository: svn
Revision: 44886
Author: tjquinn
Date: 2011-02-04 00:10:13 UTC
Link:

Log Message:
------------
Fix for 13774

On Windows, deploy an EAR then undeploy it. (for example, stateless-session.ear from the devtests) Next, deploy a web app but use the same name as the just-undeployed EAR. (for example, webapps-caching.war from SQE) The undeploy of the EAR did not clean out the applications/appName directory because of a locked JAR. The deployment of the web app fails because GlassFish finds the "left-over" file and tries to treat it as part of the web app - which does not work.

These fixes change the FileArchive implementation so that it recognizes entries only if the entries are dated after a hidden timestamp maintained in the FileArchive's directory. This hides "left-over" files from a previous deployment that were not cleaned up.

Tests: error scenario in the issue on Windows, QL tests

Revisions:
----------
44886

Modified Paths:
---------------
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deploy/shared/FileArchive.java
trunk/v3/deployment/javaee-full/src/main/java/org/glassfish/javaee/full/deployment/EarHandler.java
trunk/v3/deployment/common/src/main/java/org/glassfish/deployment/common/DeploymentUtils.java
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/server/ApplicationLifecycle.java
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchive.java
trunk/v3/deployment/common/src/test/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchiveTest.java
trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/ApplicationArchivist.java

Comment by Tim Quinn [ 25/Feb/11 ]

One of the new unit tests failed for Jane on a Windows build.

testCreateWithOlderLeftoverEntryAndThenOpen(com.sun.enterprise.deploy.shared.FileArchiveTest)

Further, Amy reported problems with the web devtests on a Hudson system:
webtier-dev-tests-v3

So I am reopening this issue.

Comment by Tim Quinn [ 11/Mar/11 ]

Fix checked in.

Repository: svn
Revision: 45495
Author: tjquinn
Date: 2011-03-11 20:14:42 UTC
Link:

Log Message:
------------
Fix for 13774.

These changes implement a "stale" file handling mechanism for the FileArchive class which prevents stale files that were left over from a previous use of the same directory from being visible to a client of the FileArchive. This scenario would happen with some frequency on Windows when an app was deployed with a name, a JAR file remained open and so the expanded directory in applications/ could not be deleted, and a different app entirely was deployed using the same name. The applications/(appname) directory would be reused - since it remained from the previous app - and the stale file(s) within would confuse GlassFish. Now, such stale files are detected and are suppressed so they are not treated as part of the FileArchive.

A hidden file at the top level of the FileArchive directory records such stale files so even after a server restart the stale files are not visible.

pom change approved by Sahoo and Jane
Test: deployment devtests on Mac OS X and Windows; error scenario on both OS types; added unit tests

Revisions:
----------
45495

Modified Paths:
---------------
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deploy/shared/FileArchive.java
trunk/v3/deployment/common/src/main/resources/com/sun/logging/enterprise/system/tools/deployment/LogStrings.properties
trunk/v3/deployment/javaee-full/src/main/java/org/glassfish/javaee/full/deployment/EarHandler.java
trunk/v3/deployment/common/pom.xml
trunk/v3/deployment/common/src/test/java/com/sun/enterprise/deploy/shared/FileArchiveTest.java
trunk/v3/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommand.java
trunk/v3/deployment/admin/src/main/java/org/glassfish/deployment/admin/LocalStrings.properties
trunk/v3/deployment/admin/src/main/java/org/glassfish/deployment/admin/UndeployCommand.java
trunk/v3/deployment/common/src/main/java/org/glassfish/deployment/common/DeploymentUtils.java
trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/ApplicationArchivist.java
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchive.java

Comment by Tim Quinn [ 14/Mar/11 ]

Release note info:

Summary:
On Windows under certain very specific conditions deploying the same or different applications using the same app name can result in unexpected errors.

To see this problem all of the following conditions must be true (from the Dec. 15 comment):

  • User deploys an application with name appName.
  • One (or more) JAR files in the expanded applications/appName directory are locked as part of deployment or accessing the application, so that the JAR(s) are not removed during undeployment.
  • The same or another application is later deployed with the same name.
  • The new application does not contain the previously-locked JAR file in the same location.
  • Some code in GlassFish searches all JARs in the application for some reason (e.g., annotation detection, persistence unit searching, sniffer work to identify the type of application).

GlassFish will consider the left-over file to be part of the second application, even though it it is not. This can cause various errors, most notably "Application [] contains no valid components."

Workarounds: (again, relevant only on Windows)
1. Avoid deploying different applications using the same app name.
2. If you need to redeploy an application but have removed a file from the app and that file remains in the applications/appName directory tree even though you redeploy the app, consider deploying the revised app using a different app name.
3. If you see this error, restart the domain admin server (use the asadmin stop-domain command or stop the domain using the admin console) and then deploy or redeploy the app.

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.





[GLASSFISH-13023] [UB]DOC. Describe how to setup a correct java on the remote machine Created: 18/Aug/10  Updated: 23/May/11  Resolved: 19/Apr/11

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

Type: Bug Priority: Major
Reporter: easarina Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 6 hours
Time Spent: 30 minutes
Original Estimate: Not Specified
Environment:

Operating System: Windows (generic)
Platform: All


Issuezilla Id: 13,023
Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

Any remote asadmin command needs in java on the remote machine and such
command use just a default java, if appserver was installed through unzipping
an archive. Users have to be advised to execute from machine A: ssh <machine B>
java -version. And if it is not JDK 6, change it. For example, on Solaris and
Linux recreate /usr/bin/java link pointing to the suitable java.
Or by setting AS_JAVA pointing on the correrct java in config/asenv.conf on the
remote machine

Also I want to mention that usually /usr/bin/java is linked with jdk 4 or 5.
So there will be error messages (for jdk4 a bad error message).



 Comments   
Comment by sherryshen [ 19/Aug/10 ]

Thank Elena for filing this bug.
Before jdk is configured as Elena described on Solaris
10 sparc machine, I saw the create-instance failure as
below.

[2010-08-18T00:58:15.96] # Actual:
/export/hudson/workspace/sherry-clise1/glassfishv3/glassfish/bin/asadmin --user
admin --host asqe-sb-7 --port 4848 create-node-ssh --nodehost asqe-sb-8
--installdir /export/hudson/workspace/sherry-clise2/glassfishv3/glassfish
asqe-sb-8_agent
[2010-08-18T00:58:15.96]
[2010-08-18T00:58:20.70] Command create-node-ssh executed successfully.
......
[2010-08-18T00:58:32.86] # Actual:
/export/hudson/workspace/sherry-clise1/glassfishv3/glassfish/bin/asadmin --user
admin --host asqe-sb-7 --port 4848 create-instance --node asqe-sb-8_agent
--systemproperties
HTTP_LISTENER_PORT=46328:HTTP_SSL_LISTENER_PORT=46331:IIOP_LISTENER_PORT=46334:IIOP_SSL_LISTENER_PORT=46337:IIOP_SSL_MUTUALAUTH_PORT=46340:JMX_SYSTEM_CONNECTOR_PORT=46343
sa_server2
[2010-08-18T00:58:32.86] Command create-instance failed.
[2010-08-18T00:58:39.04] remote failure: GlassFish requires Java SE version 6.
Your JDK is version 5
[2010-08-18T00:58:39.04]

Comment by Paul Davies [ 04/Oct/10 ]

Added [UB] to Summary to denote unbundled documentation.

Reassigned to sfordin as this information should probably be added to the
Installation Guide or Release Notes.

Comment by sherryshen [ 25/Oct/10 ]
      • Issue 14115 has been marked as a duplicate of this issue. ***
Comment by sherryshen [ 25/Oct/10 ]
      • Issue 14115 has been marked as a duplicate of this issue. ***
Comment by Scott Fordin [ 23/Mar/11 ]

Can you please provide a clearer explanation of the issue and solution here?

Comment by Scott Fordin [ 25/Mar/11 ]

This seems to be pretty much a duplicate of http://java.net/jira/browse/GLASSFISH-13943. Specifically, we clearly state the JDK requirements, and we clearly tell users that there are a whole bunch of things that can go wrong if the user chooses to not use the right Java version, so I don't think we should be telling user how to not use the right version.

Comment by sherryshen [ 30/Mar/11 ]

After cluster is created and run, the error can occur at app runtime,
JSP compile failure due to JRE in use on Win2008 +MKS9.2 in
http://java.net/jira/browse/GLASSFISH-16271
The solution is to set AS_JAVA in asenv.conf.

Comment by Scott Fordin [ 19/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Scott Fordin [ 23/May/11 ]

Restructured the Java Paths and Environment Settings section in the 3.1-3.1.1 Release Notes; divided it into several subsections that can be pointed to from other books. For example, I added pointer from the Installation Guide to this reworked section.





[GLASSFISH-12264] [Release Note]Samples. at ant all output was seen URL for samples that don't have a web client Created: 15/Jun/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: sample_apps
Affects Version/s: v3.0.1
Fix Version/s: not determined

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

Operating System: Windows Vista
Platform: All


Issuezilla Id: 12,264
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

OS: Solaris Sparc, build: SDK build 21. Samples.
At the output from "ant all" for many apps that don't have a web client at all,
for example criteriaQuery or hello-jaxws2.2, was seen URL under deploy-url-
message. i.e. "Application deployed at htt://localhost:8080/... "

I think that users should not see such misleading messages



 Comments   
Comment by scatari [ 11/Oct/10 ]

The top level app-server-ant.xml that does the "deploy" of applications blindly calls this target that
displays the message "Application deployed at <URL>".

The fix would be to display this message only when the sample has an accessible web client URL. This
would require identifying such samples as part of the individual sample build system through setting a
flag, something like "hasWebURL=true/false".

Better yet do not display anything for now even for the applications that can be accessed through web.
Anyhow, the URLs are part of the sample docs.

Comment by scatari [ 11/Oct/10 ]

<exec executable="$

{asadmin}

" failonerror="$

{failonerror}

">
<arg line=" deploy "/>
<arg line=" --user $

{javaee.server.username}

" />
<arg line=" --passwordfile '$

{javaee.server.passwordfile}

'" />
<arg line=" --host $

{javaee.server.name}

" />
<arg line=" --port $

{javaee.adminserver.port}

" />
<arg line=" --name $

{module.name}

"/>
<arg line=" --force=true "/>
<arg line=" --upload=true "/>
<arg line=" --dbvendorname $

{db.vendorname}

"/>
<arg line=" --property compatibility=v2"/>
<arg line="$

{app.module}

" />
</exec>
<antcall target="deploy-url-message"/>
</target>

<target name="deploy-url-message" if="app.url">
<echo message="Application Deployed at: $

{app.url}

"/>
</target>

Comment by scatari [ 12/Oct/10 ]

This would need fix across samples, targeting for 3.2. Will have to Release Note considering the less
impact on users, transferring to Doc.

Scott,
Please assign as appropriate.

Comment by Paul Davies [ 13/Oct/10 ]

Added 3.1-release-notes to indicate the issue should be documented in the
Release Notes.

Reset the subcomponent to sample_apps to enable any possible future code fix to
be tracked.

Comment by Paul Davies [ 13/Oct/10 ]

Reassigned to owner of selected subcomponent. No need to assign it to the RN
writer, as the 3.1-release-notes keyword indicates that this issue is to be
documented in the RN.

Comment by Nazrul [ 20/Dec/10 ]

Will be release noted by documentation team. Excluding from 3.1 bug count.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by easarina [ 28/Mar/11 ]

I did not try to run this test against latest builds. But the general idea, for apps that don't have a web client, users have to ignore this message and don't use the URL.

Comment by Scott Fordin [ 13/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-3916] [UB]Resource Adapter call to XATeminator.recover hangs if automatic recovery is enabled Created: 13/Dec/07  Updated: 06/Jun/11  Resolved: 12/May/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 9.1pe
Fix Version/s: 3.1.1_b06

Type: Bug Priority: Major
Reporter: burdeasa Assignee: Rebecca Parks
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: 3,916
Status Whiteboard:

v3_excluded

Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

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

I am the developer for a JCA 1.5 resource adapter named DTPRA. Note that DTPRA
works with WebSphere Application Server, WebLogic Application Server and JBoss
Application Server.

I needed to test DTPRA with the Sun App Server, so I downloaded Sun Java System
Application Server Enterprise Edition 9.1 (build b58g-fcs) to test DTPRA.

I am now testing transaction recovery, so I set automatic recovery to true.
That is, I have the following in my domain.xml:

<transaction-service automatic-recovery="true" heuristic-decision="rollback"
keypoint-interval="65536" retry-timeout-in-seconds="600" timeout-in-seconds="0"
tx-log-dir="$

{com.sun.aas.instanceRoot}

/logs"/>

When I start the App Server with this setting, the App Server hangs and it
never starts.

Looking at trace output from DTPRA, it is clear that the following has happened:
1) The App Server called the ResourceAdapter.start method for DTPRA.
2) As part of DTPRA startup, DTPRA calls the App Server's XATerminator.recover
method to see if there are inbound transactions to recover.

The call to XATerminator.recover never returns. Apparently there is some sort
of deadlock in the App Server when a resource adapter calls
XATerminator.recover from the ResourceAdapter.start method.

This only occurs when automatic recovery is enabled.



 Comments   
Comment by Sivakumar Thyagarajan [ 14/Dec/07 ]

Thanks for filing this issue. Assigning to Jagadish to investigate further.

Comment by Jagadish [ 09/Jan/08 ]

assigning the issue to Sankar

Comment by Jagadish [ 09/Jan/08 ]

needs evaluation in jts module

Comment by sankara [ 14/Feb/08 ]

Present Architecture doesn't allow any transactional activity till the
transaction recovery is completed and file based transaction logs are cleaned
up. It will be a big change to support in current release and will be targeted
for V3.

Comment by marina vatkina [ 20/Jun/08 ]

Reassign

Comment by sanandal [ 11/Jan/09 ]

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

Comment by marina vatkina [ 23/Sep/09 ]

Post v3

Comment by marina vatkina [ 17/May/10 ]

Will look into it...

Comment by marina vatkina [ 04/Oct/10 ]

With all the latest changes this seems to be fixed in 3.1. Please reopen if
there is an exact scenario that causes any problems.

Comment by Jagadish [ 27/Jan/11 ]

After talking to Marina, re-opening and marking this issue for release-notes.

" It is not advisable to do transactional activity (eg: starting a transaction / calling XATerminator.recover) during ResourceAdapter.start()). "

Refer the original thread for more details :

http://markmail.org/message/ogc7qndhaywfkdrp#query:+page:1+mid:kyyzpcexusbnv7ri+state:results

Recently, we have encountered the following issue :
http://java.net/jira/browse/GLASSFISH-15677
Though we propose to fix the above issue ( GLASSFISH-15677 ), there are other use-cases that might result in similar deadlock as stated in this issue ( GLASSFISH-3916).

Comment by marina vatkina [ 27/Jan/11 ]

We have 2 choices:
a) RN it
b) Document in 2 chapters - Transactions and Connectors - to get attention of all users

Comment by Paul Davies [ 04/Mar/11 ]

As this issue is included in the 3.1 Release Notes, the fix in the base documentation can be deferred until 3.2.

Comment by Scott Fordin [ 15/Apr/11 ]

Added topic to 3.1 Release Notes.

Comment by Rebecca Parks [ 12/May/11 ]

Added the Release Notes info to the Administration Guide's chapter on transactions, specifically the section on recovery limitations.

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.





Generated at Thu May 07 08:03:05 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.