On Thu, 21 Feb 2002, Remy Maucherat wrote: > > Because there is not 'a single ( or only ) good way to start tomcat'. > > > > If doing a JNI call works and is a good solution, why reinventing the > > wheel ? The daemon requires using an init()-like method and a certain > > architecture - which the other solution doesn't. > > ? > I wonder what prevents you from having an empty init method, and then doing > whatever JNI calls you want suring start.
Nothing - that's what I'm saying, both are good solutions and we shouldn't exclude one because the other does the same thing. If you start a process that does use the init() API to get all resources, and you are using the daemon to start it - that's probably a perfect solution. If you start a process that doesn't fit this model, or you want to use a different starter, or if you just want to explicitely call setUid based on some parameters inside server.xml ( and not in the wrapper properties ) or even set it conditionally or anything else - a JNI call is a better solution. ( except that 'better' than 'perfect' doesn't make sense :-). > Don't go on a rant just because the interface has an init method, and > vaguely implies how some of the design of the server should be (and also of > course because it's an interface), please ;-) > I'm surprised you're not pushing to make it an abstract class, BTW. :-) I'm not even saying that init() is bad - it's a clever idea. I was just saying it's not the only solution and in some cases you may want more control over when and to what user id you change your process to. What Patrick proposed initially with a simple JNI call is a valid solution ( and maybe more flexible ). BTW: I don't like 'hairy' interfaces that will never have more than a single implementation anyway ( because too much depend on the actual Base class behavior ), and where everyone will extend the Base class anyway. For Deamon - 4 methods is not too much, I love what's clean and simple. I don't like the 4 fail methods in DeamonController, I think DaemonContext should be a real class, DeamonListener needs a pair DeamonEvent and some methods, and so on. If the JSR is going to fail ( or if we decide to not try to implement whatever they release, if they do release it ), then I think we should discuss and review some of the API details - now we're not going to have any nasty 'expert lead' and we can do a real open source Daemon ( eventually with the contribution of the wrapper authors, who are pretty good 'experts' ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
