jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Bayern <bay...@essentially.net>
Subject Re: using jjar (was Re: thoughts on new builds (was: Re:[UPDATE]Converting existingtaglibs to use new build))
Date Fri, 13 Jul 2001 02:35:57 GMT
On Thu, 12 Jul 2001, Geir Magnusson Jr. wrote:

> > I think the idea is cool, but there are dangers that make it seem, at
> > first glance, unwieldy.  The runtime behavior of an application could be
> > modified without local action on a user's end, for instance.
> Not if you specify versions specifically - because Velocity 1.1 is
> Velocity 1.1.  If you said Velocity *, then yes, if we in Velocity land
> weren't so good about deprecation :) then you could get into real
> trouble. And that's what happens when you use a classpath, right? :)
> (I think the classpath is evil...)
> > Also, do you have any thoughts about a particular security model?  (E.g.,
> > how to accommodate unsigned jars or to determine what certificates are
> > appropriate?)
> No - that's a good thing to think about.  

The two are related, I think; the thing I was getting at by asking how
much you anticipate occuring at runtime (via a custom classloader) is that
it becomes hard to ensure that an application is "knowable" if it's
affected by things like network availability, or perhaps by a compromised
server somewhere.  I can't imagine setting up a production application,
for instance, that has dependencies this far beyond the production
entity's control.  (However, the classloader might simplify development
and testing... still, without an explicit security model, it feel like too
much would be happening automatically if the classloader automatically
fetched new versions of things.)

I think the idea is rather cool, and it's a novel approach, but I also
think it's very dangerous. :)


View raw message