[WSIT-1568] Policy verification error:Missing target MessageID for Signature Created: 14/Jun/11  Updated: 15/Nov/11  Resolved: 15/Nov/11

Status: Closed
Project: wsit
Component/s: security
Affects Version/s: 1.6
Fix Version/s: 1.6

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

Linux, Glassfish 2.1.1, metro 1.6.1


Attachments: Text File soap-log-js70.log     XML File wsit-simple.server.IPingService.xml    
Tags: 3_1_1-exclude

 Description   

This looks like a regression and not sure this was supported scenario in Metro 1.6

Scenario:
Mutual Certificate Security scenario with EncryptBeforeSigning and some headers as EncryptedParts

Please find the attached policy file and soap log.
Exception:
Error : SOAP request NOT sent
javax.xml.ws.soap.SOAPFaultException: com.sun.xml.wss.XWSSecurityException: Policy verification error:Missing target MessageID for Signature
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:189)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)
at $Proxy39.ping(Unknown Source)
at simple.client.PingServiceClientjs70.main(Unknown Source)
Caused by: javax.xml.ws.soap.SOAPFaultException: com.sun.xml.wss.XWSSecurityException: Policy verification error:Missing target MessageID for Signature
at com.sun.xml.ws.security.opt.impl.util.SOAPUtil.createSOAPFault(SOAPUtil.java:202)
at com.sun.xml.ws.security.opt.impl.util.SOAPUtil.getSOAPFaultException(SOAPUtil.java:194)
at com.sun.xml.wss.jaxws.impl.SecurityServerTube.processRequest(SecurityServerTube.java:219)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:471)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:315)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:291)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:670)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:601)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:875)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:365)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:285)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:221)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:269)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:111)
Caused by: com.sun.xml.wss.impl.PolicyViolationException: com.sun.xml.wss.XWSSecurityException: Policy verification error:Missing target MessageID for Signature
at com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:126)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.createMessage(SecurityRecipient.java:975)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:232)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.verifyInboundMessage(SecurityTubeBase.java:452)
at com.sun.xml.wss.jaxws.impl.SecurityServerTube.processRequest(SecurityServerTube.java:206)
... 40 more
Caused by: com.sun.xml.wss.XWSSecurityException: Policy verification error:Missing target MessageID for Signature
at com.sun.xml.ws.security.opt.impl.incoming.TargetResolverImpl.resolveAndVerifyTargets(TargetResolverImpl.java:118)
at com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.checkTargets(MessagePolicyVerifier.java:405)
at com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.processPrimaryPolicy(MessagePolicyVerifier.java:292)
at com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:121)
... 44 more



 Comments   
Comment by kumarjayanti [ 15/Nov/11 ]

works on trunk and will not backport to 1.6





[WSIT-1567] Update grizzly version Created: 09/Jun/11  Updated: 24/Aug/11  Resolved: 24/Aug/11

Status: Resolved
Project: wsit
Component/s: integration
Affects Version/s: current
Fix Version/s: 2.2

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

Tags: 3_1_1-exclude

 Description   

We currently depend on an outdated version of grizzly-framework-http.



 Comments   
Comment by Martin Grebac [ 23/Aug/11 ]

I believe this is a GFv2 dependency, so that actually shall be removed.





[WSIT-1556] Problem with serializing body of message (contains XML comment), on response when using Saml Sender Vouches security model Created: 11/May/11  Updated: 27/Feb/15

Status: Open
Project: wsit
Component/s: trust
Affects Version/s: 2.0.1
Fix Version/s: not determined

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

Glassfish 3.0.1 web service provider, and client dispatch api.


Attachments: Zip Archive CanonicalizationDefect.zip    
Tags: 3-1-2_exclude, 3_1_1-exclude, 3_1_2-exclude, 3_1_2_exclude, Comments, XML, metro2_2-waived

 Description   

Hi, this is what I get in the server log when the webservice is trying to serialize the response which contains XML comments.

[#|2011-04-13T16:04:46.858-0400|SEVERE|glassfish3.0.1|com.sun.xml.wss.logging.impl.opt.signature|_ThreadID=27;_ThreadName=Thread-1;|WSS1759: Following error com.sun.xml.wss.XWSSecurityException: WSS1609: Error while serializing Body element occured while performing canonicalization com.sun.xml.wss.XWSSecurityException: WSS1609: Error while serializing Body element
javax.xml.crypto.dsig.TransformException: com.sun.xml.wss.XWSSecurityException: WSS1609: Error while serializing Body element
at com.sun.xml.ws.security.opt.crypto.dsig.Exc14nCanonicalizer.transform(Exc14nCanonicalizer.java:187)
at com.sun.xml.ws.security.opt.crypto.dsig.Transform.transform(Transform.java:178)
at com.sun.xml.ws.security.opt.crypto.dsig.Reference.transform(Reference.java:183)
at com.sun.xml.ws.security.opt.crypto.dsig.Reference.digest(Reference.java:124)
at com.sun.xml.ws.security.opt.crypto.dsig.Signature.sign(Signature.java:214)
at com.sun.xml.ws.security.opt.impl.dsig.SignatureProcessor.sign(SignatureProcessor.java:122)
at com.sun.xml.wss.impl.filter.SignatureFilter.sign(SignatureFilter.java:631)
at com.sun.xml.wss.impl.filter.SignatureFilter.process(SignatureFilter.java:589)
at com.sun.xml.wss.impl.HarnessUtil.processWSSPolicy(HarnessUtil.java:93)
at com.sun.xml.wss.impl.HarnessUtil.processDeep(HarnessUtil.java:272)
at com.sun.xml.wss.impl.SecurityAnnotator.processMessagePolicy(SecurityAnnotator.java:189)
at com.sun.xml.wss.impl.SecurityAnnotator.secureMessage(SecurityAnnotator.java:150)
at com.sun.xml.wss.provider.wsit.WSITAuthContextBase.secureOutboundMessage(WSITAuthContextBase.java:1665)
at com.sun.xml.wss.provider.wsit.WSITServerAuthContext.secureResponse(WSITServerAuthContext.java:506)
at com.sun.xml.wss.provider.wsit.WSITServerAuthContext.secureResponse(WSITServerAuthContext.java:286)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processResponse(CommonServerSecurityPipe.java:262)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:239)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:127)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:295)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:519)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:288)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:143)
at org.glassfish.webservices.JAXWSServlet.doPost(JAXWSServlet.java:149)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)



 Comments   
Comment by ritzmann [ 12/May/11 ]

Could you please provide a description and possibly a sample project to reproduce your issue?

Comment by Mhui [ 24/May/11 ]

Sorry for long delay in replying I was on vacation
I will attach a sample project to reproduce the issue.

Comment by Mhui [ 24/May/11 ]

The attached zipfile contains 2 netbeans projects.
1) CanonicalizationDefectService
2) CanonicalizationClient

The 1st is a simple service, it is secured with SAML Sender vouches with certificates using developmenet defeaults.

The 2nd is a client for that service.

Note that I tried it in both secure and non secure modes.
In non secure mode I was able to get a response.
In saml mode, so long as there is a comment in the payload, the canonicalization error will occur.

Removing the comment from the service will make everything work.

Comment by kumarjayanti [ 15/Nov/11 ]

Its an important bug for metro to fix but will attempt it post 2.2

Comment by nrvmodi [ 27/Feb/15 ]

Hello I have also issue regarding this. Can you give me the solutions?

Can you please check this URL? I have describe whole problem here .

http://stackoverflow.com/questions/28696160/error-while-serializing-timestamp-element-occured-while-performing-canonicalizat





[WSIT-1535] digest verification error Created: 24/Feb/11  Updated: 02/Jan/13

Status: Open
Project: wsit
Component/s: security
Affects Version/s: 2.1
Fix Version/s: not determined

Type: Bug Priority: Critical
Reporter: yonghe Assignee: Nithya Ramakrishnan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MS .NET 4.0 and com.sun.xml.ws.webservices-rt 2.1


Attachments: Zip Archive WSIT-1535 Repro.zip    
Tags: 3-1-2_exclude, 3_1_1-exclude, 3_1_2-exclude, incomplete, metro2_2-waived

 Description   

When a string of "First line0x0D0x0ASecond line" is sent from a service implemented in MS .NET 4.0, the Java client created by Metro 2.1 will fail because of a digest verification error.

A bug was filed to MS and they are saying that it should be a bug at java side: https://connect.microsoft.com/VisualStudio/feedback/details/631605/string-digest-verification-failure-in-java-ws-security-client.

You may use the attached code to reproduce the bug.

The exceptions:

SEVERE: WSS1717: Error occurred while doing digest verification of body/payload
javax.xml.crypto.dsig.XMLSignatureException: WSS1717: Error occurred while doing digest verification of body/payload
at com.sun.xml.ws.security.opt.impl.incoming.processor.StreamingPayLoadDigester.accept(StreamingPayLoadDigester.java:109)
at com.ctc.wstx.stax.FilteredStreamReader.next(FilteredStreamReader.java:45)
at com.sun.xml.ws.security.opt.impl.util.VerifiedMessageXMLStreamReader.next(VerifiedMessageXMLStreamReader.java:86)
at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.storeElementAndChildrenNoEx(StreamReaderBufferCreator.java:245)
at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.storeElementAndChildren(StreamReaderBufferCreator.java:177)
at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.store(StreamReaderBufferCreator.java:142)
at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.create(StreamReaderBufferCreator.java:82)
at com.sun.xml.ws.security.opt.impl.incoming.VerifiedStreamMessage.copy(VerifiedStreamMessage.java:447)
at com.sun.xml.ws.api.message.Packet.copy(Packet.java:220)
at com.sun.xml.ws.dump.LoggingDumpTube.processResponse(LoggingDumpTube.java:124)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:651)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at com.sun.xml.ws.client.Stub.process(Stub.java:323)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:161)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:113)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:144)
at $Proxy40.ping2(Unknown Source)
at com.microsoft.sts.prototype.WSTrustClient.testCustomBindingIService1(WSTrustClient.java:49)
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.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
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.runners.ParentRunner.run(ParentRunner.java:236)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)



 Comments   
Comment by kumarjayanti [ 14/Mar/11 ]

Can you tell how to reproduce this in a unit-test on a Non Windows System. Specifically i tried the following (invoking the Metro Canonicalizer on the input XML being discussed on the other thread with Microsoft and i am not seeing any issues. The output is similar to what Microsoft claims is correct.

---------Test-------
package canonicalizertest;

import com.sun.xml.stream.buffer.MutableXMLStreamBuffer;
import com.sun.xml.stream.buffer.stax.StreamWriterBufferCreator;
import com.sun.xml.wss.XWSSecurityException;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.StringReader;
import javax.xml.stream.XMLInputFactory;
import javax.xml.stream.XMLOutputFactory;
import javax.xml.stream.XMLStreamReader;
import javax.xml.stream.XMLStreamWriter;

public class Main {

/**

  • @param args the command line arguments
    */
    public static void main(String[] args) throws Exception {

XMLInputFactory fact = XMLInputFactory.newInstance();
StringBuilder s = new StringBuilder();
s.append("<text>First line");
s.append("\r\n");
s.append("Second line</text>");
StringReader x = new StringReader(s.toString());
XMLStreamReader reader = fact.createXMLStreamReader;
com.sun.xml.wss.impl.c14n.StAXEXC14nCanonicalizerImpl canon = new com.sun.xml.wss.impl.c14n.StAXEXC14nCanonicalizerImpl();

XMLOutputFactory xof = XMLOutputFactory.newInstance();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
MutableXMLStreamBuffer buffer = new MutableXMLStreamBuffer();
StreamWriterBufferCreator bCreator = new StreamWriterBufferCreator(buffer);

XMLStreamWriter writer = canon;
canon.setStream(baos);
XMLStreamWriter writer_tmp = (XMLStreamWriter) bCreator;

while (!(XMLStreamReader.END_DOCUMENT == reader.getEventType()))

{ com.sun.xml.ws.security.opt.impl.util.StreamUtil.writeCurrentEvent(reader, writer_tmp); reader.next(); }

buffer.writeToXMLStreamWriter(writer);
writer.close();
try

{ baos.close(); }

catch (IOException ex)

{ throw new XWSSecurityException("Error occurred while trying to convert SAMLAssertion stream into DOM Element", ex); }

System.out.println("canonicalized output:\n" + baos.toString());

}

}
------------------

Test Output:
------------------
canonicalized output:
<text>First line
Second line</text>
------------------

Thanks

Comment by yonghe [ 28/Mar/11 ]

Please see the newly submitted zip file for details on how to repro the bug.

Yonghe

Comment by yonghe [ 21/Apr/11 ]

Please see ReadMe.txt for running Windows stuff

Comment by kumarjayanti [ 05/Jun/11 ]

I had filed an issue on SJSXP thinking that it is a problem with SJSXP, but they have gotten back with the same justification that MS has given :

http://java.net/jira/browse/SJSXP-74.
------------------------------
It appears that XMLStreamReader ignores '\r' (CR) character on Windows from
element Text. So a "\r\n" gets translated to "\n" when passed through the
XMLStreamReader.
-------------------------------
And here is the reply :

-------------------
I believe the API is doing the correct thing by translating '\r\n' or '\r' to '\n'.

http://www.w3.org/TR/xml/#sec-line-ends

"To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character."
--------------------

So now i am confused what exactly is the bug in your analysis on the Java/Metro Side. Earlier i assumed that the processing of \r\n is the problem but from what i see, the Canonicalizer in Metro never sees a \r instead it will always see a \n. Also unit-testing the canonicalizer shows the same output as MS.

I am going to ask my QE to setup the Test app that you have provided so we can try to reproduce and debug. But if you have any thoughts on what exactly is the bug that will help.





[JAX_WS-964] E2E wsrm/v1_1/invm/jcapsnack test case hangs indefinitely on Hudson Created: 01/Jul/11  Updated: 15/Nov/11  Resolved: 15/Nov/11

Status: Resolved
Project: jax-ws
Component/s: runtime
Affects Version/s: 2.2.6
Fix Version/s: 2.2.6

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

http://sysifos-sol.czech.sun.com/hudson/job/metro-main-trunk-e2e-tests-local/


Tags: 3_1_1-exclude

 Description   

The e2e test job hangs indefinitely and apparently reproducibly at the same RM test case with recent Metro trunk builds. I cannot reproduce the hang on my local machine.

The test job is a precondition for deploying Metro promotions. I will disable this particular test case for now (remember to reenable it when debugging the issue) so that we get the builds going again.

Here is a snippet of the test output:

[java] ..Generating server artifacts from /home.local/hudson/hudson-files/workspace/metro-main-trunk-e2e-tests-local/e2e/testcases/wsrm/v1_1/invm/jcapsnack/./server/PingService.wsdl
[java] [failed to localize] wsimport.ParsingWSDL()
[java] [failed to localize] wsimport.WarningMessage([failed to localize] wsdlmodeler.warning.port.SOAPBinding12(PingPort))
[java] [failed to localize] ConsoleErrorReporter.LineXOfY(110, file:/home.local/hudson/hudson-files/workspace/metro-main-trunk-e2e-tests-local/e2e/testcases/wsrm/v1_1/invm/jcapsnack/server/PingService.wsdl)
[java]
[java] [failed to localize] wsimport.GeneratingCode()
[java] Jul 1, 2011 7:56:14 AM com.sun.xml.ws.server.MonitorBase createRoot
[java] INFO: Metro monitoring rootname successfully set to: com.sun.metro:pp=/,type=WSEndpoint,name=PingService-PingPort
[java] [failed to localize] wsimport.ParsingWSDL()
[java] [failed to localize] wsimport.WarningMessage([failed to localize] wsdlmodeler.warning.port.SOAPBinding12(PingPort))
[java] [failed to localize] ConsoleErrorReporter.LineXOfY(95, file:/home.local/hudson/hudson-files/workspace/metro-main-trunk-e2e-tests-local/e2e/testcases/wsrm/v1_1/invm/jcapsnack/work/services/server/war/WEB-INF/wsdl/PingService.wsdl)
[java]
[java] [failed to localize] wsimport.GeneratingCode()
[java] injected addresses: pingPortAddress
[java] .Jul 1, 2011 7:56:14 AM com.sun.xml.ws.server.MonitorBase createRoot
[java] INFO: Metro monitoring rootname successfully set to: com.sun.metro:pp=/,type=WSClient,name=in-vm-//wsrm.v1_1.invm.jcapsnack.server/-PingPort

The last line is the last entry in the Hudson console output.



 Comments   
Comment by ritzmann [ 01/Jul/11 ]

There seems to be a similar issue with the wsrm/v1_0/invm/jcapsnack. I am disabling this one as well now. The log says:

[java] ..Generating server artifacts from /home.local/hudson/hudson-files/workspace/metro-main-trunk-e2e-tests-local/e2e/testcases/wsrm/v1_0/invm/jcapsnack/./server/PingService.wsdl
[java] [failed to localize] wsimport.ParsingWSDL()
[java] [failed to localize] wsimport.WarningMessage([failed to localize] wsdlmodeler.warning.port.SOAPBinding12(PingPort))
[java] [failed to localize] ConsoleErrorReporter.LineXOfY(100, file:/home.local/hudson/hudson-files/workspace/metro-main-trunk-e2e-tests-local/e2e/testcases/wsrm/v1_0/invm/jcapsnack/server/PingService.wsdl)
[java]
[java] [failed to localize] wsimport.GeneratingCode()
[java] Jul 1, 2011 9:04:32 AM com.sun.xml.ws.server.MonitorBase createRoot
[java] INFO: Metro monitoring rootname successfully set to: com.sun.metro:pp=/,type=WSEndpoint,name=PingService-PingPort
[java] [failed to localize] wsimport.ParsingWSDL()
[java] [failed to localize] wsimport.WarningMessage([failed to localize] wsdlmodeler.warning.port.SOAPBinding12(PingPort))
[java] [failed to localize] ConsoleErrorReporter.LineXOfY(83, file:/home.local/hudson/hudson-files/workspace/metro-main-trunk-e2e-tests-local/e2e/testcases/wsrm/v1_0/invm/jcapsnack/work/services/server/war/WEB-INF/wsdl/PingService.wsdl)
[java]
[java] [failed to localize] wsimport.GeneratingCode()
[java] injected addresses: pingPortAddress
[java] .Jul 1, 2011 9:04:32 AM com.sun.xml.ws.server.MonitorBase createRoot
[java] INFO: Metro monitoring rootname successfully set to: com.sun.metro:pp=/,type=WSClient,name=in-vm-//wsrm.v1_0.invm.jcapsnack.server/-PingPort
[java] Jul 1, 2011 9:04:36 AM [com.sun.xml.ws.rx.rm.runtime.ClientAckRequesterTask] onCompletion
[java] WARNING: WSRM1108: Response for the acknowledgement request is null
[java] Jul 1, 2011 9:04:38 AM [com.sun.xml.ws.rx.rm.runtime.ClientAckRequesterTask] onCompletion
[java] WARNING: WSRM1108: Response for the acknowledgement request is null

The last two lines seem to get repeated indefinitely in 2 second intervals.

Comment by Marek Potociar [ 14/Jul/11 ]

Reassinging to JAX-WS RI lead:

I have found out that the problem started to occur with integration of JAX-WS RI 2.2.6-promoted-b01. With the older 2.2.5-promoted-b04 the test passes. There were NO changes in the WS-RM code for some time already. Most likely the problem is related to a JAX-WS RI new databinding API commit.

Comment by Martin Grebac [ 15/Nov/11 ]

Fixed the test and re-enabled it. The contract should expect an explicit ack or no-ack from jcaps. If there's no ack message, messages get resent until timeout is reached.

Revisions:
----------
6908

Modified Paths:
---------------
trunk/wsit/tests/e2e/testcases/wsrm/v1_1/invm/jcapsnack/server/IPingImpl.java
trunk/wsit/tests/e2e/testcases/wsrm/v1_1/invm/jcapsnack/test-descriptor.xml

Diffs:
------
Index: trunk/wsit/tests/e2e/testcases/wsrm/v1_1/invm/jcapsnack/server/IPingImpl.java
===================================================================
— trunk/wsit/tests/e2e/testcases/wsrm/v1_1/invm/jcapsnack/server/IPingImpl.java (revision 6907)
+++ trunk/wsit/tests/e2e/testcases/wsrm/v1_1/invm/jcapsnack/server/IPingImpl.java (revision 6908)
@@ -1,7 +1,7 @@
/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • * Copyright (c) 1997-2010 Oracle and/or its affiliates. All rights reserved.
    + * Copyright (c) 1997-2011 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
    @@ -71,6 +71,7 @@
    } else { LOGGER.log(Level.ALL, String.format("Detected resent message '%s' with message number %d", message, msgNumber)); FIRST_MESSAGE_RESEND_DETECTED.set(true); + msgCtx.put("RM_ACK", "true"); }

    } else if (!FIRST_MESSAGE_RESEND_DETECTED.get()) {
    String errorMessage = String.format("Received message '%s' with message number %d without detecting a resend of rejected message.", message, msgNumber);





[JAX_WS-948] wsimport customization: how to prevent naming collision in the generated ObjectFactory? Created: 20/May/11  Updated: 22/Aug/11  Resolved: 22/Aug/11

Status: Resolved
Project: jax-ws
Component/s: wsimport
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: marnix.klooster Assignee: Martin Grebac
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-exclude

 Description   

I'm having the same issue as reported in JAX_WS-223; however I'm opening a new issue because that issue is already marked as Resolved.

kohsuke writes in a comment on JAX_WS-223, "The solution, as always, is to use the customization." I'm assuming this means, e.g., an external customization file as documented on http://jax-ws.java.net/nonav/2.2.1/docs/customizations.html, which is passed using the wsimport -b option.

  • Is that indeed what is meant?
  • How would I write a customization which did avoid the conflict between createAccountID() and createAccountID()? I can find no samples, and what makes it more difficult is that the conflict is not in the WSDL file but in an external XSD file.

Any help would be appreciated!



 Comments   
Comment by Martin Grebac [ 22/Aug/11 ]

Hi,
here are few links to JAXB documentation, which contain customization help as well:
http://jaxb.java.net/guide/
http://jaxb.java.net/tutorial/
http://download.oracle.com/javaee/5/tutorial/doc/bnazf.html
MartiNG





[JAX_WS-940] Modular databinding code causes error in GlassFish OSGi environment Created: 07/Apr/11  Updated: 08/Nov/11  Resolved: 08/Nov/11

Status: Resolved
Project: jax-ws
Component/s: jaxb
Affects Version/s: current
Fix Version/s: 2.2.6

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

Tags: 3_1_1-exclude

 Description   

Bhakti and Kumar were recently installing Metro trunk builds (including the latest JAX-WS 2.2.x build) on the AIX port of GlassFish 3.1.1 and that caused the following exception when deploying a web service:

[#|2011-04-01T11:21:04.871-0700|SEVERE|glassfish3.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=7;_ThreadName=Thread-8;|Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11: failed to parse runtime descriptor: com.sun.xml.ws.spi.db.DatabindingException: Unknown Databinding mode: glassfish.jaxb|#]

I doubt that this is related to AIX, it seems more likely an issue with OSGi class loading. The exception is thrown by com.sun.xml.ws.model.AbstractSEIModelImpl line 206 (method createJAXBContext()).



 Comments   
Comment by scchen [ 07/Apr/11 ]

This is most likely caused by missing the com.sun.xml.ws.spi.db.BindingContextFactory service provider file in the META-INF/services, or for some reason the ServiceFinder cannot load that service provider file to get the BindingContextFactory implementations.

Comment by ritzmann [ 08/Apr/11 ]

Generally, META-INF/services lookups have been working fine for me. It seems more likely to me that the service finder is using the wrong classloader or the class to be loaded is not properly exported.

Will post steps to reproduce.

Comment by Martin Grebac [ 08/Nov/11 ]

expected to be fixed - please reopen if the error still persists with metro promoted build > 2.2-b07





[GLASSFISH-17097] Certain message strings set in action reporter prevent asadmin from correctly handling the return action report Created: 25/Jul/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.1, 4.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Tim Quinn Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-exclude, 3_1_1-scrubbed

 Description   

Please also see the related issue.

asadmin asks the DAS to use the PropsFileActionReporter to report the command status. PropsFileActionReporter does not correctly handle certain strings when passed to setMessage if parts of the string are formatted in the same way as a manifest attribute: new line, attr-name: attr-value

The related issue shows an example in which the apparent attribute name is invalid, so asadmin's attempt to interpret the entire action report as a manifest fails.

PropsFileActionReporter should be changed so it can handle such strings and/or asadmin should use some other type of action reporter implementation that can handle such strings.



 Comments   
Comment by Tom Mueller [ 25/Jul/11 ]

Byron, is this related to the email discussion that you and Tim were already having?

Comment by Byron Nevins [ 24/Oct/11 ]

-> P4





[GLASSFISH-17066] Retry is not executed when specifying 1 as the value of Creation Retry Attempts Created: 20/Jul/11  Updated: 02/Dec/11  Resolved: 08/Aug/11

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

Type: Bug Priority: Major
Reporter: ito_m Assignee: Shalini
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: Text File connectionCreationRetryAttempts.patch    
Tags: 3_1_1-exclude, 3_1_1-scrubbed

 Description   

Here is the description about Creation Retry Attempts(connection-creation-retry-attempts) of JDBC connection Pool.

Specifies the maximum number of times that GlassFish Server retries to create a connection if the initial attempt fails. The default value is 0, which specifies that GlassFish Server does not retry to create the connection.

However there might be no difference between 0 and 1 as the value of Creation Retry Attempts. In other words, retry was not executed when specifying 1 as well as 0 according to the number of the following exception in server.log.
java.sql.SQLException: Error in allocating a connection.

I checked the ConnectionPool.createSingleResource method and found the following condition seemed to have a bug.
if (!connectionCreationRetry_ || count >= connectionCreationRetryAttempts_)

Because the above count variable will be incremented before calling resourceAllocator.createResource(), I think the condition should be changed as follows.
if (!connectionCreationRetry_ || count > connectionCreationRetryAttempts_)

Please see the attached patch. Besides, although this issue is applicable to connector(jca) as well, I raise this as a jdbc component issue.



 Comments   
Comment by Jagadish [ 26/Jul/11 ]

Yes, this is an issue.
Excluding for 3.1.1 as it is too late for the release cycle.
As a workaround, one can use the the incremented value. ie., if retry-count is expected to be 5, set it to 6.

We can fix it in the trunk.

Comment by Shalini [ 08/Aug/11 ]

Fixed in trunk.

Sending appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/ConnectionPool.java
Transmitting file data .
Committed revision 48637.

Comment by shreedhar_ganapathy [ 01/Sep/11 ]

Seems to be a candidate for 3.1.2. Can you look into it and update the issue with the fix version and build number?

Comment by Shalini [ 19/Oct/11 ]

Fixing in 3.1.2 branch

Sending connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/ConnectionPool.java
Transmitting file data .
Committed revision 50340.





[GLASSFISH-17061] Issues on the database which doesn't support setClientInfo method Created: 19/Jul/11  Updated: 20/Dec/16  Resolved: 09/Dec/11

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: 4.0
Fix Version/s: 3.1.2_dev, 4.0

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

Operating System: All
Platform: All
JDK: 6 or later


Attachments: Text File GF17061.patch    
Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-review

 Description   

Some databases don't support getClientInfo / setClientInfo method. I detected there are two issues when closing connections on the database which don't support setClientInfo method.

1. In case of enabling SQL Trace Listeners
The exception which occurs when calling setClientInfo method before closing connection is not handled appropriately because of the invocation through Proxy. As a result of the following example, JPA provider (EntityManagerSetupImpl.deploy) catches this exception and closing connections will be never executed.

at $Proxy148.setClientInfo(Unknown Source)
at com.sun.gjc.spi.jdbc40.ConnectionHolder40.setClientInfo(ConnectionHolder40.java:322)
at com.sun.gjc.spi.jdbc40.ConnectionHolder40.close(ConnectionHolder40.java:530)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:617)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:233)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:394)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:185)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:242)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:237)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper._getDelegate(EntityManagerWrapper.java:208)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.persist(EntityManagerWrapper.java:269)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.gjc.spi.JdbcObjectsFactory$1.invoke(JdbcObjectsFactory.java:143)
... 82 more

2. In case of disabling SQL Trace Listeners
RAR7115 message is output every time when closing connections as follow. I think this information is not useful for users who have already known the fact client info properties are not supported, and affects log size if many connections are used.

[#|2011-07-19T12:30:45.685+1000|INFO|glassfish3.2|javax.enterprise.resource.resourceadapter.com.sun.gjc.spi|_ThreadID=17;_ThreadName=Thread-2;|RAR7115: Unable to set ClientInfo for connection|#]
[#|2011-07-19T12:30:50.479+1000|INFO|glassfish3.2|javax.enterprise.resource.resourceadapter.com.sun.gjc.spi|_ThreadID=17;_ThreadName=Thread-2;|RAR7115: Unable to set ClientInfo for connection|#]
[#|2011-07-19T12:30:52.698+1000|INFO|glassfish3.2|javax.enterprise.resource.resourceadapter.com.sun.gjc.spi|_ThreadID=17;_ThreadName=Thread-2;|RAR7115: Unable to set ClientInfo for connection|#]

The current Glassfish implementation always calls getClientInfo()/setClientInfo() regardless of supporting these methods. I suggest it should check whether the client info properties are supported or not in advance to resolve the above issues.



 Comments   
Comment by ito_m [ 19/Jul/11 ]

I will attache the patch for this issue later.

Comment by Jagadish [ 26/Jul/11 ]

w.r.t the first issue of not closing the connection, it will be a jdbc-driver issue.
The method getClientInfo / setClientInfo are supposed to throw SQLClientInfoException in which case GlassFish will still close the connection. If this is due to Proxy used by JDBC-RA, then we need to fix it. If its due to JDBC driver, the issue is with JDBC driver.

w.r.t. the second issue of logging the message each time, yes, this could be fixed by caching the response after first call to get/setClientInfo. As a workaround, you can set the log level of "javax.enterprise.resource.resourceadapter.com.sun.gjc.spi" to WARNING which will avoid the INFO messages.

Marking to exclude for 3.1.1 as it is post Hard code freeze. We can look at fixing it in trunk.

Comment by ito_m [ 27/Jul/11 ]

I attached a patch for this issue.

Comment by ito_m [ 27/Jul/11 ]

To clarify my description, I'd like to add some comments.

w.r.t the first issue, closing a connection means that ConnectionHolder40 which is a logical connection handled by applications is called.
After resetting ClientInfo with setClientInfo() in ConnectionHolder40#close(), the corresponding ManagedConnection which is a physical connection wrapping an actual connection on DB will be put back to pool if there is no transaction managed by the application server at that time.

I think the following stacktrace indicates that SQLClientInfoException the driver returned was wrapped by InvocationTargetException. However ConnectionHolder40 catches only SQLClientInfoException according to the current implementation. Therefore close() on the super class of ConnectionHolder40 was skipped.
at $Proxy148.setClientInfo(Unknown Source)
at com.sun.gjc.spi.jdbc40.ConnectionHolder40.setClientInfo(ConnectionHolder40.java:322)
at com.sun.gjc.spi.jdbc40.ConnectionHolder40.close(ConnectionHolder40.java:530)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.gjc.spi.JdbcObjectsFactory$1.invoke(JdbcObjectsFactory.java:143)
... 82 more
Caused by: java.sql.SQLClientInfoException: the specified method is not supported in this driver.

Comment by ito_m [ 27/Jul/11 ]

>if there is no transaction
More properly if there is no transaction which the targeted connection was enlisted in.

Comment by Shalini [ 09/Dec/11 ]

Fixed in trunk. Thanks for the patch.

Sending appserver/jdbc/jdbc-ra/jdbc-core/src/main/java/com/sun/gjc/spi/ManagedConnection.java
Sending appserver/jdbc/jdbc-ra/jdbc40/src/main/java/com/sun/gjc/spi/jdbc40/ConnectionHolder40.java
Transmitting file data ..
Committed revision 51410.

Comment by Shalini [ 09/Dec/11 ]

Fixed this in 3.1.2 branch.

Sending jdbc/jdbc-ra/jdbc-core/src/main/java/com/sun/gjc/spi/ManagedConnection.java
Sending jdbc/jdbc-ra/jdbc40/src/main/java/com/sun/gjc/spi/jdbc40/ConnectionHolder40.java
Transmitting file data ..
Committed revision 51412.

Comment by hanafey [ 21/Mar/12 ]

I am using "GlassFish Server Open Source Edition 3.1.2 (build 23)" with a connection pool based on Sybase jConnect 7 and am getting zillions of

[#|2012-03-21T13:56:59.265-0400|INFO|glassfish3.1.2|
  javax.enterprise.resource.resourceadapter.com.sun.gjc.spi| _ThreadID=112;_ThreadName=Thread-2;|
  RAR7114: Unable to get ClientInfo for connection |#]

messages.

Should this problem be fixed in this version of GF?

Comment by hanafey [ 22/Mar/12 ]

The INFO level logging happens with Sybase jConnect 7 because in the method below (in ConnectionHolder40), the "getClientInfoProperties" method throws "com.sybase.jdbc4.utils.UnimplementedOperationException: The method com.sybase.jdbc4.jdbc.SybDatabaseMetaData.public ResultSet getClientInfoProperties() has not been completed and should not be called."

If this statement was moved inside of the try block, then the logging would only happen at level FINEST (but the catch block would need a more general exception since the Sybase exception extends java.lang.UnsupportedOperationException.

    private boolean isSupportClientInfo() throws ResourceException, SQLException {
        Boolean isSupportClientInfo = getManagedConnection().isClientInfoSupported();
        if (isSupportClientInfo != null) {
            return isSupportClientInfo;
        } else {
            ResultSet rs = getManagedConnection().getCachedDatabaseMetaData().getClientInfoProperties();  <<<==============
            try {
                isSupportClientInfo = rs.next();
                getManagedConnection().setClientInfoSupported(isSupportClientInfo);
                return isSupportClientInfo;
            } finally {
                try {
                rs.close();
                } catch(SQLException ex) {
                    if(_logger.isLoggable(Level.FINEST)) {
                        _logger.log(Level.FINEST, "jdbc.unable_to_get_client_info", ex);
                    }
                    return false;
                }
            }
        }
    }
Comment by emailnbw [ 10/Apr/12 ]

FWIW I just filed this similar issue: http://java.net/jira/browse/GLASSFISH-18609

Comment by hanafey [ 02/Oct/12 ]

This problem continues in GlassFish Server Open Source Edition 3.1.2.2 (build 5) (With Sybase jConnect v7 JDBC).

Any chance this is going to be fixed? My comment 2 steps above seems to be a reasonable fix...

Comment by rdelaplante [ 11/Oct/13 ]

We're running GlassFish 3.1.2.2 in production (it is now October 2013) and see tons of these warnings in the log file:

[#|2013-10-11T09:44:05.573-0400|INFO|glassfish3.1.2|javax.enterprise.resource.resourceadapter.com.sun.gjc.spi|_ThreadID=91;_ThreadName=Thread-2;|RAR7114: Unable to get ClientInfo for connection |#]

[#|2013-10-11T09:44:05.576-0400|INFO|glassfish3.1.2|javax.enterprise.resource.resourceadapter.com.sun.gjc.spi|_ThreadID=91;_ThreadName=Thread-2;|RAR7115: Unable to set ClientInfo for connection|#]

I'm not sure if it's the jTDS or PostgreSQL JDBC driver, but regardless it seems that this issue is not fixed and should be re-opened.

Comment by sebastian2 [ 19/Nov/13 ]

Hello,
we are suffering the same problem is there any plan to fix this problem for 3.1.2.2?
Thank you,
Sebastian

Comment by Lasse60 [ 04/Mar/14 ]

Any solution for 3.1.2.2???





[GLASSFISH-16993] list-*** commands should not return "Nothing to list" if there is no child. Created: 08/Jul/11  Updated: 20/Dec/16  Resolved: 28/Nov/11

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: None
Fix Version/s: 3.1.2_dev, 4.0

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

Issue Links:
Dependency
blocks GLASSFISH-16924 Error when JMS Connection factory is ... Resolved
Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-review

 Description   

Returns by list-xxx commands sometimes return "Nothing to list" if there is no such resource. I haven't tried all the list-xxx commands, but seems that this happens to all the resources, but not when listing out config elements.

If there is no connector-connection-pool, you will see:

%asadmin list-connector-connection-pools
Nothing to list.
Command list-connector-connection-pools executed successfully.

and the action report says there is one child with the name "Nothing to list" :
{"message":"","command":"list-connector-connection-pools AdminCommand","exit_code":"SUCCESS","extraProperties":{"methods":[

{"name":"GET"}

,{"messageParameters":{"targetName":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":"server"}

}}]},"children":[{"message":"Nothing to list.","properties":{}}]}

If you create MyPool
%asadmin create-connector-connection-pool --raname jaxr-ra --connectiondefinition com.sun.connector.jaxr.JaxrConnectionFactory MyPool
Connector connection pool MyPool created.
Command create-connector-connection-pool executed successfully.

You get:
%asadmin list-connector-connection-pools
MyPool
Command list-connector-connection-pools executed successfully.

and
{"message":"","command":"list-connector-connection-pools AdminCommand","exit_code":"SUCCESS","extraProperties":{"methods":[

{"name":"GET"}

,{"messageParameters":{"targetName":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":"server"}

}}]},"children":[{"message":"MyPool","properties":{}}]}

When parsing the action report, there is no way to differentiate if there is a pool called "MyPool" or "Nothing to list".

I see the same thing happens to other list commands, eg list-jdbc-resources list-jms-resources, list-jndi-resources etc.

When listing the config element, eg. list-thread-pools list-virtual-servers etc, if there is no such elements, there is no "children" in the action report. I believe this is the correct behavior.
eg.

{"message":"","command":"list-threadpools AdminCommand","exit_code":"SUCCESS","extraProperties":{"methods":[

{"name":"GET"}

,{"messageParameters":{"id":

{"acceptableValues":"","optional":"false","type":"string","defaultValue":"server"}

}}]}}

We need to fix the list-xxx commands such that no 'children' should be created in the action report when there is no child at all, instead of saying there is a child with the name "Nothing to list".



 Comments   
Comment by Tom Mueller [ 08/Jul/11 ]

Assigning to Jagadish to deal with the connector related commands.

Not outputting "Nothing to list" is in line with the asadmin output guidelines here:

http://wikis.sun.com/display/GlassFish/Asadmin+Command+Output+Guidelines

Comment by Jagadish [ 26/Jul/11 ]

Excluding the issue for 3.1.1 as its not critical. We can fix it in trunk/next release.

Providing the email exchanges between Anissa, Tom and Jagadish.

-----------------------------------------------------------------------------------------------------------------------------
OK. I shall remove the output "Nothing to List" to keep it uniform.

Tom : You may have to look at all modules / send email to all module
owners as I see other modules also having "Nothing to List" message in
the code/logStrings.

Thanks,
-Jagadish

> > On 7/11/11 11:20 AM, Tom Mueller wrote:
> > > While I understand the concerns over compatibility, please note
> > > that the adopted standard now for commands is to not output a
> > > "Nothing to list" message when there is nothing to list.
> > From the Guidelines:
> > 10. When a list has no items, then output a "Nothing to list"
> > message if and only if column headings are turned on. If there are
> > no column headings, then output nothing for an empty list.
> >
> > Anissa.
> > > Please see:
> > >
> > > http://wikis.sun.com/display/GlassFish/Asadmin+Command+Output
> > > +Guidelines
> > >
> > > Thanks.
> > > Tom
> > >
> > > On 7/11/2011 11:35 AM, Anissa Lam wrote:
> > > >
> > > > Hi Jagadish,
> > > >
> > > > Thanks for looking into this. So, instead of
> > > > {"message":"","command":"list-connector-connection-pools
> > > > AdminCommand","exit_code":"SUCCESS","extraProperties":{"methods":[

{"name":"GET"}

,{"messageParameters":{"targetName":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":"server"}

}}]},"children":[{"message":"Nothing to list.","properties":{}}]}
> > > >
> > > > it will become:
> > > >
> > > > {"message":"Nothing to list
> > > > ","command":"list-connector-connection-pools
> > > > AdminCommand","exit_code":"SUCCESS","extraProperties":{"methods":[

{"name":"GET"}

,{"messageParameters":{"targetName":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":"server"}

}}]}
> > > >
> > > > That will be fine from GUI's perspective. cc'ing Tom and Jason
> > > > in case they have any concern.
> > > >
> > > > thanks
> > > > Anissa.
> > > >
> > > > On 7/11/11 7:54 AM, Jagadish Prasath Ramu wrote:
> > > > > http://java.net/jira/browse/GLASSFISH-16993
> > > > >
> > > > >
> > > > > Hi Anissa,
> > > > >
> > > > > I am looking into the above issue where you suggested not to add a child
> > > > > to action report when there are no resources to list.
> > > > > "Nothing to list" is currently added as child of TopMessagePart of
> > > > > ActionReport.
> > > > >
> > > > > I looked at v2.x behavior and different command yields different
> > > > > results
> > > > > ie.,
> > > > > some commands display "Nothing to list"
> > > > > and
> > > > > some commands do not display the text.
> > > > >
> > > > > Is it fine from GUI's perspective if we add the message "Nothing to
> > > > > list" to the TopMessagePart of the ActionReport instead of the child of
> > > > > TopMessagePart so that we don't break backward compatibility ?
> > > > >
--------------------------------------------------------------------------------------------------------------------------------

Comment by Jagadish [ 28/Nov/11 ]

FIX IN TRUNK :

svn log -v -r 51140

r51140 | jr158900 | 2011-11-27 18:32:52 +0530 (Sun, 27 Nov 2011) | 6 lines
Changed paths:
M /trunk/main/appserver/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListConnectorConnectionPools.java
M /trunk/main/appserver/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListConnectorResources.java
M /trunk/main/appserver/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListConnectorSecurityMaps.java
M /trunk/main/appserver/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListResourceAdapterConfigs.java
M /trunk/main/appserver/jdbc/admin/src/main/java/org/glassfish/jdbc/admin/cli/ListJdbcConnectionPools.java
M /trunk/main/appserver/jdbc/admin/src/main/java/org/glassfish/jdbc/admin/cli/ListJdbcResources.java
M /trunk/main/appserver/resources/javamail/javamail-connector/src/main/java/org/glassfish/resources/javamail/admin/cli/ListJavaMailResources.java
M /trunk/main/appserver/resources/resources-connector/src/main/java/org/glassfish/resources/admin/cli/ListCustomResources.java
M /trunk/main/appserver/resources/resources-connector/src/main/java/org/glassfish/resources/admin/cli/ListJndiResources.java

svn log -v -r 51142
------------------------------------------------------------------------
r51142 | jr158900 | 2011-11-27 18:34:44 +0530 (Sun, 27 Nov 2011) | 5 lines
Changed paths:
M /trunk/main/appserver/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListAdminObjects.java

FIX IN 3.1.2 :

svn log -v -r 51138
------------------------------------------------------------------------
r51138 | jr158900 | 2011-11-26 23:15:12 +0530 (Sat, 26 Nov 2011) | 5 lines
Changed paths:
M /branches/3.1.2/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListAdminObjects.java
M /branches/3.1.2/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListConnectorConnectionPools.java
M /branches/3.1.2/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListConnectorResources.java
M /branches/3.1.2/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListConnectorSecurityMaps.java
M /branches/3.1.2/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListCustomResources.java
M /branches/3.1.2/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListJavaMailResources.java
M /branches/3.1.2/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListJndiResources.java
M /branches/3.1.2/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ListResourceAdapterConfigs.java
M /branches/3.1.2/jdbc/admin/src/main/java/org/glassfish/jdbc/admin/cli/ListJdbcConnectionPools.java
M /branches/3.1.2/jdbc/admin/src/main/java/org/glassfish/jdbc/admin/cli/ListJdbcResources.java





[GLASSFISH-16954] asadmin complains about "Unknown plain text format" when deployment fails Created: 04/Jul/11  Updated: 24/Oct/11  Resolved: 13/Jul/11

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

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

Win7 Pro SP1 64 Bit de_DE


Attachments: File basicwebapp.war    
Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

I am trying to deploy an application using "asadmin deploy --retrieve . SuperSimple.ear". Due to a bug in that EAR, deployment fails. This is a typical situation when still in development, so asadmin should be clever enough to handle this with a message like "Deployment failed due to...".

But what it actually says is "Unknown plain text format.". Least programmers will understand that this actually means: "Everything is OK, you just have a typo in your EAR"...!

c:\Users\Karg\workspace\CreateComplaintsRS\dist>C:\glassfish3\bin\asadmin deploy --retrieve . SuperSimple.ear
remote failure: Unknown plain text format. A properly formatted response from a PlainTextActionReporter
always starts with one of these 2 strings: PlainTextActionReporterSUCCESS or PlainTextActionReporterFAILURE. The response we re
ceived from the server was not understood: Signature-Version: 1.0
message: Error occurred during deployment: Exception while preparing t
he app : Exception [EclipseLink-28018] (Eclipse Persistence Services

  • 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityMa
    nagerSetupException
    Exception Description: Predeployment of
    PersistenceUnit [QUIPSY] failed.
    Internal Exception: Excepti
    on [EclipseLink-7163] (Eclipse Persistence Services - 2.2.0.v20110202
    %%%EO13): org.eclipse.persistence.exceptions.ValidationException
    L%%%Exception Description: Entity class [class de.quipsy.persistency.
    suppliedPart.SuppliedPartPk] has both an @EmbdeddedId (on attribute [
    pk]) and an @Id (on attribute [customerId]. Both ID types cannot be s
    pecified on the same entity.. Please see server.log for more details.

Exception while invoking class org.glassfish.persistence.jpa
.JPADeployer prepare method : javax.persistence.PersistenceException:
Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.2.0.
v20110202-r8913): org.eclipse.persistence.exceptions.EntityManagerSet
upException
Exception Description: Predeployment of Persiste
nceUnit [QUIPSY] failed.
Internal Exception: Exception [Ecli
pseLink-7163] (Eclipse Persistence Services - 2.2.0.v20110202-r8913):
org.eclipse.persistence.exceptions.ValidationException
Exce
ption Description: Entity class [class de.quipsy.persistency.supplied
Part.SuppliedPartPk] has both an @EmbdeddedId (on attribute [pk]) and
an @Id (on attribute [customerId]. Both ID types cannot be specified
on the same entity.
Exception [EclipseLink-28018] (Eclipse P
ersistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence
.exceptions.EntityManagerSetupException
Exception Description: Prede
ployment of PersistenceUnit [QUIPSY] failed.
Internal Exception: Exc
eption [EclipseLink-7163] (Eclipse Persistence Services - 2.2.0.v2011
0202-r8913): org.eclipse.persistence.exceptions.ValidationException

Exception Description: Entity class [class de.quipsy.persistency.supp
liedPart.SuppliedPartPk] has both an @EmbdeddedId (on attribute [pk])
and an @Id (on attribute [customerId]. Both ID types cannot be speci
fied on the same entity.
name_value: SuperSimple
name_name: name
keys: name
use-main-children-attribute: false
exit-code: FAILURE

Command deploy failed.

c:\Users\Karg\workspace\CreateComplaintsRS\dist>



 Comments   
Comment by mkarg [ 04/Jul/11 ]

In addition to that nasty and wrong message, it is not very smart that my CLI can handle e. g. 160 columns per row, but GlassFish decides to just send much less (80 or so): Yes, the above formatting was done by GlassFish, not by me...!

That's not You and it's not GlassFish. It's the JDK 1.1 Manifest class doing the formatting.

Comment by Tom Mueller [ 05/Jul/11 ]

I'm not sure if this is a bug in the deploy command or in the response framework, so I'm assigning this to Tim first to see if it is a bug in deploy. If it is a bug in the response framework, please assign to Byron.

Comment by Tim Quinn [ 05/Jul/11 ]

Markus,

Which build of GlassFish are you using?

Can you please attach your app to this issue? It would help us in recreating exactly the conditions which cause the problem you noted. If you would rather not post it publicly you can e-mail it to me directly if you prefer.

Comment by Tim Quinn [ 05/Jul/11 ]

Using a current build of 3.1.1, I deployed an app that creates tables in the database during deployment. Then I undeployed without removing the tables. The next deployment of the app was reported as "completed with warnings" after listing the database messages because the tables were already there.

I am not using Markus's application, so there clearly could be important differences. But at least in 3.1.1 this case looks to be working.

Markus, this emphasizes how valuable it will be for me to use your app itself. Thanks.

Comment by mkarg [ 06/Jul/11 ]

Tim, wanted to send you my EAR, but your server first refused the mail due to it's size, then refused to accept any mails:

tjquinn@oracle.com on 06.07.2011 09:20
The message cannot be delivered due to a configuration error on the server. Please contact your Administrator.
<quipsy.de #5.3.0 smtp;553 5.3.0 <tjquinn@oracle.com>... 550:5.7.1 Email address is not available.>

Can you please send me an email addess to karg@quipsy.de where I can push the EAR to?

Comment by mkarg [ 06/Jul/11 ]

Tim, cannot answer to the email you sent me via att.net:

Your message did not reach some or all of the intended recipients.

Subject: RE: Getting your app to test the GlassFish issue
Sent: 06.07.2011 13:26

The following recipient(s) cannot be reached:

Tim Quinn on 06.07.2011 13:26
There was a SMTP communication problem with the recipient's email server. Please contact your system administrator.
<quipsy.de #5.5.0 smtp;521-87.234.217.170 blocked by sbc:blacklist.mailrelay.att.net.>

If you like I can upload the encrypted ZIP to our public FTP server, but how to send you the secret password?

Comment by Tim Quinn [ 06/Jul/11 ]

I have diagnosed this problem this far:

The server is using a PropsFileActionReporter to capture the result of this command (as it does for all asadmin commands).

The admin CLI client fails, though, when it tries to convert the response into a Manifest (which is how command results are returned to the client after admin command execution). I stepped through it enough to know that the Attributes class (in Java SE) throws an IOException with "invalid header field" – from line 389 in the Attributes class - from the invocation of the Manifest(InputStream) constructor in the AdminCommandResponse constructor.

Because the RemoteResponseManager assumes that any IOException in reading the input stream as a manifest is due to it not being a manifest - as opposed to it being a manifest that's not properly formatted - it goes on and tries to interpret it as a plain text response message - which it is not - and that code then complains because the response lacks one of the expected prefixes for plain text responses.

I suspect that by composing the message for the action report by adding on the exception message is what's causing the problem. Looking at the message Markus posted in his original description, there is a blank line followed by

Exception while invoking class org.glassfish.persistence.jpa
.JPADeployer prepare method : (more text)

which I suspect the Manifest constructor is trying to interpret as a manifest attribute. Because the text to the left of the : is not a legal attribute name, the Attributes class throws the IOException.

I am looking at an inexpensive way to process such error messages in DeployCommand to prevent the manifest reader from incorrectly interpreting the error display as an attribute.

Comment by Tim Quinn [ 06/Jul/11 ]

As Tom suggested earlier, I am reassigning this to Byron.

The PropsFileActionReporter's setMessage method needs to format the message in a way that the message cannot be confused as a manifest attribute setting. It already does some similar work to handle line separators in the message.

This is not something the caller should do, because other formats of reporter do not have this restriction and other places other than the caller in this case (DeployCommand) might set the message to similar unfriendly values.

Comment by mkarg [ 07/Jul/11 ]

Side note: The above explanation is a good example while people nowadays tend to prefer REST. A RESTful asadmin would just do a HTTP PUT with the complete EAR, the server would try to deploy it, and send one single XML file back with a list of all deployment issues, which asadmin can parse by simple JAXP.unmarshal(file). No need to fiddle around with custom classes and complex things like Manifests and PropsFileActionReporters etc. Maybe the asadmin team likes to think about that for GF 4...

Comment by mkarg [ 11/Jul/11 ]

Any news?

Comment by Byron Nevins [ 11/Jul/11 ]

I have no way to reproduce this. There is no ear attachment.

Comment by Byron Nevins [ 11/Jul/11 ]

Please attach the output when AS_DEBUG is set to true.

Comment by Byron Nevins [ 11/Jul/11 ]

Reopen after providing a way to reproduce please...

Comment by Tim Quinn [ 11/Jul/11 ]

Marcus provided a sample app which I will (separately) send to Byron.

Comment by Byron Nevins [ 11/Jul/11 ]

Is there something wrong with attaching it to JIRA?

Comment by Byron Nevins [ 11/Jul/11 ]

I will reopen this if and when I can reproduce it.

Comment by Tim Quinn [ 11/Jul/11 ]

As I wrote to Byron separately, the app cannot be shared publicly so it cannot be attached to the issue.

Turns out my earlier e-mail to Byron did not go through. I am providing him the sample app separately.

Comment by Byron Nevins [ 11/Jul/11 ]

Mitesh says this should demonstrate the bug

Comment by Byron Nevins [ 11/Jul/11 ]

Nope. That war file does NOT show the bug:

=== This Issue remain non-reproducible ===

fetchCommandModel: got command opts: com.sun.enterprise.admin.util.CommandModelData@1037c71
doHttpCommand succeeds
Process program options
Parsing program options
Parse command options
params: {}
operands: [basicwebapp.war]
Prevalidate command options
Inject command options
Validate command options
asadmin --host localhost --port 4848 --user admin --interactive=true --echo=false --terse=true deploy --force=false --precompilejsp=false --verify=fal
se --generatermistubs=false --availabilityenabled=false --asyncreplication=true --keepreposdir=false --keepfailedstubs=false --isredeploy=false --logr
eportederrors=true basicwebapp.war
Execute command
removing --upload option
doUpload set to false
FILE PARAM: DEFAULT = D:\j2eeapps\basicwebapp.war
URI: /__asadmin/deploy?DEFAULT=D%3A%5Cj2eeapps%5Cbasicwebapp.war
URL: com.sun.enterprise.admin.util.HttpConnectorAddress@1ef8cf3
URL: http://localhost:4848/__asadmin/deploy?DEFAULT=D%3A%5Cj2eeapps%5Cbasicwebapp.war
Password options: null
Using auth info: User: admin, Password: <null>
------- RAW RESPONSE ---------
Signature-Version: 1.0
message: Error occurred during deployment: Exception while preparing t
he app : Exception [EclipseLink-28018] (Eclipse Persistence Services

  • 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityMa
    %%%EOL%%%Exception Description: Predeployment of
    %%%EOL%%%Internal Exception: Excep.
    tion [EclipseLink-7333] (Eclipse Persistence Services - 2.2.0.v201102
    %%%-r8913): org.eclipse.persistence.exceptions.ValidationException
    EOL%%%Exception Description: The reference column name [foo] mapped o
    n the element [field userCredentials] does not correspond to a valid
    field on the mapping reference.. Please see server.log for more detai
    ls.
    name_value: basicwebapp
    name_name: name
    keys: name
    use-main-children-attribute: false
    exit-code: FAILURE

------- RAW RESPONSE ---------
PROCESSING MANIFEST...
remote failure: Error occurred during deployment: Exception while preparing the app : Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.
2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityManagerSetupException
Exception Description: Predeployment of PersistenceUnit [pujavaee] failed.
Internal Exception: Exception [EclipseLink-7333] (Eclipse Persistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.Validation
Exception
Exception Description: The reference column name [foo] mapped on the element [field userCredentials] does not correspond to a valid field on the mappi
ng reference.. Please see server.log for more details.
Command deploy failed.

d:\j2eeapps>

Comment by Byron Nevins [ 13/Jul/11 ]

Comment from my code checkin

16954
GIGO. The server, actually Deployment, is sending back a corrupt (garbage!!) Manifest object. The JDK Manifest class implementation itself fails to parse it.
There is absolutely nothing that CLI can do to "fix" this.
BUT – the error message was not correct – it incorrectly assumed that it was a badly formatted plaintext return object.
I fixed the error message. The real fix must be done server-side in deployment code.

Comment by Hong Zhang [ 13/Jul/11 ]

assign to tim to follow up as tim had previously worked on it already

Comment by Tim Quinn [ 13/Jul/11 ]

I do not see how it is deployment that is the problem here. Deployment invokes the published methods on ActionReport to set the report's message. (DeployCommand, line 440)

It should be up to the various report implementations - such as PropsFileActionReporter - to do the right thing with the values presented to it. Because it's PropsFileActionReporter that knows it expresses the report as a manifest, it should be that class that does whatever is needed to correctly handle any value passed to it so it does not create an invalid manifest.

I'm passing the baton back to the admin component, because it cannot be deployment's responsibility to know that the particular implementation of ActionReport at hand is not handling the message correctly.

Comment by Byron Nevins [ 13/Jul/11 ]

Original problem is resolved





[GLASSFISH-16928] JVM crash after autodeployment Created: 30/Jun/11  Updated: 11/Jun/12  Resolved: 11/Jun/12

Status: Closed
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: future release

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

VMware virtual machine with 384 MB of RAM, running RHEL 5 (64-bit)


Attachments: Zip Archive hs_err.zip    
Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Every once in a while, it happens that JVM will crash after autodeployment and there will be no JVM process running. server.log will not show any traces of the crash, however there will be a hs_err_pid*.log. I am attaching two such logs to this issue.



 Comments   
Comment by Hong Zhang [ 05/Jul/11 ]

assign to tim to take a look as he is more familiar with this area

Comment by Tim Quinn [ 05/Jul/11 ]

Does this happen with only a single application, or does the same problem afflict more than one app?

There seem to be some Java SE bugs related to replacing ZIP (and therefore JAR files) while the Java VM has already opened the file.

Might these errors happen if you rapidly deploy the app twice in a row, so that (occasionally) the autodeployer would have the file open and be processing it at the same time that you auto-deploy the same app file again?

Currently, the autodeployer renames the application file after the deployment has finished. We might consider making a change so that autodeployment renames the file to an "in-progress" name when processing first starts. This might help avoid this particular scenario, if in fact that is what is causing the problem.

Comment by ariod [ 06/Jul/11 ]

Thanks for the comment. We're using only two applications, but this issue has occurred on both. We also try not to deploy them too rapidly, the interval is 5-10 minutes at a minimum. The deployment is done through a Maven goal (Ant plugin), so perhaps its implementation may sometimes upload the same file two times in a very short interval, triggering the Java SE bug.

Comment by Tim Quinn [ 25/Jul/11 ]

Alleged bugs in Java SE related to this:

Bug ID: 6366468 SIGSEGV from memcpy - ZipFile.getEntry(JLjava/lang/String;Z)J+0 j java.util.zip.ZipFile
BUGID: 4766057 Reading entries from certain zipped files causes

(copied from this forum thread: http://forums.oracle.com/forums/thread.jspa?threadID=2164213&tstart=-1 )

Comment by Tim Quinn [ 11/Jun/12 ]

We've been unable to reproduce this here, and our best information is that this is due to a Java SE problem.

So, I'm closing this now. If the problem recurs please re-open the issue.





[GLASSFISH-16912] getUsernameAndPassword method in SecurityMechanismSelector contains a unchecked cast to PasswordCredential resulting in ClassCastException for custom LoginModules Created: 25/Jun/11  Updated: 20/Dec/16  Resolved: 25/Oct/11

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

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

Tags: 3_1_1-exclude, 3_1_1-scrubbed

 Description   

Line 863 of com.sun.enterprise.iiop.security.SecurityMechanismSelector.java contains a unchecked cast to PasswordCredential for all items saved in the subjects private credentials.
Since it is allowed to add Objects as private credentials (subject.getPrivateCredentials().add(Object cred)) the cast should be checked.
This results in a ClassCastException for custom LoginModules which save non PasswordCredential in the private credentials set.

SecurityMechanismSelector.java
Set privateCredSet = (Set) AccessController.doPrivileged(new PrivilegedAction() {
    public java.lang.Object run() {
      return sub.getPrivateCredentials();
    }
  });
.....
.....
final Iterator it = privateCredSet.iterator();
for(;it.hasNext();){
  AccessController.doPrivileged(new PrivilegedAction(){
    public java.lang.Object run(){
      PasswordCredential pc = (PasswordCredential) it.next(); // <--- Cast should be checked
      pc.setRealm(realm_name);
      return null;
    }
  });
}


 Comments   
Comment by kumarjayanti [ 04/Jul/11 ]

nithya to fix it in the trunk ASAP

Comment by Nithya Ramakrishnan [ 25/Oct/11 ]

Fixed in both into the trunk and 3.1.2 branches





[GLASSFISH-16885] GlassfishRoleMapper in in-memory JACC package cannot work Created: 21/Jun/11  Updated: 15/Nov/11  Resolved: 15/Nov/11

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

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

Tags: 3_1_1-exclude, 3_1_1-next, 3_1_1-scrubbed, jacc, security

 Description   

GlassfishRoleMapper.java (http://java.net/projects/glassfish/sources/svn/content/trunk/v3/security/inmemory.jacc.provider/src/main/java/com/sun/enterprise/security/jacc/provider/GlassfishRoleMapper.java?rev=47593) looks like it cannot possibly function.

GlassfishRoleMapper is a RoleMapper implementation that is shipped as part of the in-memory JACC provider. It is supposed to help provide insight into how to do principal-to-role-mapping when implementing a JACC provider. It appears that such role mapping-required for a JACC provider to operate-is impossible? maybe?



 Comments   
Comment by kumarjayanti [ 11/Aug/11 ]

Hi laird,

Is this still an issue or can we close this ?.

Comment by Nithya Ramakrishnan [ 20/Oct/11 ]

Hi Laird,

Do you mean that you need to understand how to provide a custom role mapping using the in memory JACC provider? We could help you with a sample test case, if that is the case. If not, could you please clarify your exact requirements?

Thanks
Nithya

Comment by Nithya Ramakrishnan [ 15/Nov/11 ]

The RoleMapper functionality works as designed.
The cleanup required for the class would be done as part of 4.0





[GLASSFISH-16883] Error message is not trying very hard Created: 20/Jun/11  Updated: 15/Nov/11  Resolved: 28/Jun/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 3.1.2, 4.0

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Yamini K B
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-exclude

 Description   

Here is the command that I ran on a Solaris 10 Sparc machine:

~/gf/v2/appserv-tests/devtests/admin/cli>asadmin create-node-ssh --nodehost localhost --install --installdir /tmp/a node1
remote failure: Failed to install GlassFish on localhost. Please check the DAS server.log.
Command create-node-ssh failed.

It very politely asked me to look somewhere else, the server.log file, because it apparently does not know what happened. So here is the server.log

[#|2011-06-20T14:31:06.782-0700|INFO|glassfish3.2|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=15;_Thread
Name=Thread-1;|Running command on DAS: /export/home/bnlocal/glassfish3/glassfish/bin/asadmin --interactive=false install-node --installdir /tmp/a --sshuser $

{user.name}

--sshport 22 --sshkeyfile /export/home/bnlocal/.ssh/id_rsa localhost|#]

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

I have no idea what went wrong. Neither the command nor the server.log told me anything useful.



 Comments   
Comment by carlavmott [ 23/Jun/11 ]

looking at this now.

Comment by carlavmott [ 24/Jun/11 ]

Did you determine what the problem was? Did the install fail?

Comment by Byron Nevins [ 24/Jun/11 ]

Yes it definitely failed. This is from the SSH admin dev tests

Comment by carlavmott [ 24/Jun/11 ]

Reassigning to Yamini as this is failing in install node. It should print a message in the log file or to the console since it knows what the real problem is.

Comment by Yamini K B [ 27/Jun/11 ]

create-node-ssh invokes install-node but is not logging the captured output stream in server log, can be fixed.

Comment by Yamini K B [ 27/Jun/11 ]

Fix checked in on trunk r47708.





[GLASSFISH-16868] Monitoring AMX MBeans not getting created Created: 15/Jun/11  Updated: 20/Dec/16  Resolved: 13/Dec/11

Status: Resolved
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0
Fix Version/s: 4.0_dev

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

WinXP


Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

I see 404 messages with IDs MNTG0201 and MNTG0204 in my server.log after
a QL run on the latest 3.2 workspace but they do not show up in Hudson's
logs. Maybe a Windows only issue?

[#|2011-06-15T11:19:51.123+1000|WARNING|glassfish3.2|javax.enterprise.sy
stem.tools.monitor.org.glassfish.admin.monitor|_ThreadID=29;_ThreadName=
Thread-1;|MNTG0201:Flashlight listener registration failed for listener
class : com.sun.ejb.monitoring.stats.StatefulSessionBeanStatsProvider ,
will retry later |#]

[#|2011-06-15T11:19:51.170+1000|INFO|glassfish3.2|javax.enterprise.syste
m.tools.monitor.org.glassfish.admin.monitor|_ThreadID=29;_ThreadName=Thr
ead-1;|MNTG0204:com.sun.ejb.monitoring.stats.EjbMethodStatsProvider is
not a ManagedObject and will not be registered with Gmbal to create an
MBean|#]

Especially the latter is not particularly informative to users like me.
Can't it be logged with level FINE?

Jennifer added:
The MNTG0201 msg may be ok
The MNTG0204 msg means the monitoring AMX MBean are not getting
created. I ran ql on windows and see these messages also. And the
mbeans don't appear in jconsole.
Definitely a bug. Maybe it should be logged as SEVERE or WARNING.



 Comments   
Comment by Jennifer Chou [ 16/Jun/11 ]

In StatsProviderManagerDelegateImpl the call to ManagedObjectManagerFactory.createFederated(MONITORING_SERVER) is returning ManagedObjectManagerNOPImpl, which always returns false for isManagedObject(..).

In the ManagedObjectManagerFactory the call to objectNameCons.create( rootParentName ), where rootParentName is "amx:name=server,pp=/mon,type=server-mon", always returns null, which is why the ManagedObjectManagerNOPImpl is returned above.

Ken - Can you see why does create return null here?

StatsProviderManagerDelegateImpl.java (admin\monitor)
=====================================================

MONITORING_SERVER = AMXGlassfish.DEFAULT.serverMon(instanceName);

private ManagedObjectManager registerGmbal(Object statsProvider, String mbeanName) {
ManagedObjectManager mom = null;
try {
// 1 mom per statsProvider
mom = ManagedObjectManagerFactory.createFederated(MONITORING_SERVER);<-----
if (mom != null) {
mom.setJMXRegistrationDebug(true);
if (mom.isManagedObject(statsProvider))

{ ..................................................... }

else {
String spName = statsProvider.getClass().getName();
logger.log(Level.INFO, "notaManagedObject", new Object[]

{spName}

);
}
}

AMXGlassfish
============

public ObjectName serverMon(final String serverName)

{ return newObjectName("/mon", "server-mon", serverName); }

ManagedObjectManagerFactory (gmbal)
===========================

public static ManagedObjectManager createFederated(
final ObjectName rootParentName ) { <---- "amx:name=server,pp=/mon,type=server-mon"

ManagedObjectManager result = objectNameCons.create( rootParentName ) ;
if (result == null)

{ <----- result = null return ManagedObjectManagerNOPImpl.self ; }

else

{ return result ; }

}

The problem appears on windows but not on hudson.
To reproduce:

If you have run quicklook already:

1. asadmin start-domain
2. jconsole (connect remote localhost:8686, no user/password)

OR

1. asadmin start-domain
2. asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=HIGH
3. jconsole

Comment by Jennifer Chou [ 13/Jul/11 ]

Fixed by Snjezana on the GlassFish side:

47976 12.07.2011 21:22:19, by snjezana
Adding gmbal-api-only.jar to global exclude list since its presence is apparently
causing issues with monitoring runtime.
M /trunk/v3/packager/pom.xml

Justin - can you take a look on the Grizzly side if you need to scope this dependency on gmbal-api-only as "provided"?

Email thread on cause:

I see - gmbal-api-only.jar is being pulled into distribution as transitive maven dependency by recent trunk grizzly integrations. I think grizzly should be scoping this dependency as "provided" but in the meantime I'll add this jar to global exclude list so that should resolve the problem.

Thanks,

Snjezana

----- Original Message -----
From: jennifer.chou@oracle.com
To: snjezana.sevozenzerovic@oracle.com
Cc: jagadish.ramu@oracle.com, shalini.muthukrishnan@oracle.com
Sent: Tuesday, July 12, 2011 12:03:05 PM GMT -08:00 US/Canada Pacific
Subject: [Fwd: Re: Gmbal dependency]

Hi Snejzana,

Could the following be related to packaging changes? Somehow the gmbal-api-only.jar got added to the distribution. This is causing the monitoring mbeans to not get created (in ext4 filesystem). When I remove gmbal-api-only.jar from the modules directory, then the monitoring mbeans works fine.

Jennifer

-------- Original Message --------
Subject: Re: Gmbal dependency
Date: Tue, 12 Jul 2011 23:50:54 +0530
From: Jagadish Prasath Ramu <jagadish.ramu@oracle.com>
Reply-To: jagadish.ramu@oracle.com
Organization: Oracle
To: Jennifer Chou <jennifer.chou@oracle.com>
CC: Shalini <shalini.muthukrishnan@oracle.com>
References: <4E1BEB94.508@oracle.com> <4E1C7704.6090705@oracle.com>

Thanks to Sahoo, the root cause was due to the order in which the
modules get installed in a particular file system.
In ext4 filesystem, gmbal-api-only.jar is installed before gmbal.jar and
hence File.listFiles(..) bootstraps only gmbal-api.jar (Both
gmba-api.jar and gmbal.jar export common set of classes).
gmbal-api-only.jar looks for an implementation class which is in
gmbal.jar. As gmbal.jar is not resolved, MBeans were not registered.
As Shalini stated, duplicate classes should not be there.


Thanks,
-Jagadish
Sun, an Oracle Company.

On Tue, 2011-07-12 at 12:32 -0400, Jennifer Chou wrote:
> Ah ha thanks for finding this! I have been trying to track down which
> revision was the cause of breaking the monitoring mbeans because I
> noticed also the ManagedObjectManagerNOPImpl being returned.
>
> I can reproduce this also on my window laptop.
>
> Thanks,
> Jennifer
>
> On 7/12/2011 2:37 AM, Shalini wrote:
> > Hi Jennifer,
> >
> > We observed that there are 2 jars : gmbal.jar and gmbal-api-only.jar
> > in the latest trunk workspace, whereas in 3.1.1 there is just one :
> > gmbal.jar. gmbal-api-only.jar is a subset of the gmbal.jar and this
> > causes some issues on an ext4 filesystem. The ManagedObjectManagerImpl
> > could not be resolved and only a ManagedObjectManagerNOPImpl is
> > returned while a register is done on the stats provider object. When
> > this is used to do isManagedObject(), it always returns false and
> > hence the stats providers are not registered.
> >
> > This can be reproduced on any ext4 filesystem on the latest trunk
> > build. You could do an "ant all" under
> > appserv-tests/devtests/jdbc/markconnectionasbad.xa testcase. We would
> > get an InstanceNotFoundException. This should be fixed by removing the
> > duplicate gmbal-api-only.jar dependency.
> >
> > Thanks
> > Shalini.
> >

Comment by Jennifer Chou [ 13/Jul/11 ]

Can you check for Grizzly if you need to scope the dependency on gmbal-api-only as "provided"?

Comment by oleksiys [ 13/Dec/11 ]

had to be fixed as part of Grizzly->GF repackaging.





[GLASSFISH-16817] Editing IIOP Listener Bind Address Causes Listener to Fail to Start Created: 07/Jun/11  Updated: 20/Dec/16  Resolved: 27/Oct/11

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

Type: Bug Priority: Major
Reporter: charles904 Assignee: Harshad Vilekar
Resolution: Cannot Reproduce Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 5.6 x86_64
JDK 1.6.0_25


Tags: 3_1_1-exclude, 3_1_1-scrubbed

 Description   

Running:
asadmin --port 6248 set server-config.iiop-service.iiop-listener.orb-listener-1.address=localhost

Changed this snippet in my domain.xml:
<iiop-listener port="6237" id="orb-listener-1" address="0.0.0.0" lazy-init="true"></iiop-listener>
To this:
<iiop-listener port="6237" id="orb-listener-1" address="localhost" lazy-init="true">
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname=""></ssl>
</iiop-listener>

0) This domain was created with port base = 6200, but different port bases don't seem to make a difference.
1) There was no intention / action to make this a secure listener, and it doesn't add the security-enabled="true" attribute anyway.
2) The same command worked fine with 3.0.
3) This happens whether its localhost or a real host name (which we need to use to perform a workaround of our server being behind a NAT gateway as viewed by some clients).

The end result is that the default IIOP listener doesn't start up, and the output below is printed to the server log. You'll see the "Lazy-init not supported for SSL iiop-listeners" message, which is the apparent result of the unintended side effect of adding the <ssl> child element.

[#|2011-06-02T14:30:23.468-0400|WARNING|glassfish3.1|javax.enterprise.system.org.glassfish.enterprise.iiop.api|_ThreadID=30;_ThreadName=Thread-1;|ORB initialization failed in lazy init
java.lang.RuntimeException: Orb initialization erorr
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:148)
at org.glassfish.enterprise.iiop.api.ORBLazyServiceInitializer.initializeService(ORBLazyServiceInitializer.java:87)
at com.sun.enterprise.v3.services.impl.ServiceInitializerHandler.onAcceptInterest(ServiceInitializerHandler.java:107)
at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKey(SelectorHandlerRunner.java:301)
at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKeys(SelectorHandlerRunner.java:263)
at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:200)
at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:132)
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: java.lang.RuntimeException: java.lang.IllegalStateException: Invalid iiop-listener orb-listener-1. Lazy-init not supported for SSL iiop-listeners
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:622)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:263)
at org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:120)
... 9 more
Caused by: java.lang.IllegalStateException: Invalid iiop-listener orb-listener-1. Lazy-init not supported for SSL iiop-listeners
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.validateIiopListeners(GlassFishORBManager.java:758)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:504)
... 12 more

#]


 Comments   
Comment by Harshad Vilekar [ 27/Oct/11 ]

Could not duplicate this with 3.1.2_b07 nightly.

asadmin --port 6248 set server-config.iiop-service.iiop-listener.orb-listener-1.address=localhost

---------- server log --------------

[#|2011-10-27T15:43:02.242-0700|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=14;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.36 started in: 102ms - bound to [0.0.0.0:6248]|#]

[#|2011-10-27T15:43:02.241-0700|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=11;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.36 started in: 69ms - bound to [localhost:6237]|#]

[#|2011-10-27T15:43:02.243-0700|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=15;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.36 started in: 172ms - bound to [0.0.0.0:6280]|#]

:
---------- server log --------------

domain.xml:

<iiop-listener port="6237" id="orb-listener-1" address="localhost" lazy-init="true"></iiop-listener>
<iiop-listener port="6238" id="SSL" address="0.0.0.0" security-enabled="true">
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as"></ssl>
</iiop-listener>





[GLASSFISH-16782] status not available for http load balancers Created: 02/Jun/11  Updated: 21/Oct/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-16763 Porting Load Balancer Console Pages f... Closed
Tags: 3_1-next, 3_1_, 3_1_1-exclude, 3_1_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

In v2.1.1, while listing http load balancers table contains data (name,target,status)

status is found with the following code

LoadBalancer lb = AMXUtil.getDomainRoot().getLoadBalancerMap().get(key);
if( lb != null)

{ status = GuiUtil.getMessage(lb.isApplyChangeRequired()? "loadBalancer.needApply" : "loadBalancer.upToDate"); }

In v3, to find status what is the call for lb.isApplyChangeRequired(). If back end call is there, we need to create rest api conversion for this.



 Comments   
Comment by srinik76 [ 06/Jun/11 ]

Fix required for 3.1.1

Comment by kshitiz_saxena [ 07/Jun/11 ]

This issue requires some support implementation to detect changes in the load-balancer xml. This implementation must detect changes to cluster, instance, application, loadbalancer config etc. There is significant amount of work involved to achieve it, and cannot be fixed within timeline for 3.1.1. This issue will be taken up post 3.1.1.

In GUI we can remove column showing apply-changes status. It is already documented that auto-detection of load-balancer xml does not exist in 3.1 and will continue in 3.1.1 as well.





[GLASSFISH-16737] ClassCopierOrdinaryImpl call readResolve but It hasn't replace the original instance in oldToNew map. Created: 25/May/11  Updated: 08/Feb/12

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

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

Ubuntu 10.04 (i386, Version: 2.6.32-31-generic-pae)
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode)
Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs)


Tags: 3_1_1, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

I found these code from ClassCopierBase.java

/** Make the actual copy of source, using oldToNew to preserve aliasing.

  • This first checks to see whether source has been previously copied.
  • If so, the value obtained from oldToNew is returned. Otherwise,
  • <ol>
  • <li>createCopy( source ) is called to create a new copy of source.
  • <li>The new copy is placed in oldToNew with source as its key.
  • <li>doCopy is called to complete the copy.
  • <ol>
  • <p>This split into two phases isolates all subclasses from the need to
  • update oldToNew. It accommodates simple cases (arrays of primitives
  • for example) that only need to define createCopy, as well as more complex
  • case (general objects) that must first create the copy, update oldToNew,
  • and then do the copy, as otherwise self-references would cause
  • infinite recursion.
    */
    public final Object copy( Map oldToNew,
    Object source ) throws ReflectiveCopyException { return copy( oldToNew, source, false ) ; }

public final Object copy( Map oldToNew,
Object source, boolean debug ) throws ReflectiveCopyException
{
Object result = oldToNew.get( source ) ;
if (result == null)

{ result = createCopy( source, debug ) ; oldToNew.put( source, result ) ; result = doCopy( oldToNew, source, result, debug ) ; }

return result ;
}

The doCopy method may return another instance other than the one in arguments.
ClassCopierOrdinaryImpl#doCopy will call readResolve method and return the result.
Details of readResolve method can be found at
http://download.oracle.com/javase/1.3/docs/guide/serialization/spec/input.doc6.html

But neither ClassCopierOrdinaryImpl nor ClassCopierBase put the instance returned by
readResolve method to oldToNew map, If the source have two field point to same object.
If the Class of field have a readResolve method return other instance.After copy the
two field have different object,maybe they are not equals.

If I have a class Foo and Bar.
final class Foo {
Bar old;
Bar new;
}

final class Bar{
private final static Bar instance = new Bar();
private Bar(){}

public static Bar getInstance()

{ return instance; }
private Object readResolve(){ return instance; }

}

main() {
Foo foo = new Foo();
foo.old = Bar.getInstance();
foo.new = Bar.getInstance();
foo.old == foo.new //true
...After copy
copiedfoo.new == copiedfoo.old //false
}






[GLASSFISH-16720] Launcher Should have a Watchdog Mode Created: 24/May/11  Updated: 02/Dec/11  Resolved: 25/May/11

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-16732 Prepare Doc for Watchdog option Sub-task Resolved Gail Risdal  
Tags: 3_1_1-exclude

 Description   

start-server --verbose

What this REALLY does is :

(1) start a 'watchdog' process that maintains an invaluable reference to a java Process object for the started server
(2) shows all stdout/stderr output that appears before the Logging Service can be started in the server
(3) duplicates all the server.log messages

============
For the purposes of running as a Platform Service we want (1) but probably not 2 and definitely not 3. (3) is useful if there are a pair of human eyes attached. In the case of a Platform Service there's nobody around.

We are then filling up a potentially enormous logfile in domain-dir/bin – which is duplicate of server.log. Furthermore GF server itself has sophisticate log-rotation and handling features and platform services don't.

Conclusion:

Introduce a new option, --watchdog, which is like --verbose – without the verbosity.



 Comments   
Comment by Nazrul [ 24/May/11 ]

Forum thread: http://forums.java.net/node/803324

Comment by Byron Nevins [ 25/May/11 ]

The first part is finished! You can now start servers in "watchdog" mode. This new mode is EXACTLY like verbose mode except that it produces no output on the console.

e.g.

asadmin start-domain -w
asadmin start-domain --watchdog

Comment by Byron Nevins [ 25/May/11 ]

These changes added the watchdog option.
To do: Have platform services use this option. At least on Windows.

Sending admin\cli\src\main\java\com\sun\enterprise\admin\cli\StartDomainCommand.java
Sending admin\launcher\src\main\java\com\sun\enterprise\admin\launcher\GFLauncher.java
Sending admin\launcher\src\main\java\com\sun\enterprise\admin\launcher\GFLauncherInfo.java
Sending admin\launcher\src\main\java\com\sun\enterprise\admin\launcher\GFLauncherLogger.java
Sending admin\launcher\src\main\java\com\sun\enterprise\admin\launcher\LocalStrings.properties
Sending cluster\admin\pom.xml
Sending cluster\cli\pom.xml
Sending cluster\cli\src\main\java\com\sun\enterprise\admin\cli\cluster\StartLocalInstanceCommand.java
Sending cluster\common\pom.xml
Sending common\common-util\src\main\java\com\sun\enterprise\universal\process\ProcessStreamDrainer.java
Transmitting file data ..........
Committed revision 47089.

Comment by Byron Nevins [ 25/May/11 ]

Now fixed for Windows Services

Sending packager\nucleus-base\lib\install\templates\Domain-service-winsw.xml.template
Transmitting file data .
Committed revision 47090.

Comment by Byron Nevins [ 25/May/11 ]

Done.
SMF and Linux don't use the verbose option so only Windows needed to be changed.





[GLASSFISH-16681] "Exception while visiting com/sun/gjc/spi/base/PreparedStatementWrapper.class of size 9574" during QL Created: 18/May/11  Updated: 20/Dec/16  Resolved: 10/Nov/11

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

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

WinXP, GFv3.2 workspace (encountered since 28 April when I ran QL first)


Attachments: Zip Archive server.zip    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16972 ArrayIndexOutOfBoundsException at org... Closed
Tags: 3_1_1-exclude, 3_1_1-scrubbed

 Description   

When I run the QL tests (on the GF v3.2 workspace) I see the following error logged to server.log:

[#|2011-05-17T15:16:54.169+1000|SEVERE|glassfish3.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=14;_ThreadName=Thread-1;|Exception while visiting com/sun/gjc/spi/base/PreparedStatementWrapper.class of size 9574
java.lang.ArrayIndexOutOfBoundsException: 58
at java.util.ArrayList.add(ArrayList.java:352)
at org.glassfish.hk2.classmodel.reflect.impl.TypeImpl.addMethod(TypeImpl.java:94)
at org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visitMethod(ModelClassVisitor.java:227)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:361)
at org.glassfish.hk2.classmodel.reflect.util.JarArchive.onSelectedEntries(JarArchive.java:125)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:345)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:67)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:304)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:293)
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)

#]

I've seen it three times since 28 April when I started running QL on GFv3 trunk.
That is 3 out of 8 runs, so occasionally it's there.
It hasn't failed any tests though.

I've tried running single tests to see if I could narrow it down but no luck.
I've attached a server.log so you can see whereabouts in the QL it occurred the last time I saw it (around web/jsfinjection).



 Comments   
Comment by Dies Koper [ 18/May/11 ]

Fixing version.

Comment by scatari [ 02/Jun/11 ]

Not reproducible in 3.1.1.

Comment by Dies Koper [ 11/Jun/11 ]

Just a note that I'm still seeing this running QL on today's 3.2 workspace.
The location in the test run is the same as before, around 'jsfinjection':

[#|2011-06-11T16:26:53.503+1000|WARNING|glassfish3.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=12;_ThreadName=Thread-1;|WEB0361: Unable to delete D:\sources\OSS\GF\V3\v3\distributions\glassfish\target\stage\glassfish3\glassfish\domains\domain1\generated\jsp\jsfinjection\loader_31647828|#]

[#|2011-06-11T16:26:53.581+1000|INFO|glassfish3.2|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=12;_ThreadName=Thread-1;|Initializing Mojarra 2.1.1 (SNAPSHOT 20110404) for context '/jsfinjection'|#]

[#|2011-06-11T16:26:53.800+1000|SEVERE|glassfish3.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=14;_ThreadName=Thread-1;|Exception while visiting com/sun/gjc/spi/base/CallableStatementWrapper.class of size 12723
java.lang.ArrayIndexOutOfBoundsException: 88
at java.util.ArrayList.add(ArrayList.java:352)
at org.glassfish.hk2.classmodel.reflect.impl.TypeImpl.addMethod(TypeImpl.java:94)
at org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visitMethod(ModelClassVisitor.java:227)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:361)
at org.glassfish.hk2.classmodel.reflect.util.JarArchive.onSelectedEntries(JarArchive.java:125)
at org.glassfish.hk2.classmodel.reflect.util.DirectoryArchive.parse(DirectoryArchive.java:111)
at org.glassfish.hk2.classmodel.reflect.util.DirectoryArchive.onSelectedEntries(DirectoryArchive.java:92)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:345)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:67)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:304)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:293)
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)

#]

[#|2011-06-11T16:26:54.003+1000|INFO|glassfish3.2|org.hibernate.validator.engine.resolver.DefaultTraversableResolver|_ThreadID=12;_ThreadName=Thread-1;|Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.|#]

[#|2011-06-11T16:26:54.191+1000|INFO|glassfish3.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=12;_ThreadName=Thread-1;|[Filter.init]|#]

[#|2011-06-11T16:26:54.191+1000|INFO|glassfish3.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=12;_ThreadName=Thread-1;|WEB0671: Loading application [jsfinjection] at [/jsfinjection]|#]

Comment by dochez [ 10/Nov/11 ]

Could not reproduce the issue, but I made the array final and private and ensure that read/write accesses are monitored. hopefully this will fix it.

Comment by hanafey [ 21/Mar/12 ]

On GF 3.1.2 I get this exception when the domain is started:

[#|2012-03-21T16:27:34.153-0700|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=52;_ThreadName=Thread-2;|Exception while visiting com/sun/gjc/spi/jdbc40/ProfiledConnectionWrapper40.class of size 10655
java.lang.NullPointerException
        at org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
        at org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.objectweb.asm.ClassReader.accept(Unknown Source)
        at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
        at org.glassfish.hk2.classmodel.reflect.util.JarArchive.onSelectedEntries(JarArchive.java:125)
        at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
        at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
        at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
        at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)
|#]




[GLASSFISH-16587] request.getUserPrincipal() does not return MyPrincipal Created: 09/May/11  Updated: 17/Oct/15

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

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

Tags: 3_1-next, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

I've an own javax.security.auth.message.module.ServerAuthModule implementation.
In validateRequest() I put an instance of MyPrincipal to the callbackhandler
MyPrincipal myprincipal = ...;
callbackHandler.handle(new Callback[]

{ new CallerPrincipalCallback(clientSubject, myprincipal), new GroupPrincipalCallback(...) }

);
In the application request.getUserPrincipal() returns an instance of com.sun.enterprise.security.web.integration.WebPrincipal and NOT an instance of MyPrincipal!

In an ejb the call of ejbContext.getCallerPrincipal() does return an instance of MyPrincipal!

==> request.getUserPrincipal() should return the principal which is set in the ServerAuthModule



 Comments   
Comment by kumarjayanti [ 09/May/11 ]

yes this is a known issue and we made some work on it to get the behavior you are looking for. It is still not committed, more work to do.

Comment by kumarjayanti [ 18/May/11 ]

We will make an attempt to get this fixed for 3.1.1 but cannot commit based on resources and time left.

Comment by sultry [ 14/May/15 ]

Depends on this bug made that workaround:

private static Principal glassfishWorkAround(HttpServletRequest request) {
        Principal principal = null;
        try {
            Principal webPrincipal = request.getUserPrincipal();
            if (webPrincipal != null) {
                Class glassfishWrapper = Class.forName("com.sun.enterprise.security.web.integration.WebPrincipal");
                if (glassfishWrapper.isInstance(webPrincipal)) {
                    Field customPrincipal = glassfishWrapper.getDeclaredField("customPrincipal");
                    customPrincipal.setAccessible(true);
                    principal = (Principal) customPrincipal.get(webPrincipal);
                } else {
                    principal = webPrincipal;
                }
            }
        } catch (IllegalArgumentException | IllegalAccessException | NoSuchFieldException | SecurityException | ClassNotFoundException ex) {
            LOGGER.throwing("SecurityConstraint", "glassfishWorkAround", ex);
        }
        return principal;
}

public static Principal getPrincipal(HttpServletRequest request) {
        return glassfishWorkAround(request);
}

Hope it helps somebody! Anyway hope this bug will be resolved soon.

Comment by arjan tijms [ 17/Oct/15 ]

Any progress here?





[GLASSFISH-16455] Problem using https webservice client with mutual authentication Created: 26/Apr/11  Updated: 08/Nov/11  Resolved: 08/Nov/11

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

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

Red Hat Linux 2.6.18-92.el5 x86_64 x86_64 x86_64 GNU/Linux


Tags: 3_1-next, 3_1_1-exclude, keystore, masterpassword, truststore, webservice

 Description   

Scenario:
Cluster with two instances, one running on a local-node (INST_CLU_LOCAL) and another running on a remote-node (INST_CLU_REMOTE).

Issue:
I have a cluster that run a webservice client that consumes a service that requires mutual authentication. Everything works fine when the request starts from INST_CLU_LOCAL, but when the client starts from INST_CLU_REMOTE the follow error is trown
([#|2011-04-26T10:14:52.807-0300|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=146;_ThreadName=Thread-2;|AxisFault
faultCode:

{http://schemas.xmlsoap.org/soap/envelope/}

Server.userException
faultSubcode:
faultString: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
faultActor:
faultNode:
faultDetail:

{http://xml.apache.org/axis/}

stackTrace:javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at br.inf.portalfiscal.www.cte.wsdl.CTeDistribuicaoRFB.CTeDistribuicaoRFBSoapStub.cteDistribuicao(CTeDistribuicaoRFBSoapStub.java:179)
at br.gov.ce.sefaz.cte.facade.CTeFacade.cteDistribuicao(CTeFacade.java:62)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.cteDistribuicao(RecuperarCTEReceitaTimer.java:146)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.timeout(RecuperarCTEReceitaTimer.java:89)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5367)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:149)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4033)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1835)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2708)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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)

{http://xml.apache.org/axis/}

hostname:sd2awj12.sefazce.corp

javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:154)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at br.inf.portalfiscal.www.cte.wsdl.CTeDistribuicaoRFB.CTeDistribuicaoRFBSoapStub.cteDistribuicao(CTeDistribuicaoRFBSoapStub.java:179)
at br.gov.ce.sefaz.cte.facade.CTeFacade.cteDistribuicao(CTeFacade.java:62)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.cteDistribuicao(RecuperarCTEReceitaTimer.java:146)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.timeout(RecuperarCTEReceitaTimer.java:89)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5367)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:149)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4033)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1835)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2708)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.Fut|#]

[#|2011-04-26T10:14:52.808-0300|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=146;_ThreadName=Thread-2;|ureTask$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: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)
... 42 more

#])

I think that is a keystore password issue because I have changed the masterpassword, but I used --savemasterpassword and can manage my cluster trought the admin_gui.



 Comments   
Comment by kumarjayanti [ 18/May/11 ]

Not a 3.1.1 blocker. It is not clear that it is a GlassFish or a Metro WebServices problem. The user is using Apache AXIS webservice library and the SSL handshake error has Apache Axis calls at the bottom of the stack trace

Caused by: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)

Comment by mathcunha [ 21/May/11 ]

Hi,

I also figured out that the domain JDK was 1.6_14 and remote jdk was 1.6_21, and to make it works I had to enable the flag java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "true");. After that the problem was gone.

Is it a bug?!

Thank you

Comment by Tim Quinn [ 21/May/11 ]

If you have not already found it, please read through this article:

http://java.sun.com/javase/javaseforbusiness/docs/TLSReadme.html

which contains abundant information about this SSL handshaking issue.

GlassFish 3.1 and later are supported only with Java 1.6.0_22 or later for exactly this reason.

Comment by kumarjayanti [ 22/May/11 ]

http://weblogs.java.net/blog/kumarjayanti/archive/2010/11/18/ssl-renegotiation-issue-fixed-jdk16022?force=924

marking issue fixed.





[GLASSFISH-16344] Unable to start two domains on system where IPs are aliased to the same network interface. Created: 12/Apr/11  Updated: 18/Feb/13  Resolved: 18/Feb/13

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

Type: Bug Priority: Major
Reporter: Ryan Lubke Assignee: Byron Nevins
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

I'm trying to start two different domains on the same system, but have
run into some issues that I hope you may be able to help with.

Firstly, the machine I'm working with has a single NIC. The IP address
is 10.0.1.100. I've created an IP alias to this NIC, 192.168.0.100.

With a simple perl script, I'm able to bind the same port on either
address (i.e. bind a server on 10.0.1.100:5000 and 192.168.0.100:5000).

So, this confirms I have a basic working configuration.

Now, I create a second domain, domain2, and update all the appropriate
addresses to refer to 192.168.0.100. I update domain1 in a similar
fashion and set the addresses to 10.0.1.100.

I start domain1 using the following:

asadmin --host 10.0.1.100 start-domain --verbose domain1

I can see in the log that 10.0.1.100 is being used as expected.
However, when I attempt to start domain2 using:

asadmin --host 192.168.0.100 start-domain --verbose domain2

I receive the following error:

There is a process already using the admin port 4848 – it
probably is another instance of a GlassFish server.

I've looked through the code and came across this:

private static boolean isPortFreeServer(int port) {
// check 3 different ip-port combinations.
// Amazingly I have seen all 3 possibilities – so just
checking on 0.0.0.0
// is not good enough.
// Usually it is the 0.0.0.0 – but JMS (default:7676)
// only returns false from the "localhost":port combination.
// We want to be aggressively disqualifying ports rather than
the other
// way around

try {
byte[] allZero = new byte[]

{0, 0, 0, 0}

;
InetAddress add = InetAddress.getByAddress(allZero);

if (isPortFreeServer(port, add) == false)
return false; // return immediately on "not-free"

add = InetAddress.getLocalHost();

if (isPortFreeServer(port, add) == false)
return false; // return immediately on "not-free"

add = InetAddress.getByName("localhost");

return isPortFreeServer(port, add);
}
catch (Exception e)

{ // If we can't get an IP address then we can't check return false; }

}

which is invoked by StartServerHelper to ensure the port isn't already
bound.

In my environment, the second isPortFreeServer() fails as
InetAddress.getLocalHost() in this
case returns 10.0.1.100. While this return value is correct, this
appears to be a false positive.

Wouldn't it make sense, in the case when an explicit host and/or port is passed to asadmin
to perform the validation against those arguments instead of against the local addresses?



 Comments   
Comment by Byron Nevins [ 24/May/11 ]

Setting target to 3.2

RYAN –

Can you give me a simple way to reproduce this on my windows machine – i.e. step-by-step cookbook?

Comment by Ryan Lubke [ 24/May/11 ]

Unfortunately, I don't have easy access to a win32 environment so I can't tell you how to alias the IP.

The steps outside of the ip aliasing are there in the bug report.

Comment by Byron Nevins [ 18/Feb/13 ]

We have so many possible combinations and installations of networking. The current code is the result of years of testing and tweaking.

It is too dangerous to change this area of code for a very very rare situation.

Final solution: Don't do that!





[GLASSFISH-16326] javaee6 sample does not run on remote GF 3.1 Created: 06/Apr/11  Updated: 08/Dec/11

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

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

Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

I installed javaee6 with samples:
java_ee_sdk-6u2-jdk-linux-x64-ml.sh

I can run "automatic-timer" sample properly, when GF 3.1 runs on localhost.

If GF 3.1 runs on a remte host.
I set the remote GF 3.1 in bp-project/build.properties:
javaee.server.name=192.168.1.101

Now automatic-timer sample does not run:

[java] Waiting for the timer to expire
[java] Logged timeouts :
[java] org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: localhost; port: 3700 vmcid: OMG minor code: 1 completed: No
[java] at sun.reflect.GeneratedConstructorAccessor30.newInstance(Unknown Source)
[java] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[java] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[java] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
[java] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
[java] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
[java] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
[java] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
[java] at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
[java] at $Proxy26.connectFailure(Unknown Source)
[java] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:257)
[java] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:270)
[java] at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:129)
[java] at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:223)
[java] at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:228)
[java] at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:393)
[java] at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
[java] at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
[java] at com.sun.enterprise.naming.impl.SerialContext$ProviderCacheKey.getNameService(SerialContext.java:1241)
[java] at com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:411)
[java] at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:347)
[java] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:504)
[java] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
[java] at javax.naming.InitialContext.lookup(InitialContext.java:392)
[java] at enterprise.automatic_timer_client.AutomaticTimerJavaClient.getRecords(AutomaticTimerJavaClient.java:64)
[java] at enterprise.automatic_timer_client.AutomaticTimerJavaClient.main(AutomaticTimerJavaClient.java:53)
[java] Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused
[java] at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:340)
[java] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:242)
[java] ... 15 more
[java] Caused by: java.net.ConnectException: Connection refused
[java] at sun.nio.ch.Net.connect(Native Method)
[java] at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:500)
[java] at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:110)
[java] at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:325)
[java] ... 16 more
[java] javax.naming.NamingException: Lookup failed for 'java:global/automatic-timer-ejb/StatelessSessionBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl} [Root exception is javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl}

[Root exception is org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: localhost; port: 3700 vmcid: OMG minor code: 1 completed: No]]
[java] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
[java] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
[java] at javax.naming.InitialContext.lookup(InitialContext.java:392)
[java] at enterprise.automatic_timer_client.AutomaticTimerJavaClient.getRecords(AutomaticTimerJavaClient.java:64)
[java] at enterprise.automatic_timer_client.AutomaticTimerJavaClient.main(AutomaticTimerJavaClient.java:53)
[java] Caused by: javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext[myEnv=

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

[Root exception is org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: localhost; port: 3700 vmcid: OMG minor code: 1 completed: No]
[java] at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:352)
[java] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:504)
[java] ... 4 more
[java] Caused by: org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: localhost; port: 3700 vmcid: OMG minor code: 1 completed: No
[java] at sun.reflect.GeneratedConstructorAccessor30.newInstance(Unknown Source)
[java] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[java] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[java] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
[java] at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
[java] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
[java] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
[java] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
[java] at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
[java] at $Proxy26.connectFailure(Unknown Source)
[java] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:257)
[java] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:270)
[java] at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:129)
[java] at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:223)
[java] at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:228)
[java] at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:393)
[java] at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
[java] at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
[java] at com.sun.enterprise.naming.impl.SerialContext$ProviderCacheKey.getNameService(SerialContext.java:1241)
[java] at com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:411)
[java] at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:347)
[java] ... 5 more
[java] Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused
[java] at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:340)
[java] at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:242)
[java] ... 15 more
[java] Caused by: java.net.ConnectException: Connection refused
[java] at sun.nio.ch.Net.connect(Native Method)
[java] at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:500)
[java] at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:110)
[java] at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:325)
[java] ... 16 more
[java] Exception in thread "main" java.lang.NullPointerException
[java] at enterprise.automatic_timer_client.AutomaticTimerJavaClient.main(AutomaticTimerJavaClient.java:54)

Why does it use localhost instead of 192.168.1.106 ?
How can I run the sample against a remote GF 3.1 ?

Thank you



 Comments   
Comment by Tim Quinn [ 07/Apr/11 ]

Transfering to the ORB team, since the stack trace indicates the ORB cannot connect to the server.

Comment by Tim Quinn [ 07/Apr/11 ]

Forgot to change owner.

Comment by Harshad Vilekar [ 31/Oct/11 ]

For automatic-timer-client, please set the system property "org.omg.CORBA.ORBInitialHost" to point to the remote host running GlasFish.

For example, If the GlassFish server is running on 192.168.1.106, the automatic timer client on remote host works fine after adding following line to glassfish/samples/bp-project/java-client-ant.xml:
<jvmarg value="-Dorg.omg.CORBA.ORBInitialHost=192.168.1.106"/>

The sample build files and instructions need to be updated with this information.

Comment by scatari [ 08/Dec/11 ]

Will be supported in a feature release.





[GLASSFISH-16317] Some CORBA properties are ignored Created: 06/Apr/11  Updated: 20/Dec/16  Resolved: 31/Oct/11

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: v3.0.1
Fix Version/s: 3.1.2_dev

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

GlassFish Server Open Source Edition 3.0.1 (build 22)
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)


Tags: 3_1_1-exclude, 3_1_1-scrubbed, connection, jndi, orb, properties, timeout

 Description   

When specifying properties for Glassfish connection like :

org.omg.CORBA.ORBInitialHost='hostname'
org.omg.CORBA.ORBInitialPort='portnumber'

Other CORBA common properties seem to be ignored :

com.sun.corba.ee.transport.ORBWaitForResponseTimeout=5
com.sun.corba.ee.transport.ORBTCPConnectTimeouts=100:500:100:500
com.sun.corba.ee.transport.ORBTCPTimeouts=500:2000:50:1000

As you can see in this topic : http://blogs.sun.com/ejcorba/entry/client_side_transport_timeouts_and

Steps to reproduce :

  • Define the given properties in a new InitialContext
  • Start the application from Eclipse :
  • Once when Glassfish is started and the EAR deployed : everything is ok
  • Once when Glassfish is not started at all : The timeout properties are ignored ; you have to wait 1 or 2 minutes before a timeout to be thrown.


 Comments   
Comment by Cheng Fang [ 06/Apr/11 ]

re-categorize it to orb compoment.

Comment by Ken Cavanaugh [ 18/May/11 ]

No plan to fix in 3.1.1

Comment by Ken Cavanaugh [ 24/May/11 ]

Is this still a problem in 3.1.0? 3.0.1 shared a single ORB on the client side
for all naming contexts, while 3.1.0 does not. However, properties passed in
to the InitialContext are NOT passed on to the ORB. You'll need to set the
properties as system properties for the ORB to see them.

Comment by Harshad Vilekar [ 31/Oct/11 ]

Setting these properties as system properties works just fine with 3.1.2_b06 - The connection times out within 5 seconds.

Example:
java -Dcom.sun.corba.ee.transport.ORBWaitForResponseTimeout=5 -Dcom.sun.corba.ee.transport.ORBTCPConnectTimeouts=100:500:100:500 -Dcom.sun.corba.ee.transport.ORBTCPTimeouts=500:2000:50:1000 -cp .. <java client>





[GLASSFISH-16281] Glassfish 3.1 Certificate Login from standalone client fails if using a AppservCertificateLoginModule Created: 29/Mar/11  Updated: 25/Apr/14

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

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

linux 64 bit


Tags: 3_1-next, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

We are using a standalone client to connect to Glassfish 3.1 (release version under linux )
If we try and connect from our standalone client using certificate authentication it all works fine.
When we try and add a AppservCertificateLoginModule to perform authorisation based on the certificate then it fails with an iiop.login_exception. Turing on finer logging we get a

javax.security.auth.common.login.LoginException:No Certificate Credential Found
from LoginContextDriver.java:728

The same AppservCertificateLoginModule works when we connect via a JSP page it is only an iiop connect that fails.
When it fails, it enters our constructor OK but never calls our authenticateUser.
This appears to be a bug with iiop which seems to be the poor cousin these days in Glassfish. We are trying to move from Glassfish 2 but this is a blocker for us.

Our login module is currently simple eg

public class TestCertificateLoginModule extends AppservCertificateLoginModule
{
public TestCertificateLoginModule()
{
super()
_logger.info("Constructor");
}

@Override
protected void authenticateUser() throws LoginException
{
_logger.info("authenticate");
String[] groupArray=

{"ADMIN"}

;
commitUserAuthentication(groupArray);
return;
}
}

We set this up by this adding to our login.conf

certRealm:

{ test.TestCertificateLoginModule requlogLevel="FINE"; } We made glassfish use this by running asadmin set configs.config.server-config.security-service.auth-realm.certificate.property.jass-context=certRealm We are using a simple Stateless session eg @Stateless @DeclareRoles("ADMIN") @AllowRoles("ADMIN") public class TestStateless implements TestStatelessRemote { @Override public String hello() { return "hello"; } }

our sun-ejb-jar.xml contains

<enterprise-beans>
<security-role-mapping>
<role-name>ADMIN</role-name>
<group_name>ADMIN</group-name>
</security-role-mapping>
<ejb>
<ejb-name>TestStateless</ejb-name>
<jndi-name>TestStateless</jndi-name>
<ior-security-config>
<transport-config>
<integrity>required</integrity>
<confidentiality>required</confidentiality>
<establish-trust-in-target>supported</establish-trust-in-target>
<establish-trust-in-client>required</establish-trust-in-client>
</transport-config>
<sas-context>
<caller-propagation>supported<caller-propagation>
</sas-context>
</ior-security-config>

Our client code contains

InitialContext ic = new InitialContext();
TestSessionRemote t = (TestSessionRemote)ic.lookup("TestSession");
t.hello();



 Comments   
Comment by kumarjayanti [ 18/May/11 ]

Seems to be a valid bug, we never tested the AppservCertficateLoginModule with IIOP. Can you paste a full trace for this :

javax.security.auth.common.login.LoginException:No Certificate Credential Found
from LoginContextDriver.java:728

We will attempt to fix it for 3.1.1.

Comment by james100 [ 29/May/11 ]

Hi,

We gave up and moved to LDAP.
I will see if I still have some test code that generates the error

Comment by tmn [ 14/Jun/11 ]

Hi Kumar,
I'm running into this same issue of "Certificate Login from standalone client fails if using a AppservCertificateLoginModule" as described above. I would like to know your progress on solving this issue

Regards,

TMN

Comment by JeffTancill [ 11/Feb/13 ]

Not relevant to 4.0 RI.





[GLASSFISH-16181] Deployment error when local interfaces are referenced from remote EJB when EAR contains client application Created: 09/Mar/11  Updated: 25/May/11  Resolved: 25/May/11

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

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

JDK 1.6.0_24 64 bit, Linux 64 bit


Attachments: Zip Archive InjectionProblemTestCase.zip    
Tags: 3_1_1-exclude

 Description   

Consider following case:
1. Create EAR application with EJB module and client application module.
2. EJB module should have an EJB with only local interface and an EJB with remote interface only
3. Reference local EJB interface (injection) from the EJB with only remote interface
4. Try to deploy application using GlassFish administration console

Result:
Error similar to: Error occurred during deployment: Exception while deploying the app [InjectionProblemTestCase] : Target ejb LocalSessionBean for remote ejb 3.0 reference testcase.RemoteSessionBean/lsbl does not expose a remote business interface of type testcase.LocalSessionBeanLocal. Please see server.log for more details.

Additional info:
The same EJB module can be deployed without problems when package doesn't contain client application.
I am attaching a test case. It is a NetBeans project: sources and precompiled EAR.



 Comments   
Comment by marina vatkina [ 11/Mar/11 ]

Tim, Please check why ACC looks for any of the EJB refs if the acc-client doesn't reference any...

Comment by marina vatkina [ 11/Mar/11 ]

The stack trace of the exception:

[#|2011-03-11T15:37:32.163-0800|SEVERE|glassfish3.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=64;_ThreadName=Thread-1;|Target ejb LocalSessionBean for remote ejb 3.0 reference testcase.RemoteSessionBean/lsbl does not expose a remote business interface of type testcase.LocalSessionBeanLocal
java.lang.RuntimeException: Target ejb LocalSessionBean for remote ejb 3.0 reference testcase.RemoteSessionBean/lsbl does not expose a remote business interface of type testcase.LocalSessionBeanLocal
at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:737)
at com.sun.enterprise.deployment.ApplicationClientDescriptor.visit(ApplicationClientDescriptor.java:667)
at com.sun.enterprise.deployment.Application.visit(Application.java:1791)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:808)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:277)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:171)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:827)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:769)
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:380)

Comment by Tim Quinn [ 12/May/11 ]

First, the ACC is not at all involved in this. The problem occurs during deployment, not at runtime.

Second, the problem might be in EJBHandler (see lengthy stack trace below). For every @EJB-annotated EJB, the EJBHandler#getEjbReferenceDescriptors method looks in each ResourceContainerContext for an EJB ref for the current EJB. The problem could be that if it finds no ejb ref in that context it adds one. In this example, the app client does not actually refer to the EJB but this logic makes it look as though it does. Then, later, the validator complains (correctly) that the app client will not be able to access the local EJB which is nested inside the remote one.

Should this logic be more selective and not add such a reference if the context is an app client one and the bean being processed is local?

Because this is directly related to the EJB container's processing of the EJB anno I am transferring this issue to the EJB team.

"Grizzly(1)"
com.sun.enterprise.deployment.ApplicationClientDescriptor.addEjbReferenceDescriptor(ApplicationClientDescriptor.java:229)
com.sun.enterprise.deployment.annotation.context.ResourceContainerContextImpl.addEjbReferenceDescriptor(ResourceContainerContextImpl.java:75)
org.glassfish.ejb.deployment.annotation.handlers.EJBHandler.getEjbReferenceDescriptors(EJBHandler.java:235)
org.glassfish.ejb.deployment.annotation.handlers.EJBHandler.processEJB(EJBHandler.java:190)
org.glassfish.ejb.deployment.annotation.handlers.EJBHandler.processAnnotation(EJBHandler.java:109)
com.sun.enterprise.deployment.annotation.handlers.AbstractResourceHandler.processAnnotation(AbstractResourceHandler.java:142)
org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344)
org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375)
org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289)
org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:271)
org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:199)
org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134)
com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:606)
com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:445)
com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:432)
com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:408)
com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:383)
com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:246)
com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:255)
com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(ApplicationArchivist.java:649)
com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:258)
com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240)
org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:173)
org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:828)
com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:770)
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:388)
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1069)
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:98)
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1249)
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1237)
com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:473)
com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:226)
org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:189)
com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:162)
org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:160)
org.glassfish.grizzly.filterchain.ExecutorResolver$3.execute(ExecutorResolver.java:95)
org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:444)
org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:364)
org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:290)
org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:133)
org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:76)
org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:63)
org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:823)
org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:116)
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$000(WorkerThreadIOStrategy.java:55)
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$1.run(WorkerThreadIOStrategy.java:98)
org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:508)
org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:488)
java.lang.Thread.run(Thread.java:680)

Comment by marina vatkina [ 23/May/11 ]

Needs more work to solve, but it didn't work on 3.0 either

Comment by Cheng Fang [ 25/May/11 ]

The problem is NetBeans generates an incorrect MANIFEST.MF for appclient jar, with an extra Class-Path entry:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.1
Created-By: 1.6.0_24-b07 (Sun Microsystems Inc.)
X-COMMENT: Main-Class will be added automatically by build
Main-Class: injectionproblemtestcase.Main
Class-Path: InjectionProblemTestCase-ejb.jar

As a result all the @EJB annotations in the ejb jar file are also processed by appclient.

After deleting Class-Path entry and manually packaging the ear, it deploys fine.

The correct way of packaging is to include only the EJB interface classes, exception classes, etc, but not the bean classes into appclient jar. You can also package all those classes shared between ejb module and appclient module into a EAR lib jar, such as

EAR/lib/app-shared.jar
EAR/ejb.jar
EAR/appclient.jar





[GLASSFISH-16122] Problem with remote JMS client and non-standard IIOP port Created: 02/Mar/11  Updated: 04/Nov/11  Resolved: 03/Nov/11

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: v3.0.1
Fix Version/s: 3.1.2

Type: Bug Priority: Major
Reporter: matthiasfraass Assignee: Harshad Vilekar
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

windows, hp-ux


Attachments: Text File stacktrace1.txt    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-17579 [UB]ORB: set system properties: org.o... Sub-task Resolved Rebecca Parks  
Tags: 3_1_1-exclude, 3_1_1-scrubbed

 Description   

I have the suspicion that there's something wrong about IIOP property passthrough.

I have non-standard (3700) IIOP ports for our server. We have set it to 8101 (8102 for SSL).
When I try to connect to a server from a standalone client, it doesn't work when I'm setting the IIOP port programmatically.

In my classpath I only have the glassfish/modules/gf-client.jar.

When I try this:

Context jndiContext = null;
String destName = "jms/TestQueue";
ConnectionFactory connectionFactory = null;
Destination dest = null;
Connection connection;
Session session;
MessageProducer producer;
System.out.println("Connecting...");
Properties p = new Properties();
p.setProperty("org.omg.CORBA.ORBInitialPort", "8101");
jndiContext = new InitialContext(p);
connectionFactory = (ConnectionFactory) jndiContext.lookup("jms/TestConnectionFactory");
System.out.println("got the CF");
connection = connectionFactory.createConnection();
System.out.println("got the Connection");
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
System.out.println("got the Session");
dest = (Destination) jndiContext.lookup(destName);
System.out.println("got the Queue");
producer = session.createProducer(dest);
System.out.println("connected");

I get a org.omg.CORBA.COMM_FAILURE (see stracktrac1.txt for full stack trace) and:
Caused by: javax.naming.NamingException: Lookup failed for '__SYSTEM/pools/jms/TestConnectionFactory' in SerialContext ,orb'sInitialHost=localhost,orb'sInitialPort=3700 [Root exception is javax.naming.NamingException: Unable to acquire SerialContextProvider for SerialContext ,orb'sInitialHost=localhost,orb'sInitialPort=3700 [Root exception is org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No]]

Note the "orb'sInitialPort=3700"!!!

However, when I'm not setting the port programmatically but via JVM option "-Dorg.omg.CORBA.ORBInitialPort=8101" instead, everything works fine!

Connecting...
04.02.2011 17:15:27 com.sun.enterprise.transaction.JavaEETransactionManagerSimplified initDelegates
INFO: Using com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate as the delegate
04.02.2011 17:15:27 com.sun.enterprise.connectors.jms.util.JmsRaUtil getInstalledMqVersion
WARNUNG: jmsra.upgrade_check_failed
04.02.2011 17:15:27 org.hibernate.validator.util.Version
INFO: Hibernate Validator bean-validator-3.0-JBoss-4.0.2
04.02.2011 17:15:27 org.hibernate.validator.engine.resolver.DefaultTraversableResolver detectJPA
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
04.02.2011 17:15:27 com.sun.messaging.jms.ra.ResourceAdapter start
INFO: MQJMSRA_RA1101: SJSMQ JMS Resource Adapter starting: REMOTE
04.02.2011 17:15:27 com.sun.messaging.jms.ra.ResourceAdapter start
INFO: MQJMSRA_RA1101: SJSMQ JMSRA Started:REMOTE
04.02.2011 17:15:27 com.sun.messaging.jms.ra.ManagedConnectionFactory setAddressList
INFO: MQJMSRA_MF1101: setAddressList:NOT setting default value=localhost
04.02.2011 17:15:27 com.sun.messaging.jms.ra.ManagedConnectionFactory setPassword
INFO: MQJMSRA_MF1101: setPassword:NOT setting default value
04.02.2011 17:15:27 com.sun.messaging.jms.ra.ManagedConnectionFactory setUserName
INFO: MQJMSRA_MF1101: setUserName:NOT setting default value=guest
got the CF
got the Connection
got the Session
got the Queue
connected

We're running GlassFish v3 (build 74.2)



 Comments   
Comment by Satish Kumar [ 24/May/11 ]

Transferring to the ORB team since this appears to more of an issue with IIOP...

Comment by Harshad Vilekar [ 03/Nov/11 ]

Setting "org.omg.CORBA.ORBInitialPort" system property resolves this. This is expected behavior. Please see steps 4 and Steps 5 of EJB FAQ http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB

Comment by matz [ 03/Nov/11 ]

So there is no way to set this programmatically?
How am I supposed to write a client that connects to multiple servers with different ports?

I think this is not a very good solution.

Comment by Harshad Vilekar [ 04/Nov/11 ]

Try adding following line before creating InitialContext:

System.setProperty("org.omg.CORBA.ORBInitialPort", "8101");





[GLASSFISH-16064] javax.ejb.EJBException Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002 Created: 21/Feb/11  Updated: 19/Dec/16

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
Fix Version/s: 4.1.1

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

$ java -version
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)

$ uname -a
Linux 2.6.18-194.17.4.el5 #1 SMP Mon Oct 25 15:50:53 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux


Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Often I see following messages in server.log:

[#|2011-02-21T14:31:11.233+0300|WARNING|glassfish3.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=142;_ThreadName=Thread-1;|A system e
xception occurred during an invocation on EJB ChukchiManSlotMachineBean method public byte openbox.chukchiman.ChukchiManSlotMachineBean.setPickedLineCount(byte)
javax.ejb.EJBException
at openbox.session._SessionFacade_Wrapper.setSessionData(openbox/session/_SessionFacade_Wrapper.java)
at openbox.core.component.GameComponent.setData(GameComponent.java:217)
at openbox.chukchiman.ChukchiManSlotMachineBean.setPickedLineCount(ChukchiManSlotMachineBean.java:345)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4155)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5347)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:206)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy268.setPickedLineCount(Unknown Source)
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.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy189.noObjectAdaptor(Unknown Source)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:228)
at com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.updateCachedInfo(ServantCacheLocalCRDBase.java:86)
at com.sun.corba.ee.impl.protocol.ServantCacheLocalCRDBase.getCachedInfo(ServantCacheLocalCRDBase.java:77)
at com.sun.corba.ee.impl.protocol.FullServantCacheLocalCRDImpl.internalPreinvoke(FullServantCacheLocalCRDImpl.java:64)
at com.sun.corba.ee.impl.protocol.LocalClientRequestDispatcherBase.servant_preinvoke(LocalClientRequestDispatcherBase.java:240)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.servant_preinvoke(CorbaClientDelegateImpl.java:574)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:218)
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 openbox.session._SessionFacade_Remote_DynamicStub.setSessionData(openbox/session/_SessionFacade_Remote_DynamicStub.java)
... 32 more
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent: IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.doActivate(POAImpl.java:1115)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1048)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)
... 41 more

#]


 Comments   
Comment by Ken Cavanaugh [ 21/Feb/11 ]

This is logged at FINE level. If you enabled FINE level logging, you will see more
log messages, and those from the ORB will have stack traces. This is not a bug.

Did you observe any failures, or are you just reporting a log message?

Do you have FINE logging enabled, either for everything, or for logger
javax.enterprise.resource.corba?

Comment by marina vatkina [ 21/Feb/11 ]

Let's investigate this - the user reported a WARNING in the log.

Comment by marina vatkina [ 21/Feb/11 ]

Are there any other messages in the log? What kind of EJBs are used in this call stack?

Comment by lft [ 24/Feb/11 ]

This message can repeat several times.
The EJBs are staetful.

Comment by marina vatkina [ 24/Feb/11 ]

Can it be that you are trying to access a SFSB instance after it was discarded because of an exception in the previous call?

Comment by lft [ 27/Feb/11 ]

Right now I have only one occurance of this exception in logs (old server logs was cleared). And there is another exception above this one - IOP00710134, that I reported in another thread, - but it's related to another bean. There is no another exceptions related to bean that produced IOP02500002.

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-16005] cannot configure ssl key-/trust-store per http-listener in admin-gui Created: 16/Feb/11  Updated: 19/Dec/16

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

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

Tags: 3_1-next, 3_1_1-exclude, 3_1_1-scrubbed

 Description   

according to GLASSFISH-15973 the per listener configuration does not work with GlassfishSSLImpl and classname needs to be removed from ssl-element. There is no field to choose classname in admin-gui.

I think that admin-gui is the wrong place to fix this, I my opinion GlassfishSSLImpl should do the job and not the user.

Hint: you might not notice the problem if you use nickname=s1as, because then the cert from -Djavax.net.ssl.keystore is used. If you change the nickname you'll get "No available certificate" exception until you remove classname, but then you'll have to add key-store-password to ssl-element



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

After reading the comments from GLASSFISH-15973, I am still not sure how exactly GUI should change to provide better user experience.
Request Kumar to tell me what exactly GUI should do. There seems to be discrepancy of what the user prefers to see and what Kumar believes is working by design.

I am transferring this to 'security' for input. Please tell me clearly what fields should be added/modified. thanks.

Comment by schaarsc [ 16/Feb/11 ]

Preferred solution:

  • do not change admin-gui
  • make GlassfishSSLImpl aware of key-store and trust-store attributes

if GlassfishSSLImpl cannot be changed:

  • add classname to gui
  • add key-store-password to gui
  • add trust-store-password to gui
  • add documentation what these values are good for and why / when they need to be specified
Comment by schaarsc [ 16/Feb/11 ]

I noticed that you downgraded this issue to Improvement.
I thinks it's a bug, because if you enter keystore and truststore in the admin-gui it will not do what user expects and there is no way to fix it using admin-gui. domain.xml has to be edited directly.

Comment by Nazrul [ 10/May/11 ]

Lets take a look at this issue

Comment by scatari [ 25/Jun/11 ]

Marking to be considered for next release.





[GLASSFISH-15984] Validation error in remote EJB gives ClassNotFoundException: ... : Unknown protocol: osgi Created: 15/Feb/11  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: v3.0.1, 3.1_dev
Fix Version/s: 4.1.1

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

linux, windows


Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

When a validation error occurs in a remote ejb (at least with org.hibernate.validator.constraints.Length), this results in the following stacktrace:

[#|2011-02-15T10:26:46.765+0100|WARNING|glassfish3.1|javax.enterprise.resource.corba.ORBUtil|_ThreadID=21;_ThreadName=Thread-1;|IOP00810013: Could not find class org.hibernate.validator.constraints.Length in CDRInputStream.readClass
org.omg.CORBA.MARSHAL: WARNING: IOP00810013: Could not find class org.hibernate.validator.constraints.Length in CDRInputStream.readClass vmcid: OMG minor code: 13 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy285.cnfeReadClass(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readClass(CDRInputStream_1_0.java:1441)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1085)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.defaultReadObjectDelegate(IIOPInputStream.java:596)
at com.sun.corba.ee.impl.io.InputStreamHook.defaultReadObject(InputStreamHook.java:233)
at sun.reflect.annotation.AnnotationInvocationHandler.readObject(AnnotationInvocationHandler.java:312)
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.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.util.Utility.readAbstractAndNarrow(Utility.java:1026)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2157)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:345)
at java.util.HashSet.readObject(HashSet.java:291)
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.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.presentation.rmi.ExceptionHandlerImpl$ExceptionRWRMIImpl.read(ExceptionHandlerImpl.java:180)
at com.sun.corba.ee.impl.presentation.rmi.ExceptionHandlerImpl.readException(ExceptionHandlerImpl.java:290)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readException(DynamicMethodMarshallerImpl.java:502)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:205)
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 no.evote.service._OperatorService_Remote_DynamicStub.updateOperator(no/evote/service/_OperatorService_Remote_DynamicStub.java)
at no.evote.service._OperatorService_Wrapper.updateOperator(no/evote/service/_OperatorService_Wrapper.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 no.evote.service.cache.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:80)
at no.evote.service.cache.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:110)
at $Proxy323.updateOperator(Unknown Source)
at no.evote.presentation.OperatorController.saveOperator(OperatorController.java:244)
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.el.parser.AstValue.invoke(AstValue.java:234)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:43)
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:56)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:148)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
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 no.evote.service.security.DisableCachingFilter.doFilter(DisableCachingFilter.java:28)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.service.security.SelectRoleFilter.doFilter(SelectRoleFilter.java:47)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.service.security.CookieFilter.doFilter(CookieFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.service.security.CSRFFilter.doFilter(CSRFFilter.java:68)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at net.balusc.http.multipart.MultipartFilter.doFilter(MultipartFilter.java:78)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.service.security.saml.SAMLAccessFilter.doFilter(SAMLAccessFilter.java:54)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.presentation.MonitorFilter.doFilter(MonitorFilter.java:25)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at no.evote.presentation.ForceLocaleFilter.doFilter(ForceLocaleFilter.java:54)
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.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:619)
Caused by: java.lang.ClassNotFoundException: org.hibernate.validator.constraints.Length: java.net.MalformedURLException: Unknown protocol: osgi
at com.sun.corba.ee.impl.util.JDKBridge.loadClassM(JDKBridge.java:325)
at com.sun.corba.ee.impl.util.JDKBridge.loadClass(JDKBridge.java:228)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.loadClass(Util.java:640)
at com.sun.corba.ee.impl.util.RepositoryId.getClassFromType(RepositoryId.java:628)
at com.sun.corba.ee.impl.orbutil.RepIdDelegator.getClassFromType(RepIdDelegator.java:169)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readClass(CDRInputStream_1_0.java:1439)
... 182 more

#]

It has been around for a while, also discussed in the forum by someone else:
http://www.java.net/forum/topic/glassfish/glassfish/jpa-20-validaton-exceptions-and-unknown-protocol-osgi-0



 Comments   
Comment by Ken Cavanaugh [ 15/Feb/11 ]

Much too late to fix in 3.1.

The osgi: protocol is one I added in GF 3.0 to use in a codebase
where the sender and receiver are running under OSGi. The tradtional
RMI-style classpath does not work in this environment because
there is no classpath in OSGi. Instead, I defined a
osgi://<bundle name>:<version> URL to allow the receiver to find
the appropriate OSGi bundle in which to locate the class from the
class name passed in the value type that is being unmarshaled.

Unfortunately it appears that I did not find all the places in the
ORB that need to be modified in this case. It is also a bit hard
to set up an ORB-level OSGi-based regression test, but I really need
to take the time to do this.

Comment by Ken Cavanaugh [ 15/Feb/11 ]

It looks like the problem is a missing call to the classCodeBaseHandler in readClass. The
code is present in the more common case of reading a valueType (see CDRInputStream_1_0.getClassFromString
starting at line 2267 in the GF 3.1 ORB code). But it's missing in readClass.
Looks like the fix is basically to add:

ClassCodeBaseHandler ccbh = orb.classCodeBaseHandler() ;
if (ccbh != null) {
String className = repositoryID.getClassName() ;
Class<?> result = ccbh.loadClass( codebaseURL, className ) ;

if (result != null)

{ return result ; }

}

in readClass after the repIdStrings.getFromString(classRepId) call in readClass.

5 minutes to fix, 2 days to write a suitable regression test .

Comment by jdbuys [ 30/Mar/11 ]

I implemented the fix on our side but we still get the same error.

Do you have any other ideas?

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-15969] "Edit JMS Host" admin name and password: forces use of guest user Created: 13/Feb/11  Updated: 24/Apr/12  Resolved: 24/Apr/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: v3.0.1
Fix Version/s: None

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

debian linux


Issue Links:
Duplicate
is duplicated by GLASSFISH-17729 Glassfish forces use of guest user wh... Resolved
Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude, bj-reviewed

 Description   

One may change ones JMS Service from "embedded" to "remote", which works just fine. On the page titled "Edit JMS Host" one may edit "Host" "Port" "Admin Username" and "Admin Password". While changes to "Host" and "Port" function correctly, values entered into "Admin Username" and "Admin Password" are ignored completely by glassfish (GlassFish Server Open Source Edition 3.0.1 (build 22)). Instead of using the entered values glassfish uses guest / guest as admin name / password. In other words: One may only use a remote broker with glassfish if one uses guest / guest as values for username and password which I consider a serious security issue. Please fix!



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

I just checked 3.0.1 and the latest 3.1, all information entered in the "Edit JMS Host" page is persisted correctly in domain.xml
Transfer to 'jms' for evaluation.

Comment by deathtooracle [ 14/Feb/11 ]

Whoops, my explanation does not state what I wanted it to: The bug only occurs, when the JMS Service is set to "remote". With "embedded" it works, if I recall correctly.

Comment by Harshad Vilekar [ 14/Feb/11 ]

This could not be duplicated this with GlassFish 3.1, build 41. Steps below:

1. Start remote MQ broker on remote host myhost.us.oracle.com, on default port (7676), with default admin username/password.

./imqbrokerd -tty -reset store

2. On GlassFish DAS host: Admin Console - Configurations - Server Config - Java Message Server - JMS Hosts - New

Name: myJMSHost
Host: myhost.us.oracle.com
Port: 7676
Admin Username: admin
Admin Password: ***** (use default password)
Confirm New Password: ***** (use default password)

Save
-----------------
3. Restart DAS

4.Admin Console - Configurations - Server Config - Java Message Service:
Type: Remove
Default JMS Host: myJMSHost

Keep other values unchanged

Save.
-----------------
5. Admin Console - Configurations - Server Config - Java Message Service - Ping
Ping succeeded.
-----------------

6. Go To Step 2, and set password to "invalid"

7. Restart DAS

8. Repeat Step 5, ping fails this time, with "java.lang.SecurityException: JMX connector server jmxrmi: Failure detected during authentication com.sun.messaging.jmq.auth.api.FailedLoginException: [B4051]: Forbidden admin"

So, the password authentication seems to work fine with GlassFish 3.1, build 41.

Comment by Satish Kumar [ 15/Feb/11 ]

This issue is not reproducible in 3.1. Hence adding the tag - 3_1-exclude

Comment by Satish Kumar [ 24/May/11 ]

This issue is not reproducible in 3.1.*. Hence, excluding this from the 3.1.1 release cycle.

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

According to 17729 this bug still exists in 3.1.1:

As guoted by deathtooracle,

One may change ones JMS Service from "embedded" to "remote", which works just fine. On the page titled "Edit JMS Host" one may edit "Host" "Port" "Admin Username" and "Admin Password". While changes to "Host" and "Port" function correctly, values entered into "Admin Username" and "Admin Password" are ignored completely by glassfish (GlassFish Server Open Source Edition 3.0.1 (build 22)). Instead of using the entered values glassfish uses guest / guest as admin name / password. In other words: One may only use a remote broker with glassfish if one uses guest / guest as values for username and password which I consider a serious security issue. Please fix!

To demonstrate the problem. Perform the following steps:

1. Start remote MQ broker on a remote host on default port (7676), with default admin username/password using the following command

./imqbrokerd -tty -reset store

2. Deactivate guest user using the following command

/.imqusermgr update -u quest -a false

3. Configure glassfish Java Message Service and JMS host settings so that the a different user (i.e. someone other than guest)
is used to connect to the remote MQ broker.

4. Restart glass fish.

When glass fish starts up you get the following error messages in the server log.
[#|2011-11-15T16:56:56.957+1100|SEVERE|glassfish3.1.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=10;_ThreadName=Thread-2;|com.sun.messaging.jms.JMSSecurityException: [C4060]: Login failed: user=guest, broker=remote-afe.nextgen.nextgen.net:7676(31551)

Comment by Simon Meng [ 24/Apr/12 ]

The issue is not reproducible with 4.0_b33. If user changes the "Admin Username" and "Admin Password", the new values take effect in the password authentication. It is already fixed in some version.





[GLASSFISH-15638] Show "restart required" status when IIOP service configuration / port is changed Created: 20/Jan/11  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: Harshad Vilekar 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_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Per Admin Guide, "Impact of Configuration Changes" section, Configuration Changes That Require Server Restart include: Managing IIOP services.

However, "restart required" is not indicated by Admin CLI/GUI when IIOP service configuration is changed.

Example Steps:

on Admin Console

Click Server Config - ORB - IIOP Listeners - orb-listener-1 - Listener Port - Change to "3702" - Save

Expected: Restart Required notification is displayed.



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

Can you tell me which 'Admin Guide' and the location of this doc ?
Maybe this is a doc bug, i think most configuration change is dynamic now.

Comment by Harshad Vilekar [ 21/Jan/11 ]

The link to the Admin Guide that I got from the DOC team (included in GLASSFISH-15516) worked earlier - but is broken as of yesterday. Let's get the updated link from the Doc team (I just sent separate email to Paul).

If somebody can send out the list of the the configuration changes that are changed to "dynamic" as of 3.1 - that information will be very useful. Restart required notification is not generated for most of the config changes that are listed in the "Oracle GlassFish Server 3.0.1 Administration Guide" under section "Configuration Changes That Require Server Restart".

Comment by Harshad Vilekar [ 21/Jan/11 ]

Admin Guide:
> On 01/21/11 09:52, Paul M Davies (Oracle) wrote:
> Here's the link to this information in its new home on OTN: http://download.oracle.com/docs/cd/E19798-01/821-1751/gitzw/index.html

Comment by Anissa Lam [ 21/Jan/11 ]

I see. You were talking about the Admin Guide for 3.0.1.
The docs has been moved. It is now available under

http://download.oracle.com/docs/cd/E19798-01/

I see this bug has no component/owner and assigned to Nazrul.
I believe Tom should own this, look at this section
"http://download.oracle.com/docs/cd/E19798-01/821-1751/gitzw/index.html" and provide the list that actually requires server restart to the doc team.

I see this list is very out-dated.
Maybe the doc team has changed this list for 3.1 already, i don't know. If so, please use the 3.1 list and file bug accordingly.

Comment by Anissa Lam [ 21/Jan/11 ]

Where is the corresponding list for 3.1 ?
Harshad should be using the 3.1 list instead of those from 3.0.1 to file bug.

Comment by Harshad Vilekar [ 21/Jan/11 ]

That part of the doc is not updated since 3.0.1.

On 12/29/10 13:48, Paul Davies wrote:
> Hi Harshad,
>
> :
> :
> We have not updated Impact of Configuration Changes since 3.0.1, so you can refer to that for the current information.
>
> Regards,
> -Paul

Comment by Tom Mueller [ 21/Jan/11 ]

Reassigning to the orb category to determine whether changing the IIOP port requires a server restart in 3.1. For HTTP listener ports, a server restart is not necessary, so the documentation at the given link is definitely wrong. Just want to confirm whether this is also the case for the IIOP ports.

Comment by Tom Mueller [ 21/Jan/11 ]

If a server restart is not required when changing the IIOP ports, please change this to be a doc bug so that the documentation can be updated.

Comment by Ken Cavanaugh [ 21/Jan/11 ]

Changing IIOP ports definitely requires a server restart in the present implementation.
It's technically possible to change IIOP ports, but this requires ORB changes, as well as
some sort of notification mechanism between admin and the ORB. I know how to change the
ORB to support this, but I don't know how to hook something like this into admin.

In any case, this is not supported in GF 3.1, and the docs should reflect this.
Changing this to a doc bug as Tom suggested.

Comment by Ken Cavanaugh [ 21/Jan/11 ]

Oops, I mis-read Tom's comment before I made my last reply.
Changing ORB configuration requires server restart in GF 3.1.

How is this supposed to be changed in the admin CLI commands?
Assigning to Tom for further consideration.
If you want me to update the orb-listener commands, please tell me
how to do this.

Comment by Tom Mueller [ 24/Jan/11 ]

To trigger the "restart required" behavior, it is necessary for some code to detect that a change that has been made that cannot be processed without restarting, and for that code to create and send an UnprocessedChangeEvent. One way of doing this is to have a service that implements the ConfigListener interface, which has a "changed" method that takes an array of PropertyChangeEvent objects and returns list of UnprocessedChangeEvent objects. See this file for an example:

ejb/ejb-container/src/main/java/com/sun/ejb/containers/EJBTimerServiceConfigListener.java

Another way to do this is to explicitly inject the UnprocessedConfigListener class, and call its unprocessedTransactiveEvents method with a List of UnprocessedChangeEvents objects. See this file for an example of this:

core/logging/src/main/java/com/sun/enterprise/server/logging/LogManagerService.java

I suspect that this is what has happened. In earlier releases, a change to a Grizzly port required a server restart, and Grizzly took care of providing this notification. However, more recently, Grizzly no longer requires a restart to change a port number. For example, the HTTP port can be changed without a restart. However, if IIOP and the ORB still need a restart when the port changes, that could will now have to provide the notification of the unprocessed change event.

The documentation eventually needs to be cleaned up because changes to some ports require a restart, and changes to other ports do not. But the documentation generalized and says a restart is needed for all port changes.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

I don't have a ConfigListener in the ORB interface code, so I don't understand how any of this is
supposed to work.

  • Would I just need to create an implementation of ConfigListener inside an appropriate ORB bundle
    (orb-connector in this case), and annotate it as @Service? Is this automatically picked
    up by admin using hk2?
  • Presumably I would need a changed( PropertyChangeEvent[] ) method. How do I determine what the
    event is that I need to return in unprocessed events? It looks like I need to inject
    IiopListener and then look for event.getSource() of type IiopListener. The operation of
    interest on IiopListener is setPort. So what is event.getPropertyName in this case?

I think a can use a simple implementation here that simply returns everything passed
to the changed event as an unprocessed event, since nothing in the ORB is currently dynamically
updatable.

Comment by Tom Mueller [ 24/Jan/11 ]

Yes on creating the ConfigListener, except that something needs to reference the service in order to get it loaded. In the EJBTimerService, there is the following call that does this:

ejbContainerUtil.getDefaultHabitat().getComponent(EJBTimerServiceConfigListener.class);

See the EJBTimerService.java file.

It sounds like any event on an IiopListener could be made an UnprocessedChangeEvent.
I expect that the property name in the case of the port changing would be "port" since that is what is in the XML.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

One last question: is this fix needed for 3.1, or should we defer it to 3.2?

Comment by kumara [ 24/Jan/11 ]

This is arguably likely to cause confusion to the end users but is lower priority because –

1. port change is a one-time activity in most real deployments
2. After port change, a user is likely to try the application to verify that it works and will discover the problem.
3. Restart is a natural first step towards solving the problem.

I would recommend addressing it in next release and documenting in release notes that clusters/server instances need to be restarted for any configuration changes to IIOP service to take effect.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

Moving to 3.2 per Kumara's comment.

Should add some of the simple cases of ORB dynamic reconfiguration in that release in any case.

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 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-15637] IIOP Loadbalancing not happening Created: 20/Jan/11  Updated: 19/Dec/16  Due: 01/Feb/11

Status: Reopened
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 3.1_dev
Fix Version/s: future release

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

Attachments: File patch.tgz    
Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

IIOP Loadbalancing not happening with certain apps

The Initial context is created as follows

public void createContextForACC()
{
try

{ InitialContext initial = new InitialContext(); myEnv = (InitialContext)initial.lookup("java:comp/env/ejb"); }

catch(NamingException ne)

{ System.err.println("Caught an unexpected exception!"); ne.printStackTrace(); }

}

All new ic creations are going to same instance



 Comments   
Comment by Ken Cavanaugh [ 21/Jan/11 ]

I don't understand what is failing here. Is this an issue about some of the failover
tests? Which ones?

Or is it an issue about how the InitialContext is created?

I also have no idea what a lookup of java:comp/env/ejb is supposed to do.
This is not part of IIOP or FOLB.

Please clarify or close this issue.

Comment by gopaljorapur [ 21/Jan/11 ]

The loadbalancing is not happening, all new ic creations happen on one random instance in the cluster

Comment by Ken Cavanaugh [ 25/Jan/11 ]

This issue does not currently correctly describe the observed problem.
I THINK (from email and conversation with Gopal) that the problem is
that loadbalancing does not happen when the endpoints property is specified
in the app client command, but DOES happen when the endpoints property
is passed to the (first) new InitialContext call.

I will investigate that question in my testing shortly.

Comment by Ken Cavanaugh [ 26/Jan/11 ]

My test (same as the 14867 existing instance case) works with -Dcom.sun.appserver.iiop.endpoints specified,
but fails with appclient -targetserver. I've sent email to Tim to see if this is a configuration error in
my code, or an error in the ACC argument parsing.

Comment by Ken Cavanaugh [ 30/Jan/11 ]

This patch contains two fixes:

1. The sticky context reference count has been fixed to avoid extra increments, which
creates a "stuck" condition in which the same SerialContext underlying the InitialContext
call is used all the time. This fix is in glassfish-naming.

2. I added code to the ORB to detect and specially label name service implementations.
The FOLB server group manager then arranges to always send a membership label
update on the reply to any name server invocation. This means that the
lookup call on the new InitialContext will get any updates to the cluster shape.
This in turn prevents the situation where the client is always obtaining up-to-date
references from naming, but the new InitialContext call is not informed of the changes
(which happens only the the ClientGroupManager receives a response contains an
updated IOR for a membership label change).

Just unpatch the patch into the modules directory as usual.

Comment by Ken Cavanaugh [ 31/Jan/11 ]

How bad is its impact? (Severity)
Regression in IIOP FOLB from GF 2.1.

How often does it happen? (Frequency)
Happens all the time in the following test scenario (which should have
been added earlier to this issue):

0. Start with com.sun.appserv.iiop.endpoints referring to two elements, the one to start in step 2
and another in the cluster.
1. Stop the cluster.
2. Start 1 instance (inst) in the cluster.
3. LB to one instance
4. Start cluster
5. Kill inst
6. LB test

This fails because LB happens to only one instance.

How much effort is required to fix it?
I have the fixes made, and the IIOP FOLB dev test passes.
Fixes are in the ORB (new support for labelling object implementations as being in a name service)
and in glassfish-naming (Fixes in how endpoint lists are merged in RoundRobinPolicy,
and fixes in sticky context reference counting in SerialContext)

What is the risk of fixing it? (Risk)
Low. We have good test coverage for all areas. The only likely impact is on IIOP FOLB.
Other functions of the ORB are unaffected by these changes.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
I don't think a reasonable workaround exists.

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

How long has the bug existed in the product?
Since the beginning of GF 3.1 FOLB development (roughly 6 months)

Do regression tests exist for this issue?
Yes: IIOP FOLB dev test test15736.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The various tests that were failing that caused this issue to be filed (Gopal has the tests).

When will a tested fix be ready for integration?
Probably 1/31/11-2/1/11.

Comment by gopaljorapur [ 31/Jan/11 ]

he issue in 15637 is about IIOP Loadbalancing not happening , Scenario is as follows (I will update the issue with this scenario)

1. Start Cluster with 5 instances
2. Create 12 InitialContext in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see 12 of them in only one instance (incorrect behavior, load should be loadbalanced across cluster)

The test code is as follows

/// When we run appclient, we provide test id as RMIIIOPFOTC4, this creates 12 ic and 12 sfsb remote ref

if(testid.equals("RMIIIOPFOTC4"))
{
for(int i=0;i<12;i++)

{ client.createContextForACC(); client.createSFSBRemoteRef(); }

System.out.println("Test Passed");
}

//// Here is how ic is created

public void createContextForACC()
{
try

{ Context initial = new InitialContext(); myEnv = (Context)initial.lookup("java:comp/env/ejb"); }

catch(NamingException ne)

{ System.err.println("Caught an unexpected exception!"); ne.printStackTrace(); }

}

///// Here is how sfsb remote ref is
public void createSFSBRemoteRef()
{
try

{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }
catch(Exception exc)
{ exc.printStackTrace(); }
}




*******************************************************************************************************************************************************

The scenario that works:

The variation of the test, RMIIOPFOTC4A

1. Start Cluster with 5 instances
2. Create 12 InitialContext with endpoint properties in the argument in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see load distributed across all instances in the cluster (correct behavior)

Test code is as follows


/// When we run appclient, we provide test id as RMIIIOPFOTC4A, this creates 12 ic and 12 sfsb remote ref
if(testid.equals("RMIIIOPFOTC4A"))
{
for(int i=0;i<12;i++)
{ client.createContextForStandalone(); client.createSFSBRemoteRef(); }
System.out.println("Test Passed");
}

//// This is how createContextForStandalone

public void createContextForStandalone()
{
try
{ myEnv = new InitialContext(properties); }
catch(Exception exc)
{ System.err.println("Caught an unexpected exception!"); exc.printStackTrace(); }
}



///// This is how createSFSBRemoteRef is done ( its same as scenario when test fails)

public void createSFSBRemoteRef()
{
try
{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }

catch(Exception exc)

{ exc.printStackTrace(); }

}

Here is how to deploy
asadmin --user admin deploy --retrieve /export/DecCVS/agentrepo//appclient --availabilityenabled=true --target st-cluster --force=true RMIIIOPFailover.ear

appclient execution
/export/DecCVS/glassfish3/glassfish/bin/appclient -Dcom.sun.appserv.iiop.endpoints=hat2k1.us.oracle.com:23700,hat2k1.us.oracle.com:23701,hat2k2.us.oracle.com:23700,hat2k2.us.oracle.com:23701,hat2k2.us.oracle.com:23702 -client /export/DecCVS/agentrepo/appclient/RMIIIOPFailoverClient/rmi-iiop-client2Client.jar -mainclass samples.rmiiiopclient.client.ACC_Standalone_Client

Comment by Chris Kasso [ 31/Jan/11 ]

Approved for RC2.

Comment by Ken Cavanaugh [ 31/Jan/11 ]

At this point, for tracking purposes, 15637 is for the scenario I outlined above:

0. Start with com.sun.appserv.iiop.endpoints referring to two elements, the one to start in step 2
and another in the cluster.
1. Stop the cluster.
2. Start 1 instance (inst) in the cluster.
3. LB to one instance
4. Start cluster
5. Kill inst
6. LB test (which should show LB across running instances)

It's TOO LATE to change the test scenario for 15637, especially since you did not include a sufficient
description initially. I have clearly identified some defects here that need to be fixed,
so please file a NEW issue for the scenarios you have identified above. Please also indicate in any
new issues whether or not stateful vs. stateless EJBs make any difference. This does not matter
to the ORB at all, but some of your tests seem to indicate failures on the SFSB side only.
If this matters, I'll also need to add SFSB support to the dev tests.

Comment by gopaljorapur [ 31/Jan/11 ]

I have opened an issue 15768 for the Loadbalancing issue mentioned in my earlier comment

Comment by Ken Cavanaugh [ 31/Jan/11 ]

Fixed in GF rev 44807.
This includes integration of ORB version 3.1.0-b025.

Comment by gopaljorapur [ 17/Feb/11 ]

With old styled apps, this issue is not fixed

Comment by Ken Cavanaugh [ 17/Feb/11 ]

I was certain I fixed this, but I'll test it again, and target it for
3.2.





[GLASSFISH-15590] Regular Expression Checking not working for calculated values Created: 17/Jan/11  Updated: 18/Feb/13

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

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

Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

D:\gf\v3\core\kernel>asadmin get -m server.applications.x.y\.z.server.jsp.servicetime-coun*
No monitoring data to report.

D:\gf\v3\core\kernel>asadmin get -m server.applications.x.y\.z.server.jsp.servicetime-count
server.applications.x\.y\.z.server.jsp.servicetime-count = 0

=======
The first command ought to work.



 Comments   
Comment by Byron Nevins [ 17/Jan/11 ]

Another example:
========================
D:\gf\v3\core\kernel>asadmin get -m server.applications.x.y.z.server.jsp.servicetime*

server.applications.x\.y\.z.server.jsp.dotted-name =
// lots of output removed //

============
D:\gf\v3\core\kernel>asadmin get m server.applications.x.y.z.server.jsp.servicetime*
No monitoring data to report.

Comment by Byron Nevins [ 22/Mar/11 ]

As you can see – the internal code is NOT looking at things as final strings and thus misses stuff.

Another Example

D:\>asadmin get -m server.applications.x\.y.server.jsp.servicetime*
server.applications.x\.y.server.jsp.dotted-name = server.applications.x\.y.server.jsp
server.applications.x\.y.server.jsp.servicetime-count = 0
server.applications.x\.y.server.jsp.servicetime-description = Aggregate response time
server.applications.x\.y.server.jsp.servicetime-lastsampletime = 1300811411960
server.applications.x\.y.server.jsp.servicetime-name = ServiceTime
server.applications.x\.y.server.jsp.servicetime-starttime = 1300811252183
server.applications.x\.y.server.jsp.servicetime-unit = millisecond

D:\>asadmin get m server.applications.x\.y.server.jsp.servicetime*
No monitoring data to report.

Comment by Byron Nevins [ 14/Apr/11 ]
  • Why fix this issue in 3.1.1?
    Just piping output to grep with a regular expression works. Meanwhile giving the same regular expression to the monitoring framework gets no matches at all – this reflects badly on the product.
  • Which is the targeted build of 3.1.1 for this fix?
    I have no list of builds to pick from ?!?
  • Do regression tests exist for this issue?
    Yes. There are many unit tests, dev tests and QE tests
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Homer should re-run the QE 3.1 monitoring tests
Comment by scatari [ 14/Apr/11 ]

Approved.

Comment by Byron Nevins [ 24/May/11 ]

Excluding from 3.1.1

I spent an hour looking at this. The code has "high resistance to change". It is too risky and time-consuming for 3.1.1

Also there is a very very easy work-around which is to move the star upstream.

E.g. this does not work because the "-count" is a calculated thing. There is no "real" monitoring data with that name ending in a hyphen

server.applications.HelloWeb.server.sessionstotal-*

But this works fine:

server.applications.HelloWeb.server.sessionstotal*





[GLASSFISH-15490] IIOP failover Dev Test is failing Created: 07/Jan/11  Updated: 19/Dec/16

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
Fix Version/s: 4.1.1

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

Attachments: Text File orb-iiop-folb-multinode-build7.log    
Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

IIOP failover Dev Test is failing on multi node cluster, with secure admin enabled

Config 1: Single node, three instance cluster, with no secure admin: IIOP failover works fine.

Config 2: Two node, three instance cluster, with secure admin enabled: The tests fails with following exception:

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

[failOverTest] result[50]= in1
Command stop-instance for instance in1
javax.ejb.NoSuchEJBException
at orb.folb._LocationBeanRemote_Wrapper.getLocation(orb/folb/_LocationBeanRemote_Wrapper.java)
at orbfailover.Main.failOverTest(Main.java:136)
at orbfailover.Main.main(Main.java:104)
Caused by: java.rmi.NoSuchObjectException: CORBA OBJECT_NOT_EXIST 1398079490 No; nested exception is:
org.omg.CORBA.OBJECT_NOT_EXIST: ---------BEGIN server-side stack trace---------
org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy140.noObjectAdaptor(Unknown Source)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:228)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.findObjectAdapter(CorbaServerRequestDispatcherImpl.java:361)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:192)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:220)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:496)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:537)
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent: IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.doActivate(POAImpl.java:1115)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1048)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)
... 12 more

---------END server-side stack trace--------- vmcid: SUN minor code: 2 completed: No
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:269)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
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 orb.folb._LocationBeanRemote_Remote_DynamicStub.getLocation(orb/folb/_LocationBeanRemote_Remote_DynamicStub.java)
... 3 more
Caused by: org.omg.CORBA.OBJECT_NOT_EXIST: ---------BEGIN server-side stack trace---------
org.omg.CORBA.OBJECT_NOT_EXIST: FINE: IOP02500002: Failed to create or locate Object Adaptor vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy140.noObjectAdaptor(Unknown Source)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:228)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.findObjectAdapter(CorbaServerRequestDispatcherImpl.java:361)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:192)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:220)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:496)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:537)
Caused by: org.omg.PortableServer.POAPackage.AdapterNonExistent: IDL:omg.org/PortableServer/POA/AdapterNonExistent:1.0
at com.sun.corba.ee.impl.oa.poa.POAImpl.doActivate(POAImpl.java:1115)
at com.sun.corba.ee.impl.oa.poa.POAImpl.find_POA(POAImpl.java:1048)
at com.sun.corba.ee.impl.oa.poa.POAFactory.find(POAFactory.java:224)
... 12 more

---------END server-side stack trace--------- vmcid: SUN minor code: 2 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.MessageBase.getSystemException(MessageBase.java:900)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.ReplyMessage_1_2.getSystemException(ReplyMessage_1_2.java:131)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.getSystemExceptionReply(CorbaMessageMediatorImpl.java:637)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.processResponse(CorbaClientRequestDispatcherImpl.java:499)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:373)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:243)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:200)
... 6 more
[failOverTest] FAIL

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



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

The same test (with no changes) passed with latest nightly build.

Comment by Ken Cavanaugh [ 10/Jan/11 ]

As this is now passing, I'm closing this issue. I suspect there was a problem
with EJB deployment on a cluster in secure admin mode, which would result in
the observed exception.

Comment by Harshad Vilekar [ 18/Jan/11 ]

Reopening the issue, since the exception is seen intermittently with nightly hudson runs.

1. The pattern is:

  • The FailOver test fails when the instance - running on the remote node - is stopped.
  • The FailOver test works fine, when the instance - running on the same node as DAS node - is stopped.

2. The cluster state is looking fine:

$asadmin list-instances --long c1
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 6738 c1 running
in1 intg2t1000 8107 3474 c1 running
in3 localhost 8619 6630 c1 running
Command list-instances executed successfully.

3. OrbFailOver-ejb is deployed on the cluster, and looks fine:
------------------
$ asadmin list-applications c1
OrbFailOver-ejb <ejb>
------------------

Comment by Ken Cavanaugh [ 18/Jan/11 ]

Moving to next release: not a release blocker for 3.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-15429] Modifying keyfile path in a newly created config does not properly list the users Created: 04/Jan/11  Updated: 19/Dec/16

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 3.1_dev
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-13144] appclient with Extension-List manifest entry cannot be deployed Created: 26/Aug/10  Updated: 20/Dec/16  Resolved: 23/May/13

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: v3.0.1
Fix Version/s: 4.0_dev

Type: Bug Priority: Major
Reporter: David Konecny 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: GZip Archive sample-projects.tar.gz    
Issue Links:
Related
is related to GLASSFISH-20578 App client deployment/download/launch... Open
Issuezilla Id: 13,144
Tags: 3_1-exclude, 3_1_1-exclude

 Description   

As discussed offline I have ApplicationClient3.jar which in order to runs
requires MujYnterfejs.jar. I can deploy this standalone EE module to GFv301 via
command line using --libraries option and everything works fine.

If I add to manifest of ApplicationClient3.jar:

Extension-List: jar-1

jar-1-Extension-Name: MujYnterfejs.jar

and to manifest of MujYnterfejs.jar:

Extension-Name: MujYnterfejs.jar

then deployment stops working and I'm given error:

SEVERE: Exception while invoking class
org.glassfish.appclient.server.core.AppClientServerApplication start method
java.lang.RuntimeException: java.io.IOException: Jar file requires the extension
Name=MujYnterfejs.jar, spec version = but it is not in the known extensions {}

I'm adding Extension attributes to the jars because Weblogic requires them for
standalone EE module deployment. I tried to place MujYnterfejs.jar into
GlassFish's $

{domainDir}/lib/ext directory and that allowed me to deploy the
app successfully but running it resulted in ClassNotDefFound exception for a
class from MujYnterfejs.jar. I have no idea why as MujYnterfejs.jar is available
both in ${domainDir}

/lib/ext as well as via --libraries option.

I will attach two NetBeans projects with sources and build artifacts:
ApplicationClient3/dist/ApplicationClient3.jar and
MujYnterfejs/dist/MujYnterfejs.jar



 Comments   
Comment by David Konecny [ 26/Aug/10 ]

Created an attachment (id=4747)
sample-projects.tar.gz

Comment by Tim Quinn [ 04/Oct/10 ]

Setting target milestone to MS 7, although I hope to resolve this before that time.

Comment by Tim Quinn [ 15/Nov/10 ]

There are actually several aspects to this.

1. The error you see is from some deployment logic that supports Java Web Start
launches of app clients. There was in fact a bug that caused this logic to not
recognize JARs in the domain's lib/ext directory as extension JARs. It's a
simple fix and it allowed me to deploy the sample app you attached.

2. The philosophy we adopted about extension libraries and app clients is this:
Such libraries are typically installed on systems separately from installing
applications. They often reside in different places as well. With this in
mind, when a user deploys an app client or an EAR containing an app client, the
downloaded files do NOT include copies of any extension library JARs. The
assumption is that the user (or a script) would do something like this:

appclient -Djava.ext.dirs=xxx -client dir/myProgClient.jar

and the extension libraries would have been separately placed somewhere and
"xxx" would be their directories.

(The appclient launch failed eventually because the ACC could not inject an EJB
reference - the EJB was not in the app - but that's OK. It shows that the
client was able to find the class which it could not without the -Djava.ext.dirs
setting.)

3. We view things differently regarding Java Web Start launches. Here we DO
download extension library JARs to the client. The idea in this case is that
remote systems launching using Java Web Start are more likely out of reach or
more difficult to manage for system administrators than are systems which launch
using the appclient script. As a result, we felt it was important to include
the extension library JARs in the download. With the fix from #1 in place, I
could launch the sample client using Java Web Start and it gave the same results
as #2.

4. Currently - and this is an error - the app client processing does NOT pay
attention to the --libraries setting.

I will check in the fix I mentioned in #1 shortly. I will also look at fixing
the problem in #4.

Comment by Tim Quinn [ 15/Nov/10 ]

Partial fix checked in. Now the example app and ones like it should deploy
correctly. They will run correctly in Java Web Start launches without any
special action, and they will run correctly from the appclient script if the
extension library is installed on the client system and the containing directory
referenced using -Djava.ext.dirs on the appclient command.

I am leaving this open to see if we can also have Java Web Start launches also
include the libraries from the --libraries option on the deploy command.

Author: tjquinn
Date: 2010-11-16 06:07:51+0000
New Revision: 42847

Modified:

trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/ExtensionFileManager.java

Comment by Tim Quinn [ 13/Dec/10 ]

Unfortuntely I need to defer the --libraries support to a possible later release after 3.1.

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 Tim Quinn [ 23/May/13 ]

The key part of this issue has been fixed for a long time. I've created a separate issue to capture the --libraries support aspect and I'm closing this one. It was fixed long before 4.0 even though that's when I'm marking it as fixed.





[GLASSFISH-12462] server crashes: CORBA NO_PERMISSION Created: 02/Jul/10  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: v3.0.1
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: lft Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Attachments: Zip Archive mem.zip     Text File server.log_2010-09-17T18-00-08    
Issuezilla Id: 12,462
Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-next, 3_1_1-scrubbed

 Description   

Some times during nomal working of GF server (v 3.0.1) log messages like this
appears:
[#|2010-07-01T21:04:34.856+0400|SEVERE|glassfish3.0.1|FRUITCOCTAIL_15985.openbox.fruitcoctail._FruitCoctailSlotMachineBean_Serializable|_ThreadID=272;_ThreadName=Thread-1;|The
log message is null.
javax.ejb.EJBAccessException
at
openbox.session._SessionFacade_Wrapper.getCredit(openbox/session/_SessionFacade_Wrapper.java)
at openbox.core.component.GameComponent.getCredit(GameComponent.java:46)
at
openbox.core.slotmachine.AbstractSlotMachineMath.setPickedLineCount(AbstractSlotMachineMath.java:165)
at
openbox.fruitcoctail.FruitCoctailSlotMachineBean.setPickedLineCount(FruitCoctailSlotMachineBean.java:227)
at sun.reflect.GeneratedMethodAccessor1042.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1056)
at
org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1128)
at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4087)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5272)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5252)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:201)
at
com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:75)
at $Proxy266.setPickedLineCount(Unknown Source)
at sun.reflect.GeneratedMethodAccessor1041.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:146)
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:176)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:682)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:216)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)
Caused by: java.rmi.AccessException: CORBA NO_PERMISSION 9998 Maybe; nested
exception is:
org.omg.CORBA.NO_PERMISSION: ----------BEGIN server-side stack
trace----------
org.omg.CORBA.NO_PERMISSION: vmcid: 0x2000 minor code: 1806 completed: Maybe

at
org.glassfish.enterprise.iiop.impl.POAProtocolMgr.mapException(POAProtocolMgr.java:294)

at
com.sun.ejb.containers.BaseContainer.mapRemoteException(BaseContainer.java:2212)

at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2042)

at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1955)

at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:208)

at
com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:75)

at $Proxy184.getCredit(Unknown Source)

at sun.reflect.GeneratedMethodAccessor174.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:146)

at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:176)

at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:682)

at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:216)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)

at
com.sun.corba.ee.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:119)

at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:235)

at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:187)

at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:147)

at
com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:225)

at
openbox.session._SessionFacade_Remote_DynamicStub.getCredit(openbox/session/_SessionFacade_Remote_DynamicStub.java)

at
openbox.session._SessionFacade_Wrapper.getCredit(openbox/session/_SessionFacade_Wrapper.java)

at openbox.core.component.GameComponent.getCredit(GameComponent.java:46)

at
openbox.core.slotmachine.AbstractSlotMachineMath.setPickedLineCount(AbstractSlotMachineMath.java:165)

at
openbox.fruitcoctail.FruitCoctailSlotMachineBean.setPickedLineCount(FruitCoctailSlotMachineBean.java:227)

at sun.reflect.GeneratedMethodAccessor1042.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at
org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1056)

at
org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1128)

at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4087)

at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5272)

at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5252)

at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:201)

at
com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:75)

at $Proxy266.setPickedLineCount(Unknown Source)

at sun.reflect.GeneratedMethodAccessor1041.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:146)

at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:176)

at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:682)

at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:216)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1841)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1695)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1078)

at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:221)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:797)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:561)

at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2558)

at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:492)

at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:528)

Caused by: javax.ejb.AccessLocalException: Client not authorized for this
invocation.

at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1850)

at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:200)

... 47 more

---------END server-side stack trace--------- vmcid: 0x2000 minor code: 1806
completed: Maybe

at
com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:276)

at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:200)

at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:147)

at
com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:225)

at
openbox.session._SessionFacade_Remote_DynamicStub.getCredit(openbox/session/_SessionFacade_Remote_DynamicStub.java)

... 31 more

…

It appears during calling of methods stateless bean from stateful bean marked
with @RunAs in that places of code where in another case it works without
problems. I have already issued this bug ealier. So I have created workaround
for this bug: just place calling of this methods in loop which exits after 3
tryes or when EJBAccessException is absent. Now I have another problem:
Sometimes this exception starts to be continual (every time when perfoming call
to stateless bean). So application clients just can't continue working cause
this bean is central logic bean of all application. Only domain restart helps.
Domain is production, application is in production use. So just restarting is
not acceptable solution. We don't wont to migrate to the jboss, but this bug
doesn't allow to use GF 3.0.1 as production application server.

P.S. We using jdbcRealm with oracle databse.



 Comments   
Comment by Tom Mueller [ 08/Jul/10 ]

Looks EJB related.

Comment by lft [ 16/Jul/10 ]

No news about this problem? We have to reboot gf server every day. Beacuase it
can't run more than one day without crashing. We tried to declare application
roles in deployment descriptor. The problem persists. So we don't now what to do
now.

Comment by kumarjayanti [ 16/Jul/10 ]

Can u help us reproduce this with a small testcase.

Comment by lft [ 17/Jul/10 ]

I'd love to. But i can't. I don't know why this messages sometimes become cyclic.
I'll try to describe simplified model of my application. There is central
stateless bean (1) that manages abstract user session — it called SessionFacade.
It works with entities that packed with this bean in separate jar file. This
central bean has methods. Some of its methods are accessible for authenticated
clients (we use ProgrammaticLogin) and some for specific role 'COMPONENT'. There
are another (2) beans (stateful). This beans are accessible for authenticated
clients and marked with @RunAs ('COMPONENT-USER'), where COMPONENT-USER is
user of group 'COMPONENT', so every call they make to central bean uses
«COMPONENT» role.
EJBAccessException occurs during calling methods of (1)-st bean from methods of
(2)-nd bean. It seems like @RunAs does not works.
Additional information: we use GF 3.0.1, Oracle database 10.2.0.5, jdbcRealm.
PS I turned on jdbc monitoring, and I sess great values for metrics named
NumConnReleased and NumConnAcquired (about 1795846 for a day). It'is logical
connection, but is it normal?

Comment by lft [ 19/Jul/10 ]

We have another problem that disturbs us and that I was planned to report as
separate issue. But today I thought maybe it some kind related to this thread.
Description of problem: We use ProgrammaticLogin for authentication of
standalone-client applications as I mentioned earlier. After successful loging
in the first call to secure (or unsecure - doesn't matter in this case as we
have tested) EJB method continues for a abnormal long time (up to 30 seconds)
after that other methods or the same method are fast enough (< 1 sec.).

Comment by lft [ 17/Aug/10 ]

Now I'm almost sure this is memory related problem. When I increased Xmx startup
parameter from 512M to 1024M the problem disappeared. When I decreased it again
the problem came back.
I have two identical servers (All hardware and software are identical) with value
512m for Xmx. But numbers of possble parralel sessions are 5 and 10 for the first
and the second. First one works fine without errors. The second can't work more
then 1 day without restart.
I hope this inforation will be useful.

Comment by kumarjayanti [ 08/Sep/10 ]

Hi,

Can you provide a heap-dump that i can analyze ?. Have you tried with latest
builds of V3.1 to see if the problem goes away ?. I have to get a resolution on
this bug soon.

thanks.

Comment by lft [ 08/Sep/10 ]

About my previous post: now I don't think it's memory related problem. I have
monitored gc with -Xloggc option and figurted out that heap jvm memory doesn't
hit -Xmx value . After numbers of experiments It's seems to be jdbc related
problem (jdbcRealm).But I'm in doubt about it. I set 64 initial pool connections
for jdbc connection pool (default is 8), and this error does not happens for two
weeks.

kumarjayanti, I'll try to provide a heap-dump for you next time this error
appears. About GF V3.1 - we can't migrate our production servers to this version
cause it's not stable (as glassfish official site says) and we also can't
reproduce this error on test servers in not prodution enviroment cause it's not
predictable.

Comment by lft [ 08/Sep/10 ]

kumarjayanti, what tool should I use to generate heap dump? What format do you
prefer?

Comment by lft [ 13/Sep/10 ]

One of our servers crashed today with this bug and unfortunately I had no jdk
installed on that server to create heap dump. I needed to make server works
properly as quickly as possible. So I restarted it and only thing I had time to
do is to save linux process memory dump (cat /proc/<pid>/smaps). I'll install
jdk on every server to be able to make core dump next time. This time I'm
posting only linux format process memory dump.

Comment by lft [ 13/Sep/10 ]

Created an attachment (id=4870)
linux-format process dump

Comment by kumarjayanti [ 14/Sep/10 ]

Thanks for the dmp file but i am sorry to say i was not able to make much sense.

I need to know the following :
1. When you say server crash is there actually a Core Dump ?.
2. is there an error of the form OutofMemoryError : Heap Space
3. What does the sever.log at the time of the crash.

Can you please follow this one :
http://blogs.sun.com/alanb/entry/heap_dumps_are_back_with

And provide me a .hprof file (java_pidXXX.hprof) that i can later analyze with jhat.

Do you have anyother tools at your disposal that can pinpoint the problem to us.

Thanks for your patience.

Comment by lft [ 14/Sep/10 ]

1) When I say "server crashes" - I don't mean JVM crash. Glassfish server
continues to work but all deployed EJB applications becomes unusefull.
2) No there is no error like "OutofMemoryError" and I don't think it's
out-of-memory issue.
3) The server.log is full of "CORBA.NO_PERMISSION" messages (see my first post).
After this happens, every time someone call ejb method, message like that I
posted earlier is wrote down to server.log

AS I sad I had no JDK at the moment on remote server, next time i'll use jmap to
generate heap dump (jmap -dump:file=... <pid>). Thanks that you don't ignore our
issue.

Comment by kumarjayanti [ 15/Sep/10 ]

Since this is not a memory issue i don't need the Heap Dump any more. Can you
attach the full server log when the error starts happening. Do you see the word
"purged connections..." in the logs.

Does the error happen under heavy load ?. Do you suspect it is a multithreaded
access bug ?.

The orb uses thread-pool-1 by default and it's max pool size is 200 (in V3.1).
Do you think it will help to increase this size a bit to say 500 ?.

Comment by lft [ 15/Sep/10 ]

> Can you attach the full server log when the error starts happening.
Yes, I'll provide server.log
> Do you see the word "purged connections..." in the logs.
no, I don't see anything like this
> Does the error happen under heavy load ?.
It seems to me that error happen when number of parralel sessions (and threads)
increases rapidly, but I'm not shure about it.
> Do you suspect it is a multithreaded access bug ?.
May be.
> The orb uses thread-pool-1 by default and it's max pool size is 200 (in V3.1).
> Do you think it will help to increase this size a bit to say 500 ?.
I'm not shure this is thread-pool issue and not jdbc-pool issue. As I said
earlier increasing initial connections in jdbc-pool (that used both for entity
beans communication with DB and for security with jdbcRealm) maked error hapen
rarely.
I can turn on monitoring for thread pool to check out thread pool using.

Comment by lft [ 18/Sep/10 ]

Created an attachment (id=4920)
server.log_2010-09-17T18-00-08

Comment by lft [ 18/Sep/10 ]

This is one of the server logs. Logs are changing once a minute. So I decided to
post here only first one. The rest contain same exceptions.

Comment by kumarjayanti [ 30/Sep/10 ]
      • Issue 12115 has been marked as a duplicate of this issue. ***
Comment by kumarjayanti [ 04/Oct/10 ]

Can you attach the granted.policy file and exclude.policy file (if any) that get generated when you deploy
this application.

Thanks.

Comment by lft [ 04/Oct/10 ]

kumarjayanti, I sent logs and policy configs to you via e-mail.

Comment by kumarjayanti [ 06/Oct/10 ]

Will try to fix by V3.1 MS07. The main problem with this issue is the user/customer is not using V3.1 (but
V3.0.1 instead) and the issue cannot be reproduced except in Production.

Have gathered relevant information from the user and now need to investigate manually and see if there is
a problem somewhere. Again after a fix it is not clear how the user can test it unless V3.1 is used, because
a fix in V3.0.1 will only be made as a patch for GlassFish Customers.

Comment by lft [ 06/Oct/10 ]

kumarjayanti ,
Ok. We created script that reboots server every 12 hours when there is no user
sessions. So now we can wait for 3.1 release. But how can you be shure that this
problem will be fixed in 3.1 release. Do you have any suggestions about root
cause of this issue?

Comment by lft [ 06/Oct/10 ]

thanx again that you don't ignore this issue.

Comment by kumarjayanti [ 06/Oct/10 ]

--------
But how can you be shure that this
problem will be fixed in 3.1 release. Do you have any suggestions about root
cause of this issue?
--------

I can't be sure unless you confirm it by using it .
But first i have to analyze all the data u provided to see if i can get to the root cause. Will let u know.

The updates to the bug i did earlier today in terms of setting target milestone etc are project
management requirements that i need to comply with for the upcoming V3.1 release.

Comment by kumarjayanti [ 06/Oct/10 ]

--------
But how can you be shure that this
problem will be fixed in 3.1 release. Do you have any suggestions about root
cause of this issue?
--------

I can't be sure unless you confirm it by using it .
But first i have to analyze all the data u provided to see if i can get to the root cause. Will let u know.

The updates to the bug i did earlier today in terms of setting target milestone etc are project
management requirements that i need to comply with for the upcoming V3.1 release.

Comment by kumarjayanti [ 19/Nov/10 ]

would like to spend time during ms-08 to see if we can find some issue. Since we cannot reproduce this
problem at our end the only way to find some issue is to analyze the code and the logs and generated
policy sent by the user.

Comment by kumarjayanti [ 13/Apr/11 ]

Hi,

Can you verify if this problem exists with the V3.1 release and send us a way to reproduce this.





[GLASSFISH-11740] Embedded ACC API does not inject when passed a client class Created: 31/Mar/10  Updated: 08/Feb/13

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

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: Tim Quinn
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: Zip Archive HelloApp.zip    
Issuezilla Id: 11,740
Tags: 3_1-exclude, 3_1_1-exclude

 Description   

See this forum topic
http://forums.java.net/jive/post!reply.jspa?messageID=394603 (I will attach the
sample app from that topic to this issue.)

The app client contains an @EJB annotation and the driver program passes the
client class to the ACC builder (as opposed to passing a URI to the client JAR
which works correctly.)



 Comments   
Comment by Tim Quinn [ 31/Mar/10 ]

Created an attachment (id=4286)
sample EAR (with EJB and app client) and sample embedded ACC driver program

Comment by Tim Quinn [ 04/Oct/10 ]

Setting target milestone to MS 7.

This might not be fixable in the time available; it's a relative rare case but
would be good to fix.

Comment by Tim Quinn [ 17/Nov/10 ]

I am excluding this from 3.1 and tentatively targeting it for 3.2 because this
is a very rare case.





[GLASSFISH-11468] Glassfish V3 Admin console OOO after OpenSSO Policy Agent installation Created: 21/Jan/10  Updated: 08/Jul/11  Resolved: 08/Jul/11

Status: Closed
Project: glassfish
Component/s: other
Affects Version/s: V3
Fix Version/s: future release

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

Operating System: Solaris
Platform: Sun


Attachments: XML File domain.xml     Text File login.conf     Text File server.log     Text File server.policy    
Issuezilla Id: 11,468
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed

 Description   

Using Glassfish V3 on Solaris. Version = GlassFish v3 (build 74.2)
Glassfish V3 mainly used as a web container for IdM and OpenSSO Agent 3.0 (to
secure IdM logging).
Problem comes after the OpenSSO Agent has been installed (GF V3 config files
have been customized/modified by the OpenSSO install script).

The OpenSSO Agent installation main steps are:

  • Stop GF V3 domain
  • Run the OpenSSO Agent installation program
  • Start GF V3 domain
  • Deploy the OpenSSO Agent war file

After the OpenSSO Agent installation program has run, the following 3
configuration files have been modified:

  • server.policy
  • login.conf
  • domain.xml
    Those files will be attached to this report later.

Now, when starting back GF V3, the following problem occurs.

  1. /root/glassfishv3/bin/asadmin start-domain
    I don't understand the format of this jvm-option:
    -DLOG_COMPATMODE=Off

This is coming from the customized domain.xml file. 2 new jvm-options have been
defined. The definition is not done using a single line each time but several
ones this way:
<jvm-options>
-DLOG_COMPATMODE=Off
</jvm-options>
<jvm-options>

-Djava.util.logging.config.file=/opt/j2ee_agents/appserver_v9_agent/config/OpenSSOAgentLogConfig.properties
</jvm-options>

By modifying (manually) the domain.xml file to have the definition on a single
line this way:
<jvm-options>-DLOG_COMPATMODE=Off</jvm-options>

<jvm-options>-Djava.util.logging.config.file=/opt/j2ee_agents/appserver_v9_agent/config/OpenSSOAgentLogConfig.properties</jvm-options>
GF V3 starts fine.

  1. /root/glassfishv3/bin/asadmin start-domain

Waiting for DAS to start ................................
Started domain: domain1
Domain location: /root/glassfishv3/glassfish/domains/domain1
Log file: /root/glassfishv3/glassfish/domains/domain1/logs/server.log
Admin port for the domain: 4848
Command start-domain executed successfully.

By having used older GF releases (GFv2.1 for example), the problem is not
happening for those older GF releases (no need to manually modify domain.xml to
have GFv2.1 starting fine).

Also, prior the OpenSSO Agent installation, the GF V3 Administrative GUI console
was working fine (http://<host>:4848).
After the OpenSSO Agent installation, this Administrative GUI console is not
anymore working:
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while
attempting to process a 'initPage' event for '/common/index.jsf'.
+ java.lang.NullPointerException

GFv3 log file will also be attached later.



 Comments   
Comment by ttrapple [ 21/Jan/10 ]

Created an attachment (id=4169)
GF v3 domain.xml file (after OpenSSO Agent installed and manually modified)

Comment by ttrapple [ 21/Jan/10 ]

Created an attachment (id=4170)
GF v3 login.conf file (after OpenSSO Agent installed)

Comment by ttrapple [ 21/Jan/10 ]

Created an attachment (id=4171)
GF V3 server.policy file (after OpenSSO Agent installed)

Comment by ttrapple [ 21/Jan/10 ]

Created an attachment (id=4172)
GF v3 server.log file

Comment by ttrapple [ 25/Jan/10 ]

OpenSSO Agent seems not to be supported yet on Glassfish V3.
Few issues have been filed for this:
https://opensso.dev.java.net/issues/show_bug.cgi?id=5008
https://opensso.dev.java.net/issues/show_bug.cgi?id=5764

Comment by Nazrul [ 09/Aug/10 ]

Getting help from Kumar

Comment by kumarjayanti [ 08/Sep/10 ]

request the filer of this bug to test this with latest V3.1 builds :

http://hudson.glassfish.org/job/gf-trunk-build-continuous/5823/

to see if the problem persists.

If i do not hear back by the end of this week i will mark the bug for V3.2.

thanks.

Comment by kumarjayanti [ 14/Sep/10 ]

updated target.

Comment by kumarjayanti [ 04/Oct/10 ]

status whiteboard comment

Comment by kumarjayanti [ 04/Oct/10 ]

added keyword

Comment by kumarjayanti [ 08/Jul/11 ]

issue no longer relevant





[GLASSFISH-11293] Unable to install load balancer Created: 09/Dec/09  Updated: 08/Jul/11

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

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

Operating System: Windows XP
Platform: PC


Issuezilla Id: 11,293
Status Whiteboard:

3.1-exclude v3_exclude

Tags: 3_1-exclude, 3_1_1-exclude

 Description   

Unable to install load balancer using sges_ee-2_1_1-windows.exe installer both
as a full install and as an update install just for load-balancer.

I am looking at page 104 of "Sun GlassFish Enterprise Server v2.1.1 High
Availability Administration Guide." The Note in the middle of page says: "The
following steps are automatically performed by the installation program for
Enterprise Server. ..."

I am not sure that it is doing anything.

I am on Windows XP Pro SP3
Installed WebServer 7u6
Installed GF2.1.1 with HADB and Load balancer.

After creating a load balancer instance in the Admin Console and clicking on
Test Connection, fail with "Test Connection Failed."

looking at magnus.conf file, and the changes mentioned in the HA Admin Guide are
not there.

Thanks
Leonid



 Comments   
Comment by kumara [ 10/Dec/09 ]

Load balancer feature is not in v3.

Comment by shche123 [ 10/Dec/09 ]

Is version 2.1.2 in the works? If so, can that also be a candidate for a fix?

Comment by kshitiz_saxena [ 10/Dec/09 ]

Do you see any error being logged during installation? Do you see any backup
files created for magnus.conf or obj.conf created in config directory of
web-server instance?

What do you mean by 2.1.2 ?

Comment by shche123 [ 11/Dec/09 ]

GF version 2.1.2 - in the plans?

Could this issue have to do with security? Not sure...

Comment by kshitiz_saxena [ 25/Aug/10 ]

GlassFish 3.1 will have a separate installer. Excluded for 3.1.

Comment by kshitiz_saxena [ 04/Oct/10 ]

Setting Target milestone to 2.1.2. Also adding keyword 3.1-exclude.

Comment by kshitiz_saxena [ 08/Jul/11 ]

Changing priority to Major and assigning to Puneet as this is a v2 issue.





[GLASSFISH-11257] Managed Beans not supported during Java Web Start launches of app clients Created: 06/Dec/09  Updated: 10/May/13

Status: Open
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1, 3.1.1, 3.1.2, 4.0
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: Tim Quinn
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 possibleSolution.txt     Zip Archive TestManagedBeanClient.zip    
Issuezilla Id: 11,257
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude, 3_1_1-exclude, 3_1_2-exclude, 3_1_x-exclude

 Description   

Managed bean support is not available in app clients launched using Java Web
Start. This limitation arises because the annotation processing logic is based
on File objects. During Java Web Start launches the JAR files are not
accessible as File objects.



 Comments   
Comment by kumara [ 06/Dec/09 ]

Not a show stopper for v3 release.

Comment by Gail Risdal [ 08/Dec/09 ]

Added to v3 Release Notes.

Comment by Tim Quinn [ 16/Dec/09 ]

Partial fix checked in.

These changes allow annotation scanning target JARs to be specified either by
File (as before) or by URI. The Java Web Start environment makes the URIs - but
not the corresponding File objects - easily available. Further changes are
underway to complete the work on this issue.

Author: tjquinn
Date: 2009-12-16 14:57:23+0000
New Revision: 35127

Modified:

trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/annotation/impl/AppClientScanner.java

trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/annotation/impl/ModuleScanner.java

trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/annotation/introspection/ClassFile.java

Comment by Tim Quinn [ 04/Oct/10 ]

setting target milestone to MS 7. Still need to see if we can really fix this
for 3.1.

Comment by Tim Quinn [ 14/Nov/10 ]
      • Issue 11063 has been marked as a duplicate of this issue. ***
Comment by Tim Quinn [ 17/Nov/10 ]

Marking this as excluded for 3.1.

I might get to this if time permits. Otherwise we'll reconsider it for a
possible future release.

Comment by Tim Quinn [ 30/Nov/11 ]

Here is a stack trace from a Java Web Start launch of a very simple sample app client (I'll attach the code).

java.lang.RuntimeException: Error launching or running the application
at org.glassfish.appclient.client.JWSAppClientContainerMain.main(JWSAppClientContainerMain.java:144)
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.javaws.Launcher.executeApplication(Launcher.java:1914)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1847)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1609)
at com.sun.javaws.Launcher.run(Launcher.java:138)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.RuntimeException: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Env-Prop: testmanagedbean.Main/theBean@Field-Injectable Resource. Class name = testmanagedbean.Main Field name=theBean@java.lang.String@java:app/TestManagedBean/___internal_managed_bean_testmanagedbean.TheBean@@ into class testmanagedbean.Main: Lookup failed for 'java:comp/env/testmanagedbean.Main/theBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
at org.glassfish.appclient.client.JWSAppClientContainerMain$ClientRunner.run(JWSAppClientContainerMain.java:179)
at org.glassfish.appclient.client.JWSAppClientContainerMain.main(JWSAppClientContainerMain.java:138)
... 9 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Env-Prop: testmanagedbean.Main/theBean@Field-Injectable Resource. Class name = testmanagedbean.Main Field name=theBean@java.lang.String@java:app/TestManagedBean/___internal_managed_bean_testmanagedbean.TheBean@@ into class testmanagedbean.Main: Lookup failed for 'java:comp/env/testmanagedbean.Main/theBean' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:703)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:470)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectClass(InjectionManagerImpl.java:213)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectClass(InjectionManagerImpl.java:205)
at org.glassfish.appclient.client.acc.AppClientContainer$ClientMainClassSetting.getClientMainClass(AppClientContainer.java:625)
at org.glassfish.appclient.client.acc.AppClientContainer.getMainMethod(AppClientContainer.java:517)
at org.glassfish.appclient.client.acc.AppClientContainer.completePreparation(AppClientContainer.java:411)
at org.glassfish.appclient.client.acc.AppClientContainer.prepare(AppClientContainer.java:319)
at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:278)
at org.glassfish.appclient.client.JWSAppClientContainerMain$ClientRunner.run(JWSAppClientContainerMain.java:168)
... 10 more
Caused by: javax.naming.NamingException: Lookup failed for 'java:comp/env/testmanagedbean.Main/theBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.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: Lookup failed for 'java:app/TestManagedBean/___internal_managed_bean_testmanagedbean.TheBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming, com.sun.enterprise.naming.logicalName=java:comp/env/testmanagedbean.Main/theBean}

[Root exception is javax.naming.NamingException: Lookup failed for '_internal_java_app_for_app_clientTestManagedBeanjava:app/TestManagedBean/__internal_managed_bean_testmanagedbean.TheBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming, com.sun.enterprise.naming.logicalName=java:comp/env/testmanagedbean.Main/theBean}

[Root exception is javax.naming.NameNotFoundException: __internal_java_app_for_app_client__TestManagedBean__java:app]]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:599)
... 19 more
Caused by: javax.naming.NamingException: Lookup failed for 'java:app/TestManagedBean/___internal_managed_bean_testmanagedbean.TheBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming, com.sun.enterprise.naming.logicalName=java:comp/env/testmanagedbean.Main/theBean}

[Root exception is javax.naming.NamingException: Lookup failed for '_internal_java_app_for_app_clientTestManagedBeanjava:app/TestManagedBean/__internal_managed_bean_testmanagedbean.TheBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming, com.sun.enterprise.naming.logicalName=java:comp/env/testmanagedbean.Main/theBean}

[Root exception is javax.naming.NameNotFoundException: __internal_java_app_for_app_client__TestManagedBean__java:app]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.enterprise.naming.util.JndiNamingObjectFactory.create(JndiNamingObjectFactory.java:90)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$1.create(ComponentEnvManagerImpl.java:650)
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)
... 22 more
Caused by: javax.naming.NamingException: Lookup failed for '_internal_java_app_for_app_clientTestManagedBeanjava:app/TestManagedBean/__internal_managed_bean_testmanagedbean.TheBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming, com.sun.enterprise.naming.logicalName=java:comp/env/testmanagedbean.Main/theBean}

[Root exception is javax.naming.NameNotFoundException: __internal_java_app_for_app_client__TestManagedBean__java:app]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:226)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:498)
... 30 more
Caused by: javax.naming.NameNotFoundException: _internal_java_app_for_app_clientTestManagedBean_java:app
at com.sun.enterprise.naming.impl.TransientContext.resolveContext(TransientContext.java:310)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:218)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:77)
at com.sun.enterprise.naming.impl.RemoteSerialContextProviderImpl.lookup(RemoteSerialContextProviderImpl.java:109)
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.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)

Comment by Tim Quinn [ 30/Nov/11 ]

Attaching sample NB project containing a very simple app client with a ManagedBean. It works when launched using appclient -jar (path-to-appclient-JAR), and it works when deployed and the client stubs are retrieved. It does not work when launched using Java Web Start.

Comment by Tim Quinn [ 01/Dec/11 ]

Added text document describing a possible solution approach.

Comment by Tim Quinn [ 01/Dec/11 ]

Updating "affects versions" and excluding from 3.1.2 and any other other 3.1.x releases that might come along.

Comment by Tim Quinn [ 01/Dec/11 ]

Adjusting title to fix a typo that has bothered me a long time.

Comment by martinandersson.com [ 10/May/13 ]

I think this bug is something I could have stumbled upon when I try to use @Inject in my application client launched through Java web start. The impression I get is that the annotation is not scanned at all. I've expressed myself a little bit more over at stack overflow: http://stackoverflow.com/q/16480767/1268003





[GLASSFISH-11008] Enterprise profile in FIPS mode is allowing SSL2/3 protocols Created: 12/Nov/09  Updated: 08/Jul/11  Resolved: 08/Jul/11

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: v2.1
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: visu_patlolla Assignee: kumarjayanti
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,008
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude, 3_1_1-exclude, 3_1_1-scrubbed

 Description   

I have created a glassfish domain in enterprise profile with NSS modules in FIPS
mode.

In FIPS mode, SSL should be restricted to TLS protocol and only certain ciphers
suites should be enabled.

But the current glassfish configuration is not restricting. And I am able to
perform SSL communication b/w a glassfish domain configured with TLS and
glassfish configured with SSL3.

I think it is a bug in Glassfish security set up. Could some one look into this
issue ASAP?



 Comments   
Comment by visu_patlolla [ 12/Nov/09 ]
      • Issue 11008 has been confirmed by votes. ***
Comment by kumara [ 13/Nov/09 ]

Excluding from v3 defect tracking list because Enterprise profile does not exist in v3 so far.

Comment by kumarjayanti [ 06/Jul/10 ]

NSS support will not be in V3.1.

Comment by kumarjayanti [ 21/Jul/10 ]

status whiteboard updated.

Comment by kumarjayanti [ 04/Oct/10 ]

added keyword

Comment by kumarjayanti [ 08/Jul/11 ]

Since NSS is not supported in V3.X i am closing the bug. The issue can be reopened at a later stage if applicable





[GLASSFISH-9579] Strange error deploying MDB that injects EntityManager Created: 18/Sep/09  Updated: 09/Jan/13  Resolved: 09/Jan/13

Status: Closed
Project: glassfish
Component/s: standalone_client
Affects Version/s: V3
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Kim Haase Assignee: Tim Quinn
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Text File clientmdbentity.zip    
Issuezilla Id: 9,579
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude, 3_1_1-exclude

 Description   

One of the Java EE Tutorial examples is an enterprise app that contains an app
client, two MDBs, and an entity. The MDBs both inject the EntityManager as follows:

@PersistenceContext EntityManager em;

I've imported javax.persistence.EntityManager and
javax.persistence.PersistenceContext.

The errors I see when I deploy the app are the following:

[#|2009-09-18T10:41:48.792-0400|SEVERE|glassfish|global|_ThreadID=27;_ThreadName=Thread-2;|Invalid
annotation symbol found for this type of class.
symbol: FIELD location: javax.persistence.EntityManager eb.OfficeMDB.em

#]

[#|2009-09-18T10:41:48.799-0400|SEVERE|glassfish|global|_ThreadID=27;_ThreadName=Thread-2;|Invalid
annotation symbol found for this type of class.
symbol: FIELD location: javax.persistence.EntityManager eb.EquipmentMDB.em

#]

I couldn't find any prohibition in the EE 6 platform spec or the EJB 3.1 spec
against referencing an entity from a message-driven bean. This is an application
that worked fine in EE 5. I'll attach a zip file with the app in it.

The application actually runs just fine, so the error seems to be misleading. Do
I need to fix my code, or should the error not appear? It comes from "global",
so I'm not sure what component it applies to.

I'm using the current nightly GF build, glassfish-v3-b65-09_18_2009.zip, but the
error has been appearing for some time. Thanks for any assistance.



 Comments   
Comment by Kim Haase [ 18/Sep/09 ]

Created an attachment (id=3237)
application that gets strange deployment error

Comment by marina vatkina [ 21/Sep/09 ]

...

Comment by Hong Zhang [ 21/Sep/09 ]

Marina: I am not sure that I am the best person to look at this. I will let
Mitesh do the initial evaluation as it's related to entity persistence.

Comment by sherryshen [ 21/Oct/09 ]

cc

Comment by Mitesh Meswani [ 28/Oct/09 ]

Marina,

Can you please take a look

Comment by marina vatkina [ 28/Oct/09 ]

Tim,

Can you take a look? While the error messages can be more specific, the error is
logged from this code in EntityManagerReferenceHandler:

if (aeHandler instanceof AppClientContext)

{ // application client does not support @PersistenceContext String msg = localStrings.getLocalString( "enterprise.deployment.annotation.handlers.invalidaehandler", "Invalid annotation symbol found for this type of class."); log(Level.SEVERE, ainfo, msg); return getDefaultProcessedResult(); }

Why would MDBs be part of the AppClientContext?

Comment by Tim Quinn [ 28/Oct/09 ]

OK, after a while with the debugger and peering into the sample JARs I found out
what's happening.

The app client JAR's Class-Path refers to the EJB module JAR. During anno
processing, ModuleScanner#completeProcess adds any library JARs - which is
implemented to include the Class-Path entries - to the JARs to be scanned by the
anno scanner. So when the app client context is in force, it's including the
EJB JAR and that's where the offending annotation is located. So that triggers
the message.

This raises two questions:

#1. What should we do about this? The fact is that the system is indeed trying
to process an anno that does not make sense in the app client context. Some
developers, either explicitly using the Class-Path as in this case or by using
the compatibility=v2 property on deployment, will make EJB modules visible to
app clients, primarily to get access to the EJB interface.

What about logging this at WARNING or FINE instead of SEVERE?

#2. Ideally, the samples should show not only the useful coding syntax but also
the packaging approaches we recommend. It's a little more involved to create,
but it would be cleaner to show a packaging pattern in which the remote EJB
interface and any true utility classes are in a library JAR while the EJB
implementation classes are in the EJB module itself. Then the app client module
and the EJB module can depend on the library JAR, and the app client would not
depend on the EJB module JAR. This lets the client see the interface but not
any of the implementation. And, as a nice side-effect, it would avoid this
problem in our sample!

Can the sample be repackaged along those lines? Note that I'm less interested
in avoiding the error display and more interested in having the sample
demonstrate a sound packaging approach.

I'll keep ownership of this for the moment although I'm not sure who the best
owner is.

Comment by marina vatkina [ 28/Oct/09 ]

Wow!

Should we have several bugs filed from this one? This is what I think:
1. Java EE Tutorial examples should definitely reflect the latest spec requirements.

2. The error message should be more specific in what had gone wrong.

3. We should fail deployment if there is an annotation processing error (what
can a user do with such an app anyway?)

4. Either EntityManagerReferenceHandler to use a more specific assertion instead
of 'if (aeHandler instanceof AppClientContext)' so that only the main class is
checked or the referenced jars are skipped from annotations processing (aren't
they treated as just libraries in this case?)

Comment by Kim Haase [ 29/Oct/09 ]

I realized from this discussion that I actually didn't have to put the EJB JAR
in the application client classpath for this application, because the app client
doesn't access the beans directly – it just sends messages that the MDBs receive.

So I removed the Class-Path line from the manifest file, and the application no
longer gets the error, and it runs just fine.

But that doesn't resolve the underlying issue, because I might well have an
appclient that called business methods of a stateless session bean that injected
an EntityManager – I think that would be perfectly valid? And in that case I'd
have to put the EJB JAR in the classpath, and the error would occur.

Comment by marina vatkina [ 29/Oct/09 ]

No, the correct solution would be to put common interfaces in the lib jar and
place that jar into the lib/ dir of the ear file.

Comment by Tim Quinn [ 29/Oct/09 ]

Following up on my earlier thought...

Would it make sense, with reference to Marina's #2-#4, to just silently
disregard (or log at level FINE) such situations? If the particular reference
handler does not think it should work with a particular annotation given the
current context is it important to log it at such a visible level?

Ideally, the handler could choose whether to log the incident based on whether
the anno was found in the module itself or a library JAR which the module refers
to. But I'm not sure that the code running in the handler can tell the
difference at runtime.

Comment by David Konecny [ 01/Nov/09 ]

re. "#2. Ideally [...] remote EJB interface and any true utility classes are in
a library JAR" - what about Local and No-interface? NB does not provide any
guidance for creating EJB Remote interfaces in separate project but I think it
is something what can be left for user to decide. Nature of Remote interface is
that it will be used remotely from different application and therefore user has
to "somehow" export remote interface for the client in any case. But for Local
interface, more and more I think about it, it is redundant overhead to extract
interfaces to separate JAR. For No-interface it does not make any sense at all.

Comment by Tim Quinn [ 02/Nov/09 ]

I have checked in a partial fix for this, and am targeting any further fix for
3.1 and excluding it from v3.

The logic, as it stands, does not keep correct applications from working. It
correctly warns if a module includes an annotation that is not consistent with
the module type. But it also, as this issue shows, can generate noise with
error messages about annotations in JARs that are treated a library JARs. Even
so, such noise does not cause correct apps to fail or cause incorrect ones to
work.

Later we can revisit this so that the anno handler knows not only what context
it operates in (that is, what initial module it is processing for annos) but
also whether the JAR currently under inspection is that initial module or a
library module referred to from the initial module.

The change I have checked in changes the severity of the message from severe to
warning so it is not so alarming to users.

Author: tjquinn
Date: 2009-11-03 04:09:03+0000
New Revision: 33698

Modified:

trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/annotation/handlers/EntityManagerReferenceHandler.java

Comment by Tim Quinn [ 01/Oct/10 ]

I am marking this for reconsideration in 3.2.

The change I checked in a long time ago makes the message less alarming to
users. A more complete fix would require allowing the injection managers to
know what context they run in which is beyond the scope of 3.1.

Comment by Tim Quinn [ 09/Jan/13 ]

Marking this for future consideration.

Comment by Kim Haase [ 09/Jan/13 ]

I no longer see any errors or warnings about annotations (or anything else) when I deploy this example in GF 3.1.2.2. Please feel free to close it as fixed, if this seems appropriate.

Comment by Tim Quinn [ 09/Jan/13 ]

Thanks to Kim for double-checking this.

I've marked this bug as "cannot reproduce" - not in the current release anyway.





[GLASSFISH-7108] GlassFish Loadbalancer plugin for apache fails with Apache 2.0.63 shipped with Solaris 10 Update 6 Created: 30/Jan/09  Updated: 06/Mar/12

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

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

Operating System: Solaris
Platform: Sun


Attachments: HTML File error_log     XML File loadbalancer.xml    
Issuezilla Id: 7,108
Status Whiteboard:

3.1-exclude v3_exclude

Tags: 3_1-exclude, 3_1_1-exclude

 Description   

We are currently working on getting our partner's application certified on
GlassFish environment. For this we are trying tho setup Apache ( Apache
2.0.63 bundled with Solaris 10 updated 6 running on Sun Fire T5220 server) the
Load Balancer.

However on testing we are seeing following "Segmentation Fault" for requests
that go through LB plug in.

[crit] lb.runtime: RNTM2005: after LBApacheProxyRequest::LBApacheProxyRequest()
[notice] child pid 2392 exit signal Segmentation fault (11)

For the LB we used
http://download.java.net/javaee5/external/SunOS/aslb/jars/aslb-9.1-UR2-b1.jar

Doing a google, we also saw the discussion thread at
http://www.nabble.com/Loadbalancing-with-Apache---Errors-td18816655.html on the
same error.

A number customers will use the Apache bundled in Solaris 10. So the plugin
should work without any problem with the bundled Apache version.

The Apache error_logs is attached.



 Comments   
Comment by vbhat75 [ 30/Jan/09 ]

Created an attachment (id=2240)
Apache Error logs

Comment by vbhat75 [ 30/Jan/09 ]

Created an attachment (id=2241)
Load Balancer configuration File

Comment by kshitiz_saxena [ 02/Feb/09 ]

Assigning this issue to myself.

Comment by gmohideen [ 16/Feb/09 ]

Adding myself in cc iist

Comment by kshitiz_saxena [ 04/Mar/09 ]

Issue is record_rec passed has a nil uri

Code snippet :
mod_apache2lbplugin.cpp(Code modified to provide legibility)

133 /* Name Translation */
134 static int apachelbplugin_name_trans( request_rec* r)
135 {
136 ap_log_error(.....);
.
.
.
216 if((!strcmp(r->uri,"UPDATE_URL")) ...... )

Apache calls this API to handle a request. It creates request_rec and passes it
to load-balancer plugin. request_rec needs to populated correctly by apache code
before calling this API. Since this object does not have correct values for all
variables, strcmp check at line 216 fails crashing the process.

Below is dbx debugging information:
(dbx) stop in apachelbplugin_name_trans
(2) stop in
`mod_loadbalancer.so`mod_apache2lbplugin.cpp`apachelbplugin_name_trans(request_rec*)
(dbx) c
t@1 (l@1) stopped in apachelbplugin_name_trans at line 136 in file
"mod_apache2lbplugin.cpp"
136 ap_log_error(....);
(dbx) where
current thread: t@1
=>[1] apachelbplugin_name_trans(r = 0x1b0750), line 136 in "mod_apache2lbplugin.cpp"
[2] ap_run_translate_name(0x1b0750, 0xfe45e7e0, 0x7022c, 0x116e80, 0x6, 0x8),
at 0x4514c
[3] ap_process_request_internal(0x0, 0x15cfa0, 0x15d070, 0x8000000, 0x0,
0x1b0750), at 0x45b94
[4] ap_process_request(0x1b0750, 0x0, 0x4, 0x1, 0x6d400, 0x1b0750), at 0x2ba8c
[5] .st_double_foreff(0x1aa810, 0x0, 0x15d248, 0x1000, 0x6d7a8, 0x6d778), at
0x266d4
[6] ap_run_process_connection(0x1aa810, 0x2666c, 0x701cc, 0x169870, 0x0,
0x80000000), at 0x38d24
[7] 0x2d024(0x1a8790, 0x0, 0x1aa810, 0xffbff9f4, 0x6c754, 0x4e2e), at 0x2d024
[8] 0x2d1b0(0x2c800, 0x1, 0x6c400, 0x1, 0x6d400, 0x0), at 0x2d1b0
[9] 0x2d408(0x7067c, 0x70400, 0x6d400, 0x6c738, 0x1, 0x2), at 0x2d408
[10] ap_mpm_run(0x2, 0x6f400, 0x0, 0x53400, 0x6f400, 0x6c73c), at 0x2d868
[11] main(0x6c400, 0xffbffca4, 0x6c680, 0x55400, 0x7ce00, 0x55400), at 0x33e0c
(dbx) print *r
*r = {
pool = 0x1b0718
connection = 0x1aa810
server = 0x15c6b8
next = (nil)
prev = (nil)
main = (nil)
the_request = 0x1b14a8 "GET /SimpleWebApp/SimpleServlet HTTP/1.1"
assbackwards = 0
proxyreq = 0
header_only = 0
protocol = 0x1b1560 "HTTP/1.1"
proto_num = 1001
hostname = 0x1b1c68 "eas-v240-19.india.sun.com"
request_time = 1236163141013907LL
status_line = (nil)
status = 200
method = 0x1b14f8 "GET"
method_number = 0
allowed = 0
allowed_xmethods = (nil)
allowed_methods = 0x1b08f8
sent_bodyct = 0
bytes_sent = 0
mtime = 0
chunked = 0
range = (nil)
clength = 0
remaining = 0
read_length = 0
read_body = 0
read_chunked = 0
expecting_100 = 0
headers_in = (nil)
headers_out = (nil)
err_headers_out = (nil)
subprocess_env = (nil)
notes = (nil)
content_type = 0x1b0928 ""
handler = 0x1b0db8 ""
content_encoding = 0x1b0f60 ""
content_languages = 0x1b0b70
vlist_validator = 0x1b10b8 ""
user = (nil)
ap_auth_type = (nil)
no_cache = 0
no_local_copy = 0
unparsed_uri = (nil)
uri = (nil)
filename = (nil)
canonical_filename = (nil)
path_info = (nil)
args = 0x1b1520 "/SimpleWebApp/SimpleServlet"
finfo =

{ pool = 0x1b1540 valid = 0 protection = 0 filetype = APR_NOFILE user = 0 group = 0 inode = 0 device = 0 nlink = 0 size = 0 csize = 0 atime = 0 mtime = 0 ctime = 0 fname = (nil) name = (nil) filehand = (nil) }

parsed_uri =

{ scheme = (nil) hostinfo = (nil) user = (nil) password = (nil) hostname = (nil) port_str = (nil) path = (nil) query = (nil) fragment = (nil) hostent = (nil) port = 0 is_initialized = 0 dns_looked_up = 0 dns_resolved = 0 }

used_path_info = 0
per_dir_config = (nil)
request_config = (nil)
htaccess = 0x1b1540
output_filters = (nil)
input_filters = (nil)
proto_output_filters = (nil)
proto_input_filters = 0x8000
eos_sent = 2
}

There might be issue with apache 2.0.63 bundled with solaris 10 update 6.

I will also check if this is a configuration issue.

Comment by kumara [ 14/Sep/09 ]

LB plugin not being shipped with v3, does not apply to v3 release and hence excluded from bug tracking.

Comment by kshitiz_saxena [ 25/Aug/10 ]

The issue exists as Apache bundled with solaris is compiled with option
-D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64, while load-balancer plugin is
compiled with option -D_LARGEFILE64_SOURCE.

The difference in compile time options results in this issue. Compiling
load-balancer plugin with option -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64
fixes this issue. However all file IO operation starts failing in load-balancer
plugin. It will require code changes in load-balancer to address this issue.

Will not fix this issue for 3.1.

Comment by kshitiz_saxena [ 25/Aug/10 ]

Setting 3.1-exclude

Comment by kshitiz_saxena [ 04/Oct/10 ]

Adding keyword 3.1-exclude.

Comment by kshitiz_saxena [ 21/Feb/11 ]

Changing priority to critical. Users can still build apache and use it for load-balancer plugin purpose. Issue is only related to bundled apache.

Comment by kshitiz_saxena [ 08/Jul/11 ]

Changing priority to Major and assigning to Puneet as this is a v2 issue.

Comment by kshitiz_saxena [ 08/Jul/11 ]

Changing priority to Major and assigning to Puneet as this is a v2 issue.

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.





Generated at Thu Jan 19 19:52:18 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.