I'm using Tomcat 8.5.6 inside Eclipse 4.6.1. I have my web-app project/context foo, which has a JAX-RS (using RESTEasy 3.1.0.CR3) endpoint of bar, so I can fire up Tomcat inside Eclipse and access:
http://localhost:8080/foo/bar
I have a variable named foobar which I want to access inside my JAX-RS implementation using JNDI:
final String foobar = (String) new InitialContext().lookup("java:comp/env/foobar");
I plan on deploying the produced WAR in production using Tomcat autodeploy. I want to configure the foobar variable for Tomcat externally to the WAR. How can I do that so that I can test it in Eclipse?
After a lot of reading, I found what I thought to be the $CATALINA_HOME of Eclipse: …\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\. So I created a context file for foo at …\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\conf\Catalina\localhost\foo.xml to correspond to my project/context, and put the following inside it:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Environment name="foobar" type="java.lang.String" value="123"/>
</Context>
Yes, I know that Eclipse erases this directory whenever I rebuild. But after building, I saved to file at least want to see if it works. It doesn't. I get an error:
javax.naming.NameNotFoundException: Name [foobar] is not bound in this Context. Unable to find [foobar].
I want to at least get it working so I can know how to do this in production, and worry later about the context file deletion thing in Eclipse. So what did I do wrong? Why can't Tomcat in Eclipse find this JNDI variable?
Note: I am not using a web.xml file and have no desire to do so; besides, this variable should be defined outside the WAR in the production deployment.
Update: The good news is that (on Windows 10 Professional Anniversary Edition 64-bit) using the same Tomcat but in standalone mode, I put the same foobar.xml file inside the standalone Tomcat's conf\Catalina\localhost\foo.xml, and my JAX-RS application picked it up just fine. So how can I define a JNDI variable in Tomcat inside Eclipse for testing?
It appears that in order to get Eclipse+Tomcat to recognize the per-module context files, you have to go into the server configuration (double-click on the server) and turn on the Publish module contexts to separate XML files. This way Tomcat will use the specific context XML file you created. Otherwise it apparently puts them in conf/server.xml and ignores the context-specific file you created.
There is still the problem that Eclipse regenerates this file each time you do a rebuild, destroying whatever JNDI variables you placed there. I'm trying to get the workaround in https://stackoverflow.com/a/22380248/421049 to work, but not yet succeeding. Anyone have any better ideas?
At least I'm able to reproduce a production environment now --- albeit temporarily, until the next rebuild.
Your link to Markus' answer on https://stackoverflow.com/a/22380248/1794485 allowed me to get this working, or at least as described in his workaround. But the remaining problem to solve was ordering.
As he said, you can workaround this by having a local copy of the META-INF/context.xml somewhere else, and adding this folder to the Deployment Assembly in the project properties of the Eclipse project.
This didn't pick up for me initially though. It looks like that while the Deployment Assembly in the properties shows as sorted by name, in fact it has an order like any other path. When I then removed the src/main/webapp entry (so the one containing the normal META-INF/context.xml) and added it back in, this effectively moved it down the pecking order. The next Tomcat deploy and startup in Eclipse finally put my preferred copy of META-INF/context.xml in .metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\myapp\META-INF
If in doubt about the true sequence of that Deployment Assembly path, have a look under your Eclipse project on the file system - at .settings\org.eclipse.wst.common.component.
In an ideal world, you have your GWT app compiled to javascript, you serve it as static resource and you behind the scenes you have your back end code running on a JVM, and life goes well.
But that ideal world is called production during runtime.
However, during development time, when you would like to make use of the gwt code server...
You're GWT compile time dependencies are needed during runtime (sources + classes), for debugging and recompilation purposes of the GWT module.
At the same time, you may wish to have back-end supported by something like spring-boot 1.3.5.RELEASE.
In this case, spring boot, suffering multiple frequent releases, is at this point in time wanting to add as managed dependency, for example:
<hibernate-validator.version>5.2.4.Final</hibernate-validator.version>
Which, of course, is a very good thing. It is one of the many good features of spring, in fact.
Gwt, on the other hand, see link bellow,
http://www.gwtproject.org/doc/latest/DevGuideValidation.html
is still requiring you to use:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>4.1.0.Final</version>
<scope>runtime</scope>
</dependency>
Now, if you were to say: I do not care about productive development, just compile me something that works properly in production.
Then indeed, you can trivially solve the above problem by structuring your project in such manner:
ROOT
--- Backend-api
--- Backend-Impl
--- Gwt-Front-end
---- War or stand alone Spring jar module to glue it all together
Where you make the Gwt-Front end depend on the back-end APIs, for some RPC services and DTOs. The pom.xml dependencies you can for the most part manage only in your front-end module, independently of whichver dependencies you have in the back-end.
Ultimately, you make a war, or a spring boot runable jar, that carries your gwt code as static resources and carries your back-end code with all of its dependencies, namely Hirbernate validator latest version.
However, when you are trying to get a pom that works for development purposes, as far as i can see, you are stuck having to globally to manage the dependencies that are common between the back-end and the front-end layer in the ROOT pom.xml, and downgrading your dependencies to the version required by gwt.
That is, in the ideal world scenario.
You have your ROOT pom.xml simply declaring your modules and the order by which they get build. And you get your back-end-impl to have the power to state it wants to inherit dependencies from the spring-boot-starter pom.xml, etc...
In contrast to the ideal scenario, on the pom.xml configuration that actually helps you during the development time...
Well, you can have to revisit the Root pom.xml.
And you have to add in managed dependencies on this root pom.xml, so that for all those common conflicting dependencies between your GWT front-end and spring boot back-end, you always have to hammer the version of the GWT and put a downgrade in place.
This will ensure that when you do gwt:run, dev mode recompile, etc... you do not end up having the gwt compiler trying to javascript compile your Hibernate version 5, but instead the version that is indeed supported by GWT 4.1 final. Of course you might end up having a surprise in back-end code, one of these days by puting in place such a hack...
Does anybody have an idea of how to properly organize a multi module project where back-end and gwt based front-end are allowed to have conflicting depency requirements?
Ultimately, if the answer is no, I believe I will prefer to have network wastage and added communication delay, by having a pure stand-alone spring boot backend that integrates with a pure gwt stand alone jetty, where the back-end on this jetty does nothing more than dumbly kick the requests to the actual spring-boot backend. It is kind of pathetic to have gwt jetty back-end that gets called to do 1+1 by the UI and which forwards the computation to a second back-end running sprin boot that actual knows how to do the 1+1... but if this is the most productive way of working, ensuring that development is productive and the production will run without surprises, so be it.
Thanks for any feedback, and Ideally, I would like to see a multi-pom project that you can import as existing maven project into eclipse, and demonstrates how this can be achieved.
Figure out where the transitive dependency is that you want to exclude when compiling GWT code.
<dependency>
<groupId>spring-dependency-with-hibernate</groupId>
<artifactId>some-spring-boot-starter</artifactId>
<exclusions>
<exclusion>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
</exclusion>
</exclusions>
</dependency>
This way only the GWT provided hibernate version will be available at runtime.
Yes, what I wanted to do can in fact be done, though not trivially... not at all.
To setup a maven multi module pom that can be used productively in the sense that you can get code swapping both for back-end and front-end code without needing to choose either the gwt validator dependencies, or the springboot validator dependencies, essentially I organize my project as follows.
You have:
LEVEL 1: myproject-root
----- LEVEL 2: myproject-backend
---------- LEVEL 3: myproject-backend-api
---------- LEVEL 3: myproject-backend-impl
------ LEVEL 2: myproject-frontend
------ LEVEL 2: myproject-runner
-----------LEVEL 3: myproject-runner-jar
-----------LEVEL 3: myproject-runner-war
In myproject-root, you declare the submodules, naturally.
You do dependency management on some inocuous plugins such as surefire plugin. You control java source and target compile language. You do very little more than that. If you have some plugins that you can configure cross cutingly, you might as well put those in the plugin management.
In the myproject-backend, you essentially make it inherit into the dependency management the springboot depencies, by adding to your dependency management:
<dependencyManagement>
<dependencies>
<!-- Inherit dependencies from spring boot dependency management pom -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>${version.spring.boot}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
You declare the two submodules, and you're out.
You do not declare any cross cuting dependencies here. You only use the dependency management. The front-end component will be hiting the api submodule, and you do not want to be creating a dependency magnet in the backend pom, so here you are conservative as much as possible.
In the myproject-backend-api, you start by letting this submodule be a jar sub-module. Down the line, you will want to branch the api component further, by subdividing api-s by entrypoint nature.
To begin with the -api component will have apis needed for the communication between server and frontend, kind of like the typically seen "shared" in the documentation.
Here you are as careful as possible to have as little as possible in what regards to elements in the dependencies element. The front-end will be using these api's and you do not want your api package depending on any spring boot apis.
In the backend-impl, you write your actual business logic and you are free to depend on the full spring boot stack. The rule is, make sure no one ever points to this dependency magnet, especially, never let the gwt component even smell the existence of springboot libraries. Do not refer it ever.
In the myproject-frontend, you do not branch it into different sub-modules, as you might have done with the api component.
Here you make a monolitic component for gwt code so that you can more easily have the gwt maven plugin working for you doing your hot code recompilation.
In this component you depend on the myproject-api, as well as on any relevant gwt library, such as gwt-user, hibernate validator with the old version needed by gwt, etc...
The rule for the myproject-frontend is to declare every single dependency in the component as optional. You do not want to take any transitive depency on the component.
In production all you need is the myproject-frontend.jar/META-INF/resources/MyProjectModule.html...
And all such static resources that springboot will have to detect and serve.
While you are in development mode, however, what you want to do in this front end component is to:
(a) tune your gwt-plugin to not run the jetty server
<noServer>true</noServer>
The point being, if run this jetty server the only thing it would have in its classpath would be the front end code and the api, and definitely not the impl code.
And second, you do not want to use the gwt jetty, you either want to use the springboot tomcat or the springboot jetty. Much better to use the embedded containers of springboot with the appropriate websocket libraries and such.
(b) With springboot you want to server your static resources from the META-INF/resources/ or the public folder. I prefer the resources as it would be where you would normally put JSF components as well.
In any case, because the place static resources come from is special, you want to tune your gwt plugin to compile your java sources into the write folder.
<webappDirectory>${project.build.directory}/classes/META-INF/resources</webappDirectory>
So something like above.
Finally, and this was my main mistake, you do not run your code from where you write your front-end code.
That is wrong, because that forces your front-end code to need springboot depencies, which will cause you extreme pain due to conflicting libraries.
So for dodging this problem, you create the myproject-runner component, and if you want to be very detailed, you make that one a pom parent component so that you can fork your packaging into either jar or war.
I personally like the executable jar, much more to the point, than the war option. I will never want to deploy a sprinboot application in something like a heavy weight weblogic... but whatever rocks your boat.
In any case, the spring boot runner is your ultimate dependency magenet.
This component will depend on about every module you have and their transitive dependencies. But because you separate your runner component from the front-end code, and you make all the dependencies in the front-end code optinal...
Well, you essentially only bundle springboot, and the your gwt static resources.
While you are developing, what you do is .... once you know it ... simple.
(A) you start your spring boot jar application by triggering the main file. If you really want to deploy a war file, that-s your choice you can also build a war file and deploy it to a tomcat or whatever...
(b) you go to your frontend component, rirght click it, chooose run as Maven Build, and gwt:run.
The gwt run will start up the gwt code server, that will be completely blind to your backend code, the only thing it will see in front of its eyes is the code your have in the frontend component as well as all the gwt dependencies you've added in as optinal.
You can finally hot swap code in the back-end if you-re using springboot dev.
You can finally hot swap code in that monolitic frontend component, once you-ve started teh gwt plugin.
Conclusion, it-s possible, but its a hell of a mess.
Glad this problem is out of the way.
I believe I had similar problems and discovered the following while using Eclipse IDE, GWT Google Plugin, SpringBoot and Maven.
The recipe is not simple but it worked for my team.
GWT-dev and Jetty server doesn't work with SpringBoot.
You have to fix the classpath due to Jetty and gwt-dev hardcoded dependencies, only the dependencies gwt-dev and Jetty were built against will work.
I had to split the GWT UI project into two Maven artifacts.
One artifact was a WebApp capable of running only within Eclipse, with all SpringBoot libraries excluded from the classpath.
The other artifact was a deployable SpringBoot JAR with "war" maven packaging type and a WAR overlay of the Eclipse dedicated artifact, including only GWT specicic content.
I hope this helps
Just create dedicated maven profile for running GWT codeserver and add 'gwt-dev' dependency ONLY there
<profiles>
<profile>
<id>gwt-dev</id>
<dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>${gwt.version}</version>
<executions>
<execution>
<id>run-codeserver</id>
<goals>
<goal>run-codeserver</goal>
</goals>
</execution>
</executions>
<configuration>
<sourceLevel>${java.version}</sourceLevel>
<module>kn.iopm.documentserver.IDocServer</module>
<extraJvmArgs>-Xmx1G -Xms512M -Xss1G -Dlog.root=${project.build.directory}/log
</extraJvmArgs>
<runTarget>index.html</runTarget>
<persistentunitcachedir>${project.build.directory}</persistentunitcachedir>
<webappDirectory>${project.build.outputDirectory}/public</webappDirectory>
<deploy>${project.build.directory}/gwt-deploy</deploy>
<codeServerWorkDir>${project.build.directory}/gwt</codeServerWorkDir>
<launcherDir>${project.build.outputDirectory}/static</launcherDir>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
I have a WSDL and have generated code using wsimport. I have written code to the access the web service & trying to test it. It works on Tomcat, but on JBOSS 5.1 GA, it gives following error:
org.jboss.ws.metadata.wsdl.WSDLException_ Invalid default namespace_ null
I have spent 3 days figuring out the problem with no luck. One os the solutions that I tried involved jaxws-rt files & working with the jboss endorsed directory, but I am not sure which jars that need to be replaced, so I am still stuck.
Any help would be very appreciated.
I guess you already fixed this issue, but just in case someone is interested.
I had the same problem deploying a USSD gateway with Mobicents Jain Slee, that runs on top of a JBoss AS 5.1.0 GA. The gateway has to connect to a server via SOAP, so I chose JAX-WS and generated the source code from a WSDL with wsimport.
By the way, I used a similar procedure to this one to create a child Maven project and generate the java files for JAX-WS.
Failed deploy with dependencies embedded on .war file
My first approach was to include all the dependencies in the .war file that is deployed in JBoss.
I think this is achieved by default in Maven, and mvn install will do it.
In the long run, this approach failed, but at least I needed to know the list of jar files that were included in the .war file, to copy them later in a JBoss directory.
I made a lot of troubleshooting with this approach, and had many different log errors, though the main one was this:
java.util.ServiceConfigurationError: javax.xml.ws.spi.Provider: Provider org.jboss.ws.core.jaxws.spi.ProviderImpl not a subtype
That can be found in this other StackOverflow question.
Deploy without dependencies
Maven tweak
So insted, I added <scope>provided</scope> to the JAX-WS dependencies. Something like:
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-rt</artifactId>
<version>2.2</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.sun.istack</groupId>
<artifactId>istack-commons-runtime</artifactId>
<version>2.2</version>
<scope>provided</scope>
</dependency>
This produced a much lighter .war file.
Copy & remove jars in JBoss AS
Now, after deploying the .war file, when my SOAP client tries to connect to the Web Service, it throws the exception mentioned in the question:
org.jboss.ws.metadata.wsdl.WSDLException: Invalid default namespace: null
at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:134)
at org.jboss.ws.metadata.umdm.ServiceMetaData.getWsdlDefinitions(ServiceMetaData.java:293)
at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:84)
at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
at javax.xml.ws.Service.<init>(Service.java:79)
at org.ortelius.UssdServiceImplementation.<init>(UssdServiceImplementation.java:42)
at org.ortelius.OrteliusClient.sendUssdRequestToWs(OrteliusClient.java:28)
It seems that javax.xml.ws.Service calls org.jboss.ws.core.jaxws.spi.ProviderImpl, but it should be calling com.sun.xml.ws.spi.ProviderImpl, so it seems there is a conflict with jar dependencies.
To avoid this problem, it was necessary to:
Move or delete all JBoss jar files found in $JBOSS_HOME/lib/endorsed/ directory.
Copy the jars bundled in my initial .war file (the one of the failed deploy) to $JBOSS_HOME/lib/endorsed/ directory.
all the jars bundled in my .war file.
That basically made it.
Final notes
I have to confess that to find this out was a real pain, and it took me about four days to get this up & running.
I made a lot of troubleshooting with the jar dependencies, checking JBoss logs, remote debugging, comparing Java packages & classes versions, searching for jars online and reading many articles from JBoss manuals, blogs, StackOverflow, JavaRanch, etc...
The SOAP client was really simple, but the deployment in JBoss was pretty problematic.
My solution is not very orthodox, since it depends greatly on the jar files dependencies.
So I'm not sure if it will work for everyone.
Regards.
I new with spring and is following the example from "Spring in Action 3rd Edition".
I want to run the code from the example, so I copied the code.
I install Spring STS suite and have a test spring project. It seems it doesn't include spring's jar implicitly so I need to configure the build path and include and jar one by one.
And jar is in some strange location too (I think they are installed by Spring STS, although I have no idea whether it include Spring itself).
And the spring core depends on common logging from apache:
And I need to go to apache common logging site to download the jar and put it in the lib folder of the project, then set it in the build path.
The whole process is unbearable. What if spring got 20 jars? Is there other way to do this?
Thanks all.
To ease the pain of getting the dependencies, it's highly recommended that you use Maven.
All you need to get started is the following :
Checkout this 5 minute start for Apache Maven.
I have a 'Helloworld' Spring + Maven project (specifically to work with Spring In Action, I might add) setup on Git Hub which should get you started without any hassle.
If you are familiar with GIT then fork this repository otherwise,
Download the whole project as a zip/tarball from here.
This project can also be used as the starting point for a Spring app. Read more about how to get the Spring dependencies using Maven here.
Once you do that a mvn clean install inside the project directory is all you need to get all the required dependencies and there is no manual mucking about to get the jars, put them in the classpath and so on and so forth.
There should be a file called pom.xml in the root folder of your project. It contains all the dependencies.
Add this code block inside of the <dependencies> element:
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
</dependency>
This will add the missing dependency to your project. Alternatively, right click on pom.xml and select Maven -> Add Dependency ... and then type commons-logging in the search field. The editor will add the dependency in the right place when you click OK.
I am using eclipse + eclipselink + maven2 + mysql + jpa 2.0 + java SE.
I can create MySQL tables from the Entity classes with Eclipse. The persistence.xml is in src/main/resources/META-INF/...
I also has database connections specified in eclipse for production and testing. Either one is chosen with the project and seems to work.
Depending which data source is used with the project, the tables are created to selected database. What is in the persistence.xml as database connection details is ignored (not sure what to expect). Also if I right click on the persistence.xml and select 'JPA Tools' > 'Synchronize Class List'. The file gets updated with the entity classes.
The persistence.xml is also required or else the tables will not be created in either of the databases. (Tested by renaming the file)
Earlier I was also able to execute some DAO-methods for testing by putting in and loading stuff. Also there was a menu item in eclipse package explorer named 'JPA', listing the JPA entities in the project, which no longer exists.
I made no changes on the project (only closed the computer for night). The next time the project was opened, I was no longer able to perform any of the DAO-methods and I get the following error:
No Persistence provider for EntityManager named xxx
The same error comes for the main class having DAO-methods, JUnit test ran by Eclipse and the same tests executed by Maven.
Note: I am still able to create the tables from entities.
Any advice?
Usually, this is due to your resources directory not being deployed to your application container. In eclipse, right-click on the project and select Properties in your Project Explorer. Then, select the Deployment Assembly property and ensure that your "/src/main/resources" is being deployed:
The problem was in the pom.xml.
I had the dependency for hibernate as eclipselink was needed.
WRONG: This is what I Had
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>4.1.3.Final</version>
</dependency>
RIGHT: It was suppose to be
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.0.0</version>
<scope>compile</scope>
</dependency>
I got the solution by purely testing everything possible. Not sure even how I managed to try the substitution as I was able to perform test with the same pom & project earlier.
None of the errors or how it was functioning did not suggest it could be somewhat wrong.
Not even sure that's completely right, but at least it works again.