I have a web service which I created with jax-ws in NetBeans. When I create the soap client from the wsdl file, Netbeans generates the mapping classes used for serialisation.
My problem is that I don't want them. I wrote them myself and they are used in other parts of the application. I tried everything to use my classes instead of the auto generated to send the SOAP message but with no success.
The cumbersome solution would be to copy the data from one class to the other and then send the message, but my class has about twenty subclasses so I would like very much to skip this.
Use the JAXB episode option which basically allows you to instruct JAXB to reuse classes in a package. You specify the desired packages in an episode file. "episode" is just a fancy name for a jaxb binding file and it's not very different from your regular jaxb config file. Your episode file would look something like this (bindings file excerpt courtesty of Blaise Doughan's blog)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bindings version="2.1" xmlns="http://java.sun.com/xml/ns/jaxb">
<bindings scd="x-schema::tns"
xmlns:tns="http://www.example.org/Product">
<schemaBindings map="false"/>
<bindings scd="tns:product">
<class ref="com.you.yourclass"/>
</bindings>
</bindings>
</bindings>
Save the file as a .episode file and configure in your Netbeans project like so. I assume here that you've run the Create Webservice from WSDL wizard in Netbeans
Right click on Webservice node within your project. Navigate to the WSimport options tab
Under the Jaxb(xjc) options frame, add the following
(where myepisodefile.episode refers to the episode file you created earlier. Make sure the file is available within your project)
Related
In the wsdl_first sample of Apache CXF the pom file puts the wsdl file in WEB-INF/. Also all the xml files and the wsdl file in src/main/resources ends up in WEB-INF/classes, because they are in src/main/resources.
I deploy the webapp in tomcat.
My question is: when I remove the wsdl file from WEB-INF and the xml files and the wsdl file from WEB-INF/classes (and restart Tomcat), the webapp still works. Why does the pom file put the wsdl file explicitly in WEB-INF? And why are the xml files and the wsdl file in WEB-INF/classes?
In src/main/webapp there are web.xml and cxf-servlet.xml. They end up in WEB-INF/. When I remove them, things go wrong.
So remember a WSDL is the official definition of a service interface. In other words if you want to create a client for a SOAP service you need a WSDL. You can use this WSDL to then generate code artifacts for the client. It is almost exactly similar to generating a server from a WSDL.
Now the WEB-INF folder is published and when the WSDL is in there it is published too. This will allow clients to get to the WSDL. However the WSDL is not needed for the service to run. Thus we can remove the WSDL.
You would typically remove the WSDL when you secure a service against public browsing. This will remove the ability for anyone just to get hold of the service definition.
Remember the WSDL is just a definition used to generate artefacts in various languages such as Java, .Net etc.
However it is not required for a SOAP server or client to run. Just for code generation.
Is it advisable to change web.xml (or, in fact, any other file) in app server after the deployment? Do ALL app servers expose their deployment/directory structure?
I would prefer making changes locally, re-building the war (or .ear, etc.), and re-deploying the application.
Regarding your first question, it depends on the type of the resource. For a classpath resource, you can override the file in any directory that has a higher priority in the class loading mechanism of your application server ($CATALINA_HOME/lib for instance if you're using Tomcat). For an xml file, like web.xml, you can declare an external entity in the packaged file with an absolute path, but you have to be sure that the file will be present on the target server. For instance, your packaged web.xml could look like that:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document [
<!ENTITY webEntity SYSTEM 'C:\Temp\web.xml'>
]>
&webEntity;
So the actual content of the web.xml would be the content of the file C:\Temp\web.xml.
In short, there is no official way to do it but there are tricks. I guess, what people do is to produce a custom package for each production site. There are multiple ways to automate this with Maven like war overlay or classifiers. Here is an interesting link.
Regarding your second question, I would not rely on this assumption. It's quite straight-forward to modify an exploded resource on a Tomcat server but it's is not that simple on a JBoss AS.
So my enterprise project name TestProject, which contain TestProject-ejb and TestProject-war, so when I run the project the url is like this locahost:8080/TestProject-war. How can I change this url to localhost:8080/testproject. I use netbean 6.9, I try to right click on TestProject-war folder in netbean, and specify the context-path there under Run, but it still load locahost:8080/TestProject-war
You need to check that the context-root element for the web module in the application.xml file that's in the META-INF directory of your EAR has been correctly changed.
An example would look like this:
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:application="http://java.sun.com/xml/ns/javaee/application_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd"
id="Application_ID" version="6">
<display-name>TestProject</display-name>
<module>
<web>
<web-uri>TestProjectWeb.war</web-uri>
<context-root>testproject</context-root>
</web>
</module>
<module>
<ejb>TestProjectEJB.jar</ejb>
</module>
</application>
In this example the web module should be available under /testproject of the server you deploy to, so in your case http://localhost:8080/testproject.
(In case you would like to deploy to the root of your server, you can leave the context-root element empty: <context-root></context-root>.)
If you indeed see that your action in Netbeans has correctly changed this file, it may be a deployment problem like BalusC indicated. Check the location the EAR is deployed to and manually inspect whether the deployed version also has the correct value.
As Harry pointed out the default project template doesn't create an application.xml file, so you have to create it by hand at $ENTERPRISE_APP_PATH/src/conf (tested with NB 6.9.1)
Just ran into this question in the course of figuring out the same thing. Since the OP was asking about doing this in Netbeans, let me add to previous answers by describing specifically how to do this using the Netbeans IDE.
With Netbeans 8 (and possibly also with earlier versions) you can tell the IDE to create the application.xml file for you, as follows. Right-click the enterprise application project (in the OP's example this would be "TestProject"), select "New" then "Standard Deployment Descriptor...". This will create an "application.xml" file and put it in the appropriate place in your Netbeans project. Then you can easily edit this file to set the context-root element to be whatever you want.
Can someone help me to place my GWT application on Jetty. I am not using maven. I have libraries in my build path.
First I am taking the war folder already exploded and copy it in jetty/webapps, then in folder context.
I have placed a folde named BiddingSystem in folder web apps, it is an already exploded folder and not a .war file
In folder jetty/context, there is a file test.xml
I am renaming the file to BiddingSystem.xml
and also editing content of BiddingSystem.xml, finally the content of BiddingSystem.xml is
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<configure class="org.mortbay.jetty.webapp.WebAppContext">
<set name="contextPath">/BiddingSystem</set>
<set name="war"><systemproperty name="jetty.home" default="."/>/webapps/BiddingSystem</set>
</configure>
I am getting this error:
to deploy GWT app on Jetty, you often do not need to configure anything.
Copy your 'war' folder (which is created in your eclipse project by GWT) to JETTY_HOME\webapps
change the name 'war' to anything you like for examples "StockWatcher" so you will have JETTY_HOME\webapps\StockWatcher. Now start jetty server and try http://localhost:8080/StockWatcher on your Chrome :)
When GWT is compiled it creates just javascript and html (plus resources like css/jpg/etc..). GWT jars and your Java classes are only used during build process and NOT needed during deployment.
So, you just need to copy contents of you /war directory to your Jetty deployment directory.
There is a .html file which is called host page. It links to all other javascript and css pages needed. This is the entry point to your app. Just open this page in your browser.
It seems that you are new to GWT so there are a few basic things you need to know:
GWT is a client-side technology. You write Java code which is compiled to javascript that then runs inside browser. In this sense GWT is more related to javascript libraries (jQuery,..) than classic page-by-page web frameworks (jsf, Ror, php).
GWT app runs inside a single HTML page (called a host page). This page ever reloads. Look at Gmail to see how this works (though Gmail itself is not written in GWT) .
GWT is NOT a server side technology. You can use any technology on the server side (php, RoR, anything) that supports REST.
GWT can talk to server via AJAX. The data exchange format can be JSON or XML. Backend can be any technology that can produce REST-style JSON or XML content. If you have Java backend you can use GWT-RPC which adds some more capabilities over AJAX/JSON.
I have a .NET 2008 solution with a project that acts as WCF Service host. That project has a web.config file with settings that will be replaced by the installer when the project is complete. Those setting are components that make up the connection string and a few others.
This WCF project references a Business Logic project(class library which implements service code) which in turn references a DAL project which uses the Entity Framework.
What I would like to know is how can I get the values in the web.config in the WCF project to the DAL? Without using any relative paths that I have seen with OpenMappedExeConfiguration. I need to build up the connection string in the DAL based on the setting in the web.config file.
Thanks for your answers.
I`m storing shared things like connection strings in 1 folder, which even is not under folder where source code lives. In DAL tier i just use ConfigurationManager to pick it up.
In project, which starts application (in your case, it`s WCF project), i add "ConnectionStrings.config" file from my external "config" folder AS A LINK (in visual studio, press 'add an existing item' -> choose item -> next to "Add" button is an arrow where this option lives). Then i just set it through that file properties (click on file in solution explorer -> press F4) as a content of project and that it should be copied once again if modified to deploy folder. Then i add a new app.config file to project, which includes "ConnectionString.config".
Source of connectionstrings.config:
<connectionStrings>
<add name="MyConnectionString"
connectionString="Data source=tralala"/>
</connectionStrings>
Source of app.config in WCF project:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings configSource="ConnectionStrings.config"></connectionStrings>
</configuration>
I'm not sure that this is the best approach. But so far so good.
Unfortunately, the answer to your question is "copy and paste". This has always been true.
The closest thing to an exception to this rule is the "new" .NET 2.0 Settings files. Because the structure and default values for these are part of the assembly defining the component, the component can, upon startup, cause the default values to be written to the applications configuration. I imagine one could couple that with a piece of code to work with installutil to cause the defaults to be written out before the containing application is ever started, leaving the defaults in the config file to be edited before the application is used for the first time.