Re: [weld-dev] spec issue with parallel requests onto a converstaion
by Mark Struberg
Thanks Arbi!
But as the comment already mentions: this will effectively drop the A from AJAX!
Also the solution with the queue is
a) sadly not a standard for JSF-2
b) will not easily work in my example with the 2 lazy loading DataTables
c) will for sure not be working for comet kind apps
LieGrue,
strub
--- Arbi Sookazian <asookazian(a)gmail.com> schrieb am Di, 23.3.2010:
Von: Arbi Sookazian <asookazian(a)gmail.com>
Betreff: Re: [weld-dev] spec issue with parallel requests onto a converstaion
An: "Mark Struberg" <struberg(a)yahoo.de>
CC: weld-dev(a)lists.jboss.org
Datum: Dienstag, 23. März, 2010 17:24 Uhr
For insight into this:
1) http://seamframework.org/Documentation/IGetTheConversationEndedTimedOutOr...
2) RichFace's <a4j:queue>
I'm wondering if there is a timeout (or requestDelay equivalent) in Weld?
On Tue, Mar 23, 2010 at 8:18 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
Hi!
The spec currently says:
"The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking
or rejecting concurrent requests."
We do so, but now I get a pretty ugly BusyConversationException in an AJAX enabled JSF-2 component (Primefaces DataTable).
This may easily happen in other cases too and it would be really good to allow parallel requests to a @ConversationScoped bean!
Since this will get pretty heavy used in JSF-2 with <f:ajax/> we should imo aim to address this problem somehow.
Comet and other AJAX-push technologies may also get unusable this way, since they always have an open socket for this.
Also consider a page with 2 lazy loaded DataTables. They usually get rendered empty and will start to fill itself in parallel when the page gets rendered.
txs and LieGrue,
strub
PS: a similar issue with parallel AJAX requests has already been reported to the JSF EG for the ViewMap...
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
14 years, 1 month
spec issue with parallel requests onto a converstaion
by Mark Struberg
Hi!
The spec currently says:
"The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking
or rejecting concurrent requests."
We do so, but now I get a pretty ugly BusyConversationException in an AJAX enabled JSF-2 component (Primefaces DataTable).
This may easily happen in other cases too and it would be really good to allow parallel requests to a @ConversationScoped bean!
Since this will get pretty heavy used in JSF-2 with <f:ajax/> we should imo aim to address this problem somehow.
Comet and other AJAX-push technologies may also get unusable this way, since they always have an open socket for this.
Also consider a page with 2 lazy loaded DataTables. They usually get rendered empty and will start to fill itself in parallel when the page gets rendered.
txs and LieGrue,
strub
PS: a similar issue with parallel AJAX requests has already been reported to the JSF EG for the ViewMap...
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
14 years, 1 month
Fwd: documentation error @ weld extensions
by Lincoln Baxter, III
Hi Guys,
I could change this - but I thought it best to bring it to the attention of
the Weld team so it can be dealt with appropriately.
Thanks,
---------- Forwarded message ----------
From: Dominik Dorn <dominik(a)dominikdorn.com>
Date: Sat, Mar 20, 2010 at 6:59 AM
Subject: documentation error @ weld extensions
To: Lincoln Baxter <lincoln(a)ocpsoft.com>
hey lincoln,
could you please forward this to the correct person?
Theres a documentation error in
http://seamframework.org/Weld/PortableExtensionsPackage
Logger Injection:
It actually injects a org.slf4j.Logger instead of a JDK
java.util.logging.Logger.
When using the JDK logger, it throws this injection not resolvable thing.
thanks,
dominik
--
Dominik Dorn
http://dominikdorn.com
Tausche Deine Lernunterlagen auf http://www.studyguru.eu !
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
14 years, 1 month
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, 1 month
Re: [weld-dev] [seam-dev] Replacing pages.xml
by Stuart Douglas
find . | grep xhtml | wc
392 392 21192
It's going to be a big enum... we would need to make sure that you could split it up.
The only real problem I have with this approach is that all the metadata that is availible is hard coded into the page class, which means the page class has to know about every module that wants to use page level metadata. Also, you can't really configure it via xml, which I am not too worried about but may alienate some users.
Stuart
On 19/02/2010, at 4:40 PM, Gavin King wrote:
> You should even be able to make this work:
>
> @View(.....)
> login {
> @Inject Login loginBean;
> public MyAppPage next(MyAppPage page, Object outcome) {
> if ( loginBean.isLoggedIn() )
> return main;
> else
> return login;
> }
> },
>
> of course we would need a little infrastructure for injecting into enum values.
>
> On Thu, Feb 18, 2010 at 11:37 PM, Gavin King <gavin.king(a)gmail.com> wrote:
>> Oops, this is a MUCH better way to write this code:
>>
>>
>> public enum MyAppPage implements Page<MyAppPage> {
>>
>> @View(.....)
>> login {
>> public MyAppPage next(MyAppPage page, Object outcome) {
>> if (Boolean.TRUE.equals(outcome))
>> return main;
>> else
>> return login;
>> }
>> },
>>
>> @View(.....)
>> main {
>> public MyAppPage next(MyAppPage page, Object outcome) {
>> return main;
>> }
>> },
>>
>> @View(.....)
>> logout {
>> public MyAppPage next(MyAppPage page, Object outcome) {
>> return login;
>> }
>> };
>>
>> }
>>
>
>
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
14 years, 1 month
Provided scopes in CDI
by Lincoln Baxter, III
Does CDI come out of the box with an equivalent of Spring's "Prototype"
scope, which means that wherever injection is requested, a new instance of
the class is provided?
Is that what
@Inject @New MyType instance;
would be used for?
Could this be simplified by removing the need for @Inject, and requiring
only @New?
Thanks,
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
14 years, 1 month
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, 1 month
