How specifically can you use the javax.jws.WebService.wsdlLocation in JBoss 4.2.2? (This is for an EJB3 bean deployed as a web service).
There is some documentation around that it is supported, but what exactly is the format? I have tried an http, I have tried a relative URL. How does JBoss look for it, a URL, something on the classpath of the EJB, something else?
You should take a look at JBWS-2206 and related issues JBWS-1714 and JBWS-1837.
From the information I could gather, JBoss internally uses Metro (the RI) for JAX-WS. I'm not very sure about this, but it appears that Metro reads WSDLs, if provided via the wsdllocation attribute, using the classloader, thereby making META-INF/wsdl of the EJB JAR a safe choice to place WSDLs. The example file in JBWS-2206 would help as a reference.
Update
A thorough overview on how to provide your own WSDL is present in the JBoss forums.
Update #2
The JAX-WS specification, gives a better idea on why this is the case. In the section 5.2.5.3 Use of #WebService(wsdlLocation) and Metadata, one can find the specification stating that
The value of the wsdlLocation annotation element on an endpoint implementation class, if any, MUST
be a relative URL. The document it points to MUST be packaged with the application. Moreover, it MUST
follow the requirements in section 5.2.5.4 below (”Application-specified Service”).
Furthermore, it states that
A JAX-WS implementation MUST patch the location attributes of all wsdl:import and xsd:import
statement in local documents that point to local documents. An implementation MUST NOT patch any
other location attributes.
defining how the generated WSDL should appear.
Related
I'd like to get CXF, which implements JAX-RS, up and running in OSGI (specifically, Apache Karaf running Apache Felix).
Using this project: cxf-osgi-activator as an example, I see that the engineer made a design decision to split up the jetty Karaf feature from the jax-rs Karaf feature. Is there a dependency between the two at runtime? Does the jax-rs feature use some trick (from the environment: OSGI HTTP Service, for example) to get itself listening for inbound connections, or is that still needed? Maybe my question can be answered with an explanation of line 250 of the RestDeployer.java file. Where is it pulling its Server from exactly? Does it always get one, or does it have a dependency on the jetty Karaf feature?
I had a look at the tests, which seem to use iPojo or Declarative Services (hard for me to tell the difference!) to cut down on boiler plate code, but at the expense of understanding (because it requires more in-depth knowledge on the subject than I have at the moment it would seem.)
The official CXF documentation is less than desirable on this subject.
My understanding is that it boils down to having:
a web resource file annotated with JAX-RS annotations to map inbound calls to local functions
CXF runtime (some registration service that manages the lifecycle from reception of a call to return of serialized information)
a server (Java Servlet or effectively an abstraction thereof that spawns threads for a given port) Purpose of cxf-rt-transports-http-jetty
How does this all play together in OSGI? I should also mention that am most familiar with Gradle, and the Maven pom.xml files likely contain things that I do not recognize.
I do not like the accepted answer to CXF web services with OSGI and Karaf, because it is specific to Blueprint, which I do not want to use because of its reliance on XML. I am looking for a technical answer here that explains the relationship between CXF and OSGI (like the OSGI HTTP Service).
Related:
Apache CXF/JAX-RS, Felix and Jetty
Purpose of cxf-rt-transports-http-jetty
Firstly, a tiny recap about OSGi :
OSGi is a specification that needs to be implemented
Felix/Equinox are the two implementations found in karaf (see your etc/config.properties, with the property karaf.framework to check the one you use, you can change it !)
Karaf is an administration tool that will use Felix/Equinox behind each command you make. Often, those commands are proxied to the corresponding behaviour defined by OSGi to the Felix/Equinox implementation.
So, the solution you linked with Blueprint is still true no matter your context. However, if you don't like Blueprint, you can either check Declarative Services where each "bean" you would have defined in a "spring/blueprint" world would become #Service/#Reference (more pure to OSGi original way of thinking) or use OSGI CDI Integration which will be way more intuitive if you are used to the more classic #Named/#Inject way of thinking inside a bundle.
But in the end, it's exactly the same principles : you want to have a Server running registering itself to the CXF Bus (which normally you shouldn't declare in your bundle, you can use the default one) and your Service registering itself in Server.
I've been on Google for a while this morning, haven't found my answer so far. I have a single service which returns a WSDL when I request service?wsdl, and returns a WADL when I request service?_wadl.
What is the convention re use of underscore when requesting the service's WSDL or WADL? I notice that, under documentation for JAX-RS Services Description, they use the ?_wadl notation for every example. On the other hand, documentation pertaining to the use of WSDLs (usually in the context of a client making a request using CXF to open a WSDL file, to use as a service contract rather than in the context of generating/providing a WSDL to the 'outside world') refer to service?wsdl in the URLs.
Is it to do with whether the WSDL/WADL is auto-generated? Is there a parameter which can be used to define the URL used to access the WSDL/WADL? I'm using CXF 2.7.11.
These (?wsdl, ?singleWsdl) are all conventions that happen to be fallowed by everybody (I once tried to find out from where ?wsdl originated from but was unable to find any information about it).
But just like what happened with WSDL2 (with WSDL1 still being the de facto way of describing SOAP web services), people didn't rush to jump onto the WADL wagon. _wadl is probably another convention waiting to gain speed (I think they went for an underscore just because wadl and wsdl are easily confused, and easy to mistype, both keys being next to each other - but that's just my guess, I wasn't able to find out anything about this either).
And as a counter example, Jersey has another convention, /application.wadl.
I'm not familiar with CXF but at first glance after downloading the source code, it doesn't look like you can change the way the WADL is retrieved or provide another URL to access it.
I try to transfer file with Mtom and it is working pretty good until i use SoapHandler to verify client signature. SoapHandler keeps all message and changes it to base64 encoded. So when i try to get huge file, Jvm throws heap size exception. Do you guys know any ways to solve this problem?
The Java JRE comes with a JAX-WS Provider. This provider has what I would consider a bug. If a SoapHandler is added, either by directly getting the HandlerChain or by using a HandlerResolver, the message, which was correctly created using MTOM, is deconstructed and the attachment(s) are placed inline within the SOAP message. If the attachments are large, this can lead to very poor performance or out of memory errors.
The only solution I have found is to use another JAX-WS provider. From testing, Axis2 seems to work perfectly (although it has a huge number of dependencies). Simply placing another provider on the classpath will cause it to be used. Java looks for a file in META-INF/services named javax.xml.ws.spi.Provider. If this file is found, it will use the Provider specified. The main Axis2 jar will include this file to ensure the Axis2 provider is used. Other Providers may also solve this problem.
Because of this automatic Provider detection, you may find your application does or does not have this problem depending on where it is running. For example, if you deploy an application to IBM WebSphere it already has overridden the default Provider and you will not have this issue. Likely other Application Servers also have overridden the default Provider. If you can get ahold of a copy, IBM also provides a very nice jar, com.ibm.jaxws.thinclient_7.0.0.jar, that has Axis2 packaged in it. This can only be used for standalone applications (those not running in WebSphere), but it is very convenient and resolves this issue.
I must have a really bad day cause no matter what I search for I only get to this link which has only the listing for the allowed XML tags for those deployment descriptors.
I'm pretty sure I saw once a document with a thorough description of those files, but I can't seem to find it right now.
:) GF Application Deployment Guide -> Elements of the Enterprise Server Deployment Descriptors
sun-ejb-jar.xml is an old naming convention for what is today called glassfish-ejb-jar.xml. It is still supported for backward compatibility (see the GlassFish 4 deployment guide, page B-2).
glassfish-ejb-jar.xml is a GlassFish specific deployment descriptor file, documented in the deployment guide. The deployment guide describes its technical structure and is a good start for any question you might have about a specific element of the file. Examples of how-to really use the file is spread out through the entire document base.
All other application servers will most likely ignore this file. Making your application dependent on the contents of this file is the same as making your application non-portable. Thus, it should be avoided as much as possible.
Let me quote the GlassFish deployment guide (page 1-3):
Unless otherwise stated, settings in the GlassFish Server deployment
descriptors override corresponding settings in the Java EE standard
descriptors and in the GlassFish Server configuration.
The overridable standard and portable descriptor file is ejb-jar.xml and is described in the EJB 3.2 specification. The presence of the file is optional and should probably not be used if all you do with the file is describe bean behavior and services from the application server that is used. Unless application developer and application deployer is different persons with different needs, or unless you have a requirement to define different beans based on the same class, then you'll be more than covered using annotations only. That way, declared application server services is more tightly bounded to the code that actually uses the services. It will increase the readability of your code and make more sense to more people. One arguable important and encouraged use of the file is to put customizable environment entries in the descriptor file. If your application is packaged in an EAR file, consider using the application.xml descriptor file for declaration of environment entries instead.
We are considering to use Configuration Admin Service as a primary API for configuring components in our OSGi-based application. It would be nice if we could reuse some existing implementation so I'm trying to investigate and evaluate the most popular ones. I know there is:
Apache Felix Config Admin (org.apache.felix.cm)
Equinox Config Admin (org.eclipse.equinox.cm)
Are there any other implementations to be considered?
Also I was not able to find any good documentation for these implementations. I would be mainly interested in the implementation-specific details. For example I was wondering how different implementations persist the configuration data (e.g. multiple property files? XML file? multiple XML files? database?, ...).
Felix's Configuration Admin has a default implementation that persists to the file system, but they define a service interface (org.apache.felix.cm.PersistenceManager) for alternative backends that you could plug in instead.
The default implementation does the following:
The FilePersistenceManager class stores configuration data in
properties-like files inside a given directory. All configuration files are
located in the same directory.
Configuration files are created in the configuration directory by appending
the extension ".config" to the PID of the configuration. The PID
is converted into a relative path name by replacing enclosed dots to slashes.
Non-symbolic-name characters in the PID are encoded with their
Unicode character code in hexadecimal.
The three public implementations I know of are
Apache Felix
Equinox …source (this has moved recently)
Knopflerfish …front page and …source
Equinox's implementation of the ConfigurationAdmin service appears not to support fine control over the persistence policy, as Felix's does, and the Knopflerfish implementation looks (I've only read the source briefly) similar to Equinox's.
The Felix one appears to be the most recently updated and the most reliable.
At present these are the only ones I can find; at dm Server we made the decision to use Felix's bundle, and this is now obtainable from the SpringSource Enterprise Bundle Repository, where you can quick-search for Apache Felix or ConfigAdmin.
Just to complete the answer further: I personally also prefer the Felix implementation. For an example of how to change the way storage occurs at the back-end using a PersistenceManager, see also this implementation that uses standard Java property files as backing storage. Has some limitations, but at least allows you to store your configuration with your application and apart from your OSGi framework implementation.