[weld-dev] ProxyFactory#getProxyName() question

Matej Novotny manovotn at redhat.com
Tue Mar 10 12:07:21 EDT 2020


Hello,

first and foremost, these are purely internal mechanics. There is no guarantee in CDI spec or Weld docs on how the proxies should look like.
Or even on the proxies being identical from one run to another, they are an abstraction that is hidden for the most part and can be unwrapped if needed.

> I think the proxy name produced by getProxyName() is based on the (quite
> possibly indeterminate) ordering of the Set of types that happens to be
> passed to it. This would mean that even subsequent calls to this method with
> the same Set might yield different and surprising results. Is this correct?

So, looking at the method, the "middle" part of the name seems to be good, there is sorting done.
See https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/proxy/ProxyFactory.java#L280

What seems to be inconsistent is the proxy prefix - the package. The set in TypeInfo isn't sorted anyhow.
However, within one application run, I don't think you can realistically end up having two proxies for the same bean, since you can hardly invoke this method for the same bean and pass it its bean type set ordered differently.
That being said, sorting wouldn't hurt.

> proxyName contains " java.io.Cloneable$Serializable$$Proxy$ ". Is that by
> design? Or is the " java.io.Cloneable " part a mistake?

For proxy purposes, it doesn't really matter if the proxy will be "java.io.Cloneable$Serializable$$Proxy$" or "java.lang.Cloneable$Serializable$$Proxy$".

> And are the double dollar signs ( $$ ) in this case intentional as well?
> (There are certainly paths through this method that won't result in double
> dollar signs, so I'm not sure if this is a bug or a feature.)

The code path that doesn't produce this is when you use a bean class (non-Object) and instead of type closure use empty set. In such case, it would leave out the second dollar sign, at least from what I gathered.
I don't think there is a strong argument for having one/two dollar signs but consistency is a nice behavioral pattern to stick with so we could align that. I cannot really imagine a justification for having different number of dollar
signs for proxies with certain type set.

Last but not least, this class (ProxyFactory) is mostly used for subclasses used for interceptor/decorator logic, there could be something similar in ClientProxyFactory which is what handles actual bean proxies.

If you want, go ahead and create a Weld issue so this doesn't get forgotten again :)

Regards
Matej

----- Original Message -----
> From: "Laird Nelson" <ljnelson at gmail.com>
> To: weld-dev at lists.jboss.org
> Sent: Sunday, March 8, 2020 6:41:57 AM
> Subject: [weld-dev] ProxyFactory#getProxyName() question
> 
> Hello; it's me again, deep/close reading ProxyFactory.java to understand
> everything I can about proxies in Weld.
> 
> I think the proxy name produced by getProxyName() is based on the (quite
> possibly indeterminate) ordering of the Set of types that happens to be
> passed to it. This would mean that even subsequent calls to this method with
> the same Set might yield different and surprising results. Is this correct?
> 
> For example, in a test that I wrote to further understand how proxy names are
> constructed:
> 
> 
> 
> 
> final Method getProxyName =
> ProxyFactory.class.getDeclaredMethod("getProxyName", String.class,
> Class.class, Set.class, Bean.class);
> getProxyName.setAccessible(true);
> final Set<Type> typeSet = new LinkedHashSet<>();
> 
> 
> 
> // Let's add two disparate interfaces in an arbitrary, but predictable,
> order.
> 
> 
> 
> typeSet.add(Serializable.class);
> typeSet.add(Cloneable.class);
> final String proxyName = (String)getProxyName.invoke(null, null,
> Object.class, typeSet, null);
> 
> 
> 
> assertEquals("java.io.Cloneable$Serializable$$Proxy$", proxyName); // ?!
> Whoa. Not what I expected.
> 
> proxyName contains " java.io.Cloneable$Serializable$$Proxy$ ". Is that by
> design? Or is the " java.io.Cloneable " part a mistake?
> 
> And are the double dollar signs ( $$ ) in this case intentional as well?
> (There are certainly paths through this method that won't result in double
> dollar signs, so I'm not sure if this is a bug or a feature.) To my eyes,
> this is suspicious:
> https://github.com/weld/core/blob/10a1d11af8c815a2a4a8fc5a4061698215e602b0/impl/src/main/java/org/jboss/weld/bean/proxy/ProxyFactory.java#L283
> Shouldn't that happen only if there aren't any more interface names to add?
> So are the two dollar signs just a symptom of a bug?
> 
> By contrast, in case it matters, my naïve expectation, following what seems
> to me the intended logic of the method, would have been for proxyName to
> contain " java.lang.Cloneable$Serializable$Proxy$ ".
> 
> Best,
> Laird
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev



More information about the weld-dev mailing list