Re: [weld-dev] [seam-dev] Extending weld-extensions generic beans
by Pete Muir
[move to weld-dev as this has become a spec discussion]
Speaking to Stuart on IRC, he summarised it for me as:
"What I wanted to do was look for an annotation on a class @Generic(DroolsConfiguration.class), and then for every DroolsConfiguration that gets installed install a new one of that class with the same qualifiers but by the time I know about the class, it is to late, and I would need to use AfterBeanDiscovery.addBean. I think there are more use cases as well, basically anything that wants to add beans based on what it finds in the deployment and it is much easier to do it with addAnnotatedType than addBean"
I think this can be easily solved by making the initialisation lifecycle a bit more granular:
1) Fire BeforeBeanDiscovery [*] , firing ProcessAnnotatedType for each type added via ProcessAnnotatedType
2) Discover all AnnotatedTypes from bean archives, firing ProcessAnnotatedType for each type discovered
3) Fire AfterTypeDiscovery <<< Inserted step, firing ProcessAnnotatedType for each type added via ProcessAnnotatedType
4) Fire ProcessBean for each Bean created
5) Fire AfterBeanDiscovery
[*] Possibly you would want to rename BeforeBeanDiscovery to BeforeTypeDiscovery in an ideal world?
Is it possible to get this into the MR?
On 13 Apr 2010, at 00:47, Stuart Douglas wrote:
> So this is going to be much harder to implement than I thought. Because I want to look at the types that come through ProcessAnnotatedType I need to install the generic beans using AfterBeanDiscovery.addBean. This is much harder to use for this purpose than BeforeBeanDiscovery.addAnnotatedType, and no matter what I do there will be subtle and not so subtle differences between these beans and 'native' weld bean (e.g. interceptors and decorators won't work).
>
> Ideally it would also be possible to do AfterBeanDiscovery.addAnnotatedType, however for the moment the only real solution that I can see is to put this functionality in the XML module, and require the extension developer to explicitly declare their generic beans in XML. This way all the information is available in BeforeBeanDiscovery, and I can add the generic beans using addAnnotatedType.
>
> I think the syntax would be something like this:
>
> <genericBean class="org.jboss.seam.DroolsConfiguration">
> <d:KnowledgeBaseProducer/>
> <d:KnowledgeSessionProducer/>
> </genericBean>
>
> Does this sound like a reasonable solution?
>
> Stuart
>
> ________________________________________
> From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On Behalf Of Tihomir Surdilovic [tsurdilo(a)redhat.com]
> Sent: Tuesday, 13 April 2010 12:18 AM
> To: seam-dev(a)lists.jboss.org
> Subject: Re: [seam-dev] Extending weld-extensions generic beans
>
> On 4/12/10 9:51 AM, Stuart Douglas wrote:
>> After talking with Tihomir over the last few days about the seam-drools module I think that there is base functionality that is missing that belongs in weld-extensions as it is similar to the existing generic bean code.
>>
>> I will use an example from the drools module to outline the problem:
>>
>> The drools module has a DroolsConfiguration object that contains configuration, this can be installed via XML and there can be multiple DroolsConfigrations per app. for every DroolsConfiguration several object need to be produced e.g. KnowledgeBase, StatefullKnowledgeSession and a KnowledgeRuntimeLogger.
>>
>> currently we would need to do something like this:
>>
>> < d:DroolsConfiguration>
>> <app:SomeQualifier>
>> ...configuration
>> </d:DroolsConfiguration>
>>
>>
>> <d:KnowlegdeBaseProducer>
>> <d:producerMethod>
>> <app:SomeQualifier>
>> <s:parameters>
>> <d:DroolsConfiguration>
>> <s:Inject/>
>> <app:SomeQualifier/>
>> </d:DroolsConfiguration>
>> </s:parameters>
>> </d:producerMethod>
>> </d:KnowlegdeBaseProducer>
>>
>> ...same for StatefullKnowledgeSession, StatelessKnowledgeSession, KnowledgeRuntimeLogger etc.
>>
>> and wire up a producer like that for every object being created from the DroolsConfiguration. This is not good. The user should be able to just wire up the configuration and the rest of the beans should be created automatically. I think we should be able to do something like this:
>>
>> @Generic(DroolsConfiguration.class)
>> class KnowledgeBaseProducer
>> {
>> @Produces
>> @GenericQualifiers
>> public KnowledgeBase producerMethod(@Inject @GenericQualifiers DroolsConfiguration config )
>> {
>> //do stuff
>> }
>>
> and also disposer methods with for example:
> void disposerMethod(@Disposes @GenericQualifiers KnowledgeBase kbase)
> {
> ...
> }
>
> Thanks!
>> }
>>
>> @Generic tell the extensions to register a new KnowledgeBaseProducer bean for every DroolsConfiguration found.
>> @GenericQualifiers is replaced with the qualifiers on the DroolsConfiguration object when the bean is added.
>>
>> This means that all an end user has to do is wire up a single DroolsConfiguration object and everything just works.
>>
>> Does this sound like a good idea? Is there anything I have overlooked?
>>
>> Stuart
>>
>>
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
14 years
Ordering of servlet listeners
by Nicklas Karlsson
Hi,
I'm tinkering with the servlet listener -> CDI event bridge in the
seam-servlet module and noticed that currently the WeldListener is placed
last in the PostWebMetadataDeployer in weld-int.
I changed this (and verified it with the debugger) but still my own servlet
listener fires first (expecting the contexts to be up), causing problems.
Any theories as to why this is? How could we guarantee that
the WeldListener is the first one to fire?
---
Nik
14 years
Re: [weld-dev] Fwd: [weld-commits] Weld SVN: r6071 - in core/trunk/impl/src/main/java/org/jboss/weld: servlet and 1 other directory.
by Pete Muir
I'm not disputing that CDI should provide it there, but Weld is the *reference* implementation of the CDI spec so needs to provide a reference for other people to follow.
So IOW I would like guidance from the CDI EG that they intend to change it so servlet supports conversations in the next iteration of the CDI spec.
Does that make some sense?
On 9 Apr 2010, at 16:09, Lincoln Baxter, III wrote:
> I think that limiting the conversation to the JSF lifecycle is a big drawback for out-of-the-box experience -- we should be providing this for the entire servlet lifecycle. I'd argue that it is in the spirit of the new JavaEE 6 spec, which clearly provides injection in Filters, Servlets and Listeners now -- we should be providing Conversation support there as well. Filters and Servlets are still a strong part of Java EE, the core part, in my opinion -- JSF is just one option.
>
> --Lincoln
>
> On Fri, Apr 9, 2010 at 5:57 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> I agree it's not in direct contradiction, but it doesn't seem to be in the spirit of the spec either.
>
> On 9 Apr 2010, at 10:52, Nicklas Karlsson wrote:
>
> > We had been discussing with Dan and Lincoln on activating the conversation context for the entire request as it didn't seem to be a direct contradiction of the spec and Shane needed it for something about the same time so it got committed. I mailed the EG and asked about it but we can revert for now.
> >
> > On Fri, Apr 9, 2010 at 12:13 PM, Pete Muir <pmuir(a)redhat.com> wrote:
> > Guys,
> >
> > This doesn't seem in line with the spec to me, and I think we should revert it. What is the motivation for doing it?
> >
> > Pete
> >
> > Begin forwarded message:
> >
> > > From: weld-commits(a)lists.jboss.org
> > > Date: 1 April 2010 07:48:18 GMT+01:00
> > > To: weld-commits(a)lists.jboss.org
> > > Subject: [weld-commits] Weld SVN: r6071 - in core/trunk/impl/src/main/java/org/jboss/weld: servlet and 1 other directory.
> > > Reply-To: weld-commits(a)lists.jboss.org
> > >
> > > Author: shane.bryzak(a)jboss.com
> > > Date: 2010-04-01 02:48:18 -0400 (Thu, 01 Apr 2010)
> > > New Revision: 6071
> > >
> > > Modified:
> > > core/trunk/impl/src/main/java/org/jboss/weld/jsf/WeldPhaseListener.java
> > > core/trunk/impl/src/main/java/org/jboss/weld/servlet/ServletLifecycle.java
> > > Log:
> > > moved conversation setup/teardown out of jsf phase listener into servlet lifecycle (Nik says to blame me if this doesn't work ;)
> > >
> > >
> > > Modified: core/trunk/impl/src/main/java/org/jboss/weld/jsf/WeldPhaseListener.java
> > > ===================================================================
> > > --- core/trunk/impl/src/main/java/org/jboss/weld/jsf/WeldPhaseListener.java 2010-03-31 03:21:16 UTC (rev 6070)
> > > +++ core/trunk/impl/src/main/java/org/jboss/weld/jsf/WeldPhaseListener.java 2010-04-01 06:48:18 UTC (rev 6071)
> > > @@ -118,7 +118,7 @@
> > > private void beforeRestoreView(FacesContext facesContext)
> > > {
> > > log.trace(INITIATING_CONVERSATION, "Restore View");
> > > - initiateSessionAndConversation(facesContext);
> > > + //initiateSessionAndConversation(facesContext);
> > > }
> > >
> > > /**
> > > @@ -127,7 +127,7 @@
> > > private void afterRenderResponse(FacesContext facesContext)
> > > {
> > > log.trace(CLEANING_UP_CONVERSATION, "Render Response", "response complete");
> > > - getConversationManager().teardownConversation();
> > > + //getConversationManager().teardownConversation();
> > > }
> > >
> > > /**
> > > @@ -136,7 +136,7 @@
> > > private void afterResponseComplete(FacesContext facesContext, PhaseId phaseId)
> > > {
> > > log.trace(CLEANING_UP_CONVERSATION, phaseId, "the response has been marked complete");
> > > - getConversationManager().teardownConversation();
> > > + //getConversationManager().teardownConversation();
> > > }
> > >
> > > /**
> > >
> > > Modified: core/trunk/impl/src/main/java/org/jboss/weld/servlet/ServletLifecycle.java
> > > ===================================================================
> > > --- core/trunk/impl/src/main/java/org/jboss/weld/servlet/ServletLifecycle.java 2010-03-31 03:21:16 UTC (rev 6070)
> > > +++ core/trunk/impl/src/main/java/org/jboss/weld/servlet/ServletLifecycle.java 2010-04-01 06:48:18 UTC (rev 6071)
> > > @@ -162,6 +162,7 @@
> > > request.setAttribute(REQUEST_ATTRIBUTE_NAME, beanStore);
> > > lifecycle.beginRequest(request.getRequestURI(), beanStore);
> > > restoreSessionContext(request);
> > > + conversationManager(request.getSession().getServletContext()).setupConversation(request.getParameter("cid"));
> > > }
> > > }
> > >
> > > @@ -176,10 +177,12 @@
> > > {
> > > return;
> > > }
> > > - teardownSession(request);
> > > +
> > > + conversationManager(request.getSession().getServletContext()).teardownConversation();
> > > teardownRequest(request);
> > > lifecycle.getConversationContext().setBeanStore(null);
> > > lifecycle.getConversationContext().setActive(false);
> > > + teardownSession(request);
> > > }
> > >
> > > private void teardownSession(HttpServletRequest request)
> > >
> > > _______________________________________________
> > > weld-commits mailing list
> > > weld-commits(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/weld-commits
> >
> >
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> >
> >
> >
> > --
> > ---
> > Nik
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
14 years
proper handling of Events for beans in inactive Contexts?
by Mark Struberg
Hi!
I have the following scenario:
*) A ServletFilter fires a UserLoggedInEvent
*) A @ConversationScoped MyBean @Observes UserLoggedInEvent with Reception.ALWAYS
The problem here is that the Conversation is not yet 'opened' at the time the ServletFilter fires that event. Thus ConversationContext.isActive() == false and I cannot create this bean.
A similar situation appears if you try to send an event to a @ViewScoped bean from a JSF phase where the ViewMap doesn't yet exist.
So since there is no way to create a contextual instance, the obvious solution is to not send the notification to this very bean.
I didn't find this covered in the spec and I don't yet see much we can do in this case. This may cause some not so obvious behaviour and user may wonder why they don't get the event.
So, should we log some info in this case or silently swallow it?
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
14 years
Fwd: [weld-commits] Weld SVN: r6071 - in core/trunk/impl/src/main/java/org/jboss/weld: servlet and 1 other directory.
by Pete Muir
Guys,
This doesn't seem in line with the spec to me, and I think we should revert it. What is the motivation for doing it?
Pete
Begin forwarded message:
> From: weld-commits(a)lists.jboss.org
> Date: 1 April 2010 07:48:18 GMT+01:00
> To: weld-commits(a)lists.jboss.org
> Subject: [weld-commits] Weld SVN: r6071 - in core/trunk/impl/src/main/java/org/jboss/weld: servlet and 1 other directory.
> Reply-To: weld-commits(a)lists.jboss.org
>
> Author: shane.bryzak(a)jboss.com
> Date: 2010-04-01 02:48:18 -0400 (Thu, 01 Apr 2010)
> New Revision: 6071
>
> Modified:
> core/trunk/impl/src/main/java/org/jboss/weld/jsf/WeldPhaseListener.java
> core/trunk/impl/src/main/java/org/jboss/weld/servlet/ServletLifecycle.java
> Log:
> moved conversation setup/teardown out of jsf phase listener into servlet lifecycle (Nik says to blame me if this doesn't work ;)
>
>
> Modified: core/trunk/impl/src/main/java/org/jboss/weld/jsf/WeldPhaseListener.java
> ===================================================================
> --- core/trunk/impl/src/main/java/org/jboss/weld/jsf/WeldPhaseListener.java 2010-03-31 03:21:16 UTC (rev 6070)
> +++ core/trunk/impl/src/main/java/org/jboss/weld/jsf/WeldPhaseListener.java 2010-04-01 06:48:18 UTC (rev 6071)
> @@ -118,7 +118,7 @@
> private void beforeRestoreView(FacesContext facesContext)
> {
> log.trace(INITIATING_CONVERSATION, "Restore View");
> - initiateSessionAndConversation(facesContext);
> + //initiateSessionAndConversation(facesContext);
> }
>
> /**
> @@ -127,7 +127,7 @@
> private void afterRenderResponse(FacesContext facesContext)
> {
> log.trace(CLEANING_UP_CONVERSATION, "Render Response", "response complete");
> - getConversationManager().teardownConversation();
> + //getConversationManager().teardownConversation();
> }
>
> /**
> @@ -136,7 +136,7 @@
> private void afterResponseComplete(FacesContext facesContext, PhaseId phaseId)
> {
> log.trace(CLEANING_UP_CONVERSATION, phaseId, "the response has been marked complete");
> - getConversationManager().teardownConversation();
> + //getConversationManager().teardownConversation();
> }
>
> /**
>
> Modified: core/trunk/impl/src/main/java/org/jboss/weld/servlet/ServletLifecycle.java
> ===================================================================
> --- core/trunk/impl/src/main/java/org/jboss/weld/servlet/ServletLifecycle.java 2010-03-31 03:21:16 UTC (rev 6070)
> +++ core/trunk/impl/src/main/java/org/jboss/weld/servlet/ServletLifecycle.java 2010-04-01 06:48:18 UTC (rev 6071)
> @@ -162,6 +162,7 @@
> request.setAttribute(REQUEST_ATTRIBUTE_NAME, beanStore);
> lifecycle.beginRequest(request.getRequestURI(), beanStore);
> restoreSessionContext(request);
> + conversationManager(request.getSession().getServletContext()).setupConversation(request.getParameter("cid"));
> }
> }
>
> @@ -176,10 +177,12 @@
> {
> return;
> }
> - teardownSession(request);
> +
> + conversationManager(request.getSession().getServletContext()).teardownConversation();
> teardownRequest(request);
> lifecycle.getConversationContext().setBeanStore(null);
> lifecycle.getConversationContext().setActive(false);
> + teardownSession(request);
> }
>
> private void teardownSession(HttpServletRequest request)
>
> _______________________________________________
> weld-commits mailing list
> weld-commits(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-commits
14 years
Spec clarification needed
by Pete Muir
Given these beans and decorators (enabled)
interface Animal {
String hello();
}
class Cat implements Animal {
@Inject private InjectionPoint injectionPoint;
public String hello() {
return "hello";
}
public InjectionPoint getInjectionPoint() {
return injectionPoint;
}
}
@Decorator
class AnimalDecorator implements Animal {
@Inject @Delegate
private Animal bean;
public String hello() {
return bean.hello() + " world!";
}
}
class Cattery {
@Inject Cat cat;
Cat getCat() {
return cat;
}
}
Should
cattery.getCat().getInjectionPoint().isDelegate() return true or false?
I believe it should return true, as Cat is being decorated, and hence injected into the decorator delegate injection point.
Ref is https://jira.jboss.org/jira/browse/CDITCK-138
14 years
Dynamic Injection Question
by Jordan Ganoff
I was testing out a simple idea for another JMS injection type and ran into
an issue with Instance.get() and additional select annotations. The
InjectionPoint of the producer lacked the additional selected annotations.
I'm trying to create a TopicProducer and need to dynamically inject a
topic. When the topic producer is invoked the InjectionPoint does not
contain the JmsDestination (the annotations are only @Inject and @Any, which
seems like @Inject shouldn't be there either). Is there a better way to do
this?
Here's the code:
@Inject @Any Instance<Topic> anyTopic;
@Produces @JmsDestination
public TopicPublisher createTopicProducer(InjectionPoint ip, Session s)
throws JMSException
{
Topic t =
anyTopic.select(ip.getAnnotated().getAnnotation(JmsDestination.class)).get();
return TopicPublisher.class.cast(s.createProducer(t));
}
...
@Produces
@JmsDestination
public Topic getTopic(InjectionPoint ip, @Module Context c) throws
NamingException
{
JmsDestination d = ip.getAnnotated().getAnnotation(JmsDestination.class);
return (Topic) c.lookup(d.jndiName());
}
Thanks in advance.
P.S. Actual code links:
http://gist.github.com/359673
<http://gist.github.com/359673>
http://github.com/jganoff/seam3-jms/blob/master/src/main/java/org/jboss/s...
--
Jordan Ganoff
14 years
Running TCK Tests
by Gurkan Erdogdu
Hello folks;
I have been trying to run TCK tests but trouble into some weird situation. Some of the tests are sometimes passed and sometimes failed, and I did not find any reason for it. For example, I run ResolutionByTypeTest, sometimes it has passed all tests, sometimes 2 of them failed, sometimes one of them failed, sometimes 3 of them failed. But always failed tests are "testGenericBeanTypesOnManagedBean","testGenericBeanTypesOnProducerMethod",testGenericBeanTypesOnProducerField.
I have trouble with some other tests also, for example "ResolutionByNameTest#testAmbiguousELNamesResolved", it has passed %95 and failed %5 of time
What is the reason for all of these weird sitatuions ? I use Eclipse with TestNG plugin for testing.
Thanks;
--Gurkan
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
14 years
JNDI binding for CDI
by Marius Bogoevici
Hi,
I released v. 6.0.0.Beta11 which fixes the JNDI stuff for Weld - thanks Carlo for the support on the EJB side. One change is that BeanManager is now binding to java:comp instead of the previous java:app (which was not conforming to the spec), so we'll need to do a sweep of the Weld and TCK code in order to make sure that the we use the correct namespace.
Marius
14 years
standard servlet context attribute for the BeanManager
by Dan Allen
At the last Seam team meeting, the issue came up (once again) of how to get
the BeanManager from a non-contextual resource. The reality is that there
are certain lifecycle classes in Java EE that did not get categorized as
components (e.g., PhaseListener) and therefore do not support injection.
They are "outside" of CDI. We are working on an SPI for JSF to make these
classes CDI beans, but there will always be other cases.
In the current version of the spec, the standard way of looking up the
BeanManager is to use JNDI. However, JNDI is not consistently supported in
environments for which we want to write portable extensions (whether we like
it or not, people use servlet containers). Weld puts the BeanManager in a
servlet context attribute equal to the FQCN of BeanManager. Pete suggested
that we submit a change request to have this location standardized when
running in a servlet environment.
With this change, the BeanManager can be obtained as follows:
BeanManager manager = (BeanManager)
getServletContext().getAttribute(BeanManager.class.getName());
This requires no change in Weld, since Weld is already doing this.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
14 years
