Well, might not be nice but we cannot guarantee backward compatibility
for such cases. CDI defines a contract. If you break the contract then
the deployment fails. If we allow to break the contract then the
contract is useless and we could allow anything...
Anyway what's the use case here? Is there a normal-scoped producer?
I believe that having such a producer for a third-party type other than
interface is not a good practice. Is there a normal-scoped bean class
extending Hashtable? Not a good practice either. If so, the bean author
should reduce the bean types by means of @Typed and allow the bean
clients to only work with interfaces.
Martin
Dne 22.10.2015 v 00:28 Emily Jiang napsal(a):
What about legacy applications running on new JDK7? The only
workaround
is that the customers have to update the app. Otherwise, their app won't
start. This is not nice.
On Wed, Oct 21, 2015 at 2:57 PM, Martin Kouba <mkouba(a)redhat.com
<mailto:mkouba@redhat.com>> wrote:
Dne 21.10.2015 v 13:54 Emily Jiang napsal(a):
doh. You were right that the OWB-616 was for a different issue
rather
than the one I am interested.
Do you have any suggestions about working around the unproxiable
Hashtable issue?
Well, the spec only requires the injection points to be validated,
or rather the required bean types to be proxyable. So if you
inject/use Map interface instead of Hashtable, the validation should
pass.
On Wed, Oct 21, 2015 at 12:38 PM, Martin Kouba
<mkouba(a)redhat.com <mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>> wrote:
Dne 21.10.2015 v 13:20 Emily Jiang napsal(a):
Thanks Martin!
The new final method on the Hashtable is
final boolean initHashSeedAsNeeded(int capacity)
I see. This package-private method was added in JDK7.
The change went as part of the following bug fix:
[1]
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8006593
As for the OWB-616 jira, I did not look at the actual
fix, but I
assume
the fix by the following comments. I might be wrong here.
<
https://issues.apache.org/jira/browse/OWB-616#>
Mark Struberg
<
https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg>
added a comment - 01/Oct/11 19:12
I now changed the checks to allow private final and
public/protected
static final methods.
Mark does not talk about non-static package-private
methods, right?
He talks about private final and public/protected static
final =>
should work in Weld too.
If non-static package-private methods are allowed than the
spec is
violated. Unfortunately, it seems there's no tck test for this.
Thanks
Emily
On Wed, Oct 21, 2015 at 11:50 AM, Martin Kouba
<mkouba(a)redhat.com <mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>
<mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>>> wrote:
Hi Emily,
commments inline.
Dne 21.10.2015 v 11:02 Emily Jiang napsal(a):
CDI specification does not allow proxying a
class with
non-private final
methods. The java.util.Hashtable class has a
non-private final method added to the class in
later
versions
of Java, so a CDI application that previously
worked
may break
when updating the Java level.
Just for the record: what's the name of the method?
This issue was logged in CDI-527.
OpenWebBeans fixed this via the jira
(
https://issues.apache.org/jira/browse/OWB-616).
OWB-616 does not fix CDI-527 but CDI-159, i.e. a
private final
method does not cause a deployment problem. This
works in
Weld too.
On the other hand, CDI-527 is still an open issue
so we
can't simply
fix it. In theory, we could add a new feature of a
non-portable
mode. But non-portable mode is not intended to be
commonly
used.
It's kind of a workaround.
Can Weld fix this in the 2.3 or 2.2 trunk?
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org <mailto:ejiang@apache.org>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>>>
<mailto:ejiang@apache.org
<mailto:ejiang@apache.org> <mailto:ejiang@apache.org
<mailto:ejiang@apache.org>>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>>>>
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org>
<mailto:weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>>
<mailto:weld-dev@lists.jboss.org
<mailto:weld-dev@lists.jboss.org>
<mailto:weld-dev@lists.jboss.org
<mailto:weld-dev@lists.jboss.org>>>
https://lists.jboss.org/mailman/listinfo/weld-dev
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org <mailto:ejiang@apache.org>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>>>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org <mailto:ejiang@apache.org>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org <mailto:ejiang@apache.org>