On Sat, Nov 7, 2009 at 1:25 AM, Henri Gomez <henri.go...@gmail.com> wrote:
> And what about some sort of OSGI glue Thanks for volunteering :-). Note that my goal is to _remove_ any framework feature from tomcat-lite - leave just http and services, no config file or class loading. The current 'integration' interface seems to be enough for spring - feel free to add hooks/listeners for any other framework, but no direct dependency. > and Maven as build tool ? > > Well, you know my opinion on Maven. However - I'm now using ant-ivy for all downloads, and use a pom.xml file to declare the dependencies ( ant-ivy can use either its format or pom ). I also added the 'compile' section - and it seems to at least compile and test. I'm not planning to maintain or use it - but if other people want to use mvn I have no problem as long as build.xml and eclipse .classpath keep working. Costin > 2009/11/6 Costin Manolache <cos...@gmail.com>: > > On Fri, Nov 6, 2009 at 12:19 PM, Tim Funk <funk...@apache.org> wrote: > > > >> I am intrigued by the idea and have similar constraints (kids+job). > >> > >> My longer term interest in lite was a simpler deployment and moving > config > >> into scripting and out of xml. (But this was more dream due to time > >> requirements) > >> > > > > Yes, tomcat-lite should still be able to run servlets - but all the > > 'framework' from the servlet API will be out of scope. > > Tomcat-lite won't create or configure servlets for you, won't have class > > loaders or process annotations. That would be > > the job of whatever DI framework you chose - or just plain java or > > scripting. > > > > It will also not have declarative authentication - instead should have > > filters implementing auth schemes beyond what's possible > > now - for example OpenID. > > > > IMO the servlet spec - 10 years ago - was a great answer to 'how to I > write > > web applications in java'. Then the J2EE and framework > > stuff got added and added. The whole philosophy is to take away control > from > > application developer and have the framework > > provide it ( typically with a 'lowest common' flavor ). > > > > There are plenty of good DI frameworks - spring, guice, various OSGI > > implementations - that do a better job configuring objects or > > handling class loading. > > > > I think it's much better to focus on HTTP-related features. It is also a > > tractable project for people with jobs and kids, and I think > > it would be a better value for both beginners and advanced users. > > > > > > > > > >> > >> As an aside, I am wondering if the long term effect to simplification > will > >> break things like the security manager. And with the capabilities we see > in > >> VM's today - is it better to just ignore the security manager and just > tell > >> people to use an isolated VM if they wish to lock things down. Is there > a > >> good reason to use a security manager today? (This might be a survey > >> question for the user list) > >> > >> > > The applet-style security manager is history. I doubt anyone is using it > - > > or is using it correctly - on server side. It was a dead end anyways > > without good isolation and resource limitting. > > > > Isolated processes and/or isolated OS instances seems to be a much better > > approach for anyone who really needs to run untrusted code. > > > > That's one of the reasons for the proxy focus - I want at some point to > have > > tomcat-lite run a single context per process, and proxy/load > > balance requests. > > > > > > Costin > > > > > > > >> -Tim > >> > >> > >> Costin Manolache wrote: > >> > >>> Hi, > >>> > >>> Tomcat-Lite was started few years ago as an effort to produce a > smaller, > >>> cleaner version of tomcat. Unfortunately > >>> it didn't get lots of development time - I was very busy at work ( and > at > >>> home - 2 kids now ), and it didn't > >>> seem to be in a state where other people would start using it and > >>> contribute. > >>> > >> <SNIP> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
