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

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(a)aon.at&gt; 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 listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev