wrapper-user

[Wrapper-user] Integration methods; something different?

[Andrew D. <and...@hs...>]

I never use WrapperSimpleApp because of its lack of a controlled shutdown, and 
WrapperStartStopApp does not fit my usual pattern. Therefore, I always find 
myself implementing WrapperListener (3rd integration option). The use of this 
interface seems restricted to that of a helper class to launch the service, 
however I often find myself wanting to implement this directly in the service 
class itself.

In the service class main, the class could instantiate itself using arguments 
directly from the .conf file. It could then pass itself to the WrapperManager 
without any arguments, as they are no longer required. The WrapperManager could 
then call start, again without any arguments, to run the service. Of course, 
this would require an additional method for the WrapperManager, and probably a 
new interface (modified WrapperListener). This sort of thing could be 
implemented using existing methods, but you would be passing a lot of arguments 
around for no reason.

The alternative is to create an interface that all my service classes must 
implement, so that a generic WrapperListener implementor can provide a 
controlled startup and shutdown. This can be implemented using the current API, 
but does not seem as flexible.

What I want to avoid is having to create a WrapperListener implementation for 
each service class I create. Not having to use reflection would also be nice...

Am I correct in wanting to do this? Am I missing something obvious? Any 
comments welcome.

Re: [Wrapper-user] Integration methods; something different?

[Leif M. <le...@ta...>]

Andrew Dickson wrote:

>I never use WrapperSimpleApp because of its lack of a controlled shutdown, and 
>WrapperStartStopApp does not fit my usual pattern. Therefore, I always find 
>myself implementing WrapperListener (3rd integration option). The use of this 
>interface seems restricted to that of a helper class to launch the service, 
>however I often find myself wanting to implement this directly in the service 
>class itself.
>  
>
What exactly are you having problems with on Shutdown.   You can do a 
controlled
shutdown with the WrapperSimpleApp class by registering a shutdown 
hook.   This is
a good option as your application will shutdown cleanly even when not 
using the
Wrapper.

The WrapperStartStopApp can be used to execute a second class's main method
when the Wrapper shuts down.   You can easily make use of this by 
creating a new
Shutdown class which has a main method.

I used the 3rd method when I first created the Wrapper.  But once the 
other two methods
were created, I have not even once found it necessary to use method #3 
again.  I am
interested the exact problems you are encountering that make you feel 
you need to use
method #3.   It may be that I need to add additional functionality to 
the first 2 methods
or create a new helper class.   If you, Eric, and Venkatesh are finding 
it necessary to
write your own helper classes then it would make more sense for me to 
include such
a class with the Wrapper.

Cheers,
Leif

[Wrapper-user] Re: Integration methods; something different?

[Andrew D. <and...@hs...>]

Leif Mortenson <leif@...> writes:

> What exactly are you having problems with on Shutdown.   You can do a 
> controlled
> shutdown with the WrapperSimpleApp class by registering a shutdown 
> hook.   This is
> a good option as your application will shutdown cleanly even when not 
> using the
> Wrapper.

Leif, thanks for your feedback. I have not tried a shutdown hook yet. I can 
look into this.

> I used the 3rd method when I first created the Wrapper.  But once the 
> other two methods
> were created, I have not even once found it necessary to use method #3 
> again.  I am
> interested the exact problems you are encountering that make you feel 
> you need to use
> method #3.

When using WrapperSimpleApp, the start method only waits two seconds before 
reporting that "all is fine" to the Wrapper Manager (assuming service has not 
failed already). This generally results in the service manager showing that the 
service has started successfully, yet the service may still stop immediately 
due to an initialisation error. This could be a problem for an inattentive 
system administrator, or a startup script. What I prefer to do is have a 
service wrapper that has a reference to the service application instance, so 
that health checks can be performed during initialisation. Once the service 
itself has reported that "all is fine", then start can return.

I guess some other options are:
1. Have WrapperSimpleApp receive another parameter through the .conf, to set 
the start method wait time. However, this would not be as reliable.
2. Have a wrapper.filter.trigger set to catch a fatal exception and SHUTDOWN 
the Wrapper Manager. I am not sure how this would look to the service manager. 
I would also need to be more careful with my use of exception types in this 
case... :-)

There is always the chance I am making this more complex than it needs to be, 
but it does seem like a gap in functionality. 

If I am missing some other way to do this, please let me know. Also, thanks for 
providing this very useful tool.