Development tools have been evolving over the last few years. Github revolutionized the way we share and contribute code between projects. Docker made distributions of applications much easier by allowing you to provide an environment for your application to run. Both these technologies simplified the distributions of your applications, but there is still a pain point. Developers that want to tap into your source, edit and build it still have a hard time to set up all the tools. I believe that Codenvy might be the tool to fill this gap.
What is Codenvy? Codenvy is an IDE in the cloud. You can use it to view, edit, build and deploy code. All of this with just a browser. Codenvy integrates closely with Github and Docker and here is when things become interesting. This allows you to set up an environment that you can share with anyone. Why is this interesting? I already had a few readers asking me for help to set up their environments because they struggle to do it themselves. Several combinations of IDE’s and Operating Systems make the task difficult. Maybe there is another way.
My application about Java EE 7 and Angular is probably the most popular I have. I’ve decided to provide it in Codenvy to hopefully make it easier for all of you that want to try the application out.
Setup
After you signed up for Codenvy, you can easily create a new project by pointing your working sources to a git repository. In this case we are going to use, of course the Java EE 7 with Angular Github repository. You might need to specify to Codenvy that this is a Maven project. If everything was setup properly, you should get something similar to this:

In the IDE window, you can browse the code with syntax highlighting and basic code completion. You can also build the project with maven, if you use the Build menu.
Runners
Checking the code is nice, but we are more interested in actually running the code. Codenvy uses a preset of Docker containers to cover a large number of application servers and environments. There can be found in the Runners tab. Unfortunately, there is no Runner provided for Wildfly and the Glassfish one, doesn’t come with the required database. I’ve ended up by writing my own Docker container to provide a custom made Runner for the Java EE 7 Angular sample application. Here are the Dockerfiles:
Codenvy Wildfly Dockerfile
This Dockerfile is just to set up the environment needed to run the application. Add Java and Wildfly to the base Codenvy container.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | FROM codenvy/shellinabox RUN cd ~ && \ sudo mkdir /usr/lib/jvm && \ sudo wget -q -P ~/ --no-check-certificate --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u40-b25/jdk-8u40-linux-x64.tar.gz && \ sudo tar -zxf jdk-8u40-linux-x64.tar.gz -C /usr/lib/jvm && \ sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.8.0_40/bin/java 100 && \ sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk1.8.0_40/bin/javac 100 ENV CODENVY_APP_PORT_8080_HTTP 8080 ENV WILDFLY_VERSION 8.2.0.Final RUN cd ~ && \ sudo wget -q http://download.jboss.org/wildfly/$WILDFLY_VERSION/wildfly-$WILDFLY_VERSION.tar.gz && \ sudo tar -zxf wildfly-$WILDFLY_VERSION.tar.gz && \ sudo mv ~/wildfly-$WILDFLY_VERSION ~/wildfly EXPOSE 8080 RUN cd ~ && \ sudo rm -rf *.tar.gz WORKDIR /home/user CMD sudo sh ~/wildfly/bin/standalone.sh -b 0.0.0.0 && \ sudo touch ~/wildfly/standalone/deployments/ROOT.war.dodeploy && \ tail -f ~/wildfly/standalone/log/server.log |
Codenvy JavaEE 7 Angular Application Dockerfile
This Dockerfile is to map the source code available in Codenvy to a folder in the Docker container. In this way, we can then deploy the code to an application server.
| FROM radcortez/codenvy-wildfly ENV CODENVY_APP_BIND_DIR /home/user/wildfly/standalone/deployments/ROOT.war VOLUME ["/home/user/wildfly/standalone/deployments/ROOT.war"] RUN sudo touch ~/wildfly/standalone/deployments/ROOT.war.dodeploy |
Don’t bother too much about this. Codenvy will import into the project the Dockerfiles that are stored at the project structure in .codenvy/runners/environments/[NAME]
. Since I added my runner to the project sources, this will be imported automatically.
Run the Application
To run the application, just press the Play button in the top right corner. You should see the log of the container starting up and also an url at the bottom. This url is the one you need to use to access the application.

And that’s it! You can now play with the application! You even have a Terminal at your disposal.
Sharing the environment
It was easy to set up the environment here, but wouldn’t it be cool if we could just share it with other people? You could do that by using Factories. Just import your Codenvy project into a Factory and you have available an url to share, which will set up everything for you. So, to access the Java EE 7 Angular application, please use:
https://codenvy.com/f?id=ybnr6nsyrimeoyhg
A few problems
Unfortunately, I’ve also encountered a few problems when I was setting up the environment.
- The code does not get updated in the mapped folder of the running container. If you make changes to the code, you need to restart the container. Even if they are just HTML or Javascript changes for instance.
- In Safari the Runner buttons are not visible, but they are clickable.
- In Firefox I couldn’t type a dash or other special characters in the terminal.
- Terminal sometimes is not visible.
The code not updating is a real pain. Other things are minors. I hope that this could be fixed soon.
Conclusion
Codenvy is a very impressive tool, if we take into account that we are talking about a cloud browser base IDE. I don’t think that Codenvy is going to replace conventional IDE’s. Although it’s a great alternative to distribute your applications and give the chance for other developers to try them out with minimal effort. Again, here is the link for the JavaEE 7 with Angular application:
https://codenvy.com/f?id=ybnr6nsyrimeoyhg
Check the related posts:
Java EE 7 with Angular JS – Part 1
Java EE 7 with Angular JS – CRUD, REST, Validations – Part 2
Today, I’m officially part of Tomitribe. I’m very excited to work with all the amazing tribers working hard to make TomEE a compelling Java EE server.
Some of my readers follow me because I work as a Freelancer and this move may confuse you. Let me assure you, that I’m not joining Tomitribe because I was unhappy with my Freelancer career. In fact, when I’ve started as a Freelancer a couple of year ago, I had no idea how things were going to turn out. Today, I can say that it was the right move. I had the chance to work on my own stuff, travel to conferences around the world, met a lot of different people and have fun in general.
In Tomitribe, I believe I will be able to do all the things that I love as a Freelancer and many more. Until now, I only developed or built applications that sit and run on a server. From now on, I have the chance to work on the server itself. Tomitribe is still a startup, a small one, but with incredible potential. After working for a few major corporations, I’m eager to help and grow something from the ground up. This was just an opportunity that I couldn’t refuse.
I have to say thank you to Decare Systems Ireland and Anthem for two wonderful years. They always understood my needs and gave me the freedom to explore my own things.
Moving forward, a big thanks to David and Amelia for believing in me and bringing me to Tomitribe. I hope I can full fill your expectations. Cheers!

I’m sorry you are missing Andy, but I couldn’t find a better picture 🙁
Anyway, you can expect me to keep the blog running with awesome and independent content. Thank you for reading!
Over the last few days, I have been working on an application migration from JBoss 4 to Wildfly 8. The application is using different technologies, but we are going to focus here on XML Web Services, JAX-WS. Yeah, I know that they are not trendy anymore, but these were developed a long time ago and need to be maintained for compatibility issues.
Anyway, the path to migrate these services was not so easy. I’m sharing some of the problems and fixes with the hope that these could help other developers out there stuck with the same problems.
Sample Definition
Here is a sample of a Web Service definition in the old system, JBoss 4:
| @javax.jws.WebService(endpointInterface = "some.pack.age.WebService") @javax.jws.soap.SOAPBinding(style = SOAPBinding.Style.DOCUMENT) @org.jboss.ws.annotation.EndpointConfig(configName = "Standard WSSecurity Endpoint") @javax.jws.HandlerChain(file = "handlers.xml") @org.jboss.ws.annotation.SchemaValidation(enabled = true, errorHandler = CustomErrorHandler.class) public class WebServiceImpl implements WebService { |
Luckily, most of the definition is using standard Java EE annotations. Only @org.jboss.ws.annotation.EndpointConfig
and @org.jboss.ws.annotation.SchemaValidation
are from the old JBossWS libraries.
We can easily get rid of @org.jboss.ws.annotation.EndpointConfig
since we are not going to need it in the new application. For reference, it’s used to set up extra configuration data to be predefined with an endpoint. Check the documentation Predefined client and endpoint configurations.
We want to keep @org.jboss.ws.annotation.SchemaValidation
. For reference, this annotation validates incoming and outgoing SOAP messages against the relevant schema in the endpoint wsdl contract. Since the annotation no longer exists in JBossWS we have to use Apache CXF, which is the underlying implementation for JAX-WS on Wildfly.
Problems
Here are a few of the problems I’ve faced:
SchemaValidation Annotation
The annotation @org.jboss.ws.annotation.SchemaValidation
doesn’t exist anymore. You have to use the annotation org.apache.cxf.annotations.SchemaValidation
from Apache CXF.
Add the following Maven dependency to use the Apache CXF annotation:
| <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-api</artifactId> <version>2.7.11</version> <scope>provided</scope> </dependency> |
Also, notice that in the original annotation we could define an errorHandler
property. The old application used a custom error handler to set a custom error message on schema validation errors. There is no equivalent in the new annotation, so we need to do it in another way. To replicate the old behaviour I’ve used Apache CXF Interceptors. Create an interceptor class and extend AbstractPhaseInterceptor
. Here is a sample:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | public class SchemaValidationErrorInterceptor extends AbstractPhaseInterceptor<Message> { public SchemaValidationErrorInterceptor() { super(Phase.MARSHAL); } @Override public void handleMessage(Message message) throws Fault { Fault fault = (Fault) message.getContent(Exception.class); Throwable cause = fault.getCause(); while (cause != null) { if (cause instanceof SAXParseException) { fault.setMessage("Invalid XML: " + fault.getLocalizedMessage()); break; } cause = cause.getCause(); } } } |
And you can use it like this:
| @org.apache.cxf.interceptor.OutFaultInterceptors( classes = SchemaValidationErrorInterceptor.class ) |
Interceptors are used by both CXF clients and CXF servers. There are incoming and outgoing interceptor chains being executed for regular processing and also when an error occurs. In this case, we want to override the Schema Validation message, so we need to bind our interceptor in the error outgoing interceptor chain. You can use the annotation @OutFaultInterceptors
for that behaviour. Each chain is split into phases. You define the phase where you want the interceptor to run by passing the Phase.MARSHAL
in the constructor. There are other phases, but since we want to change the error message we do it in the MARSHAL
phase.
Different WSDL
The old Web Services had the WSDL file being auto generated on deploy time. Unfortunately, in some situations, the WSDL generated by JBoss 4 and Wildfly 8 are different. This can cause problems with your external callers. In this case the main problem was in the Schema Validation. Requests that were valid in JBoss 4 were not valid anymore when being executed in Wildfly 8.
The reason for this behaviour was in the target namespaces. If you are using annotated @XmlRootElement
pojos in your Web Service parameters, without defining the namespace
property in the annotation, JBoss 4 WS generated the target WSDL element with a black namespace. Apache CXF will use the Web Service default namespace to bind the WSDL elements if they are blank. For reference, this is done in CXF code: org.apache.cxf.jaxws.support.JaxWsServiceConfiguration#getParameterName
.
This could be fixed by changing the CXF code, but we opted to place the old generated WSDL file in the migrated application sources and include it in the distribution. It’s not auto generated anymore, meaning that we need to manually generate the WSDL if we change the API. We need to be careful to make sure that we are not breaking anything in the WSDL. This approach seemed better than having to maintain our own CXF version. We could probably submit a fix for this as well, but we believe that JBoss 4 behaviour was not intended.
Start CXF
To use specific API’s from CXF, is not enough to have a project dependency for it. In fact, the first few times I’ve tried the changes, nothing related with CXF seemed to work. This happens because Wildfly it’s only looking for the standard Java EE JAX-WS annotations. To have all the CXF behaviour working, we need to tell Wildfly that our application depends on CXF, even if the libs are already on the server. Yeah, it’s a bit confusing.
The application is deployed in a EAR file. So you need to create a jboss-deployment-structure.xml
and add the following content:
| <jboss-deployment-structure> <sub-deployment name="application.war"> <dependencies> <module name="org.apache.cxf"/> </dependencies> </sub-deployment> </jboss-deployment-structure> |
Using a MANIFEST.MF
in the WAR file apparently doesn’t work if it’s deployed inside an EAR file. For more information, please check Class Loading in WildFly.
If you want to use other CXF features, especially the ones linked with Spring, thing might be a bit trickier. Have a look into this post: Assorted facts about JBoss. Fact 6: JBoss and CXF: match made in heaven.
Final Definition
This should be our final definition for our Web Service:
| @WebService( wsdlLocation = "WebService.wsdl", endpointInterface = "some.pack.age.WebService" ) @SOAPBinding(style = SOAPBinding.Style.DOCUMENT) @HandlerChain(file = "/handlers.xml") @SchemaValidation(type = SchemaValidation.SchemaValidationType.IN) @OutFaultInterceptors(classes = SchemaValidationErrorInterceptor.class) public class WebServiceImpl implements BDNSWebService { |
As you can see, the required changes to migrate a Web Service from JBoss 4 to Wildfly are just a few. However, there are a few minor details that can block you for a long time if you don’t know the details. Maybe you have a different setup and the problems that you face are different. This can also help if you are just trying to setup CXF with Wildfly Anyway, I hope that this post can be useful to you.