Can we drop the maven max version enforcer constraint in weld-parent:7?
by Steven Boscarine
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hello Pete,
I saw the max maven version constraint was added to the new parent POM.
Can we make it a min version only constraint like it used to be?
I think it'll be more convenient for causal contributers if they don't
have to maintain a legacy maven version just to build our project.
Thanks,
Steven
15 years
Delegate attributes with concrete type
by Gavin King
Hrm, I just noticed something that I had not realized.
Prior to May 14, the CDI spec said that the "delegate attribute" had
to have an interface type. On May 14, I refactored this section to
make "delegate injection points" just a special kind of injection
point. And I removed - perhaps intentionally, but much more likely
unintentionally, since I did not mention it to the EG in my emails -
the restriction that the type of the delegate injection point had to
be an interface type. At some later stage I guess I got used to this
restriction not being there, and it just slipped through the cracks
without me ever really thinking through the consequences.
The problem with this is that if we have a delegate with a concrete
type, we have two possible implementations for the delegate attribute:
(1) inject a proxy, derived from the concrete class, or
(2) inject the actual intercepted instance and keep track of the
current decorator in a threadlocal.
When I originally designed this stuff, I had hoped to avoid both these
options. I'm a bit upset that I screwed up here, and that we did not
discover it until now.
Now, this is not the end of the world, the spec is still
implementable, and this only affects you if you actually *do* have a
decorator with a concrete delegate injection point type. Which is, in
fact, a useful feature. But I'm wondering if we should "challenge" the
spec? It's not too late to fix this, I think.
Roberto, what would be the process if we decided to do this?
The language that went missing was:
"The declared type of the delegate attribute must be a Java interface
type [snip]. If the declared type of a delegate attribute is not a
Java interface type [snip], the container automatically detects the
problem and treats it as a definition error [snip]."
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years
Discussion on Delegate/Decorated types
by Marius Bogoevici
Gavin,
Mark and I had a discussion tonight about decorators, trying to clarify
some aspects of the specification. It would be great if you could review
the statements/comments/use cases described below and indicate what is
correct, what isn't, how will the spec address this in the future, etc.
It is a long message, but I tried to err by being too verbose rather
than risking to leave something out.
So, the main themes of the discussion were:
a) what are the decorated types of the decorator how do we identify them
and what role do they play?
b) what are the beans that a decorator can decorate?
c) reviewing a few examples that illustrate the various points being made.
So, I think that a) could be answered by looking at the preamble of
chapter 8, which states that "A decorator implements one or more bean
types and intercepts business method invocations of beans which
implement those bean types. These bean types are called decorated types"
and 8.1 which states that "The set of decorated types of a decorator
includes all interfaces implemented directly or indirectly by the bean
class, except for java.io.Serializable"
The role of decorated types is laid out by 8.1.3 which states "The
decorator intercepts every method: • declared by a decorated type of the
decorator [...]"
b)On the other hand, I read 8.3 as saying that a decorator can decorate
only beans which are injectable as delegates ("The bean is eligible for
injection to the delegate injection point according to the rules defined
in Section 5.3, “Typesafe resolution”.")
Overall, it seems like there are two competing restrictions at play:
that a decorator can decorate only methods defined on the decorated
types (so methods which are not on the decorated types will be ignored)
and it can decorate only beans which are injectable as delegates.
It should be noted that, according to Mark, quoting Pete (and I can see
the same in the code) - Weld does not look at the interfaces implemented
by the @Decorator bean in order to retrieve the decorated types, but it
infers them from the type of the delegate. (I personally think this
violates 8.1, but Pete - in CC - knows better what are the reasons for
this).
Now, it may happen that a method is defined on the decorator and the
target class, but not on any type implemented by the decorator -
according to a) and 8.1.3, it won't be used to decorate anything. But in
Weld, for example, since the decorated types are inferred from the
@Delegate, it will be used for decoration anyway,.
The main question raised by Mark during the discussion was what is the
use for having the Decorator implement an interface, when for practical
purposes, the decorated types are indicated by the delegate type.
Furthermore, if a decorator decorates more than one type/interface, what
is the type of the injected delegate? The only possible solution now is
a type which implements/extends both interfaces, which means that only a
bean of that class or a subclass of it (including implementors if we're
talking about an interface) can be decorated. Apparently, this is
possible because of the gap in the specification that Gavin mentioned
yesterday, which allows concrete types to be delegates. If the gap was
closed by eliminating concrete classes, then you can't have a decorator
that decorates more than one interface.
The delegate type restricts the eligible beans anyway (only beans that
implement/extend this class are eligible), but why is then necessary to
indicate a number of interface types which can be decorated? My take on
this is that you may not want to decorate all methods on the delegate,
only certain methods and requiring the decorator bean to state the
interfaces it wants to decorate can be used for that purpose. But Mark
has a point here, that you can achieve the same result by just not
implementing those methods, so the requirement for the decorator to
implement certain interfaces could be considered superfluous.
c) Samples
Let's look at an example provided by Mark:
class Cat { String getName() {return "";}};
class AngoraCat extends Cat { boolean getHairLength() {return true}}
class SiamCat extends Cat { };
@Decorator CatDecorator { @Delegate Cat c; String getName() {
log.info("something"); return c.getName(); } }
Now, looking at this sample it seems like:
(ASSERTION 1) In the sample above there are no decorated types,
therefore no actual decoration takes place.
Let's add Pet, an interface and have Cat implement it
class Pet { String getRegistrationNumber()};
(ASSERTION 2) The set of decorated types consists of the interface Pet.
Now let's consider the following two decorators:
@Decorator PetDecorator implements Pet {@Delegate Pet p; String
getName() { log.info("something"); return c.getName(); }}
@Decorator CatDecorator { @Delegate Cat c; String getName() {
log.info("something"); return c.getName(); } }
(ASSERTION 3) With the modification above, both PetDecorator and
CatDecorator apply to all types of cats, but PetDecorator also applies
to Pets which are not Cats
Now, if we had:
interface Cat { String getName();};
class SiamCat implements Cat, Pet { };
class RussianForestCat implements Cat, Pet { };
@Decorator PetCatDecorator implements Cat,Pet {@Delegate SiamCat c;
String getName() { log.info("something"); return c.getName(); }}
(ASSERTION 4) PetCat will decorate SiamCat but not RussianForestCat
(won't even be picked up as a decorator since it does not meet 8.3 wrt
RussianForestCat
So - Gavin, please also indicate which of these use cases is valid and
which assertions hold or not.
Mark, I tried to lay out your questions/opinions, as well as mine, as
accurate as I could. Feel free to comment/add anything you think is
relevant. I think it is important to agree on both the letter as well as
the spirit of the specification.
Cheers,
Marius
15 years
Portable way to restore a conversation
by Shane Bryzak
As per the subject line, is there a portable way to restore the
conversation context when the conversation ID is known? I need this
functionality in Seam Remoting to support conversational AJAX requests.
15 years
Delegate attributes with concrete type
by Gavin King
Hrm, I just noticed something that I had not realized.
Prior to May 14, the CDI spec said that the "delegate attribute" had
to have an interface type. On May 14, I refactored this section to
make "delegate injection points" just a special kind of injection
point. And I removed - perhaps intentionally, but much more likely
unintentionally, since I did not mention it to the EG in my emails -
the restriction that the type of the delegate injection point had to
be an interface type. At some later stage I guess I got used to this
restriction not being there, and it just slipped through the cracks
without me ever really thinking through the consequences.
The problem with this is that if we have a delegate with a concrete
type, we have two possible implementations for the delegate attribute:
(1) inject a proxy, derived from the concrete class, or
(2) inject the actual intercepted instance and keep track of the
current decorator in a threadlocal.
When I originally designed this stuff, I had hoped to avoid both these
options. I'm a bit upset that I screwed up here, and that we did not
discover it until now.
Now, this is not the end of the world, the spec is still
implementable, and this only affects you if you actually *do* have a
decorator with a concrete delegate injection point type. Which is, in
fact, a useful feature. But I'm wondering if we should "challenge" the
spec? It's not too late to fix this, I think.
Roberto, what would be the process if we decided to do this?
The language that went missing was:
"The declared type of the delegate attribute must be a Java interface
type [snip]. If the declared type of a delegate attribute is not a
Java interface type [snip], the container automatically detects the
problem and treats it as a definition error [snip]."
15 years
Decorator question
by Mark Struberg
Hi folks!
I'm a bit unsure about the interpretation of the section 8 Decorators in the spec.
There is a sentence which really confuses me:
"The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces..."
I always thought about 2 use cases:
1.)
@Decorator
public class MyDec1 implements AnInterface {
@Inject @Delegate AnInterface1 theRealThing;
...
}
which will decorate all beans which implement the AnInterface.
2.)
@Decorator
public class MyDec2 extends AnotherBeanClass {
@Inject @Delegate AnotherBeanClass theRealThing;
...
}
which will decorate all beans which are of Type (+subclasses) of AnotherBeanClass.
This thoughts are basically backed by a few other paragraphs in the spec and also by the TCK (org.jboss.jsr299.tck.tests.lookup.injectionpoint.CatDecorator).
But for 2) the AnotherBeanClass doesn't need to implement any Interface at all (at least from the practical point of view).
txs and LieGrue,
strub
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
15 years
