> Remy, > > >And why don't you want to write your own wrapper (I doubt Embedded is > >adapted to your use case anyway), and put it in the Avalon tree ? That's why > >I do with the various Catalina wrappers Slide has, and it doesn't cause any > >problems. > > > >Also, not having separated interfaces and implementations doesn't prevent > >from running under Avalon, it only removes the inter-application security, > >which isn't very useful (unless you have a Java mail server which routinely > >tries to hack your Java web server using its internal Java APIs). > > > OK, I'll just write a wrapper that exposes no methods to other 'blocks' > If we are being asked to use CatalinaService instead of Embedded, then > there were no useful (internally published) methods available anyway. > As such if there are no methods to expose there is no need for *any* > interface/impl separation. Therefore I can go ahead as is with the > currently available Catalina (I guess).
It's not as simple as that. Catalina and CatalinaService both create "standard" Tomcat servers. The Embedded interface OTOH will create a deploy-it-yourself Tomcat; you'll have to define your own config files, and it may not behave like a standard Tomcat. Since I doubt it's what you want anyway, I'd say you should take CatalinaService and extend it (and add an interface to it, of course). Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
