===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS==
===
Please don't. What this method does is allows the Classloader to create
a class from a stream of bytes. If you are creating a class
dynamically via Javassist(or something else), you need to be able to
have this method on your classloader as defineClass is protected method.
What Javassist
The filesystem stuff exists so that I can create a URL for the
CodeSource. I needed this so that RMI classloading would work.
Bill
Adrian Brock wrote:
On Sat, 2004-01-03 at 15:41, Scott M Stark wrote:
Ah, ok. I don't want this method in the UCL layer though as its
introducing writes to
One more thing AOPClassPool.writeAsClass is polymorphic on
Javassist.ClassPool, so you won't see any usages.
Bill
Bill Burke wrote:
Please don't. What this method does is allows the Classloader to create
a class from a stream of bytes. If you are creating a class
dynamically via
So create a custom subclass of UnifiedClassLoader then. This is
introducing
a dependency into the UCL layer specific to a particular bytecode
generation framework and I don't want this in the UCL layer. Why can't
this all be hidden in the Translator.transform method for the Javassist
version of
Create a custom URL protocol handler that corresponds to an in
memory hash map then. Its way too much work to write bytes that
may never be requested out to the filesystem and is behavior
that should not be in the UCL layer.
Scott Stark
Chief Technology Officer
JBoss
It is not specific to a particular bytecode generation framework and
this is NOT a transformation, it is a class creation. If you are
creating classes dynamically with any generation framework, you need a
classloader to ClassLoader.defineClass. loadClass(String name, byte[]
newClass) is a
The big deal is that this is a new semantic that has to be supported by
all UCLs implementations, and its not a generic feature of all UCLs.
Class creation should occur through ClassLoader.loadClass. Generating
subclasses of existing classes is already done by the cmp2 layer without
having to
Patches item #870303, was opened at 2004-01-04 11:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376687aid=870303group_id=22866
Category: JBossCMP
Group: v3.2
Status: Open
Resolution:
Bugs item #863113, was opened at 2003-12-19 20:33
Message generated for change (Comment added) made by tpeuss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=863113group_id=22866
Category: Clustering
Group: v3.2
Status: Pending
Resolution: Invalid
Bugs item #870541, was opened at 2004-01-04 21:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=870541group_id=22866
Category: Nukes
Group: CVS HEAD
Status: Open
Resolution:
Bugs item #870541, was opened at 2004-01-04 22:46
Message generated for change (Settings changed) made by cooperfbi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=870541group_id=22866
Category: Nukes
Group: CVS HEAD
Status: Open
Resolution: None
Priority:
Bugs item #841526, was opened at 2003-11-13 17:03
Message generated for change (Settings changed) made by cooperfbi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=841526group_id=22866
Category: Nukes
Group: CVS HEAD
Status: Closed
Resolution: None
Bugs item #870529, was opened at 2004-01-04 22:18
Message generated for change (Settings changed) made by cooperfbi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=870529group_id=22866
Category: Nukes
Group: CVS HEAD
Status: Open
Resolution: None
Priority:
Bugs item #859407, was opened at 2003-12-13 11:31
Message generated for change (Comment added) made by cooperfbi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=859407group_id=22866
Category: Nukes
Group: CVS HEAD
Status: Closed
Resolution: None
Priority:
Bugs item #749348, was opened at 2003-06-05 08:10
Message generated for change (Settings changed) made by cooperfbi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=749348group_id=22866
Category: Nukes
Group: CVS HEAD
Status: Closed
Resolution: None
Bugs item #870529, was opened at 2004-01-04 21:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=870529group_id=22866
Category: Nukes
Group: CVS HEAD
Status: Open
Resolution:
Thanks jeff,
marcf
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Jeff Haynie
Sent: Saturday, January 03, 2004 11:25 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX 1.2, remoting, and jmx-remoting
commited to 3.2 branch
OK, I
I've commited a handful of fixes/improvements to remoting and
jmx-remoting I've found during testing and profiling our application
related to memory growth and dangling threads.
- I've added a slight improvement to the multicast detector for caching
the detection notification and
$B$*$;$AK0$-$A$c$C$?$h(B(_)$B$*$$$7$$$b$N?)$Y$K9T$-$?$$$J$!!!(B
(B
(B
(B
(B
(B
(B
(B
(B
(B
(B
(B
(B
(B
(B---
(BThis SF.net email is sponsored by: IBM Linux Tutorials.
(BBecome an expert in LINUX or just sharpen your skills.
21 matches
Mail list logo
