Problems creating SAAJ object model

Getting wsse enabled in Oracle WebLogic 10.3.x (11g) using CXF as a web service engine and Maven as a build tool proved to be a bit of a challenge. After many Google searches that came up empty, the solution included the following elements.

1) Do not package saaj-api.jar or any saaj-impl.jar with a war or ear deployed into WebLogic.

This requires a bit of work in the pom.xml files that build your project. Many of the CXF libraries have dependencies on saaj-api.jar and saaj-impl.jar so in the in all places where there is a direct or transitive dependency on a CXF library, those need to be excluded.

Example:

<dependency> 
    <groupid>org.apache.cxf</groupid> 
    <artifactid>cxf-rt-frontend-jaxws</artifactid> 
    <version>2.2.9</version> 
    <exclusions> 
        <exclusion> 
            <!-- Remove SAAJ (soap attachment) lib version that conflicts
            with Weblogic Built-In version. --> 
            <groupid>javax.xml.soap</groupid> 
            <artifactid>saaj-api</artifactid> 
        </exclusion> 
        <exclusion> 
            <!-- Remove SAAJ (soap attachment) lib version that conflicts
            with Weblogic Built-In version. --> 
            <groupid>com.sun.xml.messaging.saaj</groupid> 
            <artifactid>saaj-impl</artifactid> 
        </exclusion> 
    </exclusions> 
</dependency> 

2) Explicitly set the Soap MessageFactory class in a JVM startup parameter on the WebLogic container's JVM.

-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl


REFERENCE: http://blogs.sun.com/fintanr/entry/saaj_classcast_error_with_jdkhttp://blogs.sun.com/fintanr/entry/saaj_classcast_error_with_jdk

Oracle JDBC Connection String Nonsense

After spending several hours trying to sort out the cause of a cryptic message from Oracle's JDBC driver I finally tried something that worked, but the cause, as is often the case with Oracle error message, was completely absent from the error message text. I'm posting this because it was also completely absent from any Google results.

I had a DataSource set up with a connection string as follows:

jdbc:oracle:thin:@//10.0.50.1:1521/mysid

Any attempt to open a connection using that DataSource resulted in the following, completely useless error message:

java.sql.SQLException: Io exception: Got minus one from a read call

Changing it to a slightly different JDBC URL string format made it work.

jdbc:oracle:thin:@10.0.50.1:1521:mysid

The only differences are that // just following the @ has been removed, and the "sid" is delimited at the end by : instead of /

I hope having this matched up with the error message gets someone past all the noise about the number of processes or the number of connections in the listener. At least in my case, that stuff had absolutely nothing to do with it.

Colorado Capital Bank - Irresponsible

This evening I opened a letter from a "Senior Teller" at Colorado Capital Bank which stated that they did not have an "updated signature card" for my account. Enclosed was the "signature card" form with boxes highlighted where my wife and I were to sign and return the form in a postage paid envelope, also enclosed. I wish the only thing about this letter to be irritated about was the wasted postage and the absurd notion that our signatures would need to be updated (since they haven't changed much in nearly 20 years).

Here's a link to their Privacy Policy, which is nothing but a bunch of empty words that have absolutely NO bearing on the behavior of Colorado Capital Bank employees.

http://www.coloradocapitalbank.com/Privacy.aspx

There were a few small problems with this signature form that added up to one gigantic problem. The form included a few pieces of information in addition to the signature boxes. First, it had our entire account number (no part masked, no part truncated). That alone might have been forgivable. But wait there's more. The form also had my full name as it appears on the account, my full social security number, my date of birth, my drivers license number, my mother's maiden name, my full phone number, and my complete home address. Granted, anyone stealing this document from my mailbox could figure out the home address part, but it didn't end there. The form ALSO had my wife's full name as it appears on the account, her full social security number, her date of birth, her drivers license number, and her mother's maiden name.

There it was, all on one page, EVERYTHING anyone would need to steal our identity without making any effort at all. No social engineering would have been required, because ALL of the typical information ANY bank, utility, insurance company, credit card company, or numerous other identity dependent organizations might ask in order to verify our identity was offered up by Colorado Capital Bank on a single sheet of paper, sent to us through the U.S. mail, and expected to be returned to them through the U.S. mail.

If you have an account at Colorado Capital Bank, you should do what I intend to do and close the account immediately and demand that they destroy or secure ALL records related to the account. They are grossly irresponsible in the way they handle the vital information they have on file. If you are considering opening an account at Colorado Capital Bank, I urge you to take your business almost anywhere else. Allowing Colorado Capital Bank to mis-handle your personal information in the first place would be a VERY bad decision.

Unfortunately, I probably can't force them to be responsible with the information they already have on file. I can only close my account and hope that that removes any reason they would have in the future to send EVERY SINGLE THING required for an identity thief to make a huge mess of my financial life. A bank that acts so irresponsibly should NOT be trusted with your money, your identity, or anything else.

This is a warning for others who might find this before it is too late.

STAY AWAY FROM COLORADO CAPITAL BANK!!

Tags: complaint review bank colorado Castle Pines Castle Pines North Castle Rock South Denver irresponsible identity theft privacy policy