[weld-issues] [JBoss JIRA] (WELD-2632) Allow unwrapping of a proxied object
Title: Message Title
Klemen Ferjancic commented on WELD-2632
Re: Allow unwrapping of a proxied object
Yes, that works, I am just unhappy by the need to write wrappers/utility code instead of using JPA interface as intended. A few more thoughts
@AllowUnwrap
@Inject
private EntityManager em
however, doing it at injection point is probably the wrong place, so how about at producer:
@AllowUnwrap
@Produces
@RequestScoped
public EntityManager getEntityManager(){}
As a bonus, weld behaviour could be codified in the spec and this would allow a developer override. No other code changes needed when using JPA or similar use cases. I'm sure it is a bit more complicated that that and I also understand this is a rather narrow use case to merit an introduction of a new annotation/funcitonality in CDI. It seems cleaner and doable though. It would probably make more sense to start this discussion at the spec level. Feel free to close the issue as needed.
Add Comment
This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c)
[weld-issues] [JBoss JIRA] (WELD-2632) Allow unwrapping of a proxied object
Title: Message Title
Klemen Ferjancic updated an issue
Weld / WELD-2632
Allow unwrapping of a proxied object
Change By:
Klemen Ferjancic
This is a revival of https://issues.redhat.com/browse/WELD-2245 and [https://hibernate.atlassian.net/browse/HHH-11020] for reconsideration.I am not asking for change in default behaviour but to give developer the power to override it.The setup with injected EntityManager and unwrapping the instance is quite common so I don't think it is fair to require custom workarounds for this. I understand the logic why Weld is safeguarding this to prevent escape from proxy but there are use cases like this one in JPA where you do actually want the underlying instance. I think there should be a way to tell Weld to let us do this while keeping the defaults.Something like (making this up on the fly):{color:#9e880d}@JustLetMeUnwrap{color}{color:#00}Session session {color}= em.unwrap(Session.class); ..or any developer convenient way to override the default behaviour when needed. This would also appear to be a blind spot in JPA/CDI interop at the spec level so clarification there would also be welcome.
Add Comment
This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c)
[weld-issues] [JBoss JIRA] (WELD-2632) Allow unwrapping of a proxied object
Title: Message Title Klemen Ferjancic created an issue Weld / WELD-2632 Allow unwrapping of a proxied object Issue Type: Feature Request Assignee: Unassigned Created: 24/Jul/20 9:28 AM Priority: Minor Reporter: Klemen Ferjancic This is a revival of https://issues.redhat.com/browse/WELD-2245 and https://hibernate.atlassian.net/browse/HHH-11020 for reconsideration. I am not asking for change in default behaviour but to give developer the power to override it. The setup with injected EntityManager and unwrapping the instance is quite common so I don't think it is fair to require custom workarounds for this. I understand the logic why Weld is safeguarding this to prevent escape from proxy but there are use cases like this one in JPA where you do actually want the underlying instance. I think there should be a way to tell Weld to let us do this while keeping the defaults. Something like (making this up on the fly): @JustLetMeUnwrapSession session = em.unwrap(Session.class); ..or any developer convenient way to override the default behaviour when needed. This would also appear to be a blind spot in JPA/CDI interop at the spec level so clarification there would also be welcome. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2435) Java 9 jigsaw - weld-servlet-core WeldProvider not in module
Title: Message Title Klemen Ferjancic commented on WELD-2435 Re: Java 9 jigsaw - weld-servlet-core WeldProvider not in module I believe the interface module declares `uses com.ServiceInterface;` while the implementor declares `provides com.ServiceInterface with com.impl.MyServiceImpl;` in module-info.java. So no, you don't need the implementation in the same jar. Anyway, i thought this would be some simple fix but the problems go much deeper and probably require full module implementation across weld so perhaps this issue can be closed. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2435) Java 9 jigsaw - weld-servlet-core WeldProvider not in module
Title: Message Title Klemen Ferjancic commented on WELD-2435 Re: Java 9 jigsaw - weld-servlet-core WeldProvider not in module JAR command should spew out an automatic module name. Looks like the problem is that it can't produce an automatic module out of it since it depends on the weld-environment-common. So until everything is modularized it is not possible to include it as a module dependency. I managed to work around the issue by including the top-level dependency of weld-core instead, which contains both jars and therefore resolved both modules correctly. TLDR: it is not possible to depend on weld-submodules that depend on each other right now. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
