<< Back to previous view

[WSIT-1574] Kerberos: Signature Verification for Signature with ID _1 failed Created: 05/Jul/11  Updated: 09/Jul/11  Resolved: 09/Jul/11

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

Type: Bug Priority: Blocker
Reporter: donatasc Assignee: kumarjayanti
Resolution: Cannot Reproduce Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server side: GlassFish v3.1.1 promoted build 10, Microsoft Server 2008 R2 SP1
Client side: GlassFish v3.1.1 promoted build 10, Windows XP


File Attachments: Text File FINEST_level_server.log     Zip Archive KerberosClient.zip     Zip Archive Log&configFiles.zip     Zip Archive LogsWithDebugInfo.zip     Zip Archive MetroKerberosTest-WebService.zip    
Tags:
Participants: donatasc and kumarjayanti

 Description   

Using NetBeans 7 built web service with Kerberos authentication, deployed on Glassfish v3.1.1 promoted build 10.
Similarly built web service client, deployed on Glassfish v3.1.1 too.
On both ends did the fix, described in WSIT-1571 (otherwise metro client call does not reach web service).

Web service got called, then logged this exception:

2011-07-05T20:46:55.777+0300|SEVERE|glassfish3.1.1|com.sun.xml.wss.provider.wsit|_ThreadID=17;_ThreadName=Thread-2;|WSITPVD0035: Error in Verifying Security in Inbound Message.
com.sun.xml.wss.impl.WssSoapFaultException: WSS1710: Signature Verification for Signature with ID _1 failed
	at com.sun.xml.ws.security.opt.impl.util.SOAPUtil.newSOAPFaultException(SOAPUtil.java:158)
	at com.sun.xml.ws.security.opt.impl.incoming.Signature.process(Signature.java:350)
	at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:461)
	at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders(SecurityRecipient.java:275)
	at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:225)
	at com.sun.xml.wss.provider.wsit.WSITServerAuthContext.verifyInboundMessage(WSITServerAuthContext.java:586)
	at com.sun.xml.wss.provider.wsit.WSITServerAuthContext.validateRequest(WSITServerAuthContext.java:360)
	at com.sun.xml.wss.provider.wsit.WSITServerAuthContext.validateRequest(WSITServerAuthContext.java:263)
	at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:173)
	at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:144)
	at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)

It seems that Metro web service security code does not understand how metro client created the signature.

This makes impossible to create Metro v2.1 client and Metro v2.1 web service authenticated with Kerberos, talking to each other, therefore marking as Blocker.

Attached are client and web service NetBeans projects, Kerberos configuration files, and the server log.



 Comments   
Comment by donatasc [ 05/Jul/11 07:00 PM ]

Attached are client and web service glassfish logs with debug information, I used following JVM options:

-Dsun.security.krb5.debug=true
-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true
-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true

Logs clearly show that Kerberos protocol is functioning OK (Microsoft is not a suspect here): preauthentication succeeds for both client and server, tickets get received (after applying fix WSIT-1571).

The problem: either this is a misconfiguration (wsit-*.xml files), or Metro client creates wrong SOAP envelope with signature XML fragment, or Metro web service incorrectly verifies the signature.

Comment by kumarjayanti [ 06/Jul/11 04:34 AM ]

Can you please send us the logs client and server side with the following set :

com.sun.xml.wss.logging.impl.opt.level = FINEST
com.sun.xml.wss.logging.impl.opt.crypto.level = FINEST
com.sun.xml.wss.logging.impl.opt.signature.level = FINEST
com.sun.xml.wss.logging.impl.opt.token.level = FINEST

Please remove the 2 message dump properties that you have used ( I presume the failure occurs even without the message dump properties ? is that correct ?).

The above logging properties have to be set in logging.properties of glassfish for the server side. If your client is a standalone java client then we need to set the above properties in jre/lib/logging.properties.

Comment by donatasc [ 07/Jul/11 07:31 PM ]

Yes, failure occurs even without message dump properties.

Additional info about this case: In NetBeans, configuring Quality of Service for the web service, I opened input and output messages and unchecked all the check marks for "sign" and "encrypt". That is, no part of the SOAP message is to be signed and/or encrypted. By default the generated wsit-*.xml would look like this:

<wsp:Policy wsu:Id="TestPortBinding_hello_Input_Policy">
        <wsp:ExactlyOne>
            <wsp:All>
                <sp:EncryptedParts>
                    <sp:Body/>
                </sp:EncryptedParts>
                <sp:SignedParts>
                    <sp:Body/>
                    <sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="AckRequested" Namespace="http://docs.oasis-open.org/ws-rx/wsrm/200702"/>
                    <sp:Header Name="SequenceAcknowledgement" Namespace="http://docs.oasis-open.org/ws-rx/wsrm/200702"/>
                    <sp:Header Name="Sequence" Namespace="http://docs.oasis-open.org/ws-rx/wsrm/200702"/>
                    <sp:Header Name="CreateSequence" Namespace="http://docs.oasis-open.org/ws-rx/wsrm/200702"/>
                </sp:SignedParts>
            </wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>
    <wsp:Policy wsu:Id="TestPortBinding_hello_Output_Policy">
        <wsp:ExactlyOne>
            <wsp:All>
                <sp:EncryptedParts>
                    <sp:Body/>
                </sp:EncryptedParts>
                <sp:SignedParts>
                    <sp:Body/>
                    <sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"/>
                    <sp:Header Name="AckRequested" Namespace="http://docs.oasis-open.org/ws-rx/wsrm/200702"/>
                    <sp:Header Name="SequenceAcknowledgement" Namespace="http://docs.oasis-open.org/ws-rx/wsrm/200702"/>
                    <sp:Header Name="Sequence" Namespace="http://docs.oasis-open.org/ws-rx/wsrm/200702"/>
                    <sp:Header Name="CreateSequence" Namespace="http://docs.oasis-open.org/ws-rx/wsrm/200702"/>
                </sp:SignedParts>
            </wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>

but in this particular case it does look like:

<wsp:Policy wsu:Id="TestPortBinding_hello_Input_Policy">
        <wsp:ExactlyOne>
            <wsp:All></wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>
    <wsp:Policy wsu:Id="TestPortBinding_hello_Output_Policy">
        <wsp:ExactlyOne>
            <wsp:All></wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>

Today I also tried to generate another web service with all the default values, it still does not work, but with different error message, I'll open another JIRA for that case.

Comment by donatasc [ 07/Jul/11 07:41 PM ]

I have attached the log file produced by logging properties shown above.

Note:

  • both client and web service were deployed on one GlassFish v3.1.1 b10 instance (running on MS 2008 server),
  • glassfish.keytab contains only one key: AES128 (generated by ktpass.exe),
  • WSIT "Quality of Service" configured to use Basic128 algorith suite,
  • krb5.conf was restricted to use only AES128 etype for Kerberos service ticket (and AES gets picked, as shown by logs):
[libdefaults]
	default_realm = EDS.VMI.LT
	default_tgs_enctypes = aes128-cts
        permitted_enctypes = aes128-cts

[realms]
	EDS.VMI.LT  = {
		kdc = dc.eds.vmi.lt 
		default_domain = EDS.VMI.LT 
}

[domain_realm]
	.eds.vmi.lt = EDS.VMI.LT 
	eds.vmi.lt = EDS.VMI.LT

This should leave no room for other cypher choices.

Comment by kumarjayanti [ 08/Jul/11 11:54 AM ]

From looking at the code what is clear is that the SecretKey used for signature verification on the Server Side is not the same as the Key that was used on the Client Side.

This bug is clearly related to 1571. I am assuming you are running into this after your proposed Patch for 1571 on the client side ?.

So somehow on the client side the secretKey is not set into KerberosContext after a KerberosLogin, but it appears that on the Server Side the secretKey does get set into the KerberosContext post a successful Kerberos Login.

The relevant Code (is the very bottom of com.sun.xml.ws.security.opt.impl.incoming.KeySelectorImpl.java)

String algo = SecurityUtil.getSecretKeyAlgorithm(wssContext.getAlgorithmSuite().getEncryptionAlgorithm());
KerberosContext krbContext = wssContext.getKerberosContext();

if (krbContext == null) {
krbContext = wssContext.getSecurityEnvironment().doKerberosLogin(token.getTokenValue());
wssContext.setKerberosContext(krbContext);
try { wssContext.getSecurityEnvironment().updateOtherPartySubject(DefaultSecurityEnvironmentImpl.getSubject(wssContext), krbContext.getGSSContext().getSrcName(), krbContext.getDelegatedCredentials()); } catch (GSSException gsse) { throw new XWSSecurityException(gsse); }
}
wssContext.setExtraneousProperty(MessageConstants.KERBEROS_SHA1_VALUE, encodedRef);
return krbContext.getSecretKey(algo);

Would it be possible for you to debug more on issue 1571 and see why KerberosLogin on client side fails to set the secretKey. That IMHO should provide us a soultion to both the problems.

I will hold off on my commit (your propsed fix for 1571) since that does not seem fully correct given this server side error.

Thanks,
kumar

Comment by donatasc [ 08/Jul/11 12:05 PM ]

Yes, this behaviour is seen after applying WSIT-1571 fix (though the fix might not be the right one...)

OK, let's get back to 1571, I'll try to analyse those two cases you described in 1571.

Comment by donatasc [ 08/Jul/11 01:35 PM ]

As commented in WSIT-1571, after correctly providing SPN in wsit-*.xml file, communication between webservice client and webservice started to work.

This bug may be closed as "Invalid" or "Not reproducible".

Comment by kumarjayanti [ 09/Jul/11 10:46 AM ]

Closing this as the real issue was 1571 which was leading to this.





[WSIT-1571] IllegalArgumentException authenticating Metro client with Metro webservice @ MS 2008 R2 server (rc4-hmac) Created: 30/Jun/11  Updated: 09/Jul/11  Resolved: 09/Jul/11

Status: Resolved
Project: wsit
Component/s: security
Affects Version/s: 2.1
Fix Version/s: None

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

Web service client: GlassFish v3.0.1 on Windows XP
Web service: GlassFish v3.0.1 on Windows Server 2008 R2


File Attachments: Text File client-server.log     Zip Archive KerberosClient.zip     Text File krb5.conf     Text File login.conf     Zip Archive SecondTry-DES.zip     File SignatureFilter.diff     Zip Archive ThirdTry-Des&NoKeytab.zip    
Tags:
Participants: donatasc and kumarjayanti

 Description   

Trying web service authentication with Kerberos, web service is running on GlassFish v3.0.1 on MS Windows 2008 R2 server. Service account is created, SPN's are set, keytab's are generated (for both server and client).
On client side:
kinit -k -t donatas.keytab donatas
succeeds (gets ticket).

Having -Dsun.security.krb5.debug=true, in client glassfish log I see, that pre-authentication gets requested, then succeeds, then KDC starts negotiating service ticket (using RC4-HMAC):

-----------------------
Found ticket for donatas@EDS.VMI.LT to go to krbtgt/EDS.VMI.LT@EDS.VMI.LT expiring on Fri Jul 01 03:59:50 EEST 2011|#]
Service ticket not found in the subject|#]
>>> Credentials acquireServiceCreds: same realm|#]
default etypes for default_tgs_enctypes: 23 16 3 1 .

>>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType|#]
>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType|#]
>>> KrbKdcReq send: kdc=dc.eds.vmi.lt UDP:88, timeout=30000, number of retries =3, #bytes=1316|#]
>>> KDCCommunication: kdc=dc.eds.vmi.lt UDP:88, timeout=30000,Attempt =1, #bytes=1316|#]
>>> KrbKdcReq send: #bytes read=1320|#]
>>> KrbKdcReq send: #bytes read=1320|#]
>>> KdcAccessibility: remove dc.eds.vmi.lt|#]
>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType|#]
>>> KrbApReq: APOptions are 00000000 00000000 00000000 00000000|#]
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType|#]
Krb5Context setting mySeqNumber to: 588563156|#]
Krb5Context setting peerSeqNumber to: 0|#]
Created InitSecContextToken:
0000: 01 00 6E 82 04 DF 30 82 04 DB A0 03 02 01 05 A1 ..n...0.........
0010: 03 02 01 0E A2 07 03 05 00 00 00 00 00 A3 82 04 ................
0020: 06 61 82 04 02 30 82 03 FE A0 03 02 01 05 A1 0C .a...0..........
0030: 1B 0A 45 44 53 2E 56 4D 49 2E 4C 54 A2 20 30 1E ..EDS.VMI.LT. 0.
0040: A0 03 02 01 00 A1 17 30 15 1B 04 48 54 54 50 1B .......0...HTTP.
0050: 0D 64 63 2E 65 64 73 2E 76 6D 69 2E 6C 74 A3 82 .dc.eds.vmi.lt..
0060: 03 C5 30 82 03 C1 A0 03 02 01 17 A1 03 02 01 04 ..0.............
...
ClassName=com.sun.org.apache.xml.internal.security.algorithms.JCEMapper;MethodName=translateURItoJCEID;|Request for URI http://www.w3.org/2001/04/xmlenc#aes128-cbc|#]

[#|2011-06-30T17:59:49.615+0300|SEVERE|glassfish3.0.1|com.sun.xml.wss.logging.impl.filter|_ThreadID=23;_ThreadName=Thread-1;|WSS1414: Error extracting symmetric key Missing argument|#]

[#|2011-06-30T17:59:49.630+0300|SEVERE|glassfish3.0.1|com.sun.xml.wss.provider.wsit|_ThreadID=23;_ThreadName=Thread-1;|WSITPVD0029: Error in Securing Outbound Message.
com.sun.xml.wss.impl.WssSoapFaultException: java.lang.IllegalArgumentException: Missing argument
at ...
Caused by: com.sun.xml.wss.XWSSecurityException: java.lang.IllegalArgumentException: Missing argument
at com.sun.xml.wss.impl.filter.SignatureFilter.process(SignatureFilter.java:459)
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.WSITClientAuthContext.secureOutboundMessage(WSITClientAuthContext.java:515)
... 43 more
Caused by: java.lang.IllegalArgumentException: Missing argument
at javax.crypto.spec.SecretKeySpec.<init>(DashoA13*..)
at com.sun.xml.ws.security.impl.kerberos.KerberosContext.getSecretKey(KerberosContext.java:91)
at com.sun.xml.wss.impl.filter.SignatureFilter.process(SignatureFilter.java:432)
... 48 more

#]
-------------

Source code for KerberosContext.getSecretKey(KerberosContext.java:91) reveals:

this.sKey = new SecretKeySpec(this.secretKey, algorithm);

and for SecretKeySpec.<init>():

public SecretKeySpec(byte[] paramArrayOfByte, String paramString)
{
if ((paramArrayOfByte == null) || (paramString == null))
throw new IllegalArgumentException("Missing argument");
...

Conclusion: either algorithm or secretKey were sent as null to SecretKeySpec.
Log file, config files are attached.



 Comments   
Comment by donatasc [ 30/Jun/11 04:10 PM ]

Further analysis:

Source code (SignatureFilter.java, line 318):

if (krbContext != null) {
            byte[] kerberosToken = krbContext.getKerberosToken();
            binding.setTokenValue(kerberosToken);

            SecretKey sKey = krbContext.getSecretKey(SecurityUtil.getSecretKeyAlgorithm(dataEncAlgo));
            binding.setSecretKey(sKey);
          } else {
            log.log(Level.SEVERE, "WSS1423.kerberos.context.notset");
            throw new XWSSecurityException("WSS1423.kerberos.context.notset");
          }

method krbContext.setSecretKey() is never called. Therefore krbContext.secretKey field is null.
Therefore (KerberosContext.java, line 91):

public SecretKey getSecretKey(String algorithm) {
      if (this.sKey == null) {
91      this.sKey = new SecretKeySpec(this.secretKey, algorithm);
      }
      return this.sKey;
    }

constructor "new SecretKeySpec()" gets called with first argument as null. This at once leads to IllegalArgumentException:

public SecretKeySpec(byte[] paramArrayOfByte, String paramString)
  {
    if ((paramArrayOfByte == null) || (paramString == null))
      throw new IllegalArgumentException("Missing argument");
    ...
  }
Comment by kumarjayanti [ 30/Jun/11 04:19 PM ]

thanks for the detailed analysis. I know sometime back another person on the forums reported the same issue. Not sure if you are the one.. But all our QE Kerberos tests are working fine. We test on Linux systems using MIT Kerberos.

I think its important to reproduce your case but not sure how to start on this. I shall analyze the details you have put in and get back to you.

Comment by donatasc [ 30/Jun/11 04:29 PM ]

NetBeans project for web service client. Probably most interesting is wsit-client.xml file (and the one it imports).

Comment by donatasc [ 30/Jun/11 04:33 PM ]

Well I'm not the one on the forums

We test on Linux systems using MIT Kerberos

Yes, I'm affraid this is Windows Server specific, and google is full of unsuccessful attempts to authenticate with Windows Active Directory.
As the Kerberos debug messages show, KDC forces the client to use RC4-HMAC encryption (that is windows specific I guess):

>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType

Comment by donatasc [ 30/Jun/11 06:24 PM ]

The issue is not cypher specific. I reproduced the problem with DES-CBC-MD5 encryption method: I setup Windows Server 2008 policy to allow Des encryption methods for Kerberos (by default they are dissallowed), regenerated keytab files. Again pre-authentication completes successfully, KDC sends service ticket to the client (I'm not strong in Kerberos concepts, so I may mis-interpret log entries), client (Metro) tries to create SecretKey from the ticket and fails with the same exception: IllegalArgumentException: Missing argument.

If Metro is working with Linux Kerberos implementation, I would say there is something special how communication with Windows Server is happening (different order of commands? protocol not obeyed?). But still the error message should be different, IllegalArgumentException tells that wrong arguments are being passed (in case of windows server 2008 r2).

I have collected all the relevant files and attached as SecondTry-DES.zip

Comment by donatasc [ 30/Jun/11 06:31 PM ]

Attachment with logs/config files that reproduce the same problem with DES-CBC-MD5 encryption.

Comment by donatasc [ 01/Jul/11 01:12 PM ]

Narrowing the case even more: this time on client side no keytab was used (TGT from Windows ticket cache was used).

login.conf:

KerberosClient {
    com.sun.security.auth.module.Krb5LoginModule required
    useTicketCache=true
    principal=donatas;
};

encryption type: DES-CBC-MD5

Result the same: client glassfish server.log shows that metro finds TGT in windows cache, asks KDC for service ticket, KDC sends the ticket (and the ticket get printed out in the log), metro tries to create SecretKey out of it, fails with IllegalArgumentException: Missing argument (the same null problem).

Conclusion: this is not cypher specific, this is not keytab format specific.
Problem: Metro fails to create SecretKey out of service ticket (though gets it successfully from Windows KDC)

Comment by donatasc [ 01/Jul/11 01:14 PM ]

Attachment with glassfish server.log (client-side): ThirdTry-Des&NoKeytab.zip

Comment by donatasc [ 01/Jul/11 01:23 PM ]

Some more info: this is not web service security problem (web service does not get even called, server-side glassfish log is empty, not a single packet reached server-side glassfish).

The real problem: Metro web service CLIENT cannot deal with Kerberos service ticket, returned by Windows KDC (Server 2008 R2 SP1).

I would fully understand if error messages would tell that Windows returned service ticket in wrong format or corrupted (that it is impossible to construct SecretKey out of it), this would then be Microsoft problem. But the error message clearly shows programming error: NULL is being passed to constructor, independently from the encryption type used (reproduced with all of these: AES256, AES128, DES-CBC-MD5, RC4-MDAC).

I would raise the priority as Critical/Blocker, since this breaks the interoperability with Microsoft Windows.

Comment by kumarjayanti [ 01/Jul/11 01:28 PM ]

Thanks so much for narrowing it down....

Comment by donatasc [ 05/Jul/11 09:48 AM ]

I managed to get it working. The changes to com.sun.xml.wss.impl.filter.SignatureFilter.java (in trunk) were needed in two places, one line was added in both cases (commented with // <-- ADDED FIX):

1.

} else if (PolicyTypeUtil.kerberosTokenBinding(keyBinding)) {
    ...
    
    if (krbContext != null) {
        byte[] kerberosToken = krbContext.getKerberosToken();
        binding.setTokenValue(kerberosToken);

        krbContext.setSecretKey(kerberosToken); // <-- ADDED FIX
        SecretKey sKey = krbContext.getSecretKey(SecurityUtil.getSecretKeyAlgorithm(dataEncAlgo));
        binding.setSecretKey(sKey);
    } else {
        log.log(Level.SEVERE, LogStringsMessages.WSS_1423_KERBEROS_CONTEXT_NOTSET());
        throw new XWSSecurityException("WSS1423.kerberos.context.notset");
    }
    
    context.setKerberosTokenBinding(binding);
}

2.

} else if (PolicyTypeUtil.kerberosTokenBinding(ckBinding)) {
    ...

    if (krbContext != null) {
        byte[] kerberosToken = krbContext.getKerberosToken();
        ckBindingClone.setTokenValue(kerberosToken);

        krbContext.setSecretKey(kerberosToken); // <-- ADDED FIX
        sKey = krbContext.getSecretKey(SecurityUtil.getSecretKeyAlgorithm(dataEncAlgo));
        ckBindingClone.setSecretKey(sKey);
    } else {
        log.log(Level.SEVERE, LogStringsMessages.WSS_1423_KERBEROS_CONTEXT_NOTSET());
        throw new XWSSecurityException("WSS1423.kerberos.context.notset");
    }
    context.setKerberosTokenBinding(ckBindingClone);
}

After making these changes, the call reaches web service.

Question: can this fix make into GlassFish v3.1.1?

Comment by kumarjayanti [ 05/Jul/11 09:56 AM ]

Thanks so much. This is a great help. Unfortunately it is very late in the cycle for V3.1.1 to allow metro changes. But i will talk to my manager and see if we can make it.

Can you attach the full svn diff.

Comment by donatasc [ 05/Jul/11 10:11 AM ]

Attached the diff file. There are three changes in total (missed one more setSecretKey() call):

--- X:/TEMP/SignatureFilter.java-revBASE.svn000.tmp.java	An Lie  5 13:07:31 2011
+++ D:/tmp/filter/SignatureFilter.java	An Lie  5 13:07:16 2011
@@ -341,6 +341,7 @@
                         byte[] kerberosToken = krbContext.getKerberosToken();
                         binding.setTokenValue(kerberosToken);
                         
+                        krbContext.setSecretKey(kerberosToken);
                         SecretKey sKey = krbContext.getSecretKey(SecurityUtil.getSecretKeyAlgorithm(dataEncAlgo));
                         binding.setSecretKey(sKey);
                     }else{
@@ -450,6 +451,7 @@
                                 byte[] kerberosToken = krbContext.getKerberosToken();
                                 ckBindingClone.setTokenValue(kerberosToken);
                                 
+                                krbContext.setSecretKey(kerberosToken);
                                 sKey = krbContext.getSecretKey(SecurityUtil.getSecretKeyAlgorithm(dataEncAlgo));
                                 ckBindingClone.setSecretKey(sKey);
                             }else{
@@ -542,6 +544,7 @@
                             if(krbContext != null){
                                 byte[] kerberosToken = krbContext.getKerberosToken();
                                 ckBindingClone.setTokenValue(kerberosToken);
+                                krbContext.setSecretKey(kerberosToken);
                                 sKey = krbContext.getSecretKey(SecurityUtil.getSecretKeyAlgorithm(dataEncAlgo));
                                 ckBindingClone.setSecretKey(sKey);
                             } else{
Comment by kumarjayanti [ 08/Jul/11 11:18 AM ]

Hi,

Thanks again for your help and filing the issues. I was looking at the proposed fix and was confused why this setSecretKey() call would ever be required. I understand it is null and therefore you are seeing the "illegalArgumentException: Missing argument".

So we have the KerberosLogin.java where we try to do a KerberosLogin using the JDK supported Kerberos LoginModules and there the code sets the secretKey as follows :

===========
Set<Object> setPrivCred = loginSubject.getPrivateCredentials();
Iterator<Object> iter2 = setPrivCred.iterator();
while (iter2.hasNext()) {
Object privObject = iter2.next();
if (privObject instanceof KerberosTicket) {
KerberosTicket kerbTicket = (KerberosTicket) privObject;
try {
if (kerbTicket.getServer().getName().equals(gssContext.getTargName().toString())) { SecretKey sKey = kerbTicket.getSessionKey(); byte[] secret = sKey.getEncoded(); krbContext.setSecretKey(secret); break; }
} catch (GSSException ex) { throw new XWSSecurityException(ex); }
}
}
==========

So it appears to me that incase of ActiveDirectory somehow the result of KerberosLogin

1. does not have the KerberosTicket as a private credential in the Subject.

OR
2. the following condition check fails : if (kerbTicket.getServer().getName().equals(gssContext.getTargName().toString())) {

I would be thankful to you if you can tell us which of the two above happens ?.

Based on that i will integrate the suggested fix.

Thanks again.

Comment by donatasc [ 08/Jul/11 01:10 PM ]

I did some debuging:

kerbTicket.getServer().getName() = HTTP/dc.eds.vmi.lt@EDS.VMI.LT
gssContext.getTargName().toString() = HTTP/dc.eds.vmi.lt

Which one of them is comming from wsit-*.xml file?

Comment by donatasc [ 08/Jul/11 01:28 PM ]

I replaced "HTTP/dc.eds.vmi.lt" to "HTTP/dc.eds.vmi.lt@EDS.VMI.LT" in wsit-.xml file on the client, and *got it working (after 2 weeks of trial and error).

The real problem is that Metro is not reporting in any way, that none of KerberosTickets have kerbTicket.getServer().getName() = gssContext.getTargName().toString()
There could be at least WARNING (if not SEVERE) log message, saying that wsit-*.xml file has wrong service principal name.

Comment by kumarjayanti [ 09/Jul/11 10:45 AM ]

Thanks for all the self-debugging. Your comment is valid, i shall add a WARNING log over there.

Comment by kumarjayanti [ 09/Jul/11 01:33 PM ]

Added a WARNING as required.





[JPA_SPEC-46] Explicitly allow or disallow use of Entity Manager with extended Persistence Context for CDI injection Created: 05/Feb/13  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: donatasc Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: donatasc and ldemichiel

 Description   

CDI specification has so called producer methods, allowing to create (or retrieve) objects to be injected.

JPA specification should explicitly state whether is it allowed for Stateful Session bean to have a producer method that returns extended EntityManager?
For example, is this legal:

@ConversationScoped
@Stateful
public class MyConversationBean {
@PersistenceContext(type=EXTENDED)
private EntityManager em;

@Produces
public EntityManager getEntityManager() { return em; }
}

This would be useful if conversation is implemented with several session beans and they all want to share a single extended EntityManager.



 Comments   
Comment by ldemichiel [ 22/Feb/13 10:27 PM ]

I think this is probably more an EJB issue than a JPA one, but in any case
it is something that we should evaluate for the next release.





[JPA_SPEC-3] Allow components other than stateful sessions beans to initiate container-managed extended persistence contexts Created: 05/Dec/11  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: ldemichiel Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: donatasc and ldemichiel

 Description   

It might be useful to support the use of container-managed extended persistence contexts in singleton session beans and/or application-scoped or conversation-scoped CDI components.



 Comments   
Comment by donatasc [ 05/Feb/13 06:32 AM ]

+100

IMHO this was a huge miss in Java EE 6. Even though CDI introduced conversation scope, injection/creation of extended persistence context EM was not mentioned at all. EJB spec is also silent about extended PC, what caused me to post message like this to JPA mailing list:
http://java.net/projects/jpa-spec/lists/users/archive/2013-01/message/51

In general, extended persistence context is largely under-specified in regards to integration between CDI/EJB/JPA.





[JAXB-971] Regression: annotation @XmlJavaTypeAdapters on package is ignored since JAXB v2.2.4-1 Created: 26/Jul/13  Updated: 29/Jul/13

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.5, 2.2.6, 2.2.7
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: donatasc Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64; JDK 1.6 and JDK 1.7


Tags:
Participants: donatasc and Iaroslav Savytskyi

 Description   

JAXB v2.2.4-1 was the last version that takes into account @XmlJavaTypeAdapters annotation (applied on package). All later JAXB versions ignore this annotation - supplied XmlAdapters are not being used.

Attached is an Ant project, adapted from JAXB sample "j2s-xmlAdapter".
Original sample code (working OK in all JAXB versions) had:

@XmlRootElement
@XmlType(name="KitchenWorldBasketType")
public class KitchenWorldBasket {
    @XmlJavaTypeAdapter(AdapterPurchaseListToHashMap.class)
    HashMap basket = new HashMap();
    ...

and

public class Main {
    public static void main(String[] args) throws Exception {
        JAXBContext jc = JAXBContext.newInstance(KitchenWorldBasket.class);
        ...

The attached project has these modifications:

@XmlRootElement
@XmlType(name="KitchenWorldBasketType")
public class KitchenWorldBasket {
    //@XmlJavaTypeAdapter(AdapterPurchaseListToHashMap.class)
    @XmlElement(type = PurchaseList.class)
    public LinkedHashMap basket = new LinkedHashMap();
    ...

and

@XmlJavaTypeAdapters({
        @XmlJavaTypeAdapter(value = AdapterPurchaseListToHashMap.class, type = LinkedHashMap.class)
})
package shoppingCart;

import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapters;
import java.util.LinkedHashMap;

and

public class Main {
    public static void main(String[] args) throws Exception {
        JAXBContext jc = JAXBContext.newInstance(KitchenWorldBasket.class.getPackage().getName());
        ...

Running the attached project with JAXB v2.2.4-1 gives:

run:
     [echo] Running the sample application...
     [java] KitchenWorldBasket:
     [java] key: 9027   value: glasstop stove in black
     [java] key: 10424  value: backsplash kit in black
     [java] key: 288    value: wooden spoon
     [java] key: 289    value: salt and pepper shakers in yellow
     [java]
     [java] <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
     [java] <kitchenWorldBasket>
     [java]     <basket>
     [java]         <item key="9027">glasstop stove in black</item>
     [java]         <item key="10424">backsplash kit in black</item>
     [java]         <item key="288">wooden spoon</item>
     [java]         <item key="289">salt and pepper shakers in yellow</item>
     [java]     </basket>
     [java] </kitchenWorldBasket>

BUILD SUCCESSFUL

Running with JAXB v2.2.5, v2.2.6 and v2.2.7:

run:
     [echo] Running the sample application...
     [java] KitchenWorldBasket:
     [java]
     [java] <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
     [java] <kitchenWorldBasket>
     [java]     <basket/>
     [java] </kitchenWorldBasket>

BUILD SUCCESSFUL

There is no difference, whether namespaces are being used or not. I stumbled on this bug working with WebServices and JAX-WS/JAXB bindings (where namespaces are being used).

Additionally, annotation @XmlJavaTypeAdapter is being ignored on classes too (though I do not have a sample test case).

It seems, that @XmlJavaTypeAdapter is being taken into account only when it is applied on class fields.



 Comments   
Comment by donatasc [ 26/Jul/13 08:19 AM ]

Sample project can be downloaded from:
http://www.mif.vu.lt/~donatas/private/j2s-xmlAdapter-onPackage.zip

Comment by Iaroslav Savytskyi [ 29/Jul/13 12:58 PM ]

Hi,

Thanks a lot for reporting.

May be this problem occurred because of APT rewrite in 2.2.5. I have to check.





[JAXB-865] JAXB spec violation - binding as per "<class> Declaration": wrong namespace being assigned for preexisting class Created: 23/Sep/11  Updated: 15/Nov/11

Status: Open
Project: jaxb
Component/s: schemagen, xjc
Affects Version/s: 2.2.4u1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: donatasc Assignee: Martin Grebac
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.1, Windows 7 64bit


File Attachments: Zip Archive ClassBinding.zip     Zip Archive ClassBindingClient.zip    
Tags:
Participants: donatasc and Martin Grebac

 Description   

Scenario: Metro web service, taking as parameter complex type Name (having element value of type xs:string) and returning String (copied from element value). WSDL and Schema are developed first, then web service is being generated using wsimport maven task (wsimport is told to use package name "ws.generated" for schema compilation).

Web service part:

Complex type Name looks like:

<xs:complexType name="Name">
    <xs:sequence>
      <xs:element name="value" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>

JAXB v2.2 section "7.7 <class> Declaration" allows binding complex type to preexisting class (src/jaxws/bindings.xml):

<bindings xmlns="http://java.sun.com/xml/ns/jaxb" version="2.0"
          xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <bindings schemaLocation="../wsdl/SignatureService/SignatureService.xsd" node="/xs:schema">
        <bindings node="xs:complexType[@name='Name']">
            <class ref="preexisting.Name" />
        </bindings>
    </bindings>
</bindings>

Class preexisting.Name looks like (note: package differs from the one used by wsimport to generate schema artifacts):

package preexisting;

public class Name {
    protected String value;

    public String getValue() {
        return value;
    }

    public void setValue(String value) {
        this.value = value;
    }
}

WSDL imports schema using elementFormDefault="qualified":

...
    <types>
        <xsd:schema elementFormDefault="qualified">
            <xsd:import namespace="http://www.mitsoft.lt/VMI/EDS3/WS" schemaLocation="SignatureService.xsd"/>
        </xsd:schema>
    </types>
...

Client part:
Usual NetBeans Web Application project was created, Web Service Reference was created, importing WSDL from running service (service was deployed to http://localhost:8080/cb). This way client us unaware of any binding customizations (this is what I'm trying to achieve, imagine .Net client using this service), thus uses generated Name class (in this project: ws.generated.Name).

Having set -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true, Glassfish logs following SOAP messages:

For client, using wsimport generated class ws.generated.Name (client is unaware of any binding customizations, for example, .Net client):

INFO: ---[HTTP request]---
INFO: accept: text/xml, multipart/related
INFO: cache-control: no-cache
INFO: connection: keep-alive
INFO: content-length: 253
INFO: content-type: text/xml; charset=utf-8
INFO: host: localhost:8080
INFO: pragma: no-cache
INFO: soapaction: "http://www.mitsoft.lt/VMI/EDS3/WS/Signature/initStationarySigningRequest"
INFO: user-agent: Metro/2.1.1 (branches/2.1-6844; 2011-07-29T12:07:24+0000) JAXWS-RI/2.2.5 JAXWS/2.2
INFO: <?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
    <initStationarySigning xmlns="http://www.mitsoft.lt/VMI/EDS3/WS">
        <name>
            <value>John</value>
        </name>
    </initStationarySigning>
</S:Body>
</S:Envelope>
INFO: --------------------
INFO: ---[HTTP response 200]---
INFO: <?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
    <ns2:initStationarySigningResponse xmlns:ns2="http://www.mitsoft.lt/VMI/EDS3/WS">
        <ns2:return>name = null</ns2:return>
    </ns2:initStationarySigningResponse>
</S:Body>
</S:Envelope>
INFO: --------------------

We see, that even though client sent <value>John</value>, service is returning "name=null". What is important, in request element <value> belongs to default namespace.

To prove, that service WSDL, schema and binding are correct, I wrote another client inside the Web Service project: simple index.jsp:

<% 
            preexisting.Name name = new preexisting.Name(); 
            name.setValue("John"); 
            String result = new ws.generated.SignatureService().getSignaturePort().initStationarySigning(name); 
        %>
        <p><%= result %></p>

This client uses preexisting.Name explicitly, and SOAP messages are different:

INFO: ---[HTTP request]---
INFO: accept: text/xml, multipart/related
INFO: cache-control: no-cache
INFO: connection: keep-alive
INFO: content-length: 273
INFO: content-type: text/xml; charset=utf-8
INFO: host: localhost:8080
INFO: pragma: no-cache
INFO: soapaction: "http://www.mitsoft.lt/VMI/EDS3/WS/Signature/initStationarySigningRequest"
INFO: user-agent: Metro/2.1.1 (branches/2.1-6844; 2011-07-29T12:07:24+0000) JAXWS-RI/2.2.5 JAXWS/2.2
INFO: <?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
    <ns2:initStationarySigning xmlns:ns2="http://www.mitsoft.lt/VMI/EDS3/WS">
        <ns2:name>
            <value>John</value>
        </ns2:name>
    </ns2:initStationarySigning>
</S:Body>
</S:Envelope>
INFO: --------------------
INFO: ---[HTTP response 200]---
INFO: <?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
    <ns2:initStationarySigningResponse xmlns:ns2="http://www.mitsoft.lt/VMI/EDS3/WS">
        <ns2:return>name = John</ns2:return>
    </ns2:initStationarySigningResponse>
</S:Body>
</S:Envelope>

This time service returns correct result.
Comparing both SOAP messages reviels the problem: class preexisting.Name is being put to a different namespace that the rest of schema compilation artifacts (look for xmlns:ns2 - it is not being prepended for <value> tag).

Section 8.7.1.2 "Mapping", table 8.4 in JAXB specification says:

if @XmlType.namespace() is "##default" && @XmlType.name() is "" and class is not annotated with @XmlRootElement, then the [target namespace] of the attribute or element to which the property or field, from where this class is referenced, is mapped

As preexisting.Name class does not have any annotations, I believe this is the case (namespace=default, name=default).
But even is I add annotation:

package preexisting;

@XmlType()
public class Name {
    ...
}

the result is the same SOAP messages.

The explicit namespace declaration does not work too:

package preexisting;

@XmlType(namespace="http://www.mitsoft.lt/VMI/EDS3/WS")
public class Name {
    ...
}

The only work arround I found is to create package-info.java in package ws:

@javax.xml.bind.annotation.XmlSchema(namespace = "http://www.mitsoft.lt/VMI/EDS3/WS", elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
package preexisting;

This way stand-alone client (using generated Name class) gets correct reply. But this approach not acceptable - the class preexisting.Name is being used is several different web services all having different target namespaces (and this requires modifying preexisting classes, what is not always possible - imagine classes comming in jar archive in compiled form).

Actually two specification section 8.7.1.2 "Mapping" (table 8.4) violations demonstrated:
1. Class without any annotation (or with @XmlType() ) gets namespace from its package (and not from Schema element that references it)
2. Class with @XmlType(namespace="somenamespace") still gets namespace from its package (and not the one in annotation)

I have attached two projects demonstrating the problem: ClassBinding.zip - Maven web service project, and ClassBindingClient.zip - NetBeans Web Application project with stand-alone client.

Priority blocker, because this is specification violation and no workarround possible when preexisting classes are comming in jar file.



 Comments   
Comment by donatasc [ 23/Sep/11 08:56 AM ]

Maven project with Metro Web Service and JAXB binding customization with preexisting class.

Comment by donatasc [ 23/Sep/11 08:57 AM ]

NetBeans WebApplication project with client (in index.jsp file) using wsimport generated Name class (not the preexisting one).

Comment by donatasc [ 26/Sep/11 11:33 AM ]

Further analysis showed that I was wrong about:

1. Class without any annotation (or with @XmlType() ) gets namespace from its package (and not from Schema element that references it)
2. Class with @XmlType(namespace="somenamespace") still gets namespace from its package (and not the one in annotation)

The simplest workarround I found so far is to put XmlSchema annotation like this:

@XmlSchema(elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
package preexisting;

Note: attribute "namespace" does not have to be specified! Thus I make conclusion, that JAXB runtime automatically assigns target namespace of schema to packages of preexisting classes. The real problem: if schema has elementFormDefault="qualified", this is not automatically set for packages of preexisting classes, referenced by <class ref="..."/>.

Comment by Martin Grebac [ 15/Nov/11 01:45 PM ]

Adjusting priority since this is not a regression and there is rather easy workaround. One thing I also noticed is that you expect the wsimport to take bindings.xml into account in client generation - how do you specify the customizations for the client so that it is aware of the customization file? Best would be to invoke wsimport manually and package the artifacts to the application in this case.

Comment by donatasc [ 15/Nov/11 04:09 PM ]

Hi Martin,

Regarding client part and customizations, I have mentioned in the bug report:

This way client is unaware of any binding customizations (this is what I'm trying to achieve, imagine .Net client using this service)

that is, client MUST be unaware of any customizations (in our project our Java services are being called by .Net and other non-java clients).

The workaround I have mentioned is not acceptable, because:

  1. It is not possible to add @javax.xml.bind.annotation.XmlSchema annotation to classes comming as thirt-party library
  2. If the class must be used by several services each having different namespace, it is impossible to use this annotation at all (it defines one static namespace).

My point is that JAXB should automatically (dynamically) attach XmlSchema annotation (or meta-data) depending on whether elementFormDefault="qualified" was used or not, and on currently active namespace.

I cannot agree with Minor priority as in our project we cannot use "class ref" because of the points mentioned above (though specification doesn't specify any restrictions).





[JAXB-795] Catalog passed to XJC is not used during the schema correctness check Created: 11/Nov/10  Updated: 22/Nov/11  Resolved: 22/Nov/11

Status: Resolved
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.1
Fix Version/s: 2.2.5

Type: Bug Priority: Major
Reporter: ramapulavarthi Assignee: Iaroslav Savytskyi
Resolution: Duplicate Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Zip Archive jaxbtest795.zip    
Issue Links:
Duplicate
duplicates JAXB-616 XMLCatalog not used from xjc/xjctask ... Resolved
Issuezilla Id: 795
Tags: metro2_1-waived
Participants: basdebakker14, donatasc, Iaroslav Savytskyi, Martin Grebac, Pavel Bucek and ramapulavarthi

 Description   

When Catalog is passed to XJC, it is used to resolve imported schemas while
building the forest, but during schema correctness check, it does not set the
entity resolver. In com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.java#230,
EntityResolver is not set on the SchemaFactory. This results in to unnecessary
warning thrown during schema resolution.
See the original issue filed on jax-ws: http://java.net/jira/browse/JAX_WS-900



 Comments   
Comment by Pavel Bucek [ 19/Nov/10 09:19 AM ]

too late to get into jaxb 2.2.2

fixed in trunk (waiting for tck tests), merge to branches might be delayed
because of kenai migration.

Comment by basdebakker14 [ 16/Dec/10 02:42 AM ]

I think the fix introduced in 2.2.3 is insufficient. The problem is that the systemId passed to the LSResourceResolver may be a relative URI (it is the systemId as was written in the schema). It is now passed as is to the SAX EntityResolver set on the compiler. However, the latter cannot use it as it does not have the baseURI available.

If the systemId is relative, it should first be resolved against the baseURI before being passed to the EntityResolver.

(Note that I'm not using a Catalog, I'm passing my own EntityResolver to the SchemaCompiler.setEntityResolver() API.)

Comment by Pavel Bucek [ 13/Jan/11 04:53 AM ]

basdebakker14, can you please share test case?

Comment by basdebakker14 [ 13/Jan/11 06:28 AM ]

To run test:

1. Unpack jaxbtest795.zip, go to jaxbtest795 directory.
2. Make sure JAXB jars are on classpath.
3. Compile src/JaxbTest795.java.
4. Run it from jaxbtest795 directory.

The schema compilation will succeed, but the schema correctness check fails. The reason is that during the correctness check, the entity resolver only sees the relative URI "schema3.xsd" and has no way to know that this is referenced from a schema in "subdir".

Comment by donatasc [ 19/Jul/11 09:45 AM ]

Why is this issue tagged as incomplete? What is missing?

Comment by Martin Grebac [ 19/Jul/11 09:54 AM ]

I think it was incomplete until the testcase was delivered and not marked back since then.





[GLASSFISH-18824] GF 4.0 uses Weld 1.1.4.Final, but latest release is 1.1.8.Final Created: 22/Jun/12  Updated: 22/Oct/12  Resolved: 22/Oct/12

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b42
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Vetle Leinonen-Roeim Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: weld cdi
Participants: donatasc, jjsnyder83 and Vetle Leinonen-Roeim

 Description   

GF 4.0 uses Weld 1.1.4.Final, but latest release is 1.1.8.Final.
Consider upgrading to newest release?



 Comments   
Comment by jjsnyder83 [ 22/Jun/12 12:48 PM ]

I am currently working on this. Hopefully it won't be too long before it's complete.

Comment by Vetle Leinonen-Roeim [ 22/Jun/12 12:59 PM ]

Great!

Comment by Vetle Leinonen-Roeim [ 16/Aug/12 08:21 PM ]

Should be 1.1.9.Final instead, to fix GLASSFISH-18992.

Comment by donatasc [ 19/Oct/12 05:26 AM ]

Are there any plans/considerations for GlassFish 4.0 to integrate Weld 1.2.x (1.2.0 beta is current release) ?

Comment by jjsnyder83 [ 19/Oct/12 01:15 PM ]

I am in the process of upgrading 4.0 to Weld 1.1.10.Final. My plan is to start next week working on integration with Weld 1.2.x.

Comment by jjsnyder83 [ 22/Oct/12 02:23 PM ]

GlassFish integration with Weld was updated to Weld 1.1.10.Final with revision 56665.





[GLASSFISH-17251] xerces in webapp causing ClassCastException Created: 29/Aug/11  Updated: 18/Nov/11  Resolved: 20/Oct/11

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

Type: Bug Priority: Major
Reporter: mangrove Assignee: Sanjeeb Sahoo
Resolution: Won't Fix Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jdk7


File Attachments: Zip Archive NetBeansProjects.zip    
Tags:
Participants: donatasc, mangrove and Sanjeeb Sahoo

 Description   

There's a SAX2DOM class in the sun jvm which has a final field containing a DocumentBuilderFactory and it is initialized through the META-INF/services API which tries to use the ContextClassLoader if there's any. If this SAX2DOM class is first loaded from a webapp who has its own xerces in WEB-INF/lib then the above factory locator mechanism will find that version through the webapp's loader.

The glassfish/jvm ClassLoader debug output shows this:

[Loaded com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM from C:\Program Files\Java\jdk1.6.0_26\jre\lib\rt.jar]
[Loaded org.apache.xerces.jaxp.DocumentBuilderFactoryImpl from file:/C:/glassfish3/glassfish/domains/domain1/applications/mavenproject2-web/WEB-INF/lib/xercesImpl-2.8.1.jar]

From this point on, various errors can manifest themselves, depending on the conditions. For example, when another webapp wants to use the xml api who doesn't have xerces among its libs, it will use the other webapp's xerces. This can go unnoticed but it's not a good security practice to go from one webapp directly into another. However, if the second webapp too does have xerces on its classpath, ClassCastException will be thrown because the two webapps will have different versions of the same class and the DOMParser (loaded originally by the first webapp) cannot cast them to each other. This is caused by the DOMParser looking up the configuration by name and through the context loader:

Caused by: java.lang.ClassCastException: org.apache.xerces.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source)
at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.<init>(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.createDocument(SAX2DOM.java:328)
at com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.<init>(SAX2DOM.java:88)
at com.sun.org.apache.xalan.internal.xsltc.runtime.output.TransletOutputHandlerFactory.getSerializationHandler(TransletOutputHandlerFactory.java:191)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getOutputHandler(TransformerImpl.java:396)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerHandlerImpl.setResult(TransformerHandlerImpl.java:141)
at com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader$State.<init>(DomLoader.java:77)
at com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader.startElement(DomLoader.java:117)
at com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:60)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:486)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:464)
at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:247)
at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:181)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:366)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:338)
at com.sun.xml.ws.message.stream.StreamMessage.readPayloadAsJAXB(StreamMessage.java:253)
at com.sun.xml.ws.fault.SOAPFaultBuilder.create(SOAPFaultBuilder.java:540)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:122)
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 $Proxy162.operation(Unknown Source)
at a.mavenproject3.NewServlet.processRequest(NewServlet.java:82)
... 28 more

About the stack trace: I first caught and then reproduced the problem with webservices but that's indifferent from the root problem and the same error might come up by using other means as well.

Proposed solution (workaround for the sun jvm): during the glassfish startup phase one could load the SAX2DOM class explicitly with the root loader so the field will be inited to the default jvm factory. This seems logical for the server (and its webservice layer too) as to use only the jvm xml implementation and if a webapp wants to use its own, it can disable classloader delegation or whatever. But maybe someone who knows the topic better can come up with a real solution instead of this. (Though I highly doubt it will be only 1 line of code.)

Attached are the webapps: project1 is the webservice (I deployed it in a separate server) and project2&3 are the clients, mapped onto different web contexts.



 Comments   
Comment by donatasc [ 29/Aug/11 04:47 PM ]

I confirm the same. To workarround this bug, I've configured Glassfish with:

asadmin create-jvm-options -Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl:
-Djavax.xml.validation.SchemaFactory\\:http\\://www.w3.org/2001/XMLSchema=com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory:
-Djavax.xml.datatype.DatatypeFactory=com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl:
-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl:
-Djavax.xml.stream.XMLEventFactory=com.sun.xml.internal.stream.events.XMLEventFactoryImpl:
-Dorg.w3c.dom.DOMImplementationSourceList=com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl:
-Dorg.xml.sax.driver=com.sun.org.apache.xerces.internal.parsers.SAXParser:-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl:
-Djavax.xml.xpath.XPathFactory\\:http\\://java.sun.com/jaxp/xpath/dom=com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl

This overrides any SPI found in xerces or xalan or other xml related libraries comming with SPI declarations.

But clearly Glassfish should handle this for us.

Comment by Sanjeeb Sahoo [ 20/Oct/11 11:07 AM ]

Since JDK is assuming the provider to be a singleton (and hence is storing it in a static field), there is no way to use different provider versions in a runtime. So, I consider bundling xerces within webapp an invalid scenario. If you want to override JRE supplied implementation, please use endorsed mechanism.

Comment by mangrove [ 18/Nov/11 10:08 AM ]

I don't agree. Sometimes different webapps need different xml parsers which is often hard to get around for since they can come in with transitive dependencies. The endorsed mechanism cannot do this. But glassfish needs only one line of code to allow this kind of flexibility to happen:

rootClassLoader.loadClass("...SAX2DOM");

This initializes the static field and from then on every webapp can use it's own parser or if they don't have one then delegate to the jvm.





[GLASSFISH-17068] Apache Web server with mod_jk in front of Glassfish 3.1 doesn't accept request attributes Created: 20/Jul/11  Updated: 28/Feb/12  Resolved: 02/Aug/11

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2_b11

Type: Bug Priority: Blocker
Reporter: aplohith Assignee: oleksiys
Resolution: Fixed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 2008 r2
Apache httpd 2.2
Glassfish 3.1
Java sdk 1.6.22


File Attachments: Java Archive File grizzly-utils.jar     Java Archive File grizzly-utils.jar    
Issue Links:
Dependency
depends on GLASSFISH-17270 Integrate Grizzly 1.9.37 into Glassfi... Resolved
blocks JAX_WS-721 Timeout occurred with a server using ... Closed
Tags:
Participants: aplohith, donatasc, oleksiys and shreedhar_ganapathy

 Description   

I have configured Apache server with Glassfish as described in
http://weblogs.java.net/blog/amyroh/archive/2009/06/running_glassfi.html

As far as i see the requests are coming to glassfish but the pages do not open.
i have checked in glassfish logs and i see the error pasted below
----------------
[#|2011-07-19T20:49:21.416-0500|FINEST|glassfish3.1|org.apache.jk.common.ChannelSocket|_ThreadID=16;_ThreadName=Thread-1;ClassName=null;MethodName=null;|Accepted socket Socket[addr=/127.0.0.1,port=53912,localport=8009]|#]

[#|2011-07-19T20:49:21.416-0500|FINEST|glassfish3.1|org.apache.jk.common.ChannelSocket|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|receive() |#]

[#|2011-07-19T20:49:21.416-0500|FINEST|glassfish3.1|org.apache.jk.common.ChannelSocket|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|read() 8192 0 4 = 4|#]

[#|2011-07-19T20:49:21.416-0500|FINEST|glassfish3.1|org.apache.jk.common.ChannelSocket|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|read() 8192 4 635 = 635|#]

[#|2011-07-19T20:49:21.416-0500|FINEST|glassfish3.1|org.apache.jk.common.ChannelSocket|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|Call next 0 org.apache.jk.common.HandlerRequest@2bc5cd05|#]

[#|2011-07-19T20:49:21.417-0500|SEVERE|glassfish3.1|org.apache.jk.common.HandlerRequest|_ThreadID=18;_ThreadName=Thread-1;|Error decoding request
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
at com.sun.grizzly.tcp.Request.setAttribute(Request.java:457)
at org.apache.jk.common.HandlerRequest.decodeAttributes(HandlerRequest.java:504)
at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:454)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:306)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:817)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:746)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:939)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2011-07-19T20:49:21.418-0500|WARNING|glassfish3.1|org.apache.jk.common.ChannelSocket|_ThreadID=18;_ThreadName=Thread-1;|processCallbacks status 2|#]

[#|2011-07-19T20:49:21.418-0500|FINEST|glassfish3.1|org.apache.jk.common.ChannelSocket|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|send() 23 4|#]

[#|2011-07-19T20:49:21.418-0500|FINEST|glassfish3.1|org.apache.jk.common.ChannelSocket|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|send() 6 5|#]

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

Kindly provide a solution ASAP.



 Comments   
Comment by oleksiys [ 20/Jul/11 09:41 AM ]

patch for the GlassFish 3.1

Comment by oleksiys [ 20/Jul/11 09:42 AM ]

please copy the attached grizzly-utils.jar file to the glassfishv3/glassfish/modules folder.
You have to replace the existing grizzly-utils.jar in the mentioned folder.

Comment by aplohith [ 20/Jul/11 03:23 PM ]

Great..It works now.. Thanks a lot.

Comment by oleksiys [ 20/Jul/11 03:26 PM ]

thank you for confirming it.

Comment by donatasc [ 20/Jul/11 03:30 PM ]

Will the fix be part of GlassFish v3.1.1?

Comment by oleksiys [ 20/Jul/11 03:39 PM ]

reposting message from forum:

"This issue is caused by change made on Grizzly long time ago,

HashMap attributes = new HashMap()

changed to

Map attributes = new ConcurrentHashMap();

the problem is that ConcurrentHashMap unlike HashMap doesn't allow null values.

Don't want to roll the change back, cause not sure what was the reason for it and 3.1.1 release is very close at this point.
I can just provide a patch for GF 3.1, so you can use it."

what i can do - attach another patch for 3.1.1

Comment by donatasc [ 20/Jul/11 03:48 PM ]

Well we are running GlassFish v3 in production (with Apache HTTPD as a front-end). I was evaluating possibility to upgrade to v3.1.1 as it will get released.

I would propose to reopen the bug (or duplicate it with Affects Version being 3.1.1 b11), just to track how this will get fixed for 3.1.1 or 3.2 (if it is too late for 3.1.1).

Otherwise this bug will just get forgotten for 3.1.1.

Comment by oleksiys [ 20/Jul/11 03:52 PM ]

sure, go ahead and reopen it for 3.1.1.

Thanks.
Alexey.

Comment by oleksiys [ 20/Jul/11 04:30 PM ]

forgot to mention that it's possible to get supported GF patch release, even for the prev. GF versions. But this has to be requested throw official GF support.

Comment by oleksiys [ 02/Aug/11 03:52 PM ]

reopen to add 3.1.1 patch

Comment by oleksiys [ 02/Aug/11 03:53 PM ]

Patch for Glassfish 3.1.1

Comment by oleksiys [ 04/Aug/11 09:36 AM ]

FYI, Grizzly issue
http://java.net/jira/browse/GRIZZLY-1052

Comment by shreedhar_ganapathy [ 01/Sep/11 08:40 PM ]

Has this bug fix been checked into 3.1.2 branch? If not, could you look into whether this needs to be integrated there as well?

Comment by oleksiys [ 02/Sep/11 10:50 AM ]

umbrella issue
http://java.net/jira/browse/GLASSFISH-17270





[GLASSFISH-17037] Switching log levels persistently breaks logging service Created: 13/Jul/11  Updated: 18/Jan/12  Resolved: 19/Oct/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1_b11
Fix Version/s: 3.1.2_b06, 4.0

Type: Bug Priority: Critical
Reporter: mkarg Assignee: srinik76
Resolution: Fixed Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 64 Bit de_DE


Issue Links:
Duplicate
is duplicated by GLASSFISH-17161 NulllPointerException in GFFileHandle... Resolved
is duplicated by GLASSFISH-18205 Changing a log level via Admin Consol... Resolved
Tags: 3_1-next_release-note-added 3_1-next_release-notes 3_1_1-next 3_1_1-scrubbed
Participants: Anissa Lam, donatasc, mkarg, naman_mehta, sirajg and srinik76

 Description   

In the admin GUI I changed some log levels from INFO to FINEST and enabled logging to console, then restarted GFv3.1.1_b11 and roated the log. Since that the server.log always is nearly empty. Even after switching everything back in the GUI and another restart, GF is no more logging into domain1\logs\server.log. The only information it puts into the log is the list of options used at server start, but nothing more.



 Comments   
Comment by donatasc [ 13/Jul/11 06:23 PM ]

I confirm the same.

Problem occurs also if a new logger is being added via admin console (log levels are not touched). It seems that admin GUI messes up the logging.properties file somehow.

Comment by mkarg [ 14/Jul/11 10:13 AM ]

I was able to workaround that by setting

com.sun.enterprise.server.logging.GFFileHandler INFO

I noticed that due to the messup that one was set to OFF

Comment by naman_mehta [ 26/Jul/11 09:42 AM ]

This issue is reproducible.

When you fresh install glassfish and open logging.properties file from domains/domain1/config folder you can find the following line:

com.sun.enterprise.server.logging.GFFileHandler.level=ALL

Here, com.sun.enterprise.server.logging.GFFileHandler is the FileHandler logger and having log level set as ALL by default.

Due to the log level set to ALL it allows user to write all log messages with any log levels to the server.log file. If you set log level to INFO it logs only INFO messages to server.log file.

Now when you open admin console and go to server-config and logger settings page, you can't find log level ALL there. So com.sun.enterprise.server.logging.GFFileHandler logger value is by default point to OFF in GUI. Now user make any changes to any other logger also and clicks save it sets com.sun.enterprise.server.logging.GFFileHandler logger value to OFF. So after that no data is logged under server.log file.

So remove this property from GUI so user can't allow to set the same. We need FileHandler logger should always point to ALL log level.

Comment by naman_mehta [ 26/Jul/11 09:43 AM ]

Assigning to admin_gui team.

Comment by Anissa Lam [ 26/Jul/11 01:47 PM ]

Target this for release after 3.1.1.

Comment by mkarg [ 27/Jul/11 06:36 AM ]

What a joke! You actually want to publish a software as "ready for production use" that will completely switch off logging as soon as one does nothing but click on "Save"? I actually don't understand your definition of "stable" obviously.

Comment by sirajg [ 27/Jul/11 02:59 PM ]

The console considers the following to be valid levels : "OFF", "SEVERE", "WARNING". "INFO", "CONFIG", "FINE", FINER", "FINEST". The issue is fixed by adding "ALL" to the list.

Diffs :
— src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (revision 48367)
+++ src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (working copy)
@@ -214,6 +214,7 @@
final private static List<String> levels= new ArrayList();
static{
levels.add("OFF");
+ levels.add("ALL");
levels.add("SEVERE");
levels.add("WARNING");
levels.add("INFO");

However, there should really be a way to get valid log levels from the logging backend. Putting this data in console source code is not the ideal solution.

Comment by sirajg [ 27/Jul/11 03:00 PM ]

Or the other solution is to just remove the property com.sun.enterprise.server.logging.GFFileHandle from console.

Comment by Anissa Lam [ 10/Aug/11 04:05 PM ]

request Srini to fix this in 3.1.2 and trunk.
We will want to release note this for 3.1.1 release.

Comment by Anissa Lam [ 15/Aug/11 02:09 PM ]

Following is added to 3.1.1 release note.

Description:

Changing log levels in the Administration Console causes logging to stop. This is because the level of the com.sun.enterprise.server.logging.GFFileHandler logger is changed to OFF.

Workaround:

Fix the com.sun.enterprise.server.logging.GFFileHandler logger level using the following command:
asadmin set-log-levels com.sun.enterprise.server.logging.GFFileHandler=ALL
Specify the --target option for a server instance other than the domain administration server (DAS).

Comment by srinik76 [ 17/Aug/11 11:00 AM ]

What is the fix expected,

Do I need to remove the property from admin console page or add log level "ALL" as suggested by siraj. Please suggest so that I can fix appropriately.

Comment by Anissa Lam [ 18/Aug/11 12:26 PM ]

I don't think ALL is a valid log-level. you may want to check with Naman.
At least in v2, ALL is not allowed.
<!ENTITY % log-level
"(FINEST | FINER | FINE | CONFIG | INFO | WARNING | SEVERE | OFF)">

Also, is com.sun.enterprise.server.logging.GFFileHandler really the name of a logger ?

It depends on the answer of the above.

  • if ALL is NOT valid log-level and GFFileHandler is NOT a logger, then remove this from the logger table. Move that to the general logger setting page and provide a dropdown with all the acceptable value for user to set this. Check with Naman what is accepted value for this.
  • if ALL is NOT valid log-level, but GFFileHandler is indeed a logger, then logging.properties is wrong out-0f-box. Naman need to fix that.
Comment by naman_mehta [ 26/Aug/11 05:25 AM ]

In logging the FileHanlder log level is allowed user to write logs under specified log file. Default value is ALL for the same.

http://download.oracle.com/javase/6/docs/api/java/util/logging/FileHandler.html

But in some of the case, user wants to use there custom log handler which writes logs under some different file in different format then at that time to OFF logging user has to set this log level to OFF which in turn stop logging in server.log file. I had a bug for the same in the past so to fix the same we need to allow user to set log level as OFF for the same.

ALL and OFF are also valid log levels.

http://download.oracle.com/javase/6/docs/api/java/util/logging/Level.html

Comment by srinik76 [ 29/Aug/11 08:54 AM ]

Fix attached

Index: src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java
===================================================================
— src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (revision 49029)
+++ src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (working copy)
@@ -221,6 +221,7 @@
levels.add("FINE");
levels.add("FINER");
levels.add("FINEST");
+ levels.add("ALL");
}
}

Waiting for review comments from Anissa.

Comment by srinik76 [ 19/Oct/11 06:42 AM ]

Checked in the fix in 3.1.2 branch

Sending LoggingHandlers.java
Transmitting file data .
Committed revision 50343.

Comment by srinik76 [ 19/Oct/11 06:57 AM ]

Checked into the trunk

Sending admingui/common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java
Transmitting file data .
Committed revision 50344.





[GLASSFISH-11805] Injection of Extended persistence context does not work Created: 18/Apr/10  Updated: 03/Nov/10  Resolved: 03/Nov/10

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: v3.0.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Critical
Reporter: donatasc Assignee: Mitesh Meswani
Resolution: Fixed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Zip Archive InjectionDemo.zip    
Issuezilla Id: 11,805
Tags:
Participants: donatasc, marina vatkina, Mitesh Meswani, rogerk and Sivakumar Thyagarajan

 Description   

This CDI scenario does not work on GlassFish v3.0.1 promoted build b14:

@SessionScoped
@Stateful
public class EntityManagerProducer {
@PersistenceContext(type=PersistenceContextType.EXTENDED)
private EntityManager em;

@Produces
public EntityManager getEntityManager() { return em; }
}

@Named
@SessionScoped
@Stateful
public class A {
@Inject
private EntityManager em;

public List<University> getUniversities() { return em.createNamedQuery("University.findAll").getResultList(); }
}

JSF page:
<h:dataTable value="#{a.universities}" var="item">
<h:column>
<h:outputText value="#{item.name}"/>
</h:column>
</h:dataTable>

Exception:

Caused by: java.lang.NullPointerException at
com.sun.enterprise.container.common.impl.EntityManagerWrapper.createNamedQuery(EntityManagerWrapper.java:522)
at lt.mycompany.template.A.getUniversities(A.java:42)

Additionally, checking em.getDelegate() reveals it is null.

If I change PersistenceContext type to TRANSACTIONAL, the case starts working.
Also, if some operations on entity manager are done before injecting it to A,
everything works too.

It seems like EntityManager delegate is not being initialized if it is of type
EXTENDED.



 Comments   
Comment by rogerk [ 19/Apr/10 07:03 AM ]

Can you provide the ear/war with source code that reproduces the issue?

Comment by donatasc [ 19/Apr/10 08:30 AM ]

Created an attachment (id=4306)
testcase

Comment by donatasc [ 19/Apr/10 08:41 AM ]

Attached is complete NetBeans 6.8 Web application project, plus DDL.sql. Since
the project is using EntityManager, you could follow these steps to create the
database:
1. Create MySQL database with name "universities"
2. Execute statements in DDL.sql (at the root of ZIP archive)
3. Modify sun-resources.xml specifying your user name, password, etc. (or
recreate persistence unit persistence.xml)
4. Change @PersistenceContext type to TRANSACTIONAL in class EntityManagerProducer

This should be enough to start things going, you should see a list of two
university names in a browser:

University1
University2

Now change @PersistenceContext type back to EXTENDED (class
EntityManagerProducer), and the aforementioned Exception stack trace should
appear in Glassfish logs.

Comment by rogerk [ 26/Jul/10 10:13 AM ]

assign to Siva

Comment by rogerk [ 26/Jul/10 10:14 AM ]

sssign to Siva

Comment by Sivakumar Thyagarajan [ 08/Oct/10 02:46 AM ]

Targetting for MS6

Comment by Sivakumar Thyagarajan [ 24/Oct/10 01:20 AM ]

EntityManagerWrapper._getDelegate() returns null and hence the NPE. Request the
persistence/ejb-container teams to look into this. Marina, please route this as
you seem fit. Thanks.

Comment by Sivakumar Thyagarajan [ 24/Oct/10 03:41 AM ]

Transferring to Marina

Comment by marina vatkina [ 25/Oct/10 02:07 PM ]

Mitesh, is it fixed in 3.1?

Comment by marina vatkina [ 25/Oct/10 04:22 PM ]

The em is null because the context instance had been changed between em delegate
was added to the SessionContextImpl and it was requested from it during the call
(see SessionContextImpl id in adding/getting output):

[#|2010-10-25T16:18:15.740-0700|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
.... adding ...151804362|#]

[#|2010-10-25T16:18:15.741-0700|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
.... emf
...org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl@61936199|#]

[#|2010-10-25T16:18:15.742-0700|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
.... em ...org.eclipse.persistence.internal.jpa.EntityManagerImpl@47d1a507|#]

<...>
[#|2010-10-25T16:18:15.784-0700|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
.... getting from ...317502939|#]

[#|2010-10-25T16:18:15.784-0700|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
.... emf
...org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl@61936199|#]

[#|2010-10-25T16:18:15.784-0700|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
.... em ...null|#]

Non-extended em is not going through this map lookup.

Comment by marina vatkina [ 26/Oct/10 10:59 AM ]

The 2 context that are created are created correctly for 2 SFSBs - A that
injects EM, and EntityManagerProducer that produces it.
A.em is marked as @Inject, not @Pctx. Our code, when populates EMs in all maps
in the SFSBContainer doesn't think that there are any EM refs to process:

Set<EntityManagerReferenceDescriptor> emRefs
= ejbDescriptor.getEntityManagerReferenceDescriptors();

returns an empty collection, though some code does inject the em ref into A,
because NPE is from _getDelegate, but not from em ref access.

Assigning back to Mitesh to provide an API to be called, or to make sure the
existing API provides the correct list of EMs

Comment by Mitesh Meswani [ 01/Nov/10 06:41 PM ]

Fixed with rev https://fisheye4.atlassian.com/changelog/glassfish-svn/?cs=42368
Initialize delegate eagerly so that exported EMWrapper is functional.

This solves the issue. However, the use case depicted in the bug is not the best
of the patterns to use. Please note that as per the spec, the em exported from
EntityManagerProducer will be closed when it is removed. If there are any
dangling references to it, they would fail. Application will also need to ensure
that EM is not reentered. (EM by definition is non reentrant)

Does the application really want extended persistence context of
EntityManagerProducer to be shared by A? Can't it inject PersistenceContext into
A (A is an SFSB)? Even if A were not a SFSB, a better approach would have been
to add getUniversities() to EMProducer and call it from A.

Comment by donatasc [ 03/Nov/10 11:16 AM ]

Thank you Mitesh for fixing the issue.

All your warnings about the submitted use-case are true. My intended use would
be with conversation scoped components (I just wanted to keep bug submission
simple): how to ensure that all the EJB component playing in the same
conversation do use one and the same extended entity manager.

One conversation scoped bean might be producer for EXTENDED entity manager.
Other beans, participating in the same conversation, would use the entity
manager by @Inject'ing it. Of course, persistence context propagation would get
us the same result, but it requires us to have singe root EJB bean calling
others (if there exist two roots, we get two different entity managers). If the
conversation consists of several JSF pages, and not all of these pages are
calling the single root EJB component, we get problem that during conversation
some entities will get created by one entity manager, some others - by different.

So the solution is either for each different conversation to have single facade
EJB component (with @PersistenceContext) and to require all JSF pages to
communicate with this only component, or to @Inject entity manager produced by
component belonging to conversation, assuring that this entity manager is being
used only by this conversation solely.

If we think about conversation scoped bean, the entity manager produced by this
bean would not be reentrant (still only one thread guaranty by container), and
EJB component would get removed at the end of conversation (as all clients of
this EJB component - they would also be conversation scoped).





[GLASSFISH-3761] Foreign keys are not created with "create-tables" Created: 11/Oct/07  Updated: 06/Jan/11

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: donatasc Assignee: tware
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,761
Tags:
Participants: donatasc, gfbugbridge and tware

 Description   

I'm using GlassFish v2 with Derby database. I have two entities, and one-to-many
relationship:

@Entity
public class Studentas implements Serializable {

...

@JoinColumn(name = "KURSAS", referencedColumnName = "ID")
@ManyToOne
private Kursas kursas;

...
}

persistence.xml contains this line:

<property name="toplink.ddl-generation" value="create-tables"/>

When I try to run a project, tables are being generated, but not the foreign key.
If I change "create-tables" to "drop-and-create-tables", foreing key GETS CREATED!

So the bug is in different foreign key creation behaviour between
"create-tables" and "drop-and-create-tables" (I need "create-tables" to create
foreign keys).



 Comments   
Comment by gfbugbridge [ 11/Oct/07 05:00 PM ]

<BT6616064>

Comment by tware [ 05/Nov/07 12:13 PM ]

Workaround is to use sql script generation. If you run with drop and create
table option, the sql script should be exactly what you want. You can run the
generated SQL on the DB.





Generated at Wed Apr 23 15:20:36 UTC 2014 using JIRA 4.0.2#472.