[forge-dev] reflection to access classes in project dependencies

Thu Feb 14 12:05:00 EST 2013

Hmm, I expect loading of JARs not to the problem, is it? So the loading 
and reflecting on the "external" class should be possible.
I was thinking of the next step, implementing kind of writable JavaClass 
not just ignoring the changes, but making the modified class available 
to the project.
Sorry if I misunderstood your quest? =)

Thomas

Am 14.02.2013 17:37, schrieb John Franey:
> Thomas,
>
> I have minimal exposure to proxy due to experience with hibernate, but 
> my understanding is not adequate to understand how they would apply. 
>  Do I understand correctly that the benefit of a dynamic proxy is high 
> when a temporary class implementation is needed, and when a method of 
> the proxy is invoked, some action is taken, perhaps instantiating 
> another implementation of the interface.  In this use case, we don't 
> need to invoke the methods of a project's class, we need to inspect 
> the methods (and other members) of the class, right?
>
> John
>
>
>
>
> On Thu, Feb 14, 2013 at 11:22 AM, Thomas Frühbeck <fruehbeck at aon.at 
> <mailto:fruehbeck at aon.at>> wrote:
>
>     exactly what I was looking for :-))
>     Thanks George!
>
>     Am 14.02.2013 16:55, schrieb George Gastaldi:
>>     Hi Thomas,
>>
>>     Have a look in Forge 2.0 source code. We're using javassist at
>>     it's best in the proxy module
>>
>>
>>
>>     Em 14/02/2013, às 13:53, Thomas Frühbeck <fruehbeck at aon.at
>>     <mailto:fruehbeck at aon.at>> escreveu:
>>
>>>     Hi John,
>>>
>>>     my two cents:
>>>         - this feature is a must-have, if Forge should be more than
>>>     a tool to iniitialize projects, really great idea
>>>         - being pragmatic I would say this calls for proxy classes,
>>>     similar to CDI decorators or the copy-on-write strategy
>>>
>>>     (AFAIK the downside to CDI decorators is that they need
>>>     interfaces on the base classes, thus again requiring changes of
>>>     the classes if they hadnt been designed for it firstplace.)
>>>
>>>     I have a very similar problem I am currently trying to solve
>>>     with silly wrapper classes and was starting to think about
>>>     dynamic proxy generation - unfortunately I have _no_ experience
>>>     with such technology other than being simple user :-/
>>>
>>>     Have you thought about javassist? Is it an option at all?
>>>
>>>     Thomas
>>>
>>>
>>>     Am 14.02.2013 16:21, schrieb John Franey:
>>>>     My motivation for this email is to satisfy FORGE-773.  However,
>>>>     this is also related to FORGE-563 and FORGE-424, and resolution
>>>>     could enable other features.
>>>>
>>>>     I have written a prototype:
>>>>     1) an implementation of the forge java api interfaces which
>>>>     delegates to java's reflection, offering a read only
>>>>     perspective of java components.
>>>>     2) a forge module, currently a facet, to search for a given
>>>>     binary class in the project's dependencies and returns the
>>>>     result wrapped in the above delegate.
>>>>
>>>>     These are demonstrable in a unit test.
>>>>
>>>>     My dilemma now is how to integrate these into the forge
>>>>     project.  There are a few different areas, but I'll start with
>>>>     this:
>>>>
>>>>
>>>>     For some callers, a java class is a java class, whether it
>>>>     originates as source code (from the current forge project) or
>>>>     is a class from the dependency set.  For example, scaffolding
>>>>     primarily is a read only operation.  In this use case, it would
>>>>     be simpler for these clients to have a single interface to
>>>>     resolve classes because whether a class is source or binary is
>>>>     not relevant to the use case.
>>>>
>>>>     On the other hand, there is a set of classes in a user's
>>>>     project that are modifiable.  In these cases, a java class is
>>>>     not a java class.  Forge components might want the distinction
>>>>     somehow.  There ought the be some distinction of which class is
>>>>     modifiable and which is not.
>>>>
>>>>     Naively, I took the first thinking that the existing forge java
>>>>     model would be adequate.  To have separate java api for
>>>>     read-only and read-write java model objects seems a fundamental
>>>>     addition to the java model which requires much more effort.  In
>>>>     absence of such a model, I though to implement 'no-op' for
>>>>     those code changing methods  (e.g., Named.setName() would be
>>>>     inert).  I assumed that forge component that change source code
>>>>     would have necessary context to know when it is operating on a
>>>>     source code module, avoiding attempts to modify a binary class.
>>>>
>>>>     So, I'm looking for discussion and consensus on the above.  Any
>>>>     thoughts?
>>>>
>>>>     Regards,
>>>>     John
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     forge-dev mailing list
>>>>     forge-dev at lists.jboss.org  <mailto:forge-dev at lists.jboss.org>
>>>>     https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>     _______________________________________________
>>>     forge-dev mailing list
>>>     forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>>     _______________________________________________
>>     forge-dev mailing list
>>     forge-dev at lists.jboss.org  <mailto:forge-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>     _______________________________________________
>     forge-dev mailing list
>     forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130214/43e37dfe/attachment.html 