<div dir="ltr"><div style>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.</div><div style><br></div><div style>Putting the question another way:</div>
<div style><br></div><div style>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?</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>John</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 12:05 PM, Thomas Frühbeck <span dir="ltr"><<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hmm, I expect loading of JARs not to
the problem, is it? So the loading and reflecting on the
"external" class should be possible. <br>
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.<br>
Sorry if I misunderstood your quest? =)<br>
<br>
Thomas<br>
<br>
Am 14.02.2013 17:37, schrieb John Franey:<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">Thomas,
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>John</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Feb 14, 2013 at 11:22 AM,
Thomas Frühbeck <span dir="ltr"><<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>exactly what I was looking for :-))<br>
Thanks George!<br>
<br>
Am 14.02.2013 16:55, schrieb George Gastaldi:<br>
</div>
<div>
<div>
<blockquote type="cite">
<div>Hi Thomas,</div>
<div><br>
</div>
<div>Have a look in Forge 2.0 source code. We're
using javassist at it's best in the proxy module</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
Em 14/02/2013, às 13:53, Thomas Frühbeck <<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>>
escreveu:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>Hi John,<br>
<br>
my two cents: <br>
- this feature is a must-have, if Forge
should be more than a tool to iniitialize
projects, really great idea<br>
- being pragmatic I would say this calls
for proxy classes, similar to CDI decorators
or the copy-on-write strategy<br>
<br>
(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.)<br>
<br>
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 :-/<br>
<br>
Have you thought about javassist? Is it an
option at all?<br>
<br>
Thomas<br>
<br>
<br>
Am 14.02.2013 16:21, schrieb John Franey:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>I have written a prototype:</div>
<div>1) an implementation of the forge java
api interfaces which delegates to java's
reflection, offering a read only
perspective of java components.</div>
<div>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.</div>
<div><br>
</div>
<div>These are demonstrable in a unit test.</div>
<div><br>
</div>
<div>My dilemma now is how to integrate
these into the forge project. There are a
few different areas, but I'll start with
this:</div>
<div><br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So, I'm looking for discussion and
consensus on the above. Any thoughts?</div>
<div><br>
</div>
<div>Regards,</div>
<div>John</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>forge-dev mailing list</span><br>
<span><a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a></span><br>
<span><a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></span></div>
</blockquote>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br></blockquote></div><br></div>