CR1 of TCK 1.0.1 available
by Pete Muir
All,
I have tagged 1.0.1 CR1, and pushed it to both Maven and SourceForge (just waiting for the various servers to sync...).
Thanks to Gurkan and Mark (from OWB), Vivek, Santiago, Hong, Jitendra, Kyle and Roger (from Sun) for assiduously reporting issues. And also to David, Jozef and Marius for fixing them :-)
These release of TCK contains no known issues, and only excludes tests which are still failing in Weld.
We'll release 1.0.1 in two weeks, which I hope will have no excludes!
Best,
Pete
14 years, 9 months
Generic Beans
by Stuart Douglas
I have been looking into Gavin's ideas for generic beans, as specified at http://seamframework.org/Weld/PortableExtensionsPackage, and I have come up with a simple prototype. The details of the implementation is as follows:
- All AnnotatedTypes marked @Generic are vetoed and their details stored for later use.
- All beans that have a generic producer field have the details of the Generic annotation value stored
- after bean discovery a new bean is registered for every @Generic annotation type and every instance of the Generic annotation on a producer field. So in the example on the wiki page six beans would be registed, 3 Topics and 3 sessions, one each for 'default', 'prices' and 'deals'. these beans have a synthetic qualifier annotation added to them that only the PE knows about. Also at this point any @InjectGeneric on the annotated type is replaced with @Inject @SyntheticQualifier(value=?) so that generic beans can inject other generic beans.
- The injectionTarget for beans with a generic producer field is wrapped to set the initial value.
The prototype contains a simple test, it contains two generic beans, GenericMain and GenericDep, both are generic on TestAnnotation. GenericDep is injected into GenericMain which is then exposed via a producer field in GenericProducer and injected into InjectedBean. GenericDep injects an instance of TestAnnotation as configuration.
Could someone have a look at this and let me know if this approach is ok? (In order to build it you may need to get the most recent weld-extensions from svn)
Stuart
14 years, 9 months
Weld 1.0.1 and CDI TCK 1.0.1 timeline
by Pete Muir
All,
As previously discussed, we are aiming for a 10-12w release cycle of patch releases for Weld and for the CDI TCK. This means the 1.0.1 releases should happen around the 4th Feb.
To this end, the release schedules are:
CDI TCK
1.0.1.CR1: 21st January (Thursday this week)
1.0.1: 4th Feb
Weld
1.0.1.CR1: 28th January (Thursday next week)
1.0.1: 4th Feb
If you are working on issues for 1.0.1 please review the issues you are assigned, and check that you think you can make the CR1 dates above. If you can't, please ping me and we can either slip the issue to 1.0.1 or find some help for you.
Current assignments by the numbers are:
* Aslak - 1 issue (WELD-362)
* Dan - 2 issues (WELD-27, WELD-287)
* David - 3 issues (WELD-4, WELD-337, WELD-365)
* Marius - 10 issues (WELD-291, WELD-269, WELD-312, WELD-325, WELD-36, WELD-314, WELD-377, WELD-356, WELD-272, WELD-274)
* Nik - 4 issues (WELD-32, WELD-271, WELD-361, WELD-348)
* Roger - 5 issues (WELD-273, WELD-30, WELD-206, WELD-31, WELD-303)
* Shane - 1 issue (WELD-257)
* Stuart - 2 issue (WELD-335, WELD-309)
leaving
* Pete/Unassigned - 27 issues
Thanks!
Pete
14 years, 10 months
Question regarding behavior of Decorated dependent scoped beans
by Joseph Bergmark
While verifying the behavior of decorated dependent scoped beans on
OpenWebBeans, Gurkan mentioned that he observed the same behavior on WELD.
While verifying myself I noticed two behaviors that seem to conflict with
the spec.
1) Non-normal scoped beans don't have any restrictions on public fields. A
quick test showed that changes made to public fields directly are not
reflected when a call to a getter method that returns that value of the
public field is made. Presumably this is because there is an proxy like
object in the middle.
For example
@Inject MyBean myBean;
myBean.number = 7;
myBean.getNumber(); //would return the default value for number and not 7
which it was just set to.
2) Non-normal scoped beans don't require a public no-args constructor. If
the dependent scoped bean instead had a constructor annotated with @Inject
(as per 3.1.1), an InstantiationException was thrown.
Are these expected restrictions once that dependent scoped bean is
Decorated?
Sincerely,
Joe
14 years, 10 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
14 years, 10 months
External Event Routing
by Jordan Ganoff
I'm trying to route Events from a portable extension (to be the Seam 3 JMS
module). After talking to David Allen it seems there is currently no way to
get the qualifiers for a fired event. Without the qualifiers it doesn't
seem like routing outside of Weld-core is possible. The idea of using an
Interceptor on BeanManager.fireEvent() would have worked but we can't assign
Interceptors to an existing class.
Any ideas?
--
Jordan Ganoff
14 years, 11 months
AnnotatedType implementation in weld tests
by Stuart Douglas
I would like to write some tests for the SPI, however I need a concrete implementation of Annotated*, which are available in weld-extensions. Should I
- Copy paste them into weld-test
- Add a dependency on weld-extensions
- Split them off into a new module (weld-utils?) and add a dependency on that
- something else altogether
Stuart
14 years, 11 months
TCK - Running Java EE Web Profile
by Gurkan Erdogdu
Hi;
I try to run TCK within Java EE web profile. I have included
<method-selector>
<selector-class name="org.jboss.jsr299.tck.impl.WebProfileMethodSelector" />
</method-selector>
to TestNG suite file. But TCK still runs @Package(EAR) tests. For example, Enterprise and EJB related tests are still run. Also in some tests, TCK creates packages but its content is invalid (For example, it creates WAR with content lib/, META-INF/ , another war file within it. etc.). I will send details about it later.
Do I miss something or any other configuration is needed?
Thanks;
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
14 years, 11 months
Proposed SPI enhancements
by Gavin King
Folks, I chatted with Roberto yesterday, and we agreed that I should
write up the proposed enhancements to the SPI. So here's a draft of
the spec with my proposals. These enhancements don't require the
addition of new capabilities to the container, they just expose
pre-existing functionality to the portable extension.
The changes are:
* Addition of BeanAttributes to 11.1
* Addition of helper methods to BeanManager 11.3.19-11.3.23
* Addition of ProcessModule event 11.5.5
* Addition of ProcessInjectionPoint event 11.5.7
* Addition of ProcessProducerMethod, ProcessProducerField and Initializer 11.5.9
* Addition of ProcessBeanAttributes event 11.5.10
Please let me know what you think, and if you can see any holes.
Thanks!
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
14 years, 11 months
Stereotype inheritance
by Stuart Douglas
Does the spec define what happens in the following situation?
@RequestScoped @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Action {}
@ApplicationScoped @Action @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Home {}
@Home
public class MyBean{}
As far as I could see the spec does not define what to do when stereotypes declare stereotypes that have conflicting scopes. In this situation it would make sense to have Home's scope override Actions, but we can also get situations like this:
@RequestScoped @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Action {}
@ApplicationScoped @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Home {}
@Stereotype @Home @Action @Target(TYPE) @Retention(RUNTIME) public @interface HomeAction {}
@Home
public class MyBean{}
I think this should be an error.
Stuart
14 years, 11 months
