Develop Reference

Where should Business Delegate & Service Locator reside to not have circular dependency in this case?

I am working with Java 1.7, XDoclet 1.2.3, WildFly 8.2.1.Final, Dynamic Web Module 2.5, EJB 2.1 in Eclipse Luna.
I have an Enterprise Application project named
P001_EAR.
I have a Dynamic Web Project named P001_WAR.
I have a EJB Project named P001_EJB.
I have a EJB Client Project named P001_EJBClient.
I have a Utility Project named P001_SRC.
The P001_SRC contains the data layer, domain objects, business interface, helper classes.
The P001_EJB has Stateless Session EJBs which implements the business interface. It has a reference of P001_SRC.
The P001_EJBClient contains the remote and home interfaces of EJBs. It has a reference of P001_SRC.
The P001_WAR contains web stuff listeners, filters, servlets, JSPs, HTMLs. It has a reference of P001_SRC.
This is a typical scenario:
JSP call Servlet, Servlet call Business Delegate, Business Delegate call EJB (using ServiceLocator), EJB perform business operation.
Question is where to put Business Delegate?
I was thinking of putting them in P001_SRC but Business Delegate needs a reference to P001_EJBClient to perform their actions and that means a circular dependency.
How you would solve this issue?
Also the issue is to where to put the Service Locator? Would it go in the same project as Business Delegate?
Thanks

In a classic J2EE design pattern, the each client module of the EJB would have its own Business Delegate, which knows about the actual EJB. In your scenario, it would be in the WAR (as it's the client of the EJB). Similarly, your Service Locator would reside along with your Business Delegate and provide data about where your EJB is.
But seriously, is this some kind of exercise or school/interview question? Or are we traveling back in time? :-)
If this is for a new application, I would seriously consider moving away from EJB 2.x in favor of EJB 3.x, as it simplifies a lot. You can't even say that you "can't move", as you are already using an application server that supports EJB 3.x.

What is difference Javax.jws and javax.xml.ws

I am new to Java and trying to jump into WebServices. I found two examples somewhere and I am confused with the available options.
Firstly, javax.jws.WebService with annotation seem to work fine, but there is loads of material on javax.xml.ws. It seems javax.jws is newer and there is not much material available about it.
What is the difference between these two approaches?

Web Services Metadata Annotations (JSR 181)
Using annotations from the JSR 181 specification (java.jws.xxx), you can annotate a Web service implementation class or a Web service interface.
e.g. from Deploy JAX-WS Web Services On Tomcat
package com.mkyong.ws;
import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
//Service Endpoint Interface
#WebService
#SOAPBinding(style = Style.RPC)
public interface HelloWorld{
#WebMethod String getHelloWorldAsString();
}
JAX-WS 2.0 Annotations (JSR 224)
The JSR 224 specification defines annotations for JAX-WS 2.0 (javax.xml.ws.xxx).
e.g. from Using SOAP Faults and Exceptions in Java JAX-WS
#WebFault(name="CheckVerifyFault",
targetNamespace="http://www.example.com")
public class CheckVerifyFault extends Exception {
/**
* Java type that goes as soapenv:Fault detail element.
*/
private CheckFaultBean faultInfo;
public CheckVerifyFault(String message, CheckFaultBean faultInfo) {
super(message);
this.faultInfo = faultInfo;
}
public CheckVerifyFault(String message, CheckFaultBean faultInfo,
Throwable cause) {
super(message, cause);
this.faultInfo = faultInfo;
}
public CheckFaultBean getFaultInfo() {
return faultInfo;
}
}
Peer Reynders says:
My guess would be that BEA wanted something NOW to put into Weblogic to compete with the equivalent feature in .NET. (see, developing Web services in WebLogic is just "as easy"). Also the annotations specified in JAX-WS 2.0 (JSR-224) seem to provide you with more control. However JSR-224 does explicitly support/include JSR-181 (JSR-224: 7.10 Annotations Defined by JSR-181).
For a more complete discussion about, see JSR 181: a Java Simplification Request
See also:
Annotations references
JAX-WS annotations reference
JSR 181
JSR 224

These two package namespaces do not define different approaches.
If you're creating services based on the Web, there are two options: SOAP services (AKA Web services) or REST services (AKA RESTful services).
If implementing SOAP services in Java, the way to go is to use the JAX-WS framework. The framework provides tools, such as wsimport and wsgen, and of course an API.
The JAX-WS API includes annotations, classes and interfaces for implementing the code of a SOAP service itself and the code of a service consumer (the client).
Altogether these elements of the JAX-WS API use both javax.xml.ws and javax.jws package namespaces.
Just follow the tutorials or examples to create the services using JAX-WS. Don't worry about which packages do the API elements come from.
But remember to avoid vendor specific API elements. You're more likely to run into these vendor specific elements when using WS-* standards (e.g., WS-Security) beyond WSDL and SOAP.

Annotation Visibility between EJB and Client layer

I am attempting to read method annotations in my web layer that are defined on classes in my EJB3 layer.
The object I am working with is a JPA defined entity on my EJB layer that is being fetched with a local ejb lookup to my client layer. When I attempt to read the annotations on the methods they are missing. It appears that all of the annotations are being stripped off of the objects that are being passed from the EJB layer to the Client layer.
The annotation I would like to read is not one of the EJB or JPA annotations but something to drive the processing of the class on the web tier.
If this is typical behavior of the servers then I can write the process differently, annotating the class was the simplest solution.
Thanks
-Scott

OK, the ease of EJB 3 tripped me up here.
In the client of an EJB app I am not looking at an instance of the Class from the EJB tier but a generated instance based on a generated interface from the EJB layer. Therefore the annotations defined on the EJB layer class are not present in the client layer of the application.

JAX-WS - Service Implementation as a POJO

I was doing some reading up on building a soap service using jax-ws as part of java 6. I read that the operations that can be invoked by a client can be defined in the SEI, or Service Endpoint Interface. These operations can be implemented by a SIB, aka "Service Implementation Bean". The part that troubles me, is that this SIB "can either be a POJO or a Stateless Session EJB" according to page 4 of this book. The same definition applies on wikipedia. However, I read that a POJO (according to wikipedia) is "an ordinary Java Object, not a special object, which does not follow any of the major Java object models, conventions, or frameworks such as EJB". Thus follows my question, how can I know that my SIB is a POJO? Additionally, what is the difference between implementing my web service operations via a POJO or a stateless session EJB?

EJB 3.0 introduced annotations that allow any POJO to become a stateless session bean. Therefore the sentence "[a SIB] can either be a POJO or a Stateless Session EJB" applies to stateless session beans pre-EJB 3.0 (such as EJB 2.1). You can now write your SIB as a POJO - that is, without extending any other class or implementing any special interface that you didn't write yourself. You will still need an EJB container, though, such as WebLogic Server, IBM WAS or jBoss if you want to use EJBs.

In my point of view the biggest advantages for a ejb over POJO distrubution capacities of ejb there is plenty features exists for ejbs like CMP.
The other part any class you writed in java is a POJO in another words if your implemantion is a java class then it is a POJO.
POJO term came out for indicating that there is no need for special class type which is a need for java EE world because there is plenty special classes in java EE.
For one of advantages of ejb over POJO you can read this documentation: http://lass.cs.umass.edu/~shenoy/courses/spring11/lectures/Lec24.pdf

Constructor dependency injection with Servlet 3.0?

Since Servlet 3.0 it is possible to register Servlet instances programmatically with javax.servlet.ServletContext#addServlet. This class has also a createServlet method which analyses some annotations and performs dependency injection. I wonder if I need this method if I don't need the annotation processing. I'd like to have a servlet with a usual constructor to set required dependencies via dependency injection.
#Inject
public MyServlet(SomeDependency sd) { // Constructor
...
}
Questions:
Is it possible to construct a servlet instance "by hand" without createServlet? (new MyServlet())
Is it possible to use the dependency injection mechanism of a Java EE server to perform constructor injection? How to do it? Or is a separate DI framework like Guice required?

The recent Java EE 6 standard now supports dependency injection for servlets, the relevant part is called JSR-299 or CDI. The JSR-299 reference implementation, JBoss weld, can be deployed into servlet containers like Tomcat or Jetty as well if you don't want to use a full Java EE 6 application server like glassfish v3 e.g.
By the way, with an embedded Jetty server you can use its custom API to add preconfigured servlet instances.

Guice does this out of the box without the need for Java EE servers.
http://code.google.com/p/google-guice/wiki/ServletModule