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

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(a)aon.at&gt;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(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 > _______________________________________________ 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