My primary concern with utilizing different source build paths is that it will require
everyone to build from source. I think this could hamper FOP's acceptance, which is
the main reason I didn't support that originally. Additionally, when you think about
it, altering the source build removes only one - of your three- the concern about a
specialized classloader in a webapp/EJB environment. The other two issues remain-
testing on multiple systems and increased complexity.
In all honesty, there isn't a good answer to system dependancies in a system
independant language. Any path we take is going to have some ick to it. I believe we
may be safe in having a specialized classloader even in webapps as long as it is
designed in a careful fashion. I've used specialized classloaders several times in my
webapps without too many problems; however, what if maybe we considered more
flexibility, allowing the dynamic classloader to be switched off in cases where it's
going to be a nuisance?
To be fair, I'm pensive about a lot of this, too, because it's very, very new ground
in general. I just want to help give FOP everything it so richly deserves. If that's
the classloader, I'm here to do it. If it's helping to refine source builds, count me
in.
There haven't been any black balls cast on this, though, so I'm thinking I may
proceed, pending any further commentary in the next day or two.
-----Original Message-----
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]]
Sent: Mon 7/22/2002 2:24 AM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: FOP Specialized Classloader
Rhett,
I've read through your proposal and I end up being -0. Here are some
pros and cons that came to my mind (disclaimer: no scientific research
behind those points):
+ Works around certain problems in an elegant fashion. We can provide
the best code for each JDK-version.
+ Interested parties may be able to restore JDK 1.1 functionality more
easily. It's easier to maintain JDK 1.2 support.
- Working with classloaders may increase the difficulty of embedding FOP
especially in a web or EJB container where a bunch of special
classloaders is already active. Increased difficulty means more
support effort.
- Increased effort necessary to maintain the code over multiple
platforms. All target platforms have to be tested prior to a release.
- Increased time for familiarizing oneself with the code.
The main point that leads to my -0 is my first negative point. The
classloaders won't hurt in standalone usage but could develop into a
PITA when used in a more complex environment. -0 means I won't stand in
the way but I would like the stuff be well tested. Not being a
classloader specialist I only state my concerns about something that has
caused problems in the past.
I appreciate your effort in following down this path and I hope I'm
proven wrong because if this works great this is a very powerful
addition to FOP (and possibly other projects like Batik). Sorry for not
being more positive.
On the other side I keep thinking if improving the build process to
produce JDK-specific jars wouldn't be a better (and less painful)
approach of handling this. Just a thought...
> I'm content being on my own. I just don't want to end up building
> something that nobody wants or needs, which was really why I'd put up a
> proposal and asked for comments. Honestly, the thumbs-up I was looking
> for was from someone like Keiron so that I'd know it was believed that I
> was correctly addressing an issue that needs addressing. The majority of
> the work on the classloader will be pretty easy stuff, and I can even
> take on the "splitting" system-dependant classes into their
> version-specific components and so forth. And write documentation on
> how to do that.
>
> I was just hoping that I could get a word from a higher-up or two that
> there was an interest in this being pursued. That you've suggested I
> go for it is definitely encouraging. Anyone else want to throw in?
> Any +1s, gang?
Cheers,
Jeremias Märki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
