Solution for avoiding RuntimeException/Error of Glassfish deployment

Solution for avoiding RuntimeException/Error of Glassfish deployment 

1.  APIs for a webservice are identified only by the webmethod Name leaving along the parameters. (There is no overloading for WebMethods of a webservice)


For example: 
In providerWebService

@WebMethod

public TreatmentDto[] getTreatments(long npi)

@WebMethod

public TreatmentDto[] getTreatments(long id, long npi)

The container (Glassfish) can providers ONLY ONE getTreatments API, which means that APIs for a webservice are identified only by the webmethod Name leaving along the parameters. 

So, the above code should be:

@WebMethod

public TreatmentDto[] getTreatments(long npi)

@WebMethod

public TreatmentDto[] getPatientTreatments(long id, long npi)

otherwise, Glassfish will throw runtime Exceptions in deployment process.

2. Don't make the Container confused. 
Dependency Injection brings a lot of convenience,  but it also means that you gotta work in the cage established by the container.
For example:

In IProviderWebService.java

@WebMethod

public TreatmentDto[] getTreatments(long npi)

In ProviderWebService.java

@WebMethod

public TreatmentDto[] getTreatments(long id)

Since ProviderWebService implements IProviderWebService, the signature of the interface method and implementation method should be exactly the same. The above code will make the container confuse and throw Exception. (but ID and id are OK).

3. Deploy the frame of webservice first.  A successful Compilation doesn't mean a successful deployment. 

At very first, I implemented all the methods and compiled the whole project successfully, but my deployment failed.

The glassfish threw RuntimeExceptions, but, unlike CompileException, it wouldn't tell me what is wrong. IDE will tell me, for example, line 100 has error, or I can debug to locate the code caused the runtimeException.

To avoid this inconvenience, I deployed the interface frame first, without implement any of them. And then, I separate those method APIs to several parts. After finishing one part of the implementation, I deployed it, and then tested, published, just like the agile process. By doing this, I made sure that my final version was deployable.

4. Well, sometime, you just need to do clean -> build all -> deploy again... cannot tell the reason...

My Deployment Log
http://matrixpp.blogspot.com/2013/03/soap-deployment-log.html