RE: FOP Specialized Classloader
Hi, If I remember correctly (and read the right archive messages) the original trigger was the jdk1.3 specific code for AWT fonts. Suggesting the need to handle jdk version specific issues. There are a number of potential issues. For jdk1.4 I recently discovered they have image IO classes that use JAI in the background. There is also the PDFGraphicsConfiguration class (this has the added problem that both jdk1.4 and pre-jdk1.4 versions cannot be compiled by the same compiler). So there are issues that need to be dealt with, the question then is what is the best way: a runtime classloader solution or a compile time solution. Run time (if it works well) is better for distribution and users. From what I have seen most of the Classloader problems occur due to the classloader not properly implementing something and when classes it loads load other libraries it can get into trouble. It feels to me like a separate project: for example a wrapper that loads the jar, the default jar contains the all the classes for normal use and other jars contain a subset of classes for particular jdk versions, the configuration determines what jar contains classes for particular jdks. But it still needs a place to start. Sorry I can't give a definite yes or no answer. Will it be useful, quite possibly. Will it cause trouble, I don't think so. Is it the best solution, no idea. Hope that helps. Keiron. On Fri, 2002-07-19 at 21:09, Rhett Aultman wrote: 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? -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Rhett, Judging by the deafening silence, I would say you are on your own on this one. You may take heart from the fact that no-one has said Don't! So go for it. If you don't do it, nobody will. However, It would probably be a good idea to send a message to the other Apache Java projects, briefly outlining what you are thinking about. It may be that similar efforts are underway elsewhere. One of the more experienced devops like Keiron may be able to make more informed comments on this. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP Specialized Classloader
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]
RE: FOP Specialized Classloader
Hey, gang. I posted my inital commentary and proposal for a FOP specialized classloader that automatically and transparently resolves JVM versioning and vendor issues (and OS, and just about anything else we want). I posted it a bit over a week ago as an attachment to Bug #10379. Has anyone had the opportunity to read it? Any comments? I'm just curious as to if there is any feedback on the idea. If it's a liked idea, I will have some time to devote to working further on it next week, and so I wanted to see where we stood with it. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Monday, July 01, 2002 9:14 PM To: [EMAIL PROTECTED] Subject: Re: FOP Specialized Classloader: Request for Help #10379 Rhett, The way it seems to work is that the bug remains assigned to fop-dev, and anyone who want to add comments or attachments can go ahead. Consider it assigned to you. Keep the list in touch with what you are doing; think aloud about design issues and ask any specific questions as they arise. Most of us are working on particular areas, so you may not see any immediate responses, but if you keep us aware of what you are doing, folks can jump in with specific suggestions or objections. Don't be afraid to ask specific questions, and to ask them again if the answers aren't clear to you, or are non-existent. The initiative on this one is with you. Peter Rhett Aultman wrote: Done, and I hope I submitted it properly. I think I did. :) I'm happy to have that one set as assigned to me. If anyone else feels like jumping in on this issue, too, that's great. -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP Specialized Classloader: Request for Help (Was:RE: Fop andJDK1.2)
Done, and I hope I submitted it properly. I think I did. :) I'm happy to have that one set as assigned to me. If anyone else feels like jumping in on this issue, too, that's great. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 30, 2002 10:55 AM To: [EMAIL PROTECTED] Subject: Re: FOP Specialized Classloader: Request for Help (Was:RE: Fop andJDK1.2) Rhett, Sorry it has taken me so long to get back to you on this one. In order that this not slip completely through the cracks, please put a request for enhancement (RFE) in Bugzilla. You can pretty much copy your comments from this message into the RFE. If you have had any further thoughts on the matter, generate attachment to the RFE detailing them. If you have used bugzilla before, you will know what I mean. If not, take a look and refer any questions back here or to me. Peter Rhett Aultman wrote: Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] The discussion has thrown up some interesting points, and I hope to see Rhett get involved in this soon. I hope also that the work Rhett is talking about will give us a solid framework for changes to our support framework, both with the JVM and possibly with the frequently changing jars that we bundle. There may be other initiatives happening within Apache on that front. I think a multiplexing classloader would give us a really serious boost with regard to flexibility. This is going to be an extremely important issue not only as JVM versions become more important, but also as the differences between each vendor interpretation of the VM becomes apparrent. By supplying a classloader that can, based on various properties, deduce the correct class to load, we can keep FOP's implementation disentangled from most of these concerns. The actual act of selecting the correct location for loading a class is really not that hard, but a classloader that makes decisions for FOP is something that's going to also need someone with good experience in FOP development. Currently, that person isn't me. I think that maybe if I and someone who's a more core FOP developer could get together in private email we could get a good structure for this classloader hammered out. From there, implementation of it would be pretty easy for me to handle. So, is anyone game? Like I said, I can write it, but if I design this thing in a vacuum, it may not be nearly as good as it could be. -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP Specialized Classloader: Request for Help #10379
Rhett, The way it seems to work is that the bug remains assigned to fop-dev, and anyone who want to add comments or attachments can go ahead. Consider it assigned to you. Keep the list in touch with what you are doing; think aloud about design issues and ask any specific questions as they arise. Most of us are working on particular areas, so you may not see any immediate responses, but if you keep us aware of what you are doing, folks can jump in with specific suggestions or objections. Don't be afraid to ask specific questions, and to ask them again if the answers aren't clear to you, or are non-existent. The initiative on this one is with you. Peter Rhett Aultman wrote: Done, and I hope I submitted it properly. I think I did. :) I'm happy to have that one set as assigned to me. If anyone else feels like jumping in on this issue, too, that's great. -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP Specialized Classloader: Request for Help (Was:RE: Fop andJDK1.2)
Rhett, Sorry it has taken me so long to get back to you on this one. In order that this not slip completely through the cracks, please put a request for enhancement (RFE) in Bugzilla. You can pretty much copy your comments from this message into the RFE. If you have had any further thoughts on the matter, generate attachment to the RFE detailing them. If you have used bugzilla before, you will know what I mean. If not, take a look and refer any questions back here or to me. Peter Rhett Aultman wrote: Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] The discussion has thrown up some interesting points, and I hope to see Rhett get involved in this soon. I hope also that the work Rhett is talking about will give us a solid framework for changes to our support framework, both with the JVM and possibly with the frequently changing jars that we bundle. There may be other initiatives happening within Apache on that front. I think a multiplexing classloader would give us a really serious boost with regard to flexibility. This is going to be an extremely important issue not only as JVM versions become more important, but also as the differences between each vendor interpretation of the VM becomes apparrent. By supplying a classloader that can, based on various properties, deduce the correct class to load, we can keep FOP's implementation disentangled from most of these concerns. The actual act of selecting the correct location for loading a class is really not that hard, but a classloader that makes decisions for FOP is something that's going to also need someone with good experience in FOP development. Currently, that person isn't me. I think that maybe if I and someone who's a more core FOP developer could get together in private email we could get a good structure for this classloader hammered out. From there, implementation of it would be pretty easy for me to handle. So, is anyone game? Like I said, I can write it, but if I design this thing in a vacuum, it may not be nearly as good as it could be. -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
