You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Richard Schilling <rs...@cognitiongroup.biz> on 2009/01/09 19:57:12 UTC
Re: Enhancer specification text for discussion
Greetings everyone. Hope you all had a great Christmas and new years.
I've taken a look at instrumentation ...
After today's JDO phone call, and from Craig I understand that one of
the intentions of providing API access to the enhancer is to enhance
classes on the fly (just-in-time enhancement ?), and that the
instrumentation mechanism could be used for this. I have some vague
memory about using an enhancer API as a way to integrate the JDO toolkit
into an IDE. This would not require the "just-in-time" enhancing that
is suggested by the passing of a resource (or passing a java.lang.Class
object) to the enhancer API. As the specs stand now, enhancement would
ideally be supported in the build stage. The entire JDO spec seems to
be bent in this direction so far...
Most importantly, there's a fundamental difference between enhancement
and instrumentation that we should take into account. Instrumentation
seems to be directed primarily at _reading_ state of the virtual machine
and program state after class files are loaded. JDO is directed at both
reading and writing object state to some storage mechanism ... JDO
enhancement modifies classes at the API level and changes an
application's functionality significantly. Mixing the two concepts
arbitrarily might cause some mental consternation among developers...
but ...
I can see why someone would be inspired to take advantage of the
instrumentation facility to support class enhancement. Instrumentation
gives us the capability to modify classes on a "just-in-time" basis,
which can be extremely handy (and tempting!). But, as Craig suspects, I
don't see any support for in instrumentation for the modification of
class members. And, the specification of an agent is required, along
with the definition of a premain method (which is not presently covered
in the JDO specification).
So, how do we take advantage of the concept of instrumentation and
incorporate it into JDO? I would suggest that creating a new
specification to support on-demand class enhancement at the VM level.
The instrumentation concept has certainly paved the way for this, and I
would love to see it happen. Restricting API calls to accept only File
objects, or in some other way enforcing enhancement to be done during
the build process is, IMHO, ideal under the current JDO specification.
Okay - resources and class names don't HAVE to eliminated from the API,
but the fact that enhancement is a build level process should be
reinforced...
But, lets please DO talk about run-time enhancement features..... :-)
Perhaps not calling it an instrumentation facility. How about an
enhancement facility?
Richard
Ilan Kirsh wrote:
>>> private void loadTypeFromUrl(URL url) throws IOException
>>> {
>>> // Handle a class file:
>>> String protocol = url.getProtocol();
>>> if ("file".equals(protocol))
>>> {
>>> File file = new File(
>>> URLDecoder.decode(url.getFile(), "UTF8"));
>>> if (!file.isDirectory())
>>> loadTypeFromFile(file);
>>> }
>>>
>>> // Handle a JAR file:
>>> else if ("jar".equals(protocol))
>>> {
>>> JarURLConnection con =
>>> (JarURLConnection)url.openConnection();
>>> loadTypeFromZipEntry(con.getJarFile(),
>>> con.getJarEntry());
>>> }
>>> }
>>>
>> Just to clarify, as I have not used these particular APIs:
>>
>> Does this allow the enhancer to get a read/write File handle for a URL
>> that's in the classpath?
>
> Yes, if there is no permission restriction.
>
>> And if it's a jar file, does it allow the enhancer to replace files
>> within it?
>>
>> Craig
>
> As far as I know you cannot replace an entry in a jar file using the
> standard Java API. You can however, override the file with a new
> complete jar file.
>
> Ilan
>
>
>
Re: Enhancing using ClassFileTransformer.
Posted by Andy Jefferson <an...@datanucleus.org>.
> Quick question: Can anyone post a link with a description (or just
> describe it here) of how the VM interacts with the instrumentation API
> to process the bytestream of a class using ClassFileTransformer?
> Does the VM invoke the class loader to find a class first, before
> handing the class definition off to the ClassFileTransformer? I assume
> this is so but I want to be sure.
From what I remember the JVM will receive a request to load a class. It
retrieves the bytes of the class. It then calls the method "transform" of
the "Premain-Class" (specified in the MANIFEST.MF of the enhancer jar) with
the input bytes for the class. This method can transform the bytecode of that
class and return it, or return null (meaning there is no change to the class
definition).
See
http://datanucleus.svn.sourceforge.net/viewvc/datanucleus/platform/enhancer/trunk/src/java/org/datanucleus/enhancer/DataNucleusClassFileTransformer.java?revision=2302&view=markup
That's about it.
--
Andy (DataNucleus - http://www.datanucleus.org)
Enhancing using ClassFileTransformer.
Posted by Richard Schilling <rs...@cognitiongroup.biz>.
Right. After today's meeting, I now understand what
ClassFileTransformer is. It's pretty handy for what we are doing. Per
Craig's e-mail with the notes from today's JDO meeting, I'll be taking a
closer look at instrumentation for this purpose. This is a great
approach, because it allows us a concrete specification to implement
enhancement into build tools. Enhancing during run-time of the
application post-build is another issue, and my understanding from Craig
is that restricting enhancement during the build process is the goal.
That's great too.
The instrumentation interface is so new, that it's kind of hard to find
anything with background information. So, I'll be filling out the JDO
wiki as I go.
Quick question: Can anyone post a link with a description (or just
describe it here) of how the VM interacts with the instrumentation API
to process the bytestream of a class using ClassFileTransformer?
Does the VM invoke the class loader to find a class first, before
handing the class definition off to the ClassFileTransformer? I assume
this is so but I want to be sure.
Richard
Andy Jefferson wrote:
> Hi Richard,
>
>
>> So, how do we take advantage of the concept of instrumentation and
>> incorporate it into JDO?
>>
>
> "JDOEnhancer" interface extends ClassFileTransformer, consequently it provides
> runtime enhancement also
>
>
Re: Enhancer specification text for discussion
Posted by Andy Jefferson <an...@datanucleus.org>.
Hi Richard,
> So, how do we take advantage of the concept of instrumentation and
> incorporate it into JDO?
"JDOEnhancer" interface extends ClassFileTransformer, consequently it provides
runtime enhancement also
--
Andy (DataNucleus - http://www.datanucleus.org)
Re: Enhancer specification text for discussion
Posted by Richard Schilling <rs...@cognitiongroup.biz>.
I think I didn't address one important thing, which is what I was
leading up to. For the phrase in Craig's suggested text:
"a resource loaded from a class loader that contains the byte codes
as generated by the javac compiler "
I would either qualify this to say that the enhancer tool itself (as an
application) can find its classes using the class loader _and_ that the
classes being enhanced are not used by the currently running VM (e.g.
the enhancer), or to eliminate this line for now ...
Richard
Richard Schilling wrote:
> Greetings everyone. Hope you all had a great Christmas and new years.
> I've taken a look at instrumentation ...
>
> After today's JDO phone call, and from Craig I understand that one of
> the intentions of providing API access to the enhancer is to enhance
> classes on the fly (just-in-time enhancement ?), and that the
> instrumentation mechanism could be used for this. I have some vague
> memory about using an enhancer API as a way to integrate the JDO
> toolkit into an IDE. This would not require the "just-in-time"
> enhancing that is suggested by the passing of a resource (or passing a
> java.lang.Class object) to the enhancer API. As the specs stand now,
> enhancement would ideally be supported in the build stage. The entire
> JDO spec seems to be bent in this direction so far...
>
> Most importantly, there's a fundamental difference between enhancement
> and instrumentation that we should take into account. Instrumentation
> seems to be directed primarily at _reading_ state of the virtual
> machine and program state after class files are loaded. JDO is
> directed at both reading and writing object state to some storage
> mechanism ... JDO enhancement modifies classes at the API level and
> changes an application's functionality significantly. Mixing the two
> concepts arbitrarily might cause some mental consternation among
> developers...
>
> but ...
>
> I can see why someone would be inspired to take advantage of the
> instrumentation facility to support class enhancement.
> Instrumentation gives us the capability to modify classes on a
> "just-in-time" basis, which can be extremely handy (and tempting!).
> But, as Craig suspects, I don't see any support for in instrumentation
> for the modification of class members. And, the specification of an
> agent is required, along with the definition of a premain method
> (which is not presently covered in the JDO specification).
> So, how do we take advantage of the concept of instrumentation and
> incorporate it into JDO? I would suggest that creating a new
> specification to support on-demand class enhancement at the VM level.
> The instrumentation concept has certainly paved the way for this, and
> I would love to see it happen. Restricting API calls to accept only
> File objects, or in some other way enforcing enhancement to be done
> during the build process is, IMHO, ideal under the current JDO
> specification. Okay - resources and class names don't HAVE to
> eliminated from the API, but the fact that enhancement is a build
> level process should be reinforced...
>
> But, lets please DO talk about run-time enhancement features..... :-)
>
> Perhaps not calling it an instrumentation facility. How about an
> enhancement facility?
>
> Richard
>
>
>
> Ilan Kirsh wrote:
>>>> private void loadTypeFromUrl(URL url) throws IOException
>>>> {
>>>> // Handle a class file:
>>>> String protocol = url.getProtocol();
>>>> if ("file".equals(protocol))
>>>> {
>>>> File file = new File(
>>>> URLDecoder.decode(url.getFile(), "UTF8"));
>>>> if (!file.isDirectory())
>>>> loadTypeFromFile(file);
>>>> }
>>>>
>>>> // Handle a JAR file:
>>>> else if ("jar".equals(protocol))
>>>> {
>>>> JarURLConnection con =
>>>> (JarURLConnection)url.openConnection();
>>>> loadTypeFromZipEntry(con.getJarFile(),
>>>> con.getJarEntry());
>>>> }
>>>> }
>>>>
>>> Just to clarify, as I have not used these particular APIs:
>>>
>>> Does this allow the enhancer to get a read/write File handle for a URL
>>> that's in the classpath?
>>
>> Yes, if there is no permission restriction.
>>
>>> And if it's a jar file, does it allow the enhancer to replace files
>>> within it?
>>>
>>> Craig
>>
>> As far as I know you cannot replace an entry in a jar file using the
>> standard Java API. You can however, override the file with a new
>> complete jar file.
>>
>> Ilan
>>
>>
>>
>
>
>