Now JAX-RPC has been replaced by new standard JAX-WS, so I thought it is good time to write an entry for JAX-WS as well. Building web services with JAX-WS is pretty straight forward though it might look cumbersome to a newbie. In this entry I am going explain the basic steps for building a Java first web service, which I developed and tested with JAX-WS 2.1.4, Java 6 update 6 and Tomcat 6.0.16.
Step #1 - Write an interface
@WebService(targetNamespace = "http://vinodsingh.com", name = "MyService")
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL)
public interface MyService {
String sayHello(@WebParam(name = "name") String name);
}Step #2 - Implement the interface
@WebService(endpointInterface = "pkg.MyService")
public class MyServiceImpl implements MyService {
@Override
public String sayHello(String name) {
return "Hello " + name + "!";
}
}Step #3 - Configure web.xml
The JAX-WS context listener and servlet are required to be configured in deployment descriptor (web.xml). The WSServletContextListener initializes and configures the web service endpoint and WSServlet serves the service requests using implementing class.
----------------------------
<listener>
<listener-class>
com.sun.xml.ws.transport.http.servlet.WSServletContextListener
</listener-class>
</listener>
<servlet>
<servlet-name>jaxws
<servlet-class>com.sun.xml.ws.transport.http.servlet.WSServlet
</servlet>
<servlet-mapping>
<servlet-name>jaxws
<url-pattern>/myService
</servlet-mapping>
-----------------------------
Step #4 - sun-jaxws.xml
The JAX-WS RI uses information available in this file while initializing and configuring a web service endpoint. This file should be present in WEB-INF directory.
<endpoints
xmlns='http://java.sun.com/xml/ns/jax-ws/ri/runtime'
version='2.0'>
<endpoint
name='myService'
implementation='pkg.MyServiceImpl'
url-pattern='/myService' />
</endpoints>
For more information about this example, please go to below link which is the main link where i got the data.
http://blog.vinodsingh.com/2008/09/building-jax-ws-web-service.html
For jax-rpc example please use the below link
http://blog.vinodsingh.com/2007/08/bottom-up-jax-rpc-web-service-with.html
Thursday, October 29, 2009
Friday, August 21, 2009
javac:invalid flag error-solution
Hi
i faced this problem and suffered 2 days for this. Intially i thought this problem with my java webservices(i got this while i'm doing webservices). But its not.
its the problem with our jdk.few jdk versions supports the wildcard intries in 'javac', few are not.
Here is the full article about this.
http://javahowto.blogspot.com/2006/07/jdk-6-supports-in-classpath-but-be.html
i faced this problem and suffered 2 days for this. Intially i thought this problem with my java webservices(i got this while i'm doing webservices). But its not.
its the problem with our jdk.few jdk versions supports the wildcard intries in 'javac', few are not.
Here is the full article about this.
http://javahowto.blogspot.com/2006/07/jdk-6-supports-in-classpath-but-be.html
Wednesday, July 15, 2009
java.lang.NoClassDefFoundError: net/sf/cglib/proxy/CallbackFilter-Solution
3 solutions found.
Answer 1:
You need cglib.jar
Answer 2:
Download the jbpm-jpdl-3.2.2.zip file from URL http://labs.jboss.com/jbossjbpm/
you will find this cglib.jar in the folder path after you unzip the above downloaded file:
jbpm-jpdl-3.2.2\server\server\jbpm\lib
Answer 3:
If you have this error while using Hibernate, refer to this tuto :
http://java.developpez.com/faq/hibernate/?page=Generalites
It says to include the following libs in addition to the one delivered with Hibernate :
* Jakarta Commons Logging
* Jakarta Commons Collections
* Log4j
* dom4j
* Jta
* asm
* cglib.jar
Answer 1:
You need cglib.jar
Answer 2:
Download the jbpm-jpdl-3.2.2.zip file from URL http://labs.jboss.com/jbossjbpm/
you will find this cglib.jar in the folder path after you unzip the above downloaded file:
jbpm-jpdl-3.2.2\server\server\jbpm\lib
Answer 3:
If you have this error while using Hibernate, refer to this tuto :
http://java.developpez.com/faq/hibernate/?page=Generalites
It says to include the following libs in addition to the one delivered with Hibernate :
* Jakarta Commons Logging
* Jakarta Commons Collections
* Log4j
* dom4j
* Jta
* asm
* cglib.jar
Tuesday, June 2, 2009
validwhen example in struts
While the Struts Validator provides a host of client-side validation capabilities, it also provides a mechanism for implementing automated server-side validation. The server-side validation that we reviewed inside the ActionForm is powerful, but many times there are some simple validations that you want to perform that you do not necessarily need to write Java code to perform. As an example, consider comparing two fields for equality, such as passwords or email addresses. Furthermore, in order for the Struts Validator to work properly, you should not implement your own validate() method, which means that if you have one custom validation field then you are required to validate the entire form yourself.
This is where the Struts Validator "validWhen" validation rule comes into play. The validWhen rule reads: the form field is valid when the "test" variable's value is true. Or specifically looking at the confirmation password from the previous example:
<field property="confirmPassword" depends="validwhen">
<arg0 key="errors.confirmpassword.match"/>
<var> <var-name>test<var-name>
<var-value>(*this* == password)</var-value>
</var></field>
The validWhen rule works by defining a test variable with the test condition in its value. The value is a boolean expression that can contain the following (extracted from the Struts manual):
Single or double quoted string literals
Integer literals, which can be in decimal, octal, or hexadecimal form
null, which matches a literal null or an empty string
Other form fields, referenced by field name
Indexed form fields, referenced by an explicit integer, such as lastName[2]
Indexed form fields, referenced by an implicit integer, such as lastName[]; the implicit integer index will be the same index of the field being tested (for example this can be used to compare string values character by character)
Properties of indexed form fields (either with an explicit or implicit integer index), for example child[].lastName
The literal *this*, which represents the field currently being tested
Another couple notes about validWhen expressions:
They must be enclosed in parenthesis
You can only compare two values when performing an "and" or "or"
If the values can be converted to integer equivalents then they are converted and compared as such
As an example, if we wanted to allow our user to not set a password, then we would want to accept either "null" as a password or require that both the password and confirmation password match. This can be accomplished as follows:
<arg0 key="errors.confirmpassword.match"/>
<var> <var-name>test<var-name>
<var-value>((password == null ) or *this* == password)</var-value>
</var></field>
In this example, if the form's password field is null, the condition is true, or if the confirmation password (this) is equal to the password, the condition is true. Following through this logic, if password is null and confirmPassword is "ABC," the first condition is true and therefore the second condition is ignored. On the other hand, if password is "ABC" and confirmPassword is "DEF," the first condition fails (password is not null). Therefore, the second condition determines the final result; namely, is the confirmation password equal to the password, which it is not.
Writing validWhen expressions becomes easier and easier as you write them, but one of the challenges in using the validWhen is that validation errors do not appear in a JavaScript popup dialog, but rather appears in your
Note: All the above stuff is extracted from the http://www.informit.com/guides/content.aspx?g=java&seqNum=286.
Cheers,
This is where the Struts Validator "validWhen" validation rule comes into play. The validWhen rule reads: the form field is valid when the "test" variable's value is true. Or specifically looking at the confirmation password from the previous example:
<field property="confirmPassword" depends="validwhen">
<arg0 key="errors.confirmpassword.match"/>
<var> <var-name>test<var-name>
<var-value>(*this* == password)</var-value>
</var></field>
The validWhen rule works by defining a test variable with the test condition in its value. The value is a boolean expression that can contain the following (extracted from the Struts manual):
Single or double quoted string literals
Integer literals, which can be in decimal, octal, or hexadecimal form
null, which matches a literal null or an empty string
Other form fields, referenced by field name
Indexed form fields, referenced by an explicit integer, such as lastName[2]
Indexed form fields, referenced by an implicit integer, such as lastName[]; the implicit integer index will be the same index of the field being tested (for example this can be used to compare string values character by character)
Properties of indexed form fields (either with an explicit or implicit integer index), for example child[].lastName
The literal *this*, which represents the field currently being tested
Another couple notes about validWhen expressions:
They must be enclosed in parenthesis
You can only compare two values when performing an "and" or "or"
If the values can be converted to integer equivalents then they are converted and compared as such
As an example, if we wanted to allow our user to not set a password, then we would want to accept either "null" as a password or require that both the password and confirmation password match. This can be accomplished as follows:
<arg0 key="errors.confirmpassword.match"/>
<var> <var-name>test<var-name>
<var-value>((password == null ) or *this* == password)</var-value>
</var></field>
In this example, if the form's password field is null, the condition is true, or if the confirmation password (this) is equal to the password, the condition is true. Following through this logic, if password is null and confirmPassword is "ABC," the first condition is true and therefore the second condition is ignored. On the other hand, if password is "ABC" and confirmPassword is "DEF," the first condition fails (password is not null). Therefore, the second condition determines the final result; namely, is the confirmation password equal to the password, which it is not.
Writing validWhen expressions becomes easier and easier as you write them, but one of the challenges in using the validWhen is that validation errors do not appear in a JavaScript popup dialog, but rather appears in your
Note: All the above stuff is extracted from the http://www.informit.com/guides/content.aspx?g=java&seqNum=286.
Cheers,
Monday, June 1, 2009
check box problem in struts
PROBLEM IS:At http://jakarta.apache.org/struts/newbie.html there is a question "Why are my checkboxes not being set from ON to OFF?"
The answer states: "If the value of the checkbox is being persisted, either in a session bean or in the model, a checked box can never unchecked by a HTML form -- because the form can never send a signal to uncheck the box. The application must somehow ascertain that since the element was not sent that the corresponding value is unchecked."
It also states to possibly use a radio button. I am in the process of trying to make this work because I am keeping my form in the session. I am going to try to see if I can check for the element being sent.
ANSWER:
There is a very simple solution to the checkbox problem. The trick is to always add a hidden field AFTER the checkbox with the same parameter name but with the value set to "false":
Basically, the hidden parameter ensures that there is some request parameter submitted, which will always set the corresponding ActionForm property. If the checkbox is checked, the 2 parameters will be passed: "booleanProperty=true&booleanProperty=false". But the beanutils code only uses the first parameter to set the value. If the checkbox is left unchecked, then there will be only 1 parameter "booleanProperty=false" which will ensure the property is set.
The HTML spec says that form elements must be submitted in the GET or POST in the order that they are specified in the HTML, and all browsers I have used obey this rule. There is no risk that the hidden parameter will obscure the form field as long as you always put it after the checkbox.
The beauty of this solution is that it places the burden in the hands of the page author where there can be more flexibility. It also allows the page author to invert the meaning of the checkbox without bothering the application developer. All the page author needs to do is reword the caption, and switch the ordering of the values used in the checkbox and hidden fields. Also, it works with string or numeric properties just as easily.
It is just a work around. This solution will fail when you want to call javascript function on clicking of the checkbox. The Another solution is :- override the "reset" method in the form bean and set the checkbox value false to correctly identify the checkbox value from request. If your bean is in session scope and if you don't want to identify the correct value everytime then get the action from request object and set/reset the checkbox value.
Friday, May 8, 2009
Sun Certified Ajax Developer (CX-310-700) Objectives
Sun Certified Ajax Developer (CX-310-700)
Section 1 - JavaScript Fundamentals
* Objective 1.1Create JavaScript applications that use standard (ECMAScript 262 v3) language elements for object-based programming; including, creating objects, using the ‘new’ operator, adding and accessing members, creating and executing methods. Describe the effects of modifying the prototype object of constructor functions.* Objective 1.2Create JavaScript applications that use standard language elements for functional programming; including, creating named and anonymous functions, using closures, understanding parameter passing semantics, understanding the variable scoping rules, and using the ‘apply’ and ‘call’ functions.* Objective 1.3Create JavaScript applications that use pseudo-classical and prototypal inheritance patterns; including, creating constructor functions, creating instance methods using the constructor prototype, using closures, and using delegation and composition as alternatives to class-based inheritance.* Objective 1.4Describe how to transform JavaScript objects and data structures to and from string format via the JavaScript Object Notation (JSON, see http://www.json.org/). Create JavaScript applications that apply this knowledge and uses the Dojo-based JSON facilities.
Section 2 - DOM Fundamentals
* Objective 2.1Create JavaScript applications that use standard APIs (from the W3C levels 1 and 2 DOM specifications) to access document object model (DOM) elements of the HTML page.* Objective 2.2Create JavaScript applications that use standard APIs (from the W3C levels 1 and 2 DOM specifications) to traverse DOM nodes of the HTML page. Describe the issues with the standard DOM traversal APIs and cross-browser support.* Objective 2.3Create JavaScript applications that use standard APIs (from the W3C level 2 DOM specification) to manipulate the DOM structure of the HTML page.* Objective 2.4Create JavaScript applications that use standard APIs (from the W3C level 2 DOM specification) to register and handle events on the DOM structure of the HTML page. Describe the issues with the standard DOM events APIs and cross-browser support.
Section 3 - Ajax Fundamentals
* Objective 3.1Create JavaScript applications that use ad-hoc browser support for creating an asynchronous HTTP request to a web server; including, the de-facto standard APIs on the XMLHttpRequest (XHR) class.* Objective 3.2Describe the life cycle of an Ajax request using the de-facto standard APIs on the XMLHttpRequest class.* Objective 3.3Create JavaScript code that handles Ajax requests using the de-facto standard APIs on the XMLHttpRequest class; including, processing the response as text, XML, JSON, and raw JavaScript code.
Section 4 - The Dojo Framework
* Objective 4.1Describe why it is important to use a high-level JavaScript framework, such as Dojo, including issues around cross-browser support, incomplete and awkward standard DOM APIs, ease of development, and so on.* Objective 4.2Create JavaScript code to select DOM elements using Dojo’s selector functions, byId and query, including querying by common CSS selector syntax.* Objective 4.3Create Rich Internet Applications (RIAs) using Dojo’s Base and Core APIs, including support for DOM traversal and manipulation, browser detection, and additional functional programming facilities built into the Dojo NodeList APIs.* Objective 4.4Create RIAs that take advantage of the message-based and event-driven programming styles that are facilitated by Dojo’s event and message communication APIs, including using the dojo.connect and dojo.subscribe functions.* Objective 4.5Create RIAs that make asynchronous Ajax requests to the server using Dojo’s XHR APIs, including applying Deferreds and chaining Ajax event handlers.* Objective 4.6Create RIAs that make use of Dojo’s object-oriented programming APIs, including the dojo.declare, dojo.extend, and dojo.mixin functions; including how to mimic single, multiple, and mixin class inheritance; and including the object life cycle methods.* Objective 4.7Create RIAs that make use of Dojo’s data programming APIs, including the Identity, Read, Notification, and Write interfaces; including a few simple implementations of these interfaces (ItemFileReadStore and ItemFileWriteStore); and including the semantics of asynchronous behavior, such as fetch.
Section 5 - The Dojo Widgets
* Objective 5.1Create RIAs that make use of Dojo’s widget APIs (called “dijits”), including creating dijits defined in HTML markup or in JavaScript, including use of the dijit life cycle methods, and including knowing how to inject parameters into templated dijits.* Objective 5.2Create RIAs that make use of Dojo’s basic application dijits, including major container dijits and these specific dijits: Tree, Dialog, ProgressBar, and Tooltip.* Objective 5.3Create RIAs that make use of Dojo’s form dijits, including all standard HTML widget replacements and these specific dijits: ValidationTextBox. ComboBox, and FilteringSelect.* Objective 5.4Create RIAs that make use of Dojo’s dijit building APIs to create new UI widgets, including creating a templated dijit, and including using existing Dojo classes and mixins to create new dijits.
Section 6 - Programming Practices and Patterns
* Objective 6.1Create a secure RIA by applying security considerations of using Ajax, JSON, and other RIA technologies. Describe the security risks of an Ajax-enabled web application. Describe or apply solutions to these security risks in you client-side code.* Objective 6.2Create a well-designed RIA using common client-side design patterns, including describing and applying unobtrusive JavaScript techniques and including common web UI design patterns.* Objective 6.3Create RIAs that communicate with web servers using Java-based, server-side technologies such as Servlets, JavaServer Pages, the JSON Java APIs to handle both page-level and Ajax-level HTTP requests. Describe techniques for augmenting the HTTP response using compression, minimization, and cache-prevention.* Objective 6.4Describe common gotchas in client-side programming, such as issues with the DOCTYPE, resource caching, and CSS quirks. Describe how to debug RIA client-side code using browser environments such as Firebug and IE’s Developer Toolbar. Describe techniques for unit testing client-side coding using Dojo’s DOH facility.
Section 1 - JavaScript Fundamentals
* Objective 1.1Create JavaScript applications that use standard (ECMAScript 262 v3) language elements for object-based programming; including, creating objects, using the ‘new’ operator, adding and accessing members, creating and executing methods. Describe the effects of modifying the prototype object of constructor functions.* Objective 1.2Create JavaScript applications that use standard language elements for functional programming; including, creating named and anonymous functions, using closures, understanding parameter passing semantics, understanding the variable scoping rules, and using the ‘apply’ and ‘call’ functions.* Objective 1.3Create JavaScript applications that use pseudo-classical and prototypal inheritance patterns; including, creating constructor functions, creating instance methods using the constructor prototype, using closures, and using delegation and composition as alternatives to class-based inheritance.* Objective 1.4Describe how to transform JavaScript objects and data structures to and from string format via the JavaScript Object Notation (JSON, see http://www.json.org/). Create JavaScript applications that apply this knowledge and uses the Dojo-based JSON facilities.
Section 2 - DOM Fundamentals
* Objective 2.1Create JavaScript applications that use standard APIs (from the W3C levels 1 and 2 DOM specifications) to access document object model (DOM) elements of the HTML page.* Objective 2.2Create JavaScript applications that use standard APIs (from the W3C levels 1 and 2 DOM specifications) to traverse DOM nodes of the HTML page. Describe the issues with the standard DOM traversal APIs and cross-browser support.* Objective 2.3Create JavaScript applications that use standard APIs (from the W3C level 2 DOM specification) to manipulate the DOM structure of the HTML page.* Objective 2.4Create JavaScript applications that use standard APIs (from the W3C level 2 DOM specification) to register and handle events on the DOM structure of the HTML page. Describe the issues with the standard DOM events APIs and cross-browser support.
Section 3 - Ajax Fundamentals
* Objective 3.1Create JavaScript applications that use ad-hoc browser support for creating an asynchronous HTTP request to a web server; including, the de-facto standard APIs on the XMLHttpRequest (XHR) class.* Objective 3.2Describe the life cycle of an Ajax request using the de-facto standard APIs on the XMLHttpRequest class.* Objective 3.3Create JavaScript code that handles Ajax requests using the de-facto standard APIs on the XMLHttpRequest class; including, processing the response as text, XML, JSON, and raw JavaScript code.
Section 4 - The Dojo Framework
* Objective 4.1Describe why it is important to use a high-level JavaScript framework, such as Dojo, including issues around cross-browser support, incomplete and awkward standard DOM APIs, ease of development, and so on.* Objective 4.2Create JavaScript code to select DOM elements using Dojo’s selector functions, byId and query, including querying by common CSS selector syntax.* Objective 4.3Create Rich Internet Applications (RIAs) using Dojo’s Base and Core APIs, including support for DOM traversal and manipulation, browser detection, and additional functional programming facilities built into the Dojo NodeList APIs.* Objective 4.4Create RIAs that take advantage of the message-based and event-driven programming styles that are facilitated by Dojo’s event and message communication APIs, including using the dojo.connect and dojo.subscribe functions.* Objective 4.5Create RIAs that make asynchronous Ajax requests to the server using Dojo’s XHR APIs, including applying Deferreds and chaining Ajax event handlers.* Objective 4.6Create RIAs that make use of Dojo’s object-oriented programming APIs, including the dojo.declare, dojo.extend, and dojo.mixin functions; including how to mimic single, multiple, and mixin class inheritance; and including the object life cycle methods.* Objective 4.7Create RIAs that make use of Dojo’s data programming APIs, including the Identity, Read, Notification, and Write interfaces; including a few simple implementations of these interfaces (ItemFileReadStore and ItemFileWriteStore); and including the semantics of asynchronous behavior, such as fetch.
Section 5 - The Dojo Widgets
* Objective 5.1Create RIAs that make use of Dojo’s widget APIs (called “dijits”), including creating dijits defined in HTML markup or in JavaScript, including use of the dijit life cycle methods, and including knowing how to inject parameters into templated dijits.* Objective 5.2Create RIAs that make use of Dojo’s basic application dijits, including major container dijits and these specific dijits: Tree, Dialog, ProgressBar, and Tooltip.* Objective 5.3Create RIAs that make use of Dojo’s form dijits, including all standard HTML widget replacements and these specific dijits: ValidationTextBox. ComboBox, and FilteringSelect.* Objective 5.4Create RIAs that make use of Dojo’s dijit building APIs to create new UI widgets, including creating a templated dijit, and including using existing Dojo classes and mixins to create new dijits.
Section 6 - Programming Practices and Patterns
* Objective 6.1Create a secure RIA by applying security considerations of using Ajax, JSON, and other RIA technologies. Describe the security risks of an Ajax-enabled web application. Describe or apply solutions to these security risks in you client-side code.* Objective 6.2Create a well-designed RIA using common client-side design patterns, including describing and applying unobtrusive JavaScript techniques and including common web UI design patterns.* Objective 6.3Create RIAs that communicate with web servers using Java-based, server-side technologies such as Servlets, JavaServer Pages, the JSON Java APIs to handle both page-level and Ajax-level HTTP requests. Describe techniques for augmenting the HTTP response using compression, minimization, and cache-prevention.* Objective 6.4Describe common gotchas in client-side programming, such as issues with the DOCTYPE, resource caching, and CSS quirks. Describe how to debug RIA client-side code using browser environments such as Firebug and IE’s Developer Toolbar. Describe techniques for unit testing client-side coding using Dojo’s DOH facility.
Subscribe to:
Posts (Atom)
Posts
