Terry's Blog

Manifest.mf Extension-Name: xx.app.audit.als Specification-Version: 1.0.1 Implementation-Version: 1.0.1 Specification-Title: xx.app.audit.als Implementation-Title: xx.app.audit.als Implementation-Vendor: xxx Extension-List: log4j log4j-Extension-Name: apache.log4j log4j-Specification-Version: 1.2.15 log4j-Implementation-Version: 1.2.15 P.S.: remember return should be provided for the last line

Keep in mind these best practices when developing shared Java EE libraries and optional packages: Use shared Java EE Libraries when you want to share one or more Java EE modules (EJBs, Web Applications, Enterprise Applications, or plain Java classes) with multiple Enterprise Applications. If you need to deploy a standalone Java EE module, such as an EJB JAR file, as a shared Java EE library, package the module within an Enterprise Application. Doing so avoids potential URI conflicts, because the library URI of a standalone module is derived from the deployment name. If you choose to deploy a shared Java EE library as a standalone Java EE module, always specify a known deployment name during deployment and use that name as the URI in referencing applications. Use optional packages when multiple Java EE archive files need to share a set of Java classes. If you have a set of classes that must be available to applications in an entire domain, and you do not frequently upda

The following list provides some best practices when programming the JWS file: When you create a document-literal-bare Web Service, use the @WebParam JWS annotation to ensure that all input parameters for all operations of a given Web Service have a unique name. Because of the nature of document-literal-bare Web Services, if you do not explicitly use the @WebParam annotation to specify the name of the input parameters, WebLogic Server creates one for you and run the risk of duplicating the names of the parameters across a Web Service. In general, document-literal-wrapped Web Services are the most interoperable type of Web Service. Use the @WebResult JWS annotation to explicitly set the name of the returned value of an operation, rather than always relying on the hard-coded name return , which is the default name of the returned value if you do not use the @WebResult annotation in your JWS file. From: http://download.oracle.com/docs/cd/E12840_01/wls/docs103/webserv

When deploying your Web Service client you often need to change the endpoint of the service that has been set during the code generation. This short post explains how you can set change it at runtime in the client code. You have two approaches to do that: set the endpoint in the Port using the BindingProvider get the endpoint URL from the WSDL itself at runtime Use the Binding Provider to set the endpoint URL The first approach is to change the BindingProvider.ENDPOINT_ADDRESS_PROPERTY property value of the BindingProvider (Port) using the following code: try { EmployeeServiceService service = new EmployeeServiceService(); EmployeeService port = service.getEmployeeServicePort(); BindingProvider bp = (BindingProvider)port; bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://server1.grallandco.com:8282/HumanRessources/EmployeeServiceService" ); Employee emp = port.getEmployee( 123 ); System