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
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
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
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
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
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
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.
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
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
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
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
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 w
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
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.
14 matches
Mail list logo
