Changshin Lee's Blog

JWS 2.1 vs JWS 2.0

JWS (Java Web Services) 2.1 updates JAXB and JAX-WS to 2.1 and adds WSIT to its basic layer. Now JWS 2.1 is supported by GlassFish v2 while JWS 2.0 is built in JDK 6.

One typical issue is definitely how to use JWS 2.1 on JDK 6. It's well known that you can rely on Standard Endorsed Mechanism provided by Java SE, how about updating JWS from 2.0 to 2.1 for JDK 6u1? Comparing with WCF from .NET Framework 3.0, JDK 6 doesn't support WS-* by default. JDK 7 may be a solution, but it will take long.

Trying JNI with NetBeans C/C++ Pack on Linux

I started to read http://www.netbeans.org/kb/55/beginning-jni-part1.html and soon realized that the article was for Windows while my main development machine is Ubuntu. OK, so it means that I don't need to install cygwin and the rest of the instructions in the article should work fine, right? (Un)fortunately, you need more than the difference in case you're a unixer (including Mac OS X). Here are what I've found during driving the course:

1. First of all, yes! you don't need to install cygwin :-)

2. "Press Ctrl - F11 to clean and build the project" doesn't work for my Linux. Shift - F11 does.

3. /include/win32 -> /include/linux

4. No options for compilation. Simply don't apply -mno-cygwin -Wl,--add-stdcall-alias -shared -m32. FYI, -shared is automatically added as the project is designed for dynamic library.

5. Make sure that your output file ends with not ".dll" but ".so".

These are all except adding -fPIC option for #4 when you work on a 64-bit machine because without the option the compiler complains "/usr/bin/ld: build/Debug/GNU-Linux-x86/HelloWorldNative.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC"

To be honest, this is my first time to create a JNI project. (No wonder I "was" a Java purist ;-) As I began working on Ruby (on Rails) and Python (on Django), I came to get some interest in using other languages than Java. I think that NetBeans C/C++ Pack opens a nice possibility to develop extensions for Java beyond the language itself.

What I found during struggling for REST on GlassFish

Maybe I need to post these issues to GF or JAX-WS projects, but would like to share first with this blog.

I simply wanted to demonstrate a service exposed as both SOAP and REST.

1. Firstly, I started with GlassFish V2 M2 with JAX-WS 2.1M1. I declared a service with @WebServiceProvider as a servlet (and a servlet mappping for that as well), and unfortunately GF recognized it as a plain servlet, so any request toward the service failed. A possible workaround is using a JAX-WS descriptor (sun-jaxws.xml) in order for GlassFish to detect the service. In my opinion, this issue should be fixed.

2. Once I worked around issue #1, I viewed the admin console page and there was no entry in "Web Services" category.

3. When I browsed my web application on the admin console, "General" tab showed me a servlet that I didn't register on web.xml. Intererestingly, the name of the servlet is exactly the same as the fully qualifed class name of the @WebServiceProvider service.

4. I tried to test "restful" sample in JAX-WS 2.1, and (unfortunately again) failed to execute "ant run", which actually ran a client for a RESTful service via Dispatch. The client-side error message is:

run:
[java] Invoking Restful GET Request with query string ?num1=30&num2=20
[java] Exception in thread "main" java.lang.NullPointerException
[java] at com.sun.xml.ws.client.dispatch.SourceDispatch.toReturnValue(SourceDispatch.java:67)
[java] at com.sun.xml.ws.client.dispatch.SourceDispatch.toReturnValue(SourceDispatch.java:54)
[java] at com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:180)
[java] at com.sun.xml.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java:184)
[java] at restful.client.DispatchAddNumbersClient.main(Unknown Source)
[java] Java Result: 1

On the other hand, the server-side error is:
Query String = null
PathInfo = null
javax.xml.ws.http.HTTPException
at restful.server.AddNumbersImpl.invoke(Unknown Source)
at restful.server.AddNumbersImpl.invoke(Unknown Source)
at com.sun.xml.ws.api.server.InstanceResolver$1.invokeProvider(InstanceResolver.java:132)
at com.sun.xml.ws.server.provider.ProviderInvokerPipe.process(ProviderInvokerPipe.java:62)
at com.sun.xml.ws.server.WSEndpointImpl$1.process(WSEndpointImpl.java:156)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:156)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:238)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:97)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:161)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:49)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:246)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:185)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:619)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.processNonBlocked(DefaultProcessorTask.java:550)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:780)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:326)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:251)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:205)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:103)

"ant run-url" worked fine. Just out of curiousity, I opened the same URLs on a firefox web browser as "run-url" client called but met the following server-side error:

The log message is null.
java.lang.NullPointerException
at com.sun.xml.ws.encoding.XMLHTTPBindingCodec.compareStrings(XMLHTTPBindingCodec.java:227)
at com.sun.xml.ws.encoding.XMLHTTPBindingCodec.isMultipartRelated(XMLHTTPBindingCodec.java:210)
at com.sun.xml.ws.encoding.XMLHTTPBindingCodec.decode(XMLHTTPBindingCodec.java:180)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:154)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:238)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:97)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:124)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doGet(WSServlet.java:56)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:246)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:185)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:619)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.processNonBlocked(DefaultProcessorTask.java:550)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:780)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:326)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:251)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:205)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:103)

It seems that when you request through a browser, Content-Type request header is not set. Probably JAX-WS should check out first whether the header string is not null. This problem is not shown in JAX-WS 2.0.1, which is built in GF V2 M1.

OK, nothing is perfect, so I'm looking forward to any progress for that :-)

Web Services 2.0

After introducing "Java Web Services 2.0" at http://weblogs.java.net/blog/iasandcb/archive/2006/03/java_web_servic.html, I made up my mind to broaden the notion :-)

First of all, I felt I had to revise JWS 2.0 because JAX-WS 2.1 and WSIT came up. JWS 2.0 is a set of:

SAAJ 1.3
JAXB 2.1 + JAX-WS 2.1
WSIT

Secondly, .NET Web Services 2.0 is WCF in .NET framework 3.0. Thirdly, Interoperability 2.0 is shown by Sun and Microsoft via WSIT and WCF.

Finally, Web Services 2.0 is a combination of:

JWS 2.0
NWS 2.0
Interop 2.0

OK, as Vista and Mustang (Java SE 6) comes into the final stage, we will be happily able to enjoy WS 2.0 with MTOM, WS-*, and ease of development and use.

When you (and actually I) want to develop a Java application on a Windows PDA

I have to admit that this combination, Windows PDA and Java ME, isn't that easy to approach in terms of both quality and quantity. Firstly, there isn't so-called "RI (Reference Implementation)" of CLDC or CDC on the (obviously) hostile platform against Java. There used to be one historical software, PersonalJava targeted at Windows CE, but got obsolete as CDC came up with several profiles such as FP, PBP, and PP to replace it.

Secondly, we fall into confusion when it comes to adoption among feasible candidates. See "Java Support on Pocket PC" at http://www.comp.lancs.ac.uk/computing/users/fittond/ppcjava.html and you will soon speak to yourself, "what should I do?" "Java on PocketPC" at http://blog.vikdavid.com/2004/12/java_on_pocketp.html has more updated information specific to Windows, but it makes me feel that "still, what should I do again?"

What I exactly want to do is to create a simple web service client on top of a pretty new PDA of which OS is Windows Mobile 5. Of course, I might be able to program the client with .NET, but you know, I'm a Java guy, so I insist on using Java somewhat :-) Development and deployment can be separated: you can now develop CDC/PP applications with NetBeans 5.5 as desribed at http://www.netbeans.org/kb/55/developing-savaje.html. In order to run your applications, IBM WebSphere Everyplace Micro Environment (http://www-128.ibm.com/developerworks/websphere/zones/wireless/weme_eval_runtimes.html) seems like the best choice except the undeniable fact that it's not free. Some discussion thread at http://forum.java.sun.com/thread.jspa?messageID=4251943#4251943 also points out the selection.

OK, so I'll start to work on them, and continue writing about this tiny project, particularly how this "end-to-end" application can be built upon CDC 1.1 and Java EE 5.

The first adoption of "Java Web Services 2.0"

While reading NetBeans 5.5 Beta 2 Release Information at http://www.netbeans.org/community/releases/55/index.html, I found that (Java) Web Services 2.0 was used to introduce JAX-WS.

Although the line left "Java" out, I felt really glad to see the term as I suggested at my previous blog at http://weblogs.java.net/blog/iasandcb/archive/2006/03/java_web_servic.html. Of course, I hope Java Web Services 2.0 would be widely adopted with the brand-new name ;-)

Truth about "format-pretty-output"

I got so much feedback from my recent blog at http://weblogs.java.net/blog/iasandcb/archive/2006/06/serializing_xml.html, and it inspired me to write another.

The most noticeable comment on the blog is to use JAXP transformer to serialize Document, and in fact I couldn't agree on the solution more because I also used it.

Apart from its standard feature, transformer gives you one more nice option: make your Document more human-readable with so-called "pretty-output". The option is so popular that it is almost essential when the output should be seen by a human being, not a machine.

Transformer is basically designed to visualize abstract XML infosets, so it is no wonder to have a diversity of presentations. Even though we do canonicalization on occasion, some want 2 spaces for indentation, and some want no self-closing tags, and so on.

That strength really works for serialization of Document. On the other hand, DOM L3 LSSerializer also supports "format-pretty-output", but unfortunately you can't expect it from JAXP RI, which is also built in Java SE 5 and 6. There's an issue posted for the problem and a possible solution at https://jaxp.dev.java.net/issues/show_bug.cgi?id=6. The patch was actually applied to Apache Xerces, so the option is supported by Xerces 2.8.0.

To sum them up, Transformer can be your friend if you like to control your outputs in details. In addition to that, it's worthwhile considering taking advantage of brevity from LSSerializer.

The world's first Java EE 5 compatible implementation

TmaxSoft (yes, where I work now) achieved it (of course except the Sun RI :-). See http://java.sun.com/javaee/overview/compatibility.jsp for more details. We are planning to release some preview as well.

Thank you all for your great help, especially Alan, Arthur, and Stephen from the Sun CTS team. I couldn't forget such a beautiful weather in Boston.

P.S. More about this to come, so stay tuned!

Serializing XML, not printing XML

Suppose you have an org.w3c.dom.Document instance to output, for example, to a web browser screen or just simply on a Console, then hmm... unfortunately, we used to have no standard way within DOM API (used, not now).

Even though we can take advantage of DOM L3 Load/Save from JAXP 1.3, it doesn't mean that everybody is happy with that mainly because JAXP 1.3 is fairly new and you might have no choice but to stick to JAXP 1.2 and earlier.

One fine day, I encountered an outstanding snippet of code:

System.out.println(doc);

where doc is of Document.

And the result? Yes! it works!

...

OK, then can we generalize this? Again unfortunately, in this case Document.toString() method implementation is overriden but Document API doesn't require so. In other words, behaviors of Document.toString() vary from implementation to implementation, so you can't expect it to work always.

Therefore, I'd like to recommend two things:

1. Use the DOM L3 Save feature as long as you can.
If you use JDK 5 and later, you don't have to pay a penny for that. If you need to use JDK 4 and earlier, consider that your system is able to allow you to endorse the new JAXP set.

Here's a short example of how-to.

DOMImplementation implementation= DOMImplementationRegistry.newInstance()
.getDOMImplementation("XML 3.0");
DOMImplementationLS feature = (DOMImplementationLS) implementation.getFeature("LS",
"3.0");
LSSerializer serializer = feature.createLSSerializer();
LSOutput output = feature.createLSOutput();
output.setByteStream(System.out);
serializer.write(doc, output);

2. If your situation is inevitable, choose XMLSerializer in Xerces without depending on Document.toString(). Although it's not a standard approach, it has been working since its inception for many XML guys :-)

Here's also a short example of how-to.

XMLSerializer serializer = new XMLSerializer();
serializer.setOutputByteStream(System.out);
serializer.serialize(doc);

3. I got valuable input from commentators. It's very coincidental that I just recognized that I used the same method as them :-)

TransformerFactory transformerFactory = TransformerFactory
.newInstance();
Transformer transformer = transformerFactory.newTransformer();
transformer.setOutputProperty("indent", "yes");
transformer.transform(new DOMSource(node), new StreamResult(System.out));

#1 and #3 uses JAXP API, so if you're concerned about portability of your code, those choices can help you.

JAXB 2.0 TCK

You can download it from https://jaxb.dev.java.net/tck.html . It's still beta, but I hope we can see a final version as JAXB 2.0 spec and RI is also finalized (very soon).

Terms in JWS 2.0 - PAWSDL vs PUWSDL and GISC vs GASC

EWS 1.2 introduces two types of WSDL:

PAckaged WSDL - PAWSDL (paw sdle): WSDL files packaged in a module.
PUblished WSDL - PUWSDL (poo sdle): WSDL files published during deployment.

While JAX-RPC uses interface (java.xml.rpc.Service) for clients, JAX-WS uses class:

GenerIc Service Class - GISC (g sc): javax.xml.ws.Service
GenerAted Service Class - GASC (gas c): generated service classes extending javax.xml.ws.Service

Let's talk about JWS with some efficiency :-)

4 cases in packaing web service endpoints in Java EE 5

Web services in Java EE 5, or JWS 2.0 changes a lot in packaging endpoints. There are 3 types in a web module:

1. Neither web.xml nor webservices.xml
In this case, full annotations are required.

2. No web.xml but webservices.xml
Annotations can be overriden by webservices.xml as defined by EWS (JSR 109) 1.2.

3. Partial web.xml and webservices.xml
"Partial" here means that web.xml doesn't have any servlet declaration for endpoints because they can be detected by @WebService Annotation unlike plain Servlets.

4. Full web.xml and webservices.xml
It's just like J2EE 1.4.

JWS ME 2.0

While I introduced the term JWS (Java Web Services) 2.0, I realized that the same notion can be applied to Java ME, i.e. JWS ME 2.0:

JWS ME 1.0

JSR 172 J2ME Web Services

JWS ME 2.0

JSR 279 Service Connection API for Java ME
JSR 280 XML API for Java ME

Eclipse 3.2M6, WTP 1.5M5, and Callisto

Eclipse 3.2M6 was out and is almost ready for the final. Eclipse 3.2 supports Java SE 5 as well as Java SE 6.

Eclipse Web Tools project also unveiled WTP 1.5M5, which is aimed at Java EE 5 with Dali, EJB 3 support and JSF. Once Eclipse 3.2 and WTP 1.5 cut the final simultaneously, you will be able to enjoy developing Java EE 5 applications on top of the full Eclipse support.

When it comes to "simultaneity", Eclipse Callisto project may interest you. As a matter of fact, getting a right set for your overall purpose, for example, Java EE development, in Eclipse was quite tricky because there have been infra and component projects with different release plans in the Eclipse ecosystem. Callisto came up to solve the difficulty and already shows some sign for "good to go."

June this year would be great for Eclipse users :-)

Java Web Services (JWS) 2.0

While I was working on preparing slides for my session on TmaxDay 2006 (http://www.tmax.co.kr/tmaxday/), I came up with some idea of grouping and classifying Java web services technologies:

Java Web Services 1.0 (adopted by J2EE 1.4)

JAXP 1.2
SAAJ 1.2
JAX-RPC 1.1
(Optional) EWS (JSR 109) 1.1

Java Web Services 2.0 (adopted by Java EE 5 and Java SE 6)

JAXP 1.3 + StAX 1.0 (= JAXP 1.4)
SAAJ 1.3
JAXB 2.0 + JAX-WS 2.0 (JSR 181 included)
(Optional) EWS 1.2

Instead of calling each Java XML and Web Services technology for a certain level or time of Java EE, we can simply say "JWS (pronounced "J Wiz") 1.0" for the former set and "JWS 2.0" for the latter set. Actually this idea was inspired by Sun's i-Stack that emcompasses JAXB, JAX-RPC, JAX-WS, and so on.

Yeah, I also have to admit that JWS 2.0 is another wave of "2.0" just like Web 2.0 :-)