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

George Gastaldi ggastald at redhat.com
Thu Feb 14 10:55:18 EST 2013


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> 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
> 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/0d2c0153/attachment-0001.html 


More information about the forge-dev mailing list