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

[Thomas Frühbeck]

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
>>> 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/def18849/attachment.html