Develop Reference

Upgrading CXF and WSS4J but can't find dependencies

So I have a working project that I am trying to upgrade CXF and WSS4J
It looks like I have upgraded my client ok, but that's because I am using this for wss4j:
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j</artifactId>
<version>2.1.8</version>
<type>pom</type>
</dependency>
But my server is throwing ClassNotFound exceptions, obviously because of the type=pom.
So where do I find the new classes jars? Specifically WSPasswordCallback.
BTW, I am using CXF 3.1.9

The short answer is that they moved everything. The first place you want to look is: https://mvnrepository.com/artifact/org.apache.wss4j
That is where all the new ones are. From there you will simply need to google the class you want and see if you can find the package you need. For me WSPasswordCallback moved to the commons package...
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j-ws-security-common</artifactId>
<version>2.1.8</version>
</dependency>
IMHO this could have been handled better, but it's a start to find what you need.

Fixes for "This class does not support SAAJ 1.3" do not work

I'm trying to send a soap request from a java method according to example but getting "This class does not support SAAJ 1.3". Others have reported this error but the recommended fixes did not work for me.
What have I tried?
Added saaj-impl-1.3.jar and saaj-api-1.3.jar into maven
dependencies.
<dependency>
<groupId>javax.xml.soap</groupId>
<artifactId>saaj-api</artifactId>
<version>1.3</version>
</dependency>
<dependency>
<groupId>com.sun.xml.messaging.saaj</groupId>
<artifactId>saaj-impl</artifactId>
<version>1.3</version>
</dependency>
Added them into my java lib/ext folder
Added
-Djavax.xml.soap.SOAPConnectionFactory=weblogic.wsee.saaj.SOAPConnectionFactoryImpl
to my JAVA_OPTIONS in startWebLogic.sh. Stopped and restarted weblogic.
Added
System.setProperty("javax.xml.soap.MessageFactory","com.sun.xml.messaging.saaj.soap.ver1_3.SOAPMessageFactory1_3Impl");
System.setProperty("javax.xml.soap.SOAPConnectionFactory","weblogic.wsee.saaj.SOAPConnectionFactoryImpl");
To my code. Nothing worked. Still getting same message. These frameworks are supposed to save you time. Instead they do the opposite. Getting ready to do it the old way unless someone has an idea?

Turned out there was no
System.setProperty("javax.xml.soap.MessageFactory","com.sun.xml.messaging.saaj.soap.ver1_3.SOAPMessageFactory1_3Impl");
By peaking inside the jar, I could see it should be
System.setProperty("javax.xml.soap.MessageFactory","com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl");
That worked. Did not need the other property to be set.

Is it possible to include only the used classes in a war file with maven build?

Say I have this dependency in my pom.xml file:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
</dependency>
When I do a
clean install
all the javaee-api-6.0.jar will be included in the war file under WEB-INF\lib folder.
Is it possible that instead of including the whole jar, only classes that I use and their dependencies are included?

If you're deploying into a Java EE application server, that entire JAR is already provided by the application server, and can be omitted from the WAR file. You can accomplish this by putting it into the provided scope:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
That makes that dependency available for compilation and test execution, but will not package it into the WAR.
In contrast, trying to determine which individual classes you need so you can only include their class files is an ultimately pointless endeveor. The JVM only loads classes when they are used - that is, unused classes are not loaded.
It is generally impossible to identify the used classes at compile time due to reflection. For instance, consider:
System.console().printf("Please specify the implementation class to use");
String className = System.console().readLine();
FooService service = (FooService) Class.forName(className).newInstance();
service.work();
You can get the JVM to log which classes are loaded, but different executions can use different classes ...

It's not a viable option - at least not in maven, although You know which classes You are using, but You don't know what are the dependencies for each class that You imported - so it might be impossible satisfy it's requirements. This is why we are using tools like maven - to ease the process importing a library.
Read some more about reduce size of built project and see what are Your options there
Except for UberJAR, Your biggest chance (IMHO) would be to identify libraries that are provided by the container, and use provided scope for them.
You also could integrate 3rd party tools like ProGuard

You could use exclusions.
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<exclusion>
<groupId>...</groupId>
<artifactId>...</artifactId>
</exclusion>
</dependency>
But I don't think you could exclude at class-levels. This only excludes dependencies useful when there are conflicting dependencies in your project.

It is really not a viable option in my opinion ,as its almost impossible to know internals what all classes are required at runtime until and unless you are seeing the,implementation of all the,3rd part apis that you are using.
I also think the whole idea behind the maven is to ease the development and build process so that you won't have to do any effort in identifying the artifacts that are required at runtime or compile time. Maven will automatically figure out that for you.

Runtime dependency included in war

I am a little surprised: I declared a dependency in maven pom as runtime and it was still included in war.
I honestly expected it not to do this...
I used junit just for the purpose of demonstration...:)
For example:
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>runtime</scope>
</dependency>
</dependencies>
Thanks,
Roxana

Some maven-scopes:
if the dependency is needed in production and has to be delivered along with the application use scope runtime
if the dependency is needed only for (unit-)testing and should not be delivered use scope test
if the dependency is needed in production but is already part of the container (e.g. tomcat, JBOSS) use scope provided

If you want something at runtime then it has to be in the package. Otherwise where will the software know where to find it.
What were you expecting? And most importantly, why are you including JUnit in Runtime? It should be in test scope.

common logging jar conflict with apache axis soap client

I am getting this exception while trying to call SOAP webservice using axis. basically I have written a axis client.
org.apache.commons.discovery.DiscoveryException: Class org.apache.commons.logging.impl.SLF4JLogFactory does not implement org.apache.commons.logging.LogFactory.
When I remove the all the common-logging jars, I would able to remove these errors but these jars are coming from other apis, i dont have control on them.
Is there any way to overcome this problem?

There is a pretty detailed explanation of what the issue may be and ways to debug it in the commons logging documentation. Your particular issue may be,
There is also another more unusual way in which this cast can fail:
even when the binary is compatible, the implementation class loaded at
runtime may be linked to a different instance of the LogFactory class.
For more information, see the tech guide.

None of this solutions worked for me. I figure out my solution in SLF4J documentation
http://slf4j.org/faq.html#excludingJCL
alternative 2) provided scope Commons-logging can be rather simply and
conveniently excluded as a dependency by declaring it in the provided
scope within the pom.xml file of your project. The actual
commons-logging classes would be provided by jcl-over-slf4j. This
translates into the following pom file snippet:
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.21</version>
</dependency>
The first dependency declaration essentially states that
commons-logging will be "somehow" provided by your environment. The
second declaration includes jcl-over-slf4j into your project. As
jcl-over-slf4j is a perfect binary-compatible replacement for
commons-logging, the first assertion becomes true. Unfortunately,
while declaring commons-logging in the provided scope gets the job
done, your IDE, e.g. Eclipse, will still place commons-logging.jar on
your project's class path as seen by your IDE. You would need to make
sure that jcl-over-slf4j.jar is visible before commons-logging.jar by
your IDE.
SLF4J documentation gives more alternatives, this worked for me.

The Link to the above mentioned Documentation to section "Fixes" suggests to include
-Dorg.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
in your setup.
For some people it might be easier to include this code instead:
static
{
System.setProperty(LogFactory.FACTORY_PROPERTY, LogFactory.FACTORY_DEFAULT);
}

Replace jcl-over-slf4j jar with commons-logging jar

Probably its too late :-) but for me following worked. I am using spring boot and added it as first line in the main methods. More explanation as suggested above is here.
System.setProperty("org.apache.commons.logging.LogFactory", "org.apache.commons.logging.impl.LogFactoryImpl");