mort sahl

Greenhorn
+ Follow
since Nov 27, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by mort sahl

I got it working ... I found the answer at https://blogs.oracle.com/gc/entry/unable_to_find_valid_certification

Downloaded and ran the InstallCert program and put the resulting jssecacerts in my ../jre.lib.security directory, re-enabled the maven-failsafe-plugin and my integration tests now run.

Thanks for your help.
11 years ago
Well ... still no go ... my jks now looks like ...


$ keytool -list -v -keystore keystore.jks
Enter keystore password: Pass1word

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: tokenserver.protegrity.com
Creation date: Jun 4, 2012
Entry type: trustedCertEntry

Owner: CN=tokenserver.protegrity.com, O=Protegrity, C=US
Issuer: CN=tokenserver.protegrity.com, O=Protegrity, C=US
Serial number: d5e8ecedadcb9bd0
Valid from: Mon Apr 23 16:24:49 MDT 2012 until: Thu Apr 21 16:24:49 MDT 2022
Certificate fingerprints:
MD5: 45:A1:DC:C2:89:30:11:9B:AF:CF:C0:3E:7D:39:E2:80
SHA1: F9:6C:BA:6A:E0:62:5F:DC:03:EF:13:04:17:6D:A2:FF:E4:45:AE
Signature algorithm name: SHA1withRSA
Version: 1


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



But the same issue ...

Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

11 years ago
Thanks ... I'll give that a try when I'm back at work on Monday.
11 years ago
Here's the result of -list ...


c:\Apache\apache-tomcat-6.0.20\conf>keytool -list -v -keystore tokenserver-keystore.jks
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: elavon
Creation date: May 8, 2012
Entry type: trustedCertEntry

Owner: CN=tokenserver.protegrity.com, O=Protegrity, C=US
Issuer: CN=tokenserver.protegrity.com, O=Protegrity, C=US
Serial number: d5e8ecedadcb9bd0
Valid from: Mon Apr 23 16:24:49 MDT 2012 until: Thu Apr 21 16:24:49 MDT 2022
Certificate fingerprints:
MD5: 45:A1:DC:C2:89:30:11:9B:AF:CF:C0:3E:7D:39:E2:80
SHA1: F9:6C:BA:6A:E0:62:5F:DC::03:EF:13:04:17:6D:A2:FF:E4:45:AE
Signature algorithm name: SHA1withRSA
Version: 1


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

So, are you saying that the alias name elavon should be tokenserver.protegrity.com instead?
11 years ago
Thanks ... but I've pretty much tried it all, I think.

My maven_pre.bat file located in my Windows7 home directory contains ...

set TRUST_STORE=-Djavax.net.ssl.trustStore=C:\apache\apache-tomcat-6.0.20\conf\tokenserver-keystore.jks
set TRUST_STORE_PASSWORD=-Djavax.net.ssl.trustStorePassword=Pass1word
set MAVEN_OPTS=%TRUST_STORE% %TRUST_STORE_PASSWORD%
echo Done: MAVEN_OPTS=%MAVEN_OPTS%

When I tried .mavenrc in my Cygwin home directory it contained ...

TRUST_STORE=-Djavax.net.ssl.trustStore=C:\apache\apache-tomcat-6.0.20\conf\tokenserver-keystore.jks
TRUST_STORE_PASSWORD=-Djavax.net.ssl.trustStorePassword=Pass1word
MAVEN_OPTS="$TRUST_STORE $TRUST_STORE_PASSWORD"
echo Done: MAVEN_OPTS=$MAVEN_OPTS

I tried setting MAVEN_OPTS as a user variable in Environment Variables with the value of -Djavax.net.ssl.trustStore=C:\apache\apache-tomcat-6.0.20\conf\tokenserver-keystore.jks -Djavax.net.ssl.trustStorePassword=Pass1word

I still get the SSLHandshakException.

All works fine when I run the program as the truststore is setup on tomcat/conf and I can run the tests from inside Eclipse since I set up the truststore in the run configuration. It's just maven that's not cooperating.
If it makes any difference, I'm using Maven v 2.2.1

Thanks


11 years ago
Help please ... I've tried a number of things with no success.

The backstory ...

I'm writing a soap-based web service app. It's sole purpose is to take requests from users, reformat the request for an internal system which is also soap-based running on an SSL encrypted server. I get a response back from the SSL server, repackage it as a response to the original user request and send it back.

The problem I'm having is for integration tests. In Eclipse, if I Run or Debug, my integration tests run fine ... but I do have to set up JVM parameters in a run configuration, I've got ...

-Djavax.net.ssl.trustStore=C:\apache\apache-tomcat-6.0.20\conf\tokenserver-keystore.jks
-Djavax.net.ssl.trustStorePassword=Pass1word

The jks file contains all the info needed to talk to the SSL server.

The problem ...

When running Maven from inside Eclipse or externally, I get the following exception

WARNING: Interceptor for {http://xc.protegrity.com/ApplicationProtectorWS}ApplicationProtectorWSPortTypeService#{http://xc.protegrity.com/ApplicationProtectorWS}xcCreateSession has thrown exception, unwinding now

org.apache.cxf.interceptor.Fault: Could not send Message.

with the following ...

Caused by: javax.net.ssl.SSLHandshakeException: SSLHandshakeException invoking https://tokenserver.protegrity.com/ws/services/ApplicationProtectorWS.2.0: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I've tried defining MAVEN_OPTS with those lines pointing to the trust store in a maven_pre.bat file (Windows 7), to a .mavenrc file (when running Cygwin), I even defined MAVEN_OPTS explicitly in Window's environment variables ... but no luck. I still get the exception.

How do I define the trust store that Eclipse accepts but maven does not?

Thanks
11 years ago
I've got JForum installed ... but where is the documentation? I go to http://jforum.net/doc and get a 404 error.
11 years ago
Eventually found the answer to the problem. It seems that on Windows I had MySQL set to use INNODB and on Ubuntu it was using MyISAM. MyISAM isn't transactional, therefore my rows weren't being rolled back.

Sorry to have blamed Ubuntu. (Now to get this Windows virus off my machine and reinstall Ubuntu)
Simple ... you're doing a shellmoldlabels.size ... shellmoldlabels is null so you can't reference an attribute of a null object
if shellmoldlabels is null you're going to get the NPE ... test it this way ...

if(shellmoldlabels != null && shellmoldlabels.size != 0) {
doSomething();
}
See Chapter 12 in the Spring Reference manual ...Object RelationalMapping(ORM)data access
>> Now the question is more, what do you have against annotations?

First of all ... I am a huge fan of annotations and use them whenever possible.

That said, annotations have a huge downside -- configuration via annotation requires rebuilding the code should something change. Properly written XML configuration should only require a restart of the application to take effect.
That's Rick Hightower ... not Rich ... slip of the finger.
Until you get the answer from Emmanuel I'll jump in here ... the replies you've gotten so far haven't really told you much.

JPA is essentially a wrapper around Hibernate (and TopLink, OpenJPA, etc). Meaning that it is a set of standardized APIs that use a defined peristence provider. It is much like JMS being able to communicate to various message providers or JDBC communicating with different databases.

The advantage of JPA is that, even tho it is part of the EJB 3.0 spec, it does not require a container to run ... you can use it in non-EJB apps. JPA provides a consistent interface to different ORM persistece providers, so, in theory, you should be able to change out the provider, say from TopLink to Hibernate, with no code changes other than the persistence.xml file (the JPA configuration file).

The downside is that, since it is meant to provide a consisent API across different providers, unique features of individual providers are not supported. For instance, Hibernate's criteria API is not supported in JPA. If you want to use it, you can even while using JPA, the problem is that you are no longer provider neutral and should you want to change providers you will have to change code ... or you can use some 3rd party criteria implementation that promises to work across providers (like Rich Hightower's Krank project -- specificially his GenericDAO stuff ... there are others too).

Anyway, just a quick overview comparison -- they're meant to be mutually inclusive rather than exclusive.
It's a JPA thing ... unless entityManager.persist(article) is called, the transaction should not be committed. Under Windows it works correctly, under Ubuntu, the transaction is committed when it should not be.