[JBoss JIRA] (CDI-192) Unify coding style of the SPI interfaces
by Jozef Hartinger (Created) (JIRA)
Unify coding style of the SPI interfaces
----------------------------------------
Key: CDI-192
URL: https://issues.jboss.org/browse/CDI-192
Project: CDI Specification Issues
Issue Type: Bug
Components: Portable Extensions
Affects Versions: 1.1.EDR1
Reporter: Jozef Hartinger
Priority: Trivial
Fix For: 1.1 (Proposed)
The [JLS|http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html...] says:
{quote}
For compatibility with older versions of the Java platform, it is permitted but discouraged, as a matter of style, to redundantly specify the abstract modifier for methods declared in interfaces.
It is permitted, but strongly discouraged as a matter of style, to redundantly specify the public modifier for interface methods.
{quote}
The vast majority of CDI API interfaces specifies the public modifier while leaving out the abstract modifier, however, there are exceptions:
{code:JAVA}
public interface Context {
...
boolean isActive();
}
{code}
{code:JAVA}
public interface BeanAttributes<T> {
public abstract Set<Type> getTypes();
public abstract Set<Annotation> getQualifiers();
...
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
easy solution for class visibility checks?
by Mark Struberg
Hi folks!
I just had an idea which is so simple that I just cannot believe it!
So please review and ping me if I missed something.
This topic is related to CDI-18 (BDA dropping) and CDI-129 (@EnterpriseApplicationScoped)
What is the problem with CDI-1.0?
Well, CDI-1.0 says nothing about class visibility, but instead tries to solve all those issues by introducing the BeanDefinitionArchive (BDA). This in turn creates more harm than good.
An example of such a broken use case would be that it is currently allowed to have a public class @Singleton MyService {} residing in shared EAR jar being @Specialized by a public class @Singleton MySpecializedService extends MyService {} residing in WEB-INF/classes of one single webapp.
Obviously (with a JSR-316 conform 'sane' classloader hierarchy set up) this will not work. Because MySpecializedService is not visible from the EAR nor the other webapps (because of the ClassLoader isolation).
In CDI-18 I proposed to add the following rules:
> The container must ensure that for any
> * @Specializes @NScoped class Y extends X and
> * @Alternative @NScoped class Y implements X
> class Y is accessible by all classes which can access X in the same @NScoped context.
The problem now is: how does a custom 3rd party scope determine those rules?
Because the issue is not only valid for @EnterpriseApplicationScoped. Just imagine to add a @SystemScoped which is a singleton-per-JVM (residing in the System or extension ClassLoader), or a @ClusterScoped, ...
Today I realized that the *only* relevant thing is actually if the context maintaining the scope of 'class Y' (see definition above) can see the class Y.
It is just not valid to write a @EnterpriseApplicationScoped public class MyService if the EnterpriseApplicationScopedContext cannot see MyService.
The easiest solution would be to add a method to Context which checks the visibility at startup:
boolean isVisible(Class beanClass) or
boolean isVisible(String className) (need to think about which one works better, esp with different scenarios)
Of course since #addContext is only in AfterBeanDiscovery, we need to do this in some 'verifyDeployment' phase after the bean scanning.
wdyt?
Is the intention clear? Or should I bring more samples about how that would work?
Is there any flaw in there which I have overlooked?
LieGrue,
strub
12 years, 12 months
[JBoss JIRA] (CDI-50) Ability to veto beans, both unconditionally and based on classes visible
by Gerhard Petracek (Commented) (JIRA)
[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ]
Gerhard Petracek commented on CDI-50:
-------------------------------------
currently we have a discussion [1] about @Veto for deltaspike.
imo @Veto as it is in seam-solder doesn't fit >for the spec.< itself because extensions still get the corresponding ProcessAnnotatedType.
the current version of @Veto just works that way because there is no portable alternative for it.
however, if such an annotation gets included in the spec., classes which are annotated with it can be ignored for the >whole< bootstrapping process.
in this case the name 'Veto' doesn't make sense (for users) - marius summarized it with during our discussion:
"@Veto is technically accurate, but not intuitive (and requires an understanding of class processing, which is not a user concern)"
(short addition: 'technically accurate' is correct if ProcessAnnotatedType#veto gets called - as mentioned before ProcessAnnotatedType#veto doesn't make sense imo, if it gets included in the spec. itself -> in this case the name wouldn't be accurate at all.)
while discussing this issue we found names which would fit better - e.g. @Unmanaged or @Exclude
[1] http://markmail.org/thread/htniv3wstkopblwt
> Ability to veto beans, both unconditionally and based on classes visible
> ------------------------------------------------------------------------
>
> Key: CDI-50
> URL: https://issues.jboss.org/browse/CDI-50
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1.EDR2
>
>
> This should support both a straight veto, and conditional based on classes available.
> Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}).
> Mark Struberg proposed using @Optional
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
transactional interceptors
by Paul Bakker
Will the spec discuss an approach for interoperability with EJB? e.g. What happens if a @Transactional CDI beans invokes a session bean (and vice versa). Will the correct transaction demarcation happen? Depending on the implementation this might already work automatically, but if it doesn't work it would be very confusing to users.
My other question is if JPA integration will be specified as part of this specification (e.g. @PersistenceContext in CDI beans). This is only semi related, but might be relevant.
Besides these questions I'm very much in favor of this approach.
Paul Bakker
> From: Linda DeMichiel <linda.demichiel at oracle.com<https://lists.jboss.org/mailman/listinfo/cdi-dev>>
> Subject: [javaee-spec users] [jsr342-experts] transactional interceptors
> Date: 20 December 2011 23:16:38 GMT
> To: jsr342-experts at javaee-spec.java.net<https://lists.jboss.org/mailman/listinfo/cdi-dev>
>
>
> As part of better aligning managed bean technology across the
> platform, one of the improvements we've targeted for this release
> is the extension of "container-managed" transactions (CMT) beyond EJB.
>
> CMT is one of the original ease-of-use facilities of EJB. It entails
> the specification of declarative transaction attributes on enterprise
> bean classes or methods. The container intercepts the corresponding
> method calls and interposes the necessary operations to initiate,
> suspend, or complete JTA transactions.
>
> In order to allow CMT-like functionality to be more broadly supported,
> we propose to standardize on CDI interceptors to implement transactional
> interpositioning on managed bean methods.
>
>
> More concretely, the proposal is the following:
>
> We propose to standardize on an annotation + element values that
> capture the semantics of the current EJB transaction attributes
> (Required, RequiresNew, Mandatory, Supports, NotSupported, Never).
>
> This annotation and standardized values would be added to the
> javax.transaction package.
>
> For example, this might look as follows:
>
> @Inherited
> @InterceptorBinding
> @Target({TYPE,METHOD})
> @Retention(RUNTIME)
> public @interface Transactional {
> TxType value() default TxType.REQUIRED
> }
>
> public enum TxType {
> REQUIRED,
> REQUIRES_NEW,
> MANDATORY,
> SUPPORTS,
> NOT_SUPPORTED,
> NEVER
> }
>
>
> The JTA specification would also define the semantics of the
> corresponding interceptor classes. (Note that the classes themselves
> would not be defined, but left to the JTA implementation.)
>
> These transactional interceptors would then be applied using the
> standard CDI protocols. They would be applicable to all CDI managed
> beans as well as to classes defined as managed beans by the Java EE
> specification such as servlets, JAX-RS resource classes, and JAX-WS
> service endpoints.
>
>
> There are a few open issues here that require consideration, e.g.:
>
> (1) Whether the "value" attribute of the "Transactional" annotation
> should be binding or @NonBinding. Note that this decision affects
> the number of interceptor classes that would need to be defined.
>
> (2) Interceptor ordering. This is currently an open topic in the CDI
> expert group. Presumably it would be desirable for "system-level"
> interceptors such as transactional interceptors to be executed before
> user-defined "application-level" interceptors, but there needs to be
> a mechanism to allow such orderings to be specified in a flexible way.
>
>
> We would like to get feedback on this proposed approach and the
> related issues from the group. Other specleads should feel free to
> forward this message to their expert groups for further discussion, if
> relevant.
>
> thanks,
>
> -Linda
>
13 years
Stafeful services directly from the JSF VS "ViewBean" + stateless service
by José Rodolfo Freitas
CDI created the possibility to reach any bean in the container from a JSF
view, encouraging a closer approach between ejb and jsf (or any cdi bean
and jsf), which can potentially lead to a simpler application design. I
think that is great!
However, I'm observing that this new programming model has been
experimenting user resistance. The "traditional" way of doing things, using
a "ViewBean" accessing a Stateless Service seems to be the
more legit.
What do you think about this? I'd like to discuss best practices around it
as I see it's on the core of almost every web application design.
13 years
Fwd: [javaee-spec users] [jsr342-experts] transactional interceptors
by Pete Muir
All, FYI
Please review this carefully, as this is one of the most requested features for CDI - ability to use transactions in CDI managed beans.
Begin forwarded message:
> From: Linda DeMichiel <linda.demichiel(a)oracle.com>
> Subject: [javaee-spec users] [jsr342-experts] transactional interceptors
> Date: 20 December 2011 23:16:38 GMT
> To: jsr342-experts(a)javaee-spec.java.net
>
>
> As part of better aligning managed bean technology across the
> platform, one of the improvements we've targeted for this release
> is the extension of "container-managed" transactions (CMT) beyond EJB.
>
> CMT is one of the original ease-of-use facilities of EJB. It entails
> the specification of declarative transaction attributes on enterprise
> bean classes or methods. The container intercepts the corresponding
> method calls and interposes the necessary operations to initiate,
> suspend, or complete JTA transactions.
>
> In order to allow CMT-like functionality to be more broadly supported,
> we propose to standardize on CDI interceptors to implement transactional
> interpositioning on managed bean methods.
>
>
> More concretely, the proposal is the following:
>
> We propose to standardize on an annotation + element values that
> capture the semantics of the current EJB transaction attributes
> (Required, RequiresNew, Mandatory, Supports, NotSupported, Never).
>
> This annotation and standardized values would be added to the
> javax.transaction package.
>
> For example, this might look as follows:
>
> @Inherited
> @InterceptorBinding
> @Target({TYPE,METHOD})
> @Retention(RUNTIME)
> public @interface Transactional {
> TxType value() default TxType.REQUIRED
> }
>
> public enum TxType {
> REQUIRED,
> REQUIRES_NEW,
> MANDATORY,
> SUPPORTS,
> NOT_SUPPORTED,
> NEVER
> }
>
>
> The JTA specification would also define the semantics of the
> corresponding interceptor classes. (Note that the classes themselves
> would not be defined, but left to the JTA implementation.)
>
> These transactional interceptors would then be applied using the
> standard CDI protocols. They would be applicable to all CDI managed
> beans as well as to classes defined as managed beans by the Java EE
> specification such as servlets, JAX-RS resource classes, and JAX-WS
> service endpoints.
>
>
> There are a few open issues here that require consideration, e.g.:
>
> (1) Whether the "value" attribute of the "Transactional" annotation
> should be binding or @NonBinding. Note that this decision affects
> the number of interceptor classes that would need to be defined.
>
> (2) Interceptor ordering. This is currently an open topic in the CDI
> expert group. Presumably it would be desirable for "system-level"
> interceptors such as transactional interceptors to be executed before
> user-defined "application-level" interceptors, but there needs to be
> a mechanism to allow such orderings to be specified in a flexible way.
>
>
> We would like to get feedback on this proposed approach and the
> related issues from the group. Other specleads should feel free to
> forward this message to their expert groups for further discussion, if
> relevant.
>
> thanks,
>
> -Linda
>
>
>
>
13 years
Question about conversation.begin if transient
by Adrian Gonzalez
Hello,
This question has surely already been asked, but I'm looking over and over the following code :
if (conversation.isTransient()) {
conversation.begin();
}
Is it possible to create a single method in Conversation class to handle this ?
Something like conversation.beginIfTransient() ? (of course with a better name :) ).
WDYT ?
13 years
