I've come up with a couple more patches that try to address your
concerns:
https://issues.apache.org/jira/secure/attachment/12355259/
GERONIMO-3010-3c.patch
This one eliminates backwards compatibility support for
AnnotationProcessor and eliminates the replaceable aspects of jasper
InstanceManagerFactory, just leaving a static method for obtaining
the InstanceFactory. This is decidedly less flexible than the
previous implementation and now requires jasper to be run in a
container that supplies an InstanceManager. There are still separate
interfaces for InstanceManagers for catalina and jasper. I think
this is a considerably superior design than the next one...
This has 2 interfaces, 1 implementation (in tomcat, there's an unused
impl in jasper, see below).
https://issues.apache.org/jira/secure/attachment/12355273/
GERONIMO-3010-4.patch
In addition, this one combines the InstanceManager interfaces. I
think this is a bad idea because it forces jasper to use an interface
shared with catalina, which the previous patch does not. This makes
catalina marginally more complicated when used as a standalone
container for jasper but makes it possible to use jasper outside
catalina without any catalina classes. Note also that the previous
(3c) patch allows use of tomcat embedded in a container that supplies
its own InstanceManager implementation without pulling in any jasper
classes at runtime.
This has 1 interface, 1 implementation.
Both of these include a jasper DefaultInstanceManager that isn't
used, but could be by a project that wants to install jasper with no
annotation support.
I'd like to explore exactly how jasper creates classloaders and
whether its possible to use class reloading features of modern jvms
to eliminate the need to allow replacing the classloader in the
jasper InstanceManager at runtime. Unfortunately I doubt I'll have
time for this in the next month or so.
On Apr 6, 2007, at 5:03 AM, Remy Maucherat wrote:
David Jencks wrote:
but I won't put it in the org.apache package.
There are not too many solutions to this problem, and
(unfortunately for you, apparently) I think it's the most
appropriate, or least inappropriate if you prefer. I was already
aware it was possible to have one interface in Jasper and implement
it in Catalina, or one interface in Catalina and use it in Jasper,
and it would work ;)
yes, and I prefer 2 interfaces with the possiblity of supplying
separate implementations. This makes catalina's standalone life
slightly more complicated but jasper's life outside catalina simpler
IMO.
- I still don't know if I agree with removing the security checks
out of Catalina, merging checks between filters and servlets, etc
I think that the security checks and related code are really
specific to the tomcat classloader and you shouldn't force them on
containers embedding tomcat that use different classloaders. As
far as uniformizing the code between servlets, filters, and
listeners, I still don't understand the problem. You might well
be right, but I'd really appreciate concrete details on why some
checks are appropriate for servlets and not listeners or filters.
Since all of these objects are only created once (except for
single-thread-model servlets, which have all the checks anyway) I
don't really see why a slight difference in startup speed would
outweigh the simplicity of uniform code and relative ease of
understanding of having the object creation policy in one place.
I don't know for sure about that, I would have to look at what gets
run in each case. Maybe the implementation in the proposed patch is
fine.
I could have missed something, but so far I think what I'm proposing
is OK.
- Class hierarchy for InstanceManager -> meh (although I suppose
it perfectly fits your needs, though ...)
I agree... Geronimo implements its own InstanceManagers for tomcat
and jasper, so we don't have that problem. I'd be perfectly happy
to drop support for AnnotationProcessor entirely, but I kinda
doubt you would like it so much :-)
It does not make any difference, really: if the API changes
significantly, there's no need to keep the old API and provide fake
compatibility, it would not really help IMO.
I was complaining about the 2 interfaces + 1 abstract + 2 impls + 1
factory (maybe I forgot some). This is overengineered (for Tomcat
at least) IMO. Personally, the thing that I would like would be at
most: 1 shared interface, 1 abstract, 1 impl. OTOH, I think I
accept the idea of the InstanceManager interface.
Overall, thanks for the patch, it gives a very good basis for work
(esp if you did test it).
To be honest, this whole stuff may be 6.next material. We'll see.
thanks!
The first decision is to see if the API change is going to be
acceptable in 6.0.x.
Looking forward to your comments...
Rémy
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
