I have a standalone java application that uses cxf. I have some features to be added into the bus. thus I added a feature (implementing AbstractFeature) and injecting some headers to outgoing messages. The clients to the endpoints are defined in a core module of my project.
This is working pretty well on containers like tomcat etc.. I can see the injection done and my app working expectedly. But when it comes to the standalone java app. The bus again getting configured with the same feature class. But the requests are not going through the bus. Because the injection class is not triggered while I am debugging it.
well the issue was with some missing libraries. CXF runtime frontend jaxws library is the key to get your bus used. for maven; adding below dependency solves the issue
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>${cxf.version}</version>
</dependency>
Related
Our application is spring boot application with Apache camel routes.
Application's information like JMX, Runtime, Spring boot are exposed through hawtio.
But we are not able to see apache camel routes in hawtio.
After adding following dependency, we able to see camel (tab / plugins) in hawtio GUI.
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-management</artifactId>
<version>${version.camel}</version>
</dependency>
http://localhost:8080/actuator/hawtio
And also make sure jolokia and actuator end points are also exposed.
I am developing maven web application, in which I include the Java EE 8 standard API
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>8.0.1</version>
<scope>provided</scope>
</dependency>
I am deploying to JBoss EAP 7.2.9
In my application, I want to upload files to a JAX-RS Endpoint.
#POST
#Path("{id}/file-upload")
#Consumes(MediaType.MULTIPART_FORM_DATA)
public void uploadFile(#PathParam("id") Long id, #MultipartForm FileMetaData metaData) {}
FileMetaData
public class FileMetaData{
#FormParam("name")
private String name;
#FormParam("type")
private String type;
#FormParam("file")
#PartType("application/octet-stream")
byte[] file;
}
The problem is #MultipartForm is not part of the standard JavaEE 8 API. To use it, I must include the resteasy multipart provider in my pom
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-multipart-provider</artifactId>
<version>3.6.1.Final</version>
<scope>provided</scope>
</dependency>
I used the version provided by WildFly 14.0.0 which is the community counterpart of JBoss EAP 7.2.9. However, I am not sure whether this is the correct practice. JBoss EAP uses its own implementation of the module "resteasy-multipart-provider-3.6.1.SP9-redhat-00001.jar", which is located in a private maven repository.
In addition, I am still using the default implementations provided by JBoss for the Java EE APIs (including non-multipart JAX-RS endpoints), as I am not including any other specific dependencies in my pom.
could including the dependency above be a source of conflicts?
is there a way to depend on the module provided by JBoss without being bound to a specific JBoss version?
After more investigations, I found the following: to use a container module (e.g. jboss resteasy) in your application, add the dependency in your pom with scope provided, which means that this dependency will be provided at runtime by the container. Then you will notice that resteasy is not included in your WAR file.
The version implemented by your container is the one used at runtime and not the version you provide in your pom.xml (here 3.6.1.SP9-redhat-00001 and not 3.6.1.Final).
However, your code compiles against the version in pom, which should be less than or equal to the container provided version (assuming that higher versions from the container should always be backward compatible).
I am migrating an EAR application containing MBeans from JBoss 6 AS to Wildfly 8.2.0 AS. In my EAR application, MBeans depend on EJB before initialization.
In JBoss 6 AS, #DependsOn annotation used in MBean maintained the sequence of the deployment i.e. Dependent EJB gets deployed and then, MBean gets deployed.
In Wildfly 8.2.0, I am trying to implement the same and #DependsOn is not working.
I tried the below in jboss-service.xml to have MBeans deployed only after the deployment of EAR file but this did not happen.
<mbean code="sample.HelloWorldService" name="sample:service=HelloWorld,id=1">
<depends>jboss.j2ee:service=EARDeployment,url='application.ear'</depends>
</mbean>
I also tried #startup in EJB but I cannot control the sequence i.e. 1. EJB deployment 2. MBeans deployment.
Can anyone please help about how to control the order of deployment in Wildfly 8.2.0. I need to deploy EJB first and then MBeans. Many thanks.
Just a comment
About the EJB that you want to get from the MBeans, maybe you are misunderstanding the specificaction of jboss-deployment-structure.xml. It express an initialization dependency between singleton components (even if the related EJB are singleton be aware about possible problems with DependsOn like WLFY-4251).
Workaround
Due to you are working with Jboss/Wildfly Server, you have the option to use the jboss-deployment-structure.xml for specify dependency between modules.
Perhaps, as your are packing all in the same EAR application, you can separate the components into modules, let's say one MBean.sar module that contains the MBeans and other RelatedEJBs.jar module with the EJBs referenced by your MBeans.
Then you define the next dependency of MBeans.sar over RelatedEJBs.jar,
<jboss-deployment-structure>
...
<sub-deployment name="RelatedEJBs.jar">
...
</sub-deployment>
<sub-deployment name="MBeans.sar">
<dependencies>
<!-- Adds a dependency on the ejb jar. This could also be done with a Class-Path entry -->
<module name="deployment.YouApp.ear.RelatedEJBs.jar" />
</dependencies>
</sub-deployment>
</jboss-deployment-structure>
Edit: A useful migration guide to Wildfly.
I am using cxf-codegen-plugin version 2.7.13 (same as cxf version of Wildfly). I want to generate toString methods from wsdl so I add the -xjc-Xts argument and the dependency:
<dependency>
<groupId>org.apache.cxf.xjcplugins</groupId>
<artifactId>cxf-xjc-ts</artifactId>
<version>3.0.3</version>
</dependency>
The generated classes use org.apache.cxf.xjc.runtime.JAXBToStringStyle to create the toString methods which is only available in:
<dependency>
<groupId>org.apache.cxf.xjc-utils</groupId>
<artifactId>cxf-xjc-runtime</artifactId>
</dependency>
This dependency is not in the wildfly cxf modules so when I use this dependency with scope "provided" I get the error:
java.lang.ClassNotFoundException: org.apache.cxf.xjc.runtime.JAXBToStringStyle
When I deploy the application together with the dependency I get the following error:
Apache CXF library (cxf-xjc-runtime-2.6.2.jar) detected in ws endpoint deployment; either provide a proper deployment replacing embedded libraries with container module dependencies or disable the webservices subsystem for the current deployment adding a proper jboss-deployment-structure.xml descriptor to it. The former approach is recommended, as the latter approach causes most of the webservices Java EE and any JBossWS specific functionality to be disabled.
What makes it more strange is an article I found:
http://www.objectpartners.com/2010/11/25/leveraging-apache-cxf-and-maven-to-generate-client-side-web-service-bindings/
which mentions that the generated classes use a different class namely:
org.apache.cxf.jaxb.JAXBToStringStyle
Any help will be appreciated.
I am developing a Google Appengine Java application and I am facing a major challenge testing with the local dev server. I dumped the Eclipse tools cause I'm more flexible with Netbeans and
I am using Appengine Maven plugin for my development.
This is my sample project structure :
myapp
module-endpoints
module-web
module-ear
pom.xml
The application works when I build with mvn clean install on the root folder(myapp) and also when I use the mvn appengine:devserver command to run the module-ear application, however I can't seem to access the cloud endpoints via http://localhost:8080/_ah/api. I can only access the endpoint's API via the dynamically issued port when I access it via the admin console http://localhost:8080/_ah/admin.
The issue with this is that when testing cloud-endpoint Javascript client on the module-web project according to tutorials I am supposed to use localhost:8080/_ah/api as my url to test. Am I missing something?
If the question is still actual you could always update your pom.xml with flags so that the ports of all your modules are defined:
<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>${appengine.target.version}</version>
<configuration>
<port>8080</port>
<jvmFlags>
<jvmFlag>-Xdebug</jvmFlag>
<jvmFlag>-Xrunjdwp:transport=dt_socket,address=1044,server=y,suspend=n</jvmFlag>
<jvmFlag>-Dcom.google.appengine.devappserver_module.mymodule2.port=9090</jvmFlag>
</jvmFlags>
<disableUpdateCheck>true</disableUpdateCheck>
</configuration>
</plugin>
Then you could use localhost:9090/_ah/api/explorer to test your APIs
If you have several modules deployed, you need to update your maven app engine launcher setup to recognize the different modules. See the modules sample Java app at https://github.com/GoogleCloudPlatform/appengine-modules-sample-java.
If you've already done that, then a dispatch.xml file will tell app engine how to route requests: https://cloud.google.com/appengine/docs/java/modules/routing
It worked when I made the endpoints project the default module.
dispatch.xml is ignored on devserver, the documentation states the following.
Dispatch files
All dispatch files are ignored when running the development server.
The only way to target instances is through their ports.
This means that only the default module will be reachable at the configured port (typically 8888 or 8080). I have just tested it with app engine 1.9.25 and it does not work, so no improvement has been made.
On the other hand you can always refer to the module by its port. The module's location is logged in the console when the application starts, you will see something like:
INFO: Module instance module2-auto is running at http://localhost:37251/
In my case this was useless since I was expecting to make AJAX requests to different modules by using the same host (but different urls). For instance: