<div dir="ltr">Thomas,<div><br></div><div style>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 style><br></div><div style>John</div><div style><br></div><div style><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 class="h5">
<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">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>