+1 for doing this. Whenever a deployment event takes place (e.g. a new module is deployed) or a new transport is added to the AxisConfiguration and so on, we can check the list of faulty services and see whether we can redeploy them.
Azeez Currently, the only way to make a faulty service non-faulty is to fix the cause of the fault & restart the server, which is not a good solution. On Wed, Mar 11, 2009 at 8:59 AM, Sameera Jayasoma <[email protected]> wrote: > Hi devs, > > Current behavior of Axis2 does not allows a faulty service to become a > "normal" service. If a service becomes faulty, it remains there forever. > There is no way for a faulty service become a "normal" service, even after > its dependencies are available. > > Axis2 service becomes faulty if, > > the referenced Axis2 module is not available, > the referenced transport is not available, > there are classloading issues, > the services descriptor file has errors in it, etc.. > > For an example, Service X is added as a faulty service because the > referenced module M has not been deployed at that time. But after the module > M is deployed, service X cannot be considered as faulty anymore. Hence the > service X should be deployed as a "normal" service. This kind of scenarios > can occur when we run Axis2 in an OSGi environment. Services and modules can > come as an OSGi bundles and one can't really predict the order of these > bundles. > > I would like to improve the faulty services handling aspect in Axis2 to cope > with these situations. > > Thanks > Sameera > -- Thanks Afkham Azeez Blog: http://afkham.org Developer Portal: http://www.wso2.org WSAS Blog: http://wso2wsas.blogspot.com Company: http://wso2.com GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
