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

I have no intention of providing a way to modify the class definition of a java class defined within a dependency of the user's project. Putting the question another way: To date, the forge java model today supports only modifiable java components. This effort introduces non-modifiable java components to the forge java model. This raises the question: Would the non-modifiable java components be inspected with the same api that supports the modifiable java components (JavaClass, and others). If no, what api is used to inspect the non-modifiable java components? My naive answer is: the non-modifiable java components would be inspected using the same api as the modifiable java components. Methods of that api that expressly modify the java component would be inert for non-modifiable java components. John On Thu, Feb 14, 2013 at 12:05 PM, Thomas Frühbeck <fruehbeck(a)aon.at&gt;wrote: > 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 > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev