I'm afraid not - you have to get your IBM ID. That's IBM
There are two (at least) registration options. The other is "partner ID", which will allow you to download all IBM Software - e.g. "IBM WebSphere Application Server 7 Network Deployment Supplements CD 1 of 2" which contains what my problem was - "WebSphere Application Client".
Because there is more politics than technology in the process of getting your own copy of "WebSphere Application Client" (hereinafter referred to as WAC ), here's my deep technological analysis:
- my POM contains jetty-maven-plugin:run-war execution during pre-integration-test phase
- Maven is being run with JAVA_HOME set to WAC's JDK (almost standard JDK)
- MAVEN_OPTS configure java.ext.dirs which extend system class loader with about 400 MB of JARs from WAC - e.g. prehistoric AspectJ, Axis2 in SNAPSHOT version, servlet-api 2.5 and WebSphere specific classes.
- among these classes are all JavaEE APIs (I had to replace servlet-api and jsp-api with the ones provided by Jetty). The critical are javax.transaction.*
- WAR is standard WAR which starts Spring Context
- The critical point during Spring Context's refresh is obtaining "jta/usertransaction" from JNDI using InitialContext configured with WAC specific properties (imagine that - it's not that easy, because WAR's being started in Jetty with "plus" config, which contains it's own JNDI)
- the object obtained from remote JNDI is WAC's implementation of javax.transation.UserTransaction.
- Here the problems begin:
- object acquired from JNDI's implements javax.transation.UserTransaction loaded by system (java.ext.dirs) class loader
- Spring has detected org.springframework.transaction.jta.JtaTransactionManager's constructor which takes javax.transation.UserTransaction but loaded by Jetty's classloader from ... jetty-runner jar
- type mismatch occurs
- WAR fails to start
(to make things more complicated, please note, that my WAR not only needs WebSphere's transaction manager from remote JNDI, it also needs Jetty's global datasource using differently parameterized InitialContext).
So - I've traced down the problem - http://search.maven.org/remotecontent?filepath=org/mortbay/jetty/jetty-runner/8.0.0.v20110901/jetty-runner-8.0.0.v20110901.pom uses maven-dependency-plugin:unpack-dependencies to pack all dependencies into the JAR.
If only the dependencies were not contained in the JAR and the runner relied on the dependent JAR being present on classpath by means of standard Maven dependency resolution, everything would work - I could just include dependency to jetty-runner in my jetty-maven-plugin with the exclusion of javax.transaction:jta. Now I had to manually remove these classes from jetty-runner JAR in my local Maven repository.
I hope I've explained my problem quite well
So - using IBM's JDK is a tiny part of the problem - you would also need: remote WAS, local WAC, remote usertransaction and remote EJBs