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

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