tomcat apache and ALL their friends
Could someone please explain to me, I'm currently just a bit confused, why tomcat is now is multiple peices? Also, what peices do I really need to have? Why does it feel the need to install what seems like EVERY java or java-like package? Does this new scheme require going to apache2 to make it work since there is not a libapache-mod-jk that I can find? Sorry I've not been keeping up on the world of Debian java. I really appreciate any information anyone can forward along. J. R. Westmoreland -- J.R. Westmoreland (W7JR) E-mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tomcat apache and ALL their friends
On Thu, 2003-10-09 at 11:19, J. R. Westmoreland wrote: > Could someone please explain to me, I'm currently just a bit confused, why tomcat is > now is multiple peices? > Also, what peices do I really need to have? Why does it feel the need to install > what seems like EVERY java or java-like package? 'apt-get install tomcat4' should take care of all that, no? > Does this new scheme require going to apache2 to make it work since there is not a > libapache-mod-jk that I can find? http://lists.debian.org/debian-java/2003/debian-java-200308/msg00018.html Apparently, tomcat-connectors will take care of this, though it's still not in sid, as far as I can tell. > > J. R. Westmoreland > > > -- > J.R. Westmoreland (W7JR) > E-mail: [EMAIL PROTECTED] -- Michael R Head <[EMAIL PROTECTED]> http://suppressingfire.org/~burner/gpg.key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
On Wed, 2003-10-08 at 05:11, Daniel Bonniot wrote: > 1) Necessity for findjava > > I think Jan explained this well in his last message. Package A might > work with kaffe or gij but not sablevm, while package B works with gij > or sablevm but not kaffe. Alternatives cannot handle this situation. > Findjava is the tool that allow the startup scripts of A and B to > declare this fact, while being abstract over binary locations. > Furthermore, one can invent more abstract tags to pass to finjava, like > 'awt', 'server' or whatever. Ok, I begin to see the motivation. Findjava overrides (replaces) the alternatives mechanism because the proper "alternative" for a given java app may vary from application to application. Certain apps that know they can run on certain free VMs may take advantage of certain specific features and so forth and therefore want a common way to search for those apps locations. This seems like a reasonable motivation. However, my concern would be that these tunings can become so app <--> vm specific that findjava does not really support their needs or contains elaborate tunings specific to a single app/vm relationship. It seems more straightforward to me to have the "for java in kaffe, sable, foo, bar" logic reside in the kick-off script for the actual app that knows it wants to do special free VM oriented things. For instance, if the Tomcat maintainer decides that compiling certain baseline classes with GCJ before running the main system with GIJ is a good idea then I can't see that findjava will elegantly accomodate that. The idea itself may be sound but probably doesn't belong in a common package and actually probably belongs in something like tomcat-gcj-booster.deb or somesuch. All things considered, I think that my preference is to have each VM provide some Debian-specific tightened up version of $JAVA_HOME that we specify in java-policy and then have $JAVA_HOME be managed by alternatives. Therefore, /usr/lib/javahome will be an alternative that points into a set of directories provided by some VM that looks and feels like a Sun style JAVA_HOME. That's just me but I think its the sanest option that will get the most things running the quickest. > 2) Independence of the JVM packages > > That's Ean's point. Each JVM has its own command line arguments, so code > is needed to translate a standardized set of command line arguments to > the JVM own format. We should not put this translation code in a common > package, because then each maintainer will need to update it from time > to time, and it will be a mess. Yes. That is where I'm at. > Ean wrote: Nope, not me. -- _ Ean Schuessler [EMAIL PROTECTED] Chief Technology Officer 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
Hi Jan, hello Ricky, Jan Schulz wrote: Hello Ricky, Wednesday, October 8, 2003, 5:56:22 PM, you wrote: Well, if the Debian Java policy were modified so that the command line were rigorously defined (basically take the output of java -help from the Sun JVM or elsewhere) I'm waiting for the screams... /me screams: not the same discussion again! ;) it's been a few weeks of hard work (and fun) to convince Jan to drop too simplifying approaches (like 'why don't we make a debian policy what java command line options should be') from the java policy proposals, and work out something more flexible, which is his findjava scheme. the bottom line is: sun doesn't care about debian. No matter what debian decides, even if it's based on java 1.4.2, it won't prevent Sun from breaking that 'interface' in, say, 1.5. They have a history of inconsistency both with the synopsis and the semantics of their java command's options between the releases. And even if one agrees on a policy that would necessarily have to specify some command line options that are not in some release of JDK, debian wouldn't be allowed to distribute the modified source of the java script, AFAIK, so we would be back to square one in 6 months. And that's just the problems with Sun's implementation, I could go on ranting about others for a while, too. But just read the thread ;) The alternatives system works fine for sensible-editor, where you just specify a file on the /usr/bin/java has to garantee even much more: that the commandlien interface is the same all over, that the JVM is able to run *all* code, which is thrown at it. OYu can't do that with the variety of JVMs, which are available on debian. For example all free JVMs lack the ability to run swing code or (AFAIR) the java-1.4 NIO code. Exactly. There is huge difference between managing application that 'do one specific thing' and managing a java runtime. You can't guerantee that a piece of code you supply to /usr/bin/java will also run on it. In part because of the incomplete state the free VMs are in, but in part also because of the miserable quality of code in some applications, that depend on a particular undocumented mis-feature of some specific version of Sun's offer to run, despite Sun telling people to program to the API. Currently, for example, the Xerces-J team has got a bug filed in their apache bugtracking system, with a ton of duplicate bug entries, because someone checked in some code that depends on an undocumented feature of some sun.* class to look up something about Character Encodings. Unfortunately, the Xerces J developers don't want to lose that 'feature' so the miserable code will stay in, preventing the next release of Xerces-J from being buildable on any free VM. Of course they could also use ICU4J, or ICU4JNI, or java.nio from java 1.4, but the responsible developers seem to want to have the feature on all platforms, which for them means using undocumented classes from Sun, that even Sun tells them to avoid. And of course it's far from running on all platforms. ;) Read the threads for more examples of 'unportable java code' in other projects. ;) I don't see why sensible-java, or just 'java' couldn't have a standard interface, with things like java -classpath BLAH -bootclasspath BLAH etc. Isn't that Becuas ethe altwernative system could garantee the 'backend', like core classes and so on. Things like -bootclasspath are only used by broken by design applications, anyway. It's -X*bootclasspath nowadays with Sun's VM, and it's there for a single reason: debugging. Applications have no buisiness replacing classes from the core libraries. This seems to negate some of the reasons you gave, other than 'a future VM might not do this'. All of them try, but there is no 'official' interface and there isn't any way to be *sure*, that this stays the 'standard interface of sun JVMs'. I would also be happy, if I could say: here, java has to take this arguments and it must resultin this-and-that. But this will be *really* confusing, when future sun java versions changes this interface. And they have a long record of doing so in the past. Beside, that doesn't buy you much, except knowing how to pass a few arguments around. Most of time, when an application doesn't run, it's not because someone forgot to set -Xmx128M, but because some amateur programmer checked in some code that uses sun.* classes, and sun changed their internals in the meantime. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
Ean Schuessler wrote: On Wed, 2003-10-08 at 05:11, Daniel Bonniot wrote: 1) Necessity for findjava I think Jan explained this well in his last message. Package A might work with kaffe or gij but not sablevm, while package B works with gij or sablevm but not kaffe. Alternatives cannot handle this situation. Findjava is the tool that allow the startup scripts of A and B to declare this fact, while being abstract over binary locations. Furthermore, one can invent more abstract tags to pass to finjava, like 'awt', 'server' or whatever. Ok, I begin to see the motivation. Findjava overrides (replaces) the alternatives mechanism because the proper "alternative" for a given java app may vary from application to application. Certain apps that know they can run on certain free VMs may take advantage of certain specific features and so forth and therefore want a common way to search for those apps locations. Turn 'proper "alternative"' into 'working "alternative"' and you've got the original motivation ;) This seems like a reasonable motivation. However, my concern would be that these tunings can become so app <--> vm specific that findjava does not really support their needs or contains elaborate tunings specific to a single app/vm relationship. It seems more straightforward to me to have the "for java in kaffe, sable, foo, bar" logic reside in the kick-off script for the actual app that knows it wants to do special free VM oriented things. the way I understood it, it has little to do with specific tunings, and more with giving the application packager a simple, common way to tell the user which VMs will work with the package, while at the same time giving the user some choice, and allowing him to overwrite the choice the packager made. For example, it seems to be impossible for a non-root user, to overwrite the java alternative, whereas the proposed scheme allows the user to specify a different (maybe even working ;) jvm that he one that comes up on top of the alternative system. Given that currently some applications may run with some VMs, but not with others, and not on all platforms, findjava seems like a good compromise to me, which takes the idea of alternatives system, and extends it to be more flexible to be able to cope with current VM situation, i.e. debug everywhere ;) For instance, if the Tomcat maintainer decides that compiling certain baseline classes with GCJ before running the main system with GIJ is a good idea then I can't see that findjava will elegantly accomodate that. Wouldn't specifying gij as the only VM in the findjava setup file that can run the gcj-ed tomcat be enough? You certainly wouldn't want to recompile tomcat with gcj on every invocation? ;) All things considered, I think that my preference is to have each VM provide some Debian-specific tightened up version of $JAVA_HOME that we specify in java-policy and then have $JAVA_HOME be managed by alternatives. Therefore, /usr/lib/javahome will be an alternative that points into a set of directories provided by some VM that looks and feels like a Sun style JAVA_HOME. That's just me but I think its the sanest option that will get the most things running the quickest. The trouble with JAVA_HOME is that even if debian specifies it, hardly any java application developer would be bothered to follow debian's specification, instead of whatever ad-hoc pseudo-standard de-jour JAVA_HOME seems to ben in whatever the current JVM release on the developer's target/developement platform is. From my experience with dealing with open source java developers, to most of them JAVA_HOME is like crack: once they get hooked on accessing sun's internals directly, it's very hard to get them off the quick fix. While kaffe now follows a more jre like file layout, some things will fail nevertheless (like code trying to access tools.jar in order to use Sun's javac, a classical ant, or tomcat fallacy). Code that relies on JAVA_HOME is VM dependant by design, and runs on free VMs by pure chance. That it often runs nevertheless is mostly the fruit of hard work trying to find ways to work around, ahem, sloppy programming ;) So I'm quite opposed to debian trying to standardise/faciliate something that is bad practice. Instead, it would be, in my opinion, better to teach the open source java developers to avoid using Sun's internals in their code. Both debian-java-home and findjava are attempts to deal with the same problem. But debian-java-home doesn't do much good: it adds some more burden on package maintainers, giving developers some hope that their apps may run on the VMs, if they use JAVA_HOME at all. But it's not giving users the security that a particular java application they installed will actually run on their system. Findjava, on the other hand, doesn't care about java home at all. It is just a mechanism for users and application packagers to come together on a VM-application combination that is supposed to
Bug#212863: finjava: a tentative summary
Hello Dalibor, Replying here, becasue I haven't seen the post from Ean. Thursday, October 9, 2003, 7:17:19 PM, you wrote: > the way I understood it, it has little to do with specific tunings, and > more with giving the application packager a simple, common way to tell > the user which VMs will work with the package, while at the same time > giving the user some choice, and allowing him to overwrite the choice > the packager made. Yes, the tuning is something you get for free. I can't really imagine tuning a java package in a way, that it becomes so VM specific, that a 'findjava' mechnism does not anymore work. I think, if that happens, than it's time to Depends: and use only this 'one-and-only' VM. Or use different starter classes in different packages. On the other hand, I will try to extent the findjava command with all interesting options you might find valuable to add. As I already said, I can imagine a '--mem128' command to allocate 128MB of memory (would be mapped by the sun VMs to '-Xm128m' IIRC). > For example, it seems to be impossible for a non-root user, to overwrite > the java alternative, whereas the proposed scheme allows the user to > specify a different (maybe even working ;) jvm that he one that comes up > on top of the alternative system. There are two systems: one to use a 'preferred VM', which is used, *if* possible. And there is a 'overwrite' mechanism, which is described as 'testing only' in the manpage. >> For instance, if the Tomcat maintainer decides that compiling certain >> baseline classes with GCJ before running the main system with GIJ is a >> good idea then I can't see that findjava will elegantly accomodate that. This would result in a native tomcat, which would not use a 'java bytecode interpreter', but would be a normal app under normal debian policy. And not under the debian policy for java "bytecode" apps. > Wouldn't specifying gij as the only VM in the findjava setup file that > can run the gcj-ed tomcat be enough? You certainly wouldn't want to > recompile tomcat with gcj on every invocation? ;) No, that would result in errors, when the user specifys a 'overwrite VM'. Compiled to native *must* AFAIK run with gcj and not with any other java VM. >>>That's Ean's point. Each JVM has its own command line arguments, so code >>>is needed to translate a standardized set of command line arguments to >>>the JVM own format. We should not put this translation code in a common >>>package, because then each maintainer will need to update it from time >>>to time, and it will be a mess. >> Yes. That is where I'm at. > Could the findjava script then be split apart into VM specific 'plugins' > to do the work? then the VM package maintainers could independently > update 'findjava-kaffe' from 'findjava-sablevm', while keeping the > calling interface for the main 'findjava' script. IMO, the findjava mecanism already does this: You can specify certain internal things via a variable in the java-config-file, which is in turn read, when findjava is called with certain options. For example, this here might end up in a JVM, optimised for server use and allocate 128MB of Heap [please note: the mem thing isn't yet implemented!]: findjava --server --mem128 ibm-java-1.4 sun-java-1.4 kaffe It will try to find the best VM available and try to optimise it. The java-config-file for sun-java-1.4 might look like this: JAVACMD="/usr/lib/j2sdk1.4/bin/java" SERVER="-server" CLIENT="-client" MEM128="-Xm128m" # don't remember what the right options was... MEM256="-Xm256m" Resulting in a outputted command like /usr/lib/j2sdk1.4/bin/java -server -Xm128m Dalibor might add the kaffe equivalent... Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
On Thu, 2003-10-09 at 12:17, Dalibor Topic wrote: > For example, it seems to be impossible for a non-root user, to overwrite > the java alternative, whereas the proposed scheme allows the user to > specify a different (maybe even working ;) jvm that he one that comes up > on top of the alternative system. Given that currently some applications > may run with some VMs, but not with others, and not on all platforms, > findjava seems like a good compromise to me, which takes the idea of > alternatives system, and extends it to be more flexible to be able to > cope with current VM situation, i.e. debug everywhere ;) export JAVA_HOME=/usr/lib/kaffe (not so hard) > The trouble with JAVA_HOME is that even if debian specifies it, hardly > any java application developer would be bothered to follow debian's > specification, instead of whatever ad-hoc pseudo-standard de-jour > JAVA_HOME seems to ben in whatever the current JVM release on the > developer's target/developement platform is. From my experience with > dealing with open source java developers, to most of them JAVA_HOME is > like crack: once they get hooked on accessing sun's internals directly, > it's very hard to get them off the quick fix. > > While kaffe now follows a more jre like file layout, some things will > fail nevertheless (like code trying to access tools.jar in order to use > Sun's javac, a classical ant, or tomcat fallacy). Code that relies on > JAVA_HOME is VM dependant by design, and runs on free VMs by pure > chance. That it often runs nevertheless is mostly the fruit of hard work > trying to find ways to work around, ahem, sloppy programming ;) These issues are orthogonal. The directory structure of a VM that launches an app has no impact on whether it can call Sun internal code or not. It comes down to what the ClassLoaders will find. > So I'm quite opposed to debian trying to standardise/faciliate something > that is bad practice. Instead, it would be, in my opinion, better to > teach the open source java developers to avoid using Sun's internals in > their code. A noble ambition but I don't see us having much influence on the general community of Java authors out there. The JAVA_HOME convention is a reality, crappy as it may be, and many Java applications attempt to use it. Requiring Debian Java VMs to present some semblance of the JAVA_HOME "standard" is going to make more apps run on more VMs for Debian. Dealing with the use of Sun internals is a border case that needs to be addressed seperately for those apps that do so. > Both debian-java-home and findjava are attempts to deal with the same > problem. But debian-java-home doesn't do much good: it adds some more > burden on package maintainers, giving developers some hope that their > apps may run on the VMs, if they use JAVA_HOME at all. But it's not > giving users the security that a particular java application they > installed will actually run on their system. >From that perspective I'm not against the notion of packages being able to specify their own preference for a VM to run against and I'm not against centralizing the logic that finds that VM. > Could the findjava script then be split apart into VM specific 'plugins' > to do the work? then the VM package maintainers could independently > update 'findjava-kaffe' from 'findjava-sablevm', while keeping the > calling interface for the main 'findjava' script. Maybe something like: /etc/findjava/kaffe: JAVA_HOME=/usr/lib/kaffe JAVA_BIN=/usr/lib/kaffe/bin/java BASE_CLASSES=$JAVA_HOME/jre/lib/rt.jar MX=-mx COMMAND_LINE_CLASSPATH=-classpath=$BASE_CLASSES:$CLASSPATH ..etc.. or something like that... or something... but then kaffe would provide /etc/findjava/kaffe as part of its package and findjava would pick it up and invocation time. -- _ Ean Schuessler [EMAIL PROTECTED] Brainfood, Inc. http://www.brainfood.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
In message: <[EMAIL PROTECTED]> Dalibor Topic <[EMAIL PROTECTED]> writes: > >Things like -bootclasspath are only used by broken by design >applications, anyway. It's -X*bootclasspath nowadays with Sun's VM, and >it's there for a single reason: debugging. Applications have no >buisiness replacing classes from the core libraries. In general, I agree... but I'll also say that Sun has no business putting Xerces (of a decidedly old version) into the core libraries. But they do anyway, and if you want to use a recent version of Xerces, you have to go dorking with the bootclasspath. - Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
Hello Dalibor, Thursday, October 9, 2003, 6:34:56 PM, you wrote: >> I'm waiting for the screams... > /me screams: not the same discussion again! ;) Thanks! :) [...big snip, complete ACK...] > Unfortunately, the Xerces J developers don't want to lose that 'feature' > so the miserable code will stay in, preventing the next release of > Xerces-J from being buildable on any free VM. Than I'm particulary happy, that eclipse will lose the internal xerces in the next version :) Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
Hi Ean, thanks for your quick reply! Ean Schuessler wrote: On Thu, 2003-10-09 at 12:17, Dalibor Topic wrote: For example, it seems to be impossible for a non-root user, to overwrite the java alternative, whereas the proposed scheme allows the user to specify a different (maybe even working ;) jvm that he one that comes up on top of the alternative system. Given that currently some applications may run with some VMs, but not with others, and not on all platforms, findjava seems like a good compromise to me, which takes the idea of alternatives system, and extends it to be more flexible to be able to cope with current VM situation, i.e. debug everywhere ;) export JAVA_HOME=/usr/lib/kaffe (not so hard) Which only works for those apps that use JAVA_HOME to find the java executable to run themselves. Not for the others. The trouble with JAVA_HOME is that even if debian specifies it, hardly any java application developer would be bothered to follow debian's specification, instead of whatever ad-hoc pseudo-standard de-jour JAVA_HOME seems to ben in whatever the current JVM release on the developer's target/developement platform is. From my experience with dealing with open source java developers, to most of them JAVA_HOME is like crack: once they get hooked on accessing sun's internals directly, it's very hard to get them off the quick fix. While kaffe now follows a more jre like file layout, some things will fail nevertheless (like code trying to access tools.jar in order to use Sun's javac, a classical ant, or tomcat fallacy). Code that relies on JAVA_HOME is VM dependant by design, and runs on free VMs by pure chance. That it often runs nevertheless is mostly the fruit of hard work trying to find ways to work around, ahem, sloppy programming ;) These issues are orthogonal. The directory structure of a VM that launches an app has no impact on whether it can call Sun internal code or not. It comes down to what the ClassLoaders will find. I've gone over this with Jan, and it seems that most apps use JAVA_HOME for two things: a) access Sun internal code, where having a JAVA_HOME layout doesn't help the free VMs run that code anyway. b) running with a VM that's not in $PATH. Which is what findjava is made for ;) c) avoiding free VMs like kaffe: See http://lists.codehaus.org/pipermail/jcontainer-commits/2003-July/000399.html for example: # Checking for JAVA_HOME is required on *nix due # to some distributions stupidly including kaffe in /usr/bin there providing a JAVA_HOME doesn't help either. d) to work around Cygwin's unix paths vs. Windows paths issues: http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03231.html there providing JAVA_HOME doesn't make sense for debian either. Is there any other use of JAVA_HOME you've seen? Where there is something gained by using JAVA_HOME that a) can not be provided by findjava and at the same time b) is portable through java runtimes? So I'm quite opposed to debian trying to standardise/faciliate something that is bad practice. Instead, it would be, in my opinion, better to teach the open source java developers to avoid using Sun's internals in their code. A noble ambition but I don't see us having much influence on the general community of Java authors out there. The JAVA_HOME convention is a reality, crappy as it may be, and many Java applications attempt to use it. Requiring Debian Java VMs to present some semblance of the JAVA_HOME "standard" is going to make more apps run on more VMs for Debian. I believe that's wishful thinking. The JAVA_HOME variable could be set by findjava script as well, if it would matter that much. But from my experience of wrestling with poorly programmed java applications, most of the stuff uses JAVA_HOME for trivial things, like finding the java binary, or utterly non-portable mess ;) Dealing with the use of Sun internals is a border case that needs to be addressed seperately for those apps that do so. Yep. A pox on their house and all that! ;) Both debian-java-home and findjava are attempts to deal with the same problem. But debian-java-home doesn't do much good: it adds some more burden on package maintainers, giving developers some hope that their apps may run on the VMs, if they use JAVA_HOME at all. But it's not giving users the security that a particular java application they installed will actually run on their system. From that perspective I'm not against the notion of packages being able to specify their own preference for a VM to run against and I'm not against centralizing the logic that finds that VM. Could the findjava script then be split apart into VM specific 'plugins' to do the work? then the VM package maintainers could independently update 'findjava-kaffe' from 'findjava-sablevm', while keeping the calling interface for the main 'findjava' script. Maybe something like: /etc/findjava/kaffe: JAVA_HOME=/usr/lib/kaffe JAVA_BIN=/usr/lib/kaffe/bin/java BAS
Re: findjava is the question, is fixjava the answer?
T. Alexander Popiel wrote: In message: <[EMAIL PROTECTED]> Dalibor Topic <[EMAIL PROTECTED]> writes: Things like -bootclasspath are only used by broken by design applications, anyway. It's -X*bootclasspath nowadays with Sun's VM, and it's there for a single reason: debugging. Applications have no buisiness replacing classes from the core libraries. In general, I agree... but I'll also say that Sun has no business putting Xerces (of a decidedly old version) into the core libraries. But they do anyway, and if you want to use a recent version of Xerces, you have to go dorking with the bootclasspath. Well, yes. But no matter which version they put in, it's always going to have bugs, and be a decidedly old version in a year from now. I thought there was a documented way to replace the parser implementation using system properties? How about using your own class loader to load the parser classes in their own namespace and using those instead? cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
Jan Schulz wrote: Unfortunately, the Xerces J developers don't want to lose that 'feature' so the miserable code will stay in, preventing the next release of Xerces-J from being buildable on any free VM. Than I'm particulary happy, that eclipse will lose the internal xerces in the next version :) What's good for eclipse, seems to be good for other projects, too. eXist is looking for ways to replace Xerces for XML serialization at least (which is where I saw the bug in xerces for the first time). Just shows how, as free java implementations gain momentum, the projects containing broken and unportable java code will suffer, and lose mind share. I see gcj as a major driving factor there. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
Hello Ean, Thursday, October 9, 2003, 7:33:22 AM, you wrote: > For instance, if the Tomcat maintainer decides that compiling certain > baseline classes with GCJ before running the main system with GIJ is a > good idea then I can't see that findjava will elegantly accomodate that. > The idea itself may be sound but probably doesn't belong in a common > package and actually probably belongs in something like > tomcat-gcj-booster.deb or somesuch. True. And this package will depend *only' on gcj and will not touch any java related things like jar files or java bytecode interpreeter. This things will be handled --more or less-- under normal debian policy. > All things considered, I think that my preference is to have each VM > provide some Debian-specific tightened up version of $JAVA_HOME that we > specify in java-policy and then have $JAVA_HOME be managed by > alternatives. IMO: JAVA_HOME is good for three things: * ant, which depends on the java property java.home set and some apps in java.home/bin/* * other apps, which rely on internal things in java.home * uses '$JAVA_HOME/bin/java to start the app The first is done in the 'ant-environment', which specifies a 'kind of' java.home, but the only requirement is 'it runs ant'. The second can't properly be helped in any other way than 'Depends: ' The third can be trivaly helped by patching the startup script, which would probably anyway be needed bvecause of 'free VMs', which are surely not considered (think: internal options) in this startscripts. Did I miss something? Anyway, even if we specify a 'JAVA_HOME' layout, it will not help us with the alternative system. The problem with alternactives are quite different from why a JAVA_HOME layout would be usefull or not. No matter we are using '/usr/bin/java' or '/usr/lib/java-home[/bin/java]', the same problems will show up. We would then need a 'findjavahome' script. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
In message: <[EMAIL PROTECTED]> Dalibor Topic <[EMAIL PROTECTED]> writes: >T. Alexander Popiel wrote: >> In message: <[EMAIL PROTECTED]> >> Dalibor Topic <[EMAIL PROTECTED]> writes: >> >>>Things like -bootclasspath are only used by broken by design >>>applications, anyway. It's -X*bootclasspath nowadays with Sun's VM, and >>>it's there for a single reason: debugging. Applications have no >>>buisiness replacing classes from the core libraries. >> >> >> In general, I agree... but I'll also say that Sun has no business >> putting Xerces (of a decidedly old version) into the core libraries. >> But they do anyway, and if you want to use a recent version of >> Xerces, you have to go dorking with the bootclasspath. > >Well, yes. But no matter which version they put in, it's always going to >have bugs, and be a decidedly old version in a year from now. I thought >there was a documented way to replace the parser implementation using >system properties? How about using your own class loader to load the >parser classes in their own namespace and using those instead? I have not found any documented way of replacing the parser version. Mangling bootclasspath to do it isn't documented, either... but follows from first principles. Given that the code which is having trouble is being run inside both jboss and weblogic, we don't have particularly good control of the classloader (unless we do a whole bunch of platform-specific dinking for each one). The core libraries have no business depending on or including separately distributable packages like xerces... but that's a rant for another day. - Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: findjava is the question, is fixjava the answer?
Hello Dalibor, Thursday, October 9, 2003, 9:12:38 PM, you wrote: > Well, yes. But no matter which version they put in, it's always going to > have bugs, and be a decidedly old version in a year from now. I thought > there was a documented way to replace the parser implementation using > system properties? Just got this: |eclipse -vm c:\java\my14vm\jre\bin\java -vmargs |-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.StandardParserConfiguration |-Djava.endorsed.dirs=c:\eclipse\dev\i0930\eclipse\plugins\org.apache.xerces_4.0.13 |More information on the Endorsed Standards Override Mechanism can be found |at http://java.sun.com/j2se/1.4.2/docs/guide/standards/ [...] |Here are some links to 1.4 XML info to help with your conversion: | http://java.sun.com/j2se/1.4.2/docs/guide/xml/index.html | http://java.sun.com/j2se/1.4.2/docs/guide/xml/jaxp/index.html [...] Seems that eclipse will not replace xerces, but will just switch obver to the JAXP API (=xerces on sun derived). Hopefully they will still try to get XMLpull as the normal XML parser... |[plan item] Remove dependancy on Xerces |https://bugs.eclipse.org/bugs/show_bug.cgi?id=37696 Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
On Thu, 2003-10-09 at 13:46, Dalibor Topic wrote: > Which only works for those apps that use JAVA_HOME to find the java > executable to run themselves. Not for the others. They often use JAVA_HOME to find the executable, the base class libraries, the compiler and jar. Of course, that presents another set of issues with regard to alternatives. If JAVA_HOME points at /usr/lib/kaffe then how can javac = jikes and so forth. I'm not saying that JAVA_HOME kicks ass or is even sane, it is just a widely used convention. > I've gone over this with Jan, and it seems that most apps use JAVA_HOME > for two things: > > a) access Sun internal code, where having a JAVA_HOME layout doesn't > help the free VMs run that code anyway. > > b) running with a VM that's not in $PATH. Which is what findjava is made > for ;) >From that perspective, shouldn't findjava just be /usr/bin/java? > Is there any other use of JAVA_HOME you've seen? Where there is > something gained by using JAVA_HOME that a) can not be provided by > findjava and at the same time b) is portable through java runtimes? Other than what I said earlier, no. > I believe that's wishful thinking. The JAVA_HOME variable could be set > by findjava script as well, if it would matter that much. But from my > experience of wrestling with poorly programmed java applications, most > of the stuff uses JAVA_HOME for trivial things, like finding the java > binary, or utterly non-portable mess ;) It could, if all Debian VMs provide a JAVA_HOME-like structure. > Maybe it would be better to maintain the findjava-vm-binding as a > separate package, so that bugs in one don't force exclusion of the other > from testing? Sensible enough. -- _ Ean Schuessler [EMAIL PROTECTED] Brainfood, Inc. http://www.brainfood.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tomcat apache and ALL their friends
> Sorry I've not been keeping up on the world of Debian java. I never have been into it really, since I needed JDK 1.4 and didn't find anything of how to get it officially. This is why I actually went the non debian way, I guess: Installing JDK and Tomcat manually, not using apt-get, thus being able to run a recent Tomcat on a recent VM. This way, installing java and Tomcat and connecting Apache to Tomcat was quite simple, with no interference with the rest of the system. I can go and send you some instructions if you want to go that way, too. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#212863: finjava: a tentative summary
Hello Ean, Thursday, October 9, 2003, 10:26:10 PM, you wrote: > They often use JAVA_HOME to find the executable, the base class > libraries, The base classes shouldn't matter apart from ant bootclasspath, which is already included in the ant-environment. > the compiler and jar. Both are usebale from ant: jar is replaced by a internal implementation based on zip classes and the compiler can be specified via short names or classfiles. > Of course, that presents another set of > issues with regard to alternatives. If JAVA_HOME points at > /usr/lib/kaffe then how can javac = jikes and so forth. Have a look at the 'ant-environment' in teh proposed policy. > I'm not saying that JAVA_HOME kicks ass or is even sane, it is just a > widely used convention. Yes, and all usecases, which are interesting for debian are IMO done in slighly different, but much more saner ways with the new policy. >>From that perspective, shouldn't findjava just be /usr/bin/java? No. /usr/bin/java is expected to be a JVM, not something,w hich outputs a VM command. USer will use it for things like 'my first java app' and so on. >> Maybe it would be better to maintain the findjava-vm-binding as a >> separate package, so that bugs in one don't force exclusion of the other >> from testing? > Sensible enough. If you would have a look at findjava and how it works, then it would be clear, that this *is* *already* *done* via the java-config-files. It is not as flexible as a 'execjava <_*lots*_ of options> mainClass' with different implemntations, but I can't think of a situation, where so much flexibility is needed. If you look at the java apps in debian, none of them does any JVM specific tuning. findjava is flexible as well, up to a point and I think that this point is *far* above any need of a package. All of you: please read the proposed policy and the scripts, which are mentiond there and also the helper scripts. There is no need to hit each otheres over the head with additional requirements, if much of the work is are already done. :) They are easily getabale by deb http://www.katzien.de/debian/java ./ -> apt-get install new-java-policy Proposed policy: zless /usr/share/doc/new-java-policy/policy.txt.gz Manpages: java-config(1), java-config-file(5), findjava(1), findjavarc(5), dh_java(1), update-java-config(1) And try the scripts: findjava [--server|--client|] kaffe sun-java-1.4 sablevm gij java-config [--all | --contrib |--classpath] $PACKAGE (where $PACKAGE is one of `ls /usr/share/java-config/` dh_java with a debian-dir with package.java and package.jars (see manpage) For the ant-environment, see the java-config-files of kaffe and sun-java-1.4 in /usr/share/java-config. I hope once this is common, I can persuade Stephan to include such things in the Common Debian Build System, so that they can be used like with the 'findjava' script. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
