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

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 >> 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