Hello I have a WebService Client on my java project the which is on weblogic. Now I need add the header for security reasons to my petition. I have tried everything and finally a friend help me with a code for Jboss the which works fine on Jboss, but on weblogic it gives me a problem with of castClassException.
Like the title said the original class is "ClientInstanceInvocationHandler" and I need that on "ClientProxy" of APACHE CXF
Here is the problem:
org.apache.cxf.endpoint.Client client = ClientProxy.getClient( port );
Does anyone have a solution?
According to this site https://community.oracle.com/thread/2467175?tstart=0 the problem is that the Apache classes are not properly on the classpath of the server.
They said they "set the APACHE CXF jars as a User Defined Library and set it to the 'Deployed by Default' option".
In this blog with the same problem, they use the following fragment in their weblogic-application.xml:
<prefer-application-resources>
<resource-name>META-INF/services/javax.xml.ws.spi.Provider</resource-name>
</prefer-application-resources>
From what I can understand weblogic returns it's own implementations for these methods unless you tell it to prefer the standard interface and put an implementation of the standard interface on the classpath. I guess the custom class gives some extra performance or features beyond the standard interface.
The Apache CXF site itself addresses this in a similar way, but suggests a different package name (javax.jws.*)
In addition to all this, some people had problems getting weblogic to find and recognise the jars because it was loading weblogic classes in preference and had to do the following:
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
But I have seen variations on this, depending on where your Apache jars are located.
Related
I am running into the follow error while upgrading my versions of Jetty for a Dropwizard project:
java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory. (Use org.eclipse.jetty.util.ssl.SslContextFactory$Server or org.eclipse.jetty.util.ssl.SslContextFactory$Client instead)
The tricky part is that I do not directly set up my SslContextFactory in code. Instead, Dropwizard sets it up behind the scenes at application startup, where it quickly runs into this issue and fails.
I see from the Dropwizard documentation that certain environment variables can be set on the Jetty server that it spins up, but I do not see documentation on how to modify specific classes.
If I add a jetty.xml file within $JETTY_HOME$/etc/config, will Dropwizard know how to pick this up?
I just need to understand how Dropwizard picks up settings on Jetty so I can use SslContextFactory.Server and resolve this error at startup.
Your version of Dropwizard is too old.
Dropwizard properly uses the SslContextFactory.Server where appropriate.
I made a web-application with JSF 2.0. It supports german (default) and english, which is selected by the languages, sent in the http-header.
On my local server (Tomcat 6.0) the automatic language-selection was correct, if I had "german" on the highest priority, the application was german. The same for english.
But now I deployed it to my webserver (Tomcat 6.0 behind an Apache Webserver, using ModJk) and now it is only in english. But the http header is still the same:
Accept-Language: de-de,en-us;q=0.8,de;q=0.5,en;q=0.3
(Fetched from Firebug)
The entry for the language-packs in my faces-config.xml looks like this:
<application>
<locale-config>
<default-locale>de</default-locale>
<supported-locale>en</supported-locale>
</locale-config>
<resource-bundle>
<base-name>de.citkomm.tbm.locale.Lang</base-name>
<var>lang</var>
</resource-bundle>
</application>
Files "Lang.properties" and "Lang_en.properties" in de.citkomm.tbm.locale are correctly deployed.
Is this a problem with Apache + ModJk + Tomcat 6.0 or is something misconfigured? Does anyone have an idea why the wrong language is selected by Tomcat?
Thanks in advance!
That's strange... I would think that mod_jk should not affect this as you verify that the HTTP header still contains the correct Accept-Language. For a sanity-check if you are on the same internal network then you can try accessing the Tomcat web app directly and skip the Apache Web Server altogether, however I doubt this is the problem.
If you have any common libraries deployed on your Tomcat server environment then it is possible that a different version of your JSF implementation is being used, possibly an earlier version that has an internationalization bug.
I have seen this occur on application servers like JBoss and Glassfish that by default come prepackaged with their own JSF implementation. Likewise the JBoss/Glassfish classloaders gave preference to the bundled JSF implementation libraries versus any JSF implementations that appear in WEB-INF/lib.
Tomcat 6 however does not do this by default but I still suspect a classloading issue of some kind. Double check your common libraries and deployed libraries on the web server and verify that the correct JSF implementations exist there.
Well, I don't know why tomcat uses the evironment-variable of my Ubuntu Server, but it does.
Changed LANG from "en_US.UTF-8" to "de_DE.UTF-8" and now everything's fine. :S
Thanks anyway!
In a J2EE application, how do I create a global Filter that can access other webapps installed on that app server?
In case anyone is still interested, here are my findings regarding this question:
For tomcat and others webapp servers derived from it (eg: JBoss), you can add your filter to the "global" web.xml, usually located under $TOMCAT_HOME/conf/web.xml.
For Websphere, I´ve found the following article to be useful: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101859 . In this case, the basic idea is that you write a ServletContext Listener and uses it to attach your filter to the app
The Servlet-API does not provide such a security leak. But some containers offer alike. Have a look at the <Valve> Configuration of Apache Tomcat. Maybe there is a similar functionality for webshere, but typically you need to hire a ibm consultant to "find" the configuration.
Some application servers/servlet containers (Tomcat, JBoss) provide the cross context feature. It does depend on what you're running your application within however, it's not a J2EE feature.
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
I'm not sure whether this will help you in what you want to do. What is it exactly? : )
Take a look at this response as well:
What does the crossContext attribute do in Tomcat? Does it enable session sharing?
There is no way to do this in a container/platform independent way. Your J2EE container might provide hooks for you to do this though.
This worked for me: https://stackoverflow.com/a/8815211/964681
Sorry, couldn't just comment on your question. Haven't enough "points".
I have done this on Websphere (re: title of this topic) using wsdl2java for generating wsdl to java mapping xml file.
My endpoint is a generic stateless EJB. The code in EJB is generated by traversing the each wsdl and getting the wsdl operation and stuck it in the generated remote EJB interface.
Each EJB method impl is generic and handles all the services the same.
Used instructions on this doc to do this on WAS: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/twbs_devwbsjaxrpcwsdl.html
Now, I am asking you all for help if anyone has done something similar in Sun AS 9.1.
Starting from existing WSDL (and xsd) files. Knowing the sole EJB service endpoint implementation for each services are the same, and generating an EAR file (webservices.xml, ejb-jar.xml, etc).
Have struggled with wscompile and alike, but not getting anyware in the same fashion I did for WebSphere.
Thanks for help.
You want to create a WS client which runs under Sun AS? I don't know Sun AS in detail and I don't know the WS libraries it supplies. But you may want to use a public WS library:
Apache Axis 2
Apache CXF
For every library there is documentation which describes how to create a project from WSDL.
You could even use Eclipse to create a project from WSDL for you: File -> New -> Other... -> Web Services -> WSDL. Make sure you have the "WST Web Services" Plugins installed.
I've never used it myself, but I just recently read about the wsdlLocation() attribute of the WebService annotation, which is supposed to map the service to a preexisting WSDL document (not sure if you're even using EJB3, though).
Does anyone know of a really simple way of publishing Java methods as web services? I don't really want the overhead of using Tomcat or Jetty or any of the other container frameworks.
Scenario: I've got a set of Java methods in a service type application that I want to access from other machines on the local LAN.
Well, Tomcat or Jetty may be overkill for publishing just some methods as a web service. But on the other hand its not too complicated and they do the job, so why not?
I had a similar problem not too long ago and used a Tomcat together with Axis2. Just download Tomcat, unpack it, deploy the Axis2 WAR. To publish a webservice, there are several aproaches, the one I took is probably one of the easiest:
Just build your application as usual and annotate the web service class and methods with the appropriate annotaions from javax.jws.*. Package everything into a jar. Create a service.xml in the META-INF directory of your jar file and put this into it:
<service name="name of the service" scope="<one of request, session or application>">
<description>
optional description of your service
</description>
<messageReceivers>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only" class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver" />
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out" class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
</messageReceivers>
<parameter name="ServiceClass" locked="false">put here the fully qualified name of your service class (e.g. x.y.z.FooService)</parameter>
</service>
Rename the .jar to .aar and put it into the /webapps/axis2/WEB-INF/services/ directory. Start tomcat and the service will be deployed. You can check if it is running by visiting the axis2 page (http://localhost:8080/axis2/). There you will see which services are deployed and which methods are exported. Also you can get the WSDL url there to connect to your service.
Read http://ws.apache.org/axis2/1_4_1/contents.html for more about using Axis2. The approach I described here is not found exactly like this in the docs, but it works very well.
Update: If you just want to provide web services and really don't need any of the other features of Tomcat (e.g. serving of plain old web pages, jsps or other stuff), you can also use the Axis2 standalone server. But except for the setup part it doesn't change anything I described.
I've written a slightly more detailed version of this, which can be found at: http://www.slashslash.de/lang/en/2008/10/java-webservices-mit-apache-tomcat-und-axis2/ (don't let the German in URL irritate you, it's written in English)
Web services depend on HTTP. You might not want tomcat or Jetty. In that case, you have to implement HTTP yourself.
Erhm. Why not just use RMI?
Jetty's pretty lightweight. Otherwise, I think XML-RPC is your only sensible option.
The simplier solution than the one that Simon has discribed, ist to use the tools that alrady do that. If you use eclipse you could use http://ws.apache.org/axis2/tools/1_2/eclipse/servicearchiver-plugin.html
to generate the aar file.