tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: Tomcat-Lite update
Date Sat, 07 Nov 2009 16:27:42 GMT
On Sat, Nov 7, 2009 at 1:25 AM, Henri Gomez <henri.gomez@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 <costin@gmail.com>:
> > On Fri, Nov 6, 2009 at 12:19 PM, Tim Funk <funkman@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message