Fooling Javac
So I'm not going to claim this is portable, but shouldn't it be possible to provide a different implementation of java.io.FileSystem that reads files from the current ClassLoader and writes them to a buffer in memory? I'm assuming that javac uses java.io.File (anyone know?), so this would let you compile JSPs without constructing an external environment for them, or writing the source code or class file to the filesystem. The problem is that FileSystem is not public, and the method to get the current one is native, so you'd have to hack the rt.jar to get this to work. But it might be an interesting experiment to see if it even makes a noticeable difference. Aaron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [half-off-topic] Java Compilers
On Thu, 4 Oct 2001, Deacon Marcus wrote: Could you give me url please? http://java.sun.com/ (Go to the search box in the upper right and put in dynamic event listeners. It's the first hit. There's now a new article and an old article - you want the old one.) Aaron
RE: [half-off-topic] Java Compilers
If you haven't seen it already, there's an article on the Swing Connection on creating dynamic event listeners or some such which seems to have been the basis for the Dynamic Proxy support in JDK 1.3. It has source code for generating classes on the fly that implement arbitrary interfaces, including some generic routines for writing useful bits of bytecode. If your goals are limited enough in scope, you may want to skip the source code and just spew out bytecode directly based on the XML file you're reading. Also, I have JDK 1.2 implementation of Dynamic Proxies that you're welcome to look at, based on the aforementioned article. Aaron On Thu, 4 Oct 2001, Deacon Marcus wrote: Hi, From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 04, 2001 2:35 AM To: [EMAIL PROTECTED] Subject: Re: [half-off-topic] Java Compilers Hi, On Thu, 4 Oct 2001, Deacon Marcus wrote: There would be two classes, CompileUnit and CompileContext. First, you create a CompileContext, initialize it with working dir and classpath, then you create CompileUnit, initialize it with CompileContext and a .java file. Then, you can call .prepare() or .compile() to compile the file, and .newInstance() to create an instance or .getClass() to get Class. Or you could use Class.forName(), since in most cases CompileContext's classpath would be active classpath. so you're talking about generating java source code, and compiling it on the fly? Exactly. I'm coding it right now - looks like CompileContext is enough - I'll post when I finish of course. I'm sure you see the similarity to .JSP now. if my interpretation is correct, yes (o: While it may seem basic, having API for this wouldn't hurt. Possible scenario: Supponse, there's some kind of mail server with *extremely* complicated rule-set in form of 200kb+ xml. Why not take it, convert it into .java implementing some interface, convert it to java source with hundreds if not more ifs and cases, and load it as compiled code. What I need: since JDK 1.4b2, tools.jar just isn't what it used to be... so I need some kind of 100% java java compiler. And, I have no idea where to search for one. Of course, there's dozens, but it must be both stable and compatible with JDK 1.1 - 1.4. Short of searching google, which I'm sure you're already doing I cant help you there. What I can suggest though, is for source code generation, a project called Jenesis (http://www.inxar.org) which provides a nice API based on the Java Language spec. Generating source is out of scope of this project. I need it mainly for the complicated configs etc - no point in generating structure out of xml which is then analyzed everytime when you can compile it into bytecode. I'm sure it's possible to do xml-config to java-source transformation in xsl, but I don't like it personally, so I'll leave it to someone else. cheers dim Greetings, deacon Marcus ~ HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting, please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)
Re: Does the beta Tomcat 4 support multiple TLD files in a jar?
On Sat, 19 May 2001, Jayson Falkner wrote: I assume it does. If so what is the correct way to use this functionality? I have been having little luck trying and can't find the answer documented. Here is a little insight on what I was attempting. The JAR has all of the class files in their correct directories along with a TLD in the META-INF directory named exampleTags.tld. exampleTags.tld has the uri element set with the value /exampleTags.tld. ... taglib ... uri/exampleTags.tld/uri /taglib Well, first it shouldn't be just plain uri: taglib taglib-uri/myPRlibrary/taglib-uri taglib-location/WEB-INF/tlds/PRlibrary_1_4.tld/taglib-uri /taglib And second, what are you using for the taglib-location? That's how it would locate the .tld file. If you're not using one, perhaps you need to prefix the URI with META-INF/ since all the TLDs are required to be in the META-INF directory of the packaged JAR. Aaron I am trying the following with a JSP. --- %@ taglib prefix=e uri=/exampleTags.tld % Here is the example tag output: e:example / --- But a servlet exception error message keeps popping up. org.apache.jasper.JasperException: File /exampleTags.tld not found ... Anyone had this before? Advice would be appreciated. Jayson Falkner V.P./CTO, Amberjack Software LLC [EMAIL PROTECTED] www.jspinsider.com
Re: Deployment Descriptor Editor
On Fri, 16 Mar 2001, Remy Maucherat wrote: Is it the same UI that is used in OpenEJB ? Also, can it edit the security constraints ? Sorry, I've been out of touch for a while. Yes, and yes. It has editors for everything in the servlet 2.2 deployment desriptor, including security constraints. For security constraints, you still have to enter the URL pattern manually, but it knows about the available transport guarantees, HTTP methods, and security roles so you just select those from a list. As for OpenEJB, I hadn't updated the version there until tonight, but it is the same tool. So in addition to web app WARs, you can edit EJB JARs including the standard DD and the extensions for JBoss 2.0 and OpenEJB 1.1, and you can edit JCA RARs including the standard DD and the extensions for OpenEJB 1.1. It uses a plugin architecture so there are separate plugins for J2EE 1.2, OpenEJB, JBoss, etc. and you load the plugins you're interested in and then when you open a J2EE archive or directory it loads the data and editor screens for the plugins you've selected (or the ones that care about that archive type, at any rate). I'm wondering if Tomcat won't eventually have a separate custom DD for WARs (like WEB-INF/tomcat-web.xml or whatever), in which case we'd want to create a Tomcat plugin in addition to the standard servlet spec. In any case, I did finally manage a downloadable version, though I'm still working on setting up a box for anonymous CVS 'n stuff. Aaron http://www.mearaworks.com/jedi-1_0b4.zip http://www.mearaworks.com/jedi-1_0b4-src.zip
Deployment Descriptor Editor
I have a GUI for editing deployment descriptors in-place in J2EE archives or directories laid out like archives (so far EJB 1.1 JARs, Servlet 2.2 WARs, JCA 1.0 RARs). It's open-source under the X license, though for the few weeks without a home on the web. I wonder if you'd be interested in including a binary with Tomcat (the 3.x branch for now, since it doesn't support 2.3 yet). If anyone's interested in trying it out, I can send you a copy. Aaron
Re: Tomcat 4 unpacking of WAR files behavior
On Fri, 2 Mar 2001, Craig R. McClanahan wrote: Yes sure. I think the best would be not to unpack the WARs (it's a lot cleaner). +1, as long as we can keep performance reasonable. Well, memory's cheap. You can always just read the whole WAR in. Then you'll get great performance. :) As a middle ground, it probably wouldn't be too horrible to implement a ClassLoader that cached frequently-accessed resources from the WAR. Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
It's always going to be the case that the Avalon and Tomcat releases don't sync up perfectly. How would you feel about making any Tomcat changes necessary to support the Avalon patch, but maintaining the Avalon block itself outside of the main Tomcat 4.0 module? That way the Avalon support could be updated independently for new releases of Avalon *or* Tomcat. Aaron Remy Maucherat wrote: I'm -1 on applying the Avalon patch in the 4.0 tree. The rationale is : - Avalon isn't ready yet. It's still in alpha stage, and I fear there may be API changes in the pipeline. - TC 4.0 should be out before Avalon. If Avalon 3.1 evolves *after* TC 4.0 is released, this would break the wrapper included in TC 4.0 and make it incompatible with the Avalon 3.1 production release, which would more or less force us to do a TC maintenance release. For these reasons, I'd like to see an official Avalon wrapper introduced in Tomcat 4.1, but not in Tomcat 4.0. I also propose to remove the current Avalon wrapper from the Tomcat 4.0 repository, to avoid the maintenance related issues. The 4.1 repository should be recreated very soon, since TC 4.0 has gone back into feature freeze mode (but we want to fix the sealing violation problems reported by many people before). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: The case of the disappearing webapps...
Probably caused by using a URLClassLoader. On Windows, it locks JAR files and never lets go (I've seen this). Also, there was a rumor that it caches JAR files so if you redeploy an updated app with a new JAR file with the same name as the old one it will still use the old one, or something like that. I haven't tried to confirm that part of it. The only solution I've found is to implement a new ClassLoader for JAR files, because if you're very careful with your JarFile objects and streams you can definitely avoid this on Windows. I haven't seen that problem on Linux. Aaron On Fri, 19 Jan 2001, David Weinrich wrote: Ok, I think I have found the problem, and I am guessing the following is happening: 19-Jan-2001 15:10:44 StandardHost[localhost]: Undeploying web application at context path /struts-test 19-Jan-2001 15:10:44 StandardHost[localhost]: Removing expanded directory c:\java\tomcat-4.1\webapps\struts-test * the container is trying to undeploy the application ( hey I didn't even know this happened ;) because it was deployed from a .war file. 19-Jan-2001 15:10:44 HostConfig[localhost] Error undeploying web application at context path /struts-test java.io.IOException: Cannot delete file c:\java\tomcat-4.1\webapps\struts-test\WEB-INF\lib\struts.jar at org.apache.catalina.core.StandardHost.remove(StandardHost.java:794) * Win2k is not allowing the container to delete a library file that it thinks is currently in use ( struts.jar in this case ). 19-Jan-2001 15:11:06 StandardHost[localhost]: Deploying web application at context path /struts-test from URL file:C:\java\tomcat-4.1\webapps\struts-test * catalina finds the struts-test directory and doesn't re-deploy the application from the .war file. If I shutdown, delete the expanded directories, and restart, the .war files deploy normally: 19-Jan-2001 15:56:26 StandardHost[localhost]: Recording expanded app at path /struts-test 19-Jan-2001 15:56:26 StandardHost[localhost]: Deploying web application at context path /struts-upload from URL jar:file:C:\java\tomcat-4.1\webapps\struts-upload.war!/ 19-Jan-2001 15:56:26 StandardHost[localhost]: expand(jar:file:C:\java\tomcat-4.1\webapps\struts-upload.war!/) 19-Jan-2001 15:56:26 StandardHost[localhost]: Proposed directory name: struts-upload ... I will try to dig into this more later tonight/this weekend. Any further hints/ideas would be appreciated :) David Weinrich - 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: [MY_OPINION] Tomcat 3.x
On Mon, 18 Dec 2000, Henri Gomez wrote: The users will decide. Be fair, let them evaluate TC 3.3. Speaking as a user, this doesn't make sense. It's fine to compare two different products, but it doesn't make any sense to compare two different versions of the same product that are undergoing simultaneous release cycles. Especially when you ask the list which you should be looking at, and you get one answer: "V3.3 because the architecture is better and V4 is an unstable rewrite," followed immediately by "V4 because the architecture is better and V3.3 is an unstable rewrite." The immediate reaction to which is, "if the *developers* can't even figure it out, I'm going elsewhere." I'm not saying you should cut off all 3.3 development, I just think it should fork and use a name other than "Tomcat". Maybe "xTomcat". :) Aaron
Re: jboss on tomcat update
For what it's worth... -- Forwarded message -- Date: Mon, 30 Oct 2000 19:03:39 -0500 From: Free Software Foundation [EMAIL PROTECTED] To: Aaron Mulder [EMAIL PROTECTED] Subject: Re: Java, GPL, APL Aaron Mulder wrote: Okay, I've heard too many opinions on the GPL, so I'm taking it to the source. I will discuss this in general terms if it's OK with you. There exist two open-source products. One uses an Apache license. One uses a GPL license. They are complimentary products - the capabilites of both together are greater than that of either alone. They can be run totally independently, communicating over the network, but the performance is not great. They can also be run together, in the same Java VM, and the performance is much better. The GPL product has included some code that configures and launches the APL product. It directly references Java classes (such as the startup class) that are part of the APL product. This is what allows you to run them together within one VM. The APL product does not ever reference the GPL code directly - only through the standard interfaces defined by Sun in one of the javax.* packages. After the startup sequence, the GPL product never refers to the APL code directly at all (essentially, the APL product is a client of the GPL product). So the questions are: 1) Is it legal for the APL product to work with the GPL product through the standard interfaces defined by Sun in the javax.* packages? We suspect yes, since this is a standard and the APL program never reaches "through" those standard interfaces to deal directly with the GPL code. It appears that you combine the APL'ed software with the GPL'ed software to form a larger program. This is not permitted, since the APL is incompatible with the GPL. 2) Is it legal for the GPL product to directly reference APL classes to configure and start the APL product? No, that is not legal, because you are combining the two programs to form a larger program. 2b) If there is a problem with this, is there any way to configure and start the two products in the same VM? Not if they make calls to each other. You'll need to get the license of one or the other changed to a dual license---the disjunction of the GPL and the APL. 3) Would it be appropriate to package the GPL product and "glue code" (startup and configuration for APL product) together, and leave the APL product separate? We believe this is legally the same as distributing them together, and thus, is not permitted. 4) Would it be legal to package everything together, and create one combined download that "out-of-the-box" runs both products together? This is the subject of much debate. That is not permitted since the APL is incompatible with the GPL. So it's not clear whether the phrase "contains or is derived from" would apply to this single unified package. We argue that it definitely does, when you combine them together to form a larger program. -- Bradley M. Kuhn Free Software Foundation | Phone: +1-617-542-5942 59 Temple Place, Suite 330 | Fax: +1-617-542-2652 Boston, MA 02111-1307 USA | Web: http://www.gnu.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jBoss-Dev] Re: jboss on tomcat update
(EVERYONE: Please, PLEASE, leave the threats at the door. Honestly, raising the general level of antagonism is not getting us anywhere!) On Mon, 30 Oct 2000, marc fleury wrote: Aaron the bundling of APIs (JSP, EJB) that don't work together (JSP doesnt rely on EJB, and EJB doesnt rely on JSP) is PURE aggregation. It is useful for the beans. There is never CMD in the aggregate work. I am sorry but the line in the license is extremelly clear (yes specially 2b rickard). Marc, nothing in this entire discussion has convinced me that the GPL is "extremely clear" on anything - in fact, I find that quite the opposite to be true. No matter how many times you state "that is not true" or "the text is clear" it does not convince anyone else of anything. Perhaps you could substantiate your arguments slightly more? You seem to think that containment should be strictly interpreted as "a line of code from program X is placed in program Y". However, that is not clarified anywhere in the GPL. There is nothing in the wording of the license that leads me to believe that "containment" refers to "lines of source code" as opposed to "entire products". What leads you to this conclusion? And once again, the deciding factor is not what Marc Fleury thinks, or even what the jBoss Board thinks, it is what the users, observers, and lawyers think - what the "community" thinks. After all, nowhere in the license does it state that the composition of and/or opinions of the board will never change. Don't you find it just a little bit worrisome that no one who has spoken up from any of the Apache projects believes that jBoss can be legally integrated with Tomcat or Avalon? Even if every single one of them is wrong, don't you think this unanimous opposition from the groups we are trying to work with is going to cause problems with the adoption of the integrated work? Aaron In other words a J2EE server is pure "API together bundled" but I don't see the other API from my code, and I never have to add anything to anyone of them. All CMD work is GPL'ed (MBeans). Same mistake with JMX, it is VERY ignorant to claim linking - GPL. so GPL work does run on windows, because windows is not CMD work of GPL... this is getting tiring... JMX is not CMD work of jboss... marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder |Sent: Monday, October 30, 2000 6:49 AM |To: jBoss Developer |Subject: Re: [jBoss-Dev] Re: jboss on tomcat update | | |On Mon, 30 Oct 2000, Ole Husgaard wrote: | Before we go to such drastic steps as changing the license, | we should find out exactly what is the problem with the | license we have now. I've seen many flames and much hearsay, | and a lot of crying from both sides, but from facts and | valid arguments I have only been able to identify three | "problems": | | 1) jBoss cannot include the Tomcat code and distribute |the combination without breaking the APL license of |Tomcat. | 2) Tomcat cannot include the jBoss code and distribute |the combination without breaking the GPL license of |jBoss. | 3) Someone (forgot who) refuses to add the jBoss code |to their tree because they have a problem with the |GPL license. | | I think we need to add | | 4) It has been debated whether it is legal for jBoss to include | packages such as JMX which are neither GPL nor "safe" | operating system code | | In all three cases my opinion is "So what?". | | We're all entitled to an opinion. | | In the two first cases: These two programs can | easily be distributed seperately. | | I think the usefulness of a J2EE server is dramatically |higher than the usefulness of an EJB server. Thus I think it's |safe to say that it's a "good thing" to be able to integrate |jBoss and Tomcat. If you insist on keeping them separate, you |sacrifice performance (I don't think you could rationally claim |they're totally separate product when you distribute same-VM |integration code that deals with both directly - unless that's |yet another package), distribution (2 packages? How silly is |that?), and market (Let's see, I could have one integrated and |fully-tested product [Weblogic], or two completely separate |products that not even that authors believe can be safely run |together...) | | In the last case: Don't we already have our own | fine CVS tree? | | However, I say again that one of the fundamentals of open source |is that we should be able to share code. When someone puts together a |*really good* package Foo, everyone in the community who could benefit |from Foo should be able to use it and improve it. Isn't that what this is |all about? It does't make any sense to say "You are welcom
Re: [jBoss-Dev] Re: jboss on tomcat update
On Sun, 29 Oct 2000, Dan OConnor wrote: In no way is the choice of license intended to prevent aggregation with Tomcat, nor to the best of my knowledge does the board--or the jBoss community in general--currently believe that this is the result. This sort of opinion is not like source code; we can't compile it and see it run (or not). I'm sorry about that. But there it is. Do you acknowledge that a number of people have a different opinion? If so, do you think their opinions count? That is, will you be happy if everyone on the jBoss board believes that jBoss can be legally integrated with Tomcat, or will you be happy if everyone in the world believes that jBoss can be legally integrated with Tomcat? In my case, it is not a case of what I believe, but what my company's clients believe, and unfortunately they do not see eye to eye with the jBoss board. Does that matter to you? It matters to me, because it matters to the people who decide what I will be paid to work on. :) I think we should do whatever we can to make jBoss universally acceptable. Because I want everyone in the universe to be able to choose to use it, on the basis of its features not on the basis of its license. Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jBoss-Dev] Re: jboss on tomcat update
On Sat, 28 Oct 2000, Jon Stevens wrote: on 10/28/2000 4:06 PM, "marc fleury" [EMAIL PROTECTED] wrote: Indeed if the Avalon guy puts jBoss code in his tree and "contains" our work in his work then yeah.. that needs to be GPL. Bingo. So, this is something that is a major problem for me. This is truly unfortunate. There are definitely ares of code that could be shared - that *should* be shared, such as logging, dynamic proxies, thread pools, and so on. It's too bad that it doesn't happen until a javax package is available... Particularly since those are *not* open source (well, under a much more restrictive license, anyway). On Sat, 28 Oct 2000, marc fleury wrote: |2.b.) You must cause any work that you distribute or publish, that in |whole or in part contains or is derived from the Program or any part |thereof, to be licensed as a whole at no charge to all third parties under |the terms of this License. again, "work that contains the Program" is code that "contains" physically the Program (maybe thinking import in programming terms can help). What can I say? I agree that this is a reasonable interpretation. But I don't think it's the only interpretation, and I'm not sure it's even the interpretation intended by the authors. There's another section that specifically allows distribution of GPL and non-GPL programs on the same medium (Linux distributions), and that passage would be redundant if this passage reads as you suggest. I think it would definitely be safe to download a set of RPMs (one per product) and then install them all and configure them to point to each other (using network protocols, standard interfaces, etc.), but I think it's very questionable whether you can put them in a single pre-configured package. The problem is, I'm in a situation where (to quote "Ronin"), "Whenever there's a doubt, there is no doubt." Whatever you say, I haven't heard anything that convinces me that the interpretation is clear - I can easily see both sides of the disagreement. I suspect the only way for this to ultimately be resolved is to take it to a lawyer and/or RMS. Any volunteers? :) Overall, the most unfortunate thing here is that I don't believe either party is trying to lock out code from the other. But the fact that the licenses are not compatible means that one group or the other has to change licenses in order to enable true sharing of code, which is one of the greatest promises of open source. And it doesn't sound like either party is willing. Aaron
