<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Pete,<br>
<br>
It has been awhile, my project is now on github:<br>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<a href="http://github.com/walterjwhite/service.query.base">http://github.com/walterjwhite/service.query.base</a><br>
<br>
I am in the process of re-organizing my projects and will open source a
good number of them. I'm about 25% done (just of uploading to github /
ohloh / etc.). I want to modify my code to keep up with your
suggestions and of course to get it to depend / use Weld Extensions'
auto proxy.<br>
<br>
You can also find some example of how I intend to use this:<br>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<a href="http://github.com/walterjwhite/service.query.defect">http://github.com/walterjwhite/service.query.defect</a><br>
<br>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<a href="http://github.com/walterjwhite/service.query.deployment">http://github.com/walterjwhite/service.query.deployment</a><br>
<br>
I am working on other examples that actually use these services, that
will be coming in probably 2 weeks at this rate. I use or will use
query services in servlets and servlet filters.<br>
<br>
Feel free to check out some of my other projects too.<br>
<br>
<br>
Let me know what you think.<br>
<br>
Thanks,<br>
<br>
Walter<br>
<br>
On 07/14/2010 05:49 PM, Pete Muir wrote:
<blockquote cite="mid:7FEFDFB9-9045-4A20-96EB-5EACA97D4992@redhat.com"
type="cite">
<pre wrap="">Ok, you convinced me - let's just make sure we document it :-)
On 14 Jul 2010, at 22:47, Stuart Douglas wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I don't think that is does break the contract, especially in the case of an abstract class. The javadoc just says :
Returns the target instance.
And the instance of the generated proxy is the target instance. Proxy is not really a good word for this, as this is not really a proxy in the design patterns sense, but a proxy in the 'uses JDK proxies' sense. I wish they had called JDK proxies something else.
Stuart
On 14/07/2010, at 10:53 PM, Pete Muir wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 13 Jul 2010, at 21:18, Stuart Douglas wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 14/07/2010, at 3:56 AM, Pete Muir wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 13 Jul 2010, at 00:45, Walter White wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Stuart,
Your idea sounds good as well.
I think my original motivation was when I first started with Spring in 2008, we proxied an abstract DAO if we didn't need custom functionality. If we needed custom functionality, then we extended the abstract DAO making it concrete. There was a configuration in spring that let you do that, but at that point in time, it was useful to avoid writing the same code again and again.
I need to play around with that more to have a better answer.
Walter
On 07/12/2010 06:05 PM, Stuart Douglas wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 13/07/2010, at 2:20 AM, Pete Muir wrote:
</pre>
<blockquote type="cite">
<pre wrap="">We definitely want something like this in WeldX.
However I would argue we should follow the design of interceptors much more closely.
1) The aroundInvoke method should take an InvocationContext, returning null for getTarget (what is the reason for passing the proxy into the method in the design below)?
2) Drop the interface implementation requirement, and use the @AroundInvoke annotation
3) Add an annotation used to find the handlers e.g. @ServiceHandler
4) Add a meta-annotation @ServiceBinding(QueryInvocationHandler.class) @interface QueryService {}
WDYT?
</pre>
</blockquote>
<pre wrap="">Looks good, I was planning on doing the meta-annotation stuff at some point, and using AroundInvoke rather than implementing InvocationHandler is certainly an improvement.
I don't see why getTarget should return null though. Even though having access to the object may not be not particularly useful, I think that most people would find this behaviour surprising. Also they may want to call getClass() or use instanceof on the object to determine the exact type they are dealing with.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
What would getTarget return then? By definition there is no proxied object.
</pre>
</blockquote>
<pre wrap="">
I would have it return the Proxy instance.
</pre>
</blockquote>
<pre wrap="">
In this case, we would need to redefine the InvocationContext interface, as getTarget then has the wrong contract.
Hmm, I can't see a good path through this. I am loath to add more interfaces that do different things.
Any ideas?
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>