<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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
cite="mid:CACYKaEvtY2L2d_qddPSYZYkHySoVsSOTu+Rpd2DQ5daOVs8j7Q@mail.gmail.com"
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 style="">I have written a prototype:</div>
<div style="">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 style="">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 style=""><br>
</div>
<div style="">These are demonstrable in a unit test.</div>
<div style=""><br>
</div>
<div style="">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 style=""><br>
</div>
<div style=""><br>
</div>
<div style="">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 style=""><br>
</div>
<div style="">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 style=""><br>
</div>
<div style="">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 style=""><br>
</div>
<div style="">So, I'm looking for discussion and consensus on
the above. Any thoughts?</div>
<div style=""><br>
</div>
<div style="">Regards,</div>
<div style="">John</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
forge-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/forge-dev">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</body>
</html>