What's the actual meaning of BeanManager.resolveDecorators?
by Marius Bogoevici
Hey,
We have an outstanding issue regarding decorators resolution. The problem is caused by the way Weld currently interprets the resolution of decorators. The use can be found in the TCK, inorg.jboss.jsr299.tck.tests.decorators.custom.CustomDecoratorTest.testCustomImplementationOfDecoratorInterface()
1) We have a Decorator whose decoratedTypes set is {Vehicle} - in this case it is custom, but this is not necessarily a precondition
2) We have a ManagedBean of the type Bus which implements Vehicle
3) BeanManger.resolveDecorators({Bus}) returns nothing
Item #3 causes the test to fail. I read the specification and discussed this with Pete as well, and it's not very clear to both of us what is the intent of the specification in this case. So, here are the relevant parts:
11.3.11 (Decorator Resolution) states that: "The method BeanManager.resolveDecorators() returns the ordered list of decorators for a set of bean types and a set of qualifiers [...]" and that "The first argument is the set of bean types of the decorated bean.". The method does not seem to have been designed for classes, but for ManagedBeans, whose bean types include the bean class and its supertypes (and in the case of custom beans, they could potentially decide what types they do or don't have).
There are two possible interpretations:
a) the one which is currently applied in Weld: one must specify *all* bean types of a managed bean when invoking resolveDecorators(), otherwise said "VehicleDecorator does not decorate Bus, but it decorates Vehicle"
b) a more relaxed approach, where the supertypes are inferred from the arguments as well, so that resolveDecorators({Bus}) is in all respects equivalent to resolveDecorators({Bus, Vehicle})
It should be noted that this has no practical consequence on the way Weld works internally, as decorator resolution for Weld beans is always performed against the whole set of bean types. However, this will affect the way in which extensions to the framework work.
Common sense would dictate to follow b), since Bus implements Vehicle indeed. However, as I explained before, this does not seem to be what the specification currently says. The only possible reasoning I can see behind that is that a managed bean may not include all its supertypes in getTypes(), therefore it would be wrong to assume that a certain decorator is applicable in its case.
So, what is the actual meaning of BeanManager.resolveDecorators()?
Cheers,
Marius
15 years, 11 months
About ConversationScope Signature
by Gurkan Erdogdu
Hi;
Also in signature test, it errors on ConversationScoped class. It says that this class does not contain @Inherited. But it must contain.
It seems an error.
--Gurkan
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
15 years, 11 months
About BeforeBeanDiscovery Method
by Gurkan Erdogdu
Hi;
While running signature test, discovered that spec defines
BeforeBeanDiscovery#public void addInterceptorBinding(Class<? extends Annotation> bindingType, Annotation... bindingTypeDef);
But CDI API defines
BeforeBeanDiscovery#public void addInterceptorBinding(Class<?
extends Annotation> bindingType);
we use first one, which one is correct?
--Gurkan
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
15 years, 11 months
A ConversationManager API
by Nicklas Karlsson
Hi,
There has been many requests for a standard ConversationManager
API that could be used by other frameworks (SE, GraniteDS, Seam
Remoting etc) so there was a short brainstorming session and we came
up with the following proposal on which I now request your feedback.
public interface ConversationManager
{
/**
* Activates the conversation context
*
* @return The conversation manager
* @throws IllegalStateException if the context is already active
*/
public abstract ConversationManager activateContext();
/**
* Deactivates the conversation context
*
* @return The conversation manager
* @throws IllegalStateException if the context is already deactivated
*/
public abstract ConversationManager deactivateContext();
/**
* Checks the state of the conversation context
*
* @return true if the conversation context is active, false otherwise
*/
public abstract boolean isContextActive();
/**
* Starts a new, transient conversation
*
* @return The conversation manager
* @throws IllegalStateException if there is already an active
conversation or if the conversation context is not active
*/
public abstract ConversationManager createTransientConversation();
/**
* Ends the current transient conversation
*
* @return The conversation manager
* @throws IllegalStateException if the current transaction is not
transient or if the conversation context is not active
*/
public abstract ConversationManager endTransientConversation();
/**
* Restores a long-running conversation.
*
* @param cid The id of the conversation to restore
* @return The conversation manager
* @throws NonexistentConversationException if the conversation id
is null or not a known long-running conversation
* @throws IllegalStateException if there already an active
conversation or if the conversation context is not active
*/
public abstract ConversationManager restoreConversation(String cid);
/**
* Marks a long-running conversation transient
*
* @param cid The id of the conversation to make transient
* @return The conversation manager
* @throws NonexistentConversationException if the conversation id
is null or not a known long-running conversation
* @throws IllegalStateException if the conversation context is not active
*/
public abstract ConversationManager endConversation(String cid);
/**
* Marks all long-running conversations as transient and destroys them
*
* @return The conversation manager
* @throws IllegalStateException if the conversation context is not active
*/
public abstract ConversationManager endAllConversations();
/**
* Returns the long-running conversation IDs
*
* @return The long-running conversations IDs
* @throws IllegalStateException if the conversation context is not active
*/
public abstract Set<String> getConversations();
/**
* Returns a new, unused conversation ID
*
* @return A new, unused conversation ID
* @throws IllegalStateException if the conversation context is not active
*/
public abstract String getNewConversationId();
/**
* Checks if a conversation ID is in use for any other conversation
than the current one
*
* @return True if the conversation ID is in use, false otherwise
* @throws IllegalStateException if the conversation context is not active
*/
public abstract boolean isConversationIdInUse(String id);
}
Does it do the job? Needs more ? Needs less? Violates the
specification in any point (from JSF perspective)?
---
Nik
15 years, 11 months
