Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
The goal was to inject bean in facesconverter via CDI, but I don't have
this need anymore, since faces converter is not an eligible injection
point, so I opted to use request scoped JSF managed beans that have
facesconverter defined within the bean. That's working fine. Thanks.
Okay, I can cc myfaces user group as well, going forward. :-)
On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
i'm still not clear about your goal and where you need injection
maybe share a (runnable) sample to show us what you are talking about
side note: myfaces list can help you a lot about it too
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*
http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com
Interesting, that will allow you to get instance of beans, if already
instantiated, and that could have helped in converter, only if beans
already injected earlier?
On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
was thinking to
http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html
getAttributes()
method (depend a bit on your real need)
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*
http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com
Faces context? Please explain.
On Nov 20, 2012 1:56 AM, Romain Manni-Bucau
rmannibu...@gmail.com
wrote:
You cant use faces context?
Le 20 nov. 2012 03:01, Howard W. Smith, Jr.
smithh032...@gmail.com
a
écrit :
For minimal changes, I'm adding FacesConverter to JSF
requestscoped
managedBean's as per the Stackoverflow answer below:
How can I inject in @FacesConverter?
http://stackoverflow.com/a/13156834/933054
Yes, this means more classes in the project, but honestly, I have
not
had
to spend much time 'maintaining' my Converter classes at all. I
just
tested
this concept, and I'm not experiencing this exceptioin any more.
While testing the above, I see more exceptions to resolve related
to
migrating to CDI. Will let you all know, if I have any more
questions.
Thanks for all the responses/help, so far. :)
On Mon, Nov 19, 2012 at 7:20 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
If it is a nested class you need it otherwise (class foo in
foo.java
file)
you dont need it
Le 20 nov. 2012 01:16, Howard W. Smith, Jr.
smithh032...@gmail.com
a
écrit :
Good question. I removed 'static', because I didn't see it in
the
code
at
following URLs:
https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-DependencyInjection
http://stackoverflow.com/questions/7531449/cdi-injection-into-a-facesconverter
https://issues.apache.org/jira/browse/EXTCDI-127
On Mon, Nov 19, 2012 at 4:30 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
Why removing static? It means it is no more manageable by
cdi
(cdi
cant
do
a new on it)
Le 19 nov. 2012 22:13, Howard W. Smith, Jr.
smithh032...@gmail.com
a
écrit :
@Advanced was found in the following:
import
org.apache.myfaces.extensions.cdi.core.api.Advanced;
After some tinkering, I removed 'static' from the
following
definition,
public static class AddressTypeControllerConverter
implements
Converter {
I also added @Advanced to the FacesConverter/Converter,
and
latest
error
is
the following:
Nov 19, 2012 4:08:21 PM
javax.faces.component._ExternalSpecifications
isBeanValidationAvailable
INFO: MyFaces Bean Validation support enabled
Nov 19, 2012 4:08:21 PM
org.apache.myfaces.application.ApplicationImpl
internalCreateConverter
SEVERE: Could not instantiate converter class
jsf.address.pf_AddressTypeController$AddressTypeControllerConverter
java.lang.InstantiationException:
jsf.address.pf_AddressTypeController$AddressTypeControllerConverter
On Mon, Nov 19, 2012 at 3:07 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
you could also have used CODI BeanManagerProvider#getReference to get access to
the bean.
The support you need out of the box will come in JSF-2.2.
LieGrue,
strub
- Original Message -
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org
Cc:
Sent: Tuesday, November 20, 2012 1:56 PM
Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via
facescontext
T he goal was to inject bean in facesconverter via CDI, but I don't have
this need anymore, since faces converter is not an eligible injection
point, so I opted to use request scoped JSF managed beans that have
facesconverter defined within the bean. That's working fine. Thanks.
Okay, I can cc myfaces user group as well, going forward. :-)
On Nov 20, 2012 7:37 AM, Romain Manni-Bucau
rmannibu...@gmail.com
wrote:
i'm still not clear about your goal and where you need injection
maybe share a (runnable) sample to show us what you are talking about
side note: myfaces list can help you a lot about it too
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*
http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com
Interesting, that will allow you to get instance of beans, if already
instantiated, and that could have helped in converter, only if beans
already injected earlier?
On Nov 20, 2012 7:11 AM, Romain Manni-Bucau
rmannibu...@gmail.com
wrote:
was thinking to
http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html
getAttributes()
method (depend a bit on your real need)
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*
http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com
Faces context? Please explain.
On Nov 20, 2012 1:56 AM, Romain Manni-Bucau
rmannibu...@gmail.com
wrote:
You cant use faces context?
Le 20 nov. 2012 03:01, Howard W. Smith, Jr.
smithh032...@gmail.com
a
écrit :
For minimal changes, I'm adding FacesConverter
to JSF
requestscoped
managedBean's as per the Stackoverflow answer
below:
How can I inject in @FacesConverter?
http://stackoverflow.com/a/13156834/933054
Yes, this means more classes in the project, but
honestly, I have
not
had
to spend much time 'maintaining' my
Converter classes at all. I
just
tested
this concept, and I'm not experiencing this
exceptioin any more.
While testing the above, I see more exceptions to
resolve related
to
migrating to CDI. Will let you all know, if I have
any more
questions.
Thanks for all the responses/help, so far. :)
On Mon, Nov 19, 2012 at 7:20 PM, Romain
Manni-Bucau
rmannibu...@gmail.comwrote:
If it is a nested class you need it otherwise
(class foo in
foo.java
file)
you dont need it
Le 20 nov. 2012 01:16, Howard W. Smith,
Jr.
smithh032...@gmail.com
a
écrit :
Good question. I removed
'static', because I didn't see it in
the
code
at
following URLs:
https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-DependencyInjection
http://stackoverflow.com/questions/7531449/cdi-injection-into-a-facesconverter
https://issues.apache.org/jira/browse/EXTCDI-127
On Mon, Nov 19, 2012 at 4:30 PM, Romain
Manni-Bucau
rmannibu...@gmail.comwrote:
Why removing static? It means it is
no more manageable by
cdi
(cdi
cant
do
a new on it)
Le 19 nov. 2012 22:13, Howard
W. Smith, Jr.
smithh032...@gmail.com
a
écrit :
@Advanced was found in the
following:
import
org.apache.myfaces.extensions.cdi.core.api.Advanced;
After some tinkering, I
removed 'static' from the
following
definition,
public static class
AddressTypeControllerConverter
implements
Converter {
I also added @Advanced to the
FacesConverter/Converter,
and
latest
error
is
the following:
Nov 19, 2012 4:08:21 PM
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i'm still not clear about your goal and where you need injection maybe share a (runnable) sample to show us what you are talking about side note: myfaces list can help you a lot about it too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Interesting, that will allow you to get instance of beans, if already instantiated, and that could have helped in converter, only if beans already injected earlier? On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: was thinking to http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html getAttributes() method (depend a bit on your real need) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Faces context? Please explain. On Nov 20, 2012 1:56 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: You cant use faces context? Le 20 nov. 2012 03:01, Howard W. Smith, Jr. smithh032...@gmail.com a écrit : For minimal changes, I'm adding FacesConverter to JSF requestscoped managedBean's as per the Stackoverflow answer below: How can I inject in @FacesConverter? http://stackoverflow.com/a/13156834/933054 Yes, this means more classes in the project, but honestly, I have not had to spend much time 'maintaining' my Converter classes at all. I just tested this concept, and I'm not experiencing this exceptioin any more. While testing the above, I see more exceptions to resolve related to migrating to CDI. Will let you all know, if I have any more questions. Thanks for all the responses/help, so far. :) On Mon, Nov 19, 2012 at 7:20 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: If it is a nested class you need it otherwise (class foo in foo.java file) you dont need it Le 20 nov. 2012 01:16, Howard W. Smith, Jr. smithh032...@gmail.com a écrit : Good question. I removed 'static', because I didn't see it in the code at following URLs: https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-DependencyInjection http://stackoverflow.com/questions/7531449/cdi-injection-into-a-facesconverter https://issues.apache.org/jira/browse/EXTCDI-127 On Mon, Nov 19, 2012 at 4:30 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Why removing static? It means it is no more manageable by cdi (cdi cant do a new on it) Le 19 nov. 2012 22:13, Howard W. Smith, Jr. smithh032...@gmail.com a écrit : @Advanced was found in the following: import org.apache.myfaces.extensions.cdi.core.api.Advanced; After some tinkering, I removed 'static' from the following
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]:https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i'm still not clear about your goal and where you need injection maybe share a (runnable) sample to show us what you are talking about side note: myfaces list can help you a lot about it too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Interesting, that will allow you to get instance of beans, if already instantiated, and that could have helped in converter, only if beans already injected earlier? On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: was thinking to http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html getAttributes() method (depend a bit on your real need) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Faces context? Please explain. On Nov 20, 2012 1:56 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: You cant use faces context? Le 20 nov. 2012 03:01, Howard W. Smith, Jr. smithh032...@gmail.com a écrit : For minimal changes, I'm adding FacesConverter to JSF requestscoped managedBean's as per the Stackoverflow answer below: How can I inject in @FacesConverter? http://stackoverflow.com/a/13156834/933054 Yes, this means more classes in the project, but honestly, I have not had to spend much time 'maintaining' my Converter classes at all. I just tested this concept, and I'm not experiencing this exceptioin any more. While testing the above, I see more exceptions to resolve related to migrating to CDI. Will let you all know, if I have any more questions. Thanks for all the responses/help, so far. :) On Mon, Nov 19, 2012 at 7:20 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: If it is a nested class you need it otherwise (class foo in foo.java file) you dont need it Le 20 nov. 2012 01:16, Howard W. Smith, Jr. smithh032...@gmail.com a écrit : Good question. I removed 'static', because I didn't see it in the code at following URLs: https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-DependencyInjection
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]:https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i'm still not clear about your goal and where you need injection maybe share a (runnable) sample to show us what you are talking about side note: myfaces list can help you a lot about it too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Interesting, that will allow you to get instance of beans, if already instantiated, and that could have helped in converter, only if beans already injected earlier? On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: was thinking to http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html getAttributes() method (depend a bit on your real need) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Faces context? Please explain. On Nov 20, 2012 1:56 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: You cant use faces context? Le 20 nov. 2012 03:01, Howard W. Smith, Jr. smithh032...@gmail.com a écrit : For minimal changes, I'm adding FacesConverter to JSF requestscoped managedBean's as per the Stackoverflow answer below: How can I inject in @FacesConverter? http://stackoverflow.com/a/13156834/933054 Yes, this means more classes in the project, but honestly, I have not had to spend much time 'maintaining' my Converter classes at all. I just tested this concept, and I'm not experiencing this exceptioin any more. While testing the above, I see more exceptions to resolve related to migrating to CDI. Will let you all know, if I have any more questions. Thanks for all the responses/help, so far. :) On Mon, Nov 19, 2012 at 7:20 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: If it is a nested class you need it otherwise (class foo in foo.java file) you dont need it Le 20 nov. 2012 01:16, Howard W. Smith, Jr. smithh032...@gmail.com a écrit : Good question. I removed 'static', because I didn't see it in the code at following URLs: https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-DependencyInjection
Re: Migrating to CDI: @Asynchronous
MyFaces Users,
Please read OP (or my original email below), and then read this email, and
advise.
Romain,
Yes, I have a code snippet; please continue reading beyond/below first code
snippet.
Below is the code that is called by multiple beans as well as the bean
where this method is defined.
/*
* Is it safe to start a new thread in a JSF managed bean?
* Look at answers by BalusC and David Blevins
*
http://stackoverflow.com/questions/6149919/is-it-safe-to-start-a-new-thread-in-a-jsf-managed-bean
*
* Java EE 6 Tutorial Chapter 27 Using Asynchronous Method Invocation
in Session Beans
* http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html
*/
@Asynchronous
public FutureDate updateGoogleCalendarPostEditAsync(Date
tripDateToBePlacedInQueue) {
String log;
Date tripDate =
usersController.queueDateAndOrUpdateGoogleCalendar(tripDateToBePlacedInQueue);
if (tripDate == null) {
return new AsyncResult(tripDate);
}
performingGoogleCalendarMaintenace = true;
try {
if (usersController.googleCalendarHasEvents()) {
usersController.deleteEvents(tripDate, tripDate);
}
String tripDateFrom = displayUtil.getDateFromDateTime(tripDate,
false);
String tripDateTo = displayUtil.getDateFromDateTime(tripDate,
false);
ListOrders list = getFacade().findAllConfirmed(tripDateFrom,
tripDateTo, true);
if (list != null) {
for (Orders o : list) {
usersController.addEventToCalendar(newGoogleCalendarEvent(o));
}
}
log = pf_OrdersController.updateGoogleCalendarPostEditAsync():
+
new DateTime(tripDate).toString(MM/dd/) +
processed successfully;
} catch (Exception e) {
e.printStackTrace();
messages.addFormErrorMsg(Error updating Google Calendar,
(e.getMessage() != null) ? e.getMessage() : );
log = pf_OrdersController.updateGoogleCalendarPostEditAsync():
+
new DateTime(tripDate).toString(MM/dd/) +
processing failed due to exception;
} finally {
performingGoogleCalendarMaintenace = false;
}
System.out.println(log);
// Return our result
return new AsyncResult(tripDate);
}
Below, is code where the @Asynchronous method is *called within the same
bean*, and is not the last piece of code in the calling method.
/*
* 1. if tripDate changed, then update Google Calendar for
original trip date
* 2. update Google Calendar for current trip date
*/
if (new
DateTime(current.getReportDateTime()).toString(MM/dd/).equals(
new DateTime(tripDateBeforeEdit).toString(MM/dd/))
== false) {
updateGoogleCalendarPostEditAsync(tripDateBeforeEdit);
}
updateGoogleCalendarPostEditAsync(current.getReportDateTime());
}
if (invokePrepareEdit)
return prepareEdit();
else
return null;
Below, is code that is at the very end of a calling method and *called
within the same bean*, so there are no concerns here.
/*
* update Google Calendar for current trip date
*/
updateGoogleCalendarPostEditAsync(current.getReportDateTime());
return returnToBrowseOrView();
Below, is code that was *added to another bean*, that will call the
*@Asynchronous
method defined on the other bean* (ordersController).
public void updateGoogleCalendar() {
if (relatedEntityName.equals(orders)) {
Orders order = (Orders) relatedEntityObj;
ordersController.updateGoogleCalendarPostEditAsync(order.getTripDateTime());
}
}
The method above, updateGoogleCalendar(), is called by code similar to
below, which is not the last code executed in calling method.
if (relatedEntityName.equals(orders)) {
auditTrailDesc = Updated ORDER: updated ORIGIN +
(originTx != null originTx.length() 0
? ( + originTx + ) : );
auditTrailController.createFromRelatedEntity(relatedEntityName,
relatedEntityObj, auditTrailDesc);
*// update Google Calendar*
*updateGoogleCalendar();*
}
else if (relatedEntityName.equals(orderDriver)) {
OrderDriver od = (OrderDriver) relatedEntityObj;
OrderCostDetails orderCostDetails =
od.getOrderCostDetails();
Orders order = new
ArrayList(orderCostDetails.getOrders()).get(0);
auditTrailDesc = updated ORIGIN +
Thanks,
Howard
On Tue, Nov 20, 2012 at 2:25 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
Hi,
can you share any snippet of code?
*Romain Manni-Bucau*
*Twitter: @rmannibucau
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i'm still not clear about your goal and where you need injection maybe share a (runnable) sample to show us what you are talking about side note: myfaces list can help you a lot about it too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Interesting, that will allow you to get instance of beans, if already instantiated, and that could have helped in converter, only if beans already injected earlier? On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: was thinking to http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html getAttributes() method (depend a bit on your real need) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Faces context? Please explain. On Nov 20, 2012 1:56 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: You cant use faces context? Le 20 nov. 2012 03:01, Howard W. Smith, Jr. smithh032...@gmail.com a écrit : For minimal changes, I'm adding FacesConverter to JSF requestscoped managedBean's as per the Stackoverflow answer below: How can I inject in @FacesConverter? http://stackoverflow.com/a/13156834/933054 Yes, this means more classes in the project, but honestly, I have not had to spend much time 'maintaining' my Converter classes at all. I just tested this concept, and I'm not experiencing this exceptioin any more. While testing the above, I see more exceptions to resolve related to migrating to CDI. Will let you all know, if I have any more questions. Thanks for all the responses/help, so far. :) On Mon, Nov 19, 2012 at 7:20 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: If it is a nested class you need it otherwise (class foo in foo.java file) you dont need it Le 20 nov. 2012 01:16, Howard W.
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
CDI injection using @Advanced should work perfectly fine. We tested this excessively and use it on several containers in production. I'm curious why it doesn't work for you. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano rmpest...@yahoo.com.br Cc: Sent: Tuesday, November 20, 2012 3:13 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i'm still not clear about your goal and where you need injection maybe share a (runnable) sample to show us what you are talking about side note: myfaces list can help you a lot about it too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Interesting, that will allow you to get instance of beans, if already instantiated, and that could have helped in converter, only if beans already injected earlier? On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: was thinking to http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html getAttributes() method (depend a bit on your real need) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Faces context? Please explain. On Nov 20, 2012 1:56 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: You cant use faces context? Le 20 nov. 2012 03:01, Howard W. Smith, Jr. smithh032...@gmail.com a écrit : For minimal changes, I'm adding FacesConverter to JSF requestscoped managedBean's as per the Stackoverflow answer below: How can I inject in @FacesConverter? http://stackoverflow.com/a/13156834/933054 Yes, this means more classes in the project, but honestly, I have not had to spend much time
Re: Migrating to CDI: @Asynchronous
Hi!
One of my first advice is to make sure that beans.xml is really there for the
container.
I've seen this pretty often if someone starts the webapp directly from Eclipse.
In that case the CDI container sometimes cannot find WEB-INF/beans.xml as
eclipse doesn't set the classpath entries correctly.
Sometimes it helps to add a META-INF/beans.xml to the webapp classpath. This
will end up in WEB-INF/classes/META-INF/beans.xml and is perfectly fine from a
spec perspective.
There's a 30% chance that this is your problem ;)
For the @Asynchronous:
In general I do not really like @Asynchronous in webapps. It's really very
seldom useful as you need to wait for the result anyway. It also doesn't get
any Session, Request or Transaction information propagated over and it's not
guaranteed to succeed. Think about what happens if an Exception gets hit in the
asynchronous bean?
This is really only useful in 2 cases:
* fire and forget. If you don't take care if the job succeeds or not, then you
might use it.
* spawning off multiple jobs and waiting for all of them before returning.
Still you need to take a lot of care about error handling and similar stuff.
In our big application where we really need asynchronous tasks to be guaranteed
to get executed we went the classic route which works on the Host since the
60s: we just write the job into an own 'Tasks' table and process it via an own
Quartz job. On success, it updates the status. On error it sets the task to a
failure status and adds information about the cause.
That way we have a failure safe and restartable implementation.
LieGrue,
strub
- Original Message -
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org
Cc:
Sent: Tuesday, November 20, 2012 3:06 PM
Subject: Re: Migrating to CDI: @Asynchronous
MyFaces Users,
Please read OP (or my original email below), and then read this email, and
advise.
Romain,
Yes, I have a code snippet; please continue reading beyond/below first code
snippet.
Below is the code that is called by multiple beans as well as the bean
where this method is defined.
/*
* Is it safe to start a new thread in a JSF managed bean?
* Look at answers by BalusC and David Blevins
*
http://stackoverflow.com/questions/6149919/is-it-safe-to-start-a-new-thread-in-a-jsf-managed-bean
*
* Java EE 6 Tutorial Chapter 27 Using Asynchronous Method Invocation
in Session Beans
* http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html
*/
@Asynchronous
public FutureDate updateGoogleCalendarPostEditAsync(Date
tripDateToBePlacedInQueue) {
String log;
Date tripDate =
usersController.queueDateAndOrUpdateGoogleCalendar(tripDateToBePlacedInQueue);
if (tripDate == null) {
return new AsyncResult(tripDate);
}
performingGoogleCalendarMaintenace = true;
try {
if (usersController.googleCalendarHasEvents()) {
usersController.deleteEvents(tripDate, tripDate);
}
String tripDateFrom = displayUtil.getDateFromDateTime(tripDate,
false);
String tripDateTo = displayUtil.getDateFromDateTime(tripDate,
false);
ListOrders list = getFacade().findAllConfirmed(tripDateFrom,
tripDateTo, true);
if (list != null) {
for (Orders o : list) {
usersController.addEventToCalendar(newGoogleCalendarEvent(o));
}
}
log = pf_OrdersController.updateGoogleCalendarPostEditAsync():
+
new DateTime(tripDate).toString(MM/dd/) +
processed successfully;
} catch (Exception e) {
e.printStackTrace();
messages.addFormErrorMsg(Error updating Google Calendar,
(e.getMessage() != null) ? e.getMessage() : );
log = pf_OrdersController.updateGoogleCalendarPostEditAsync():
+
new DateTime(tripDate).toString(MM/dd/) +
processing failed due to exception;
} finally {
performingGoogleCalendarMaintenace = false;
}
System.out.println(log);
// Return our result
return new AsyncResult(tripDate);
}
Below, is code where the @Asynchronous method is *called within the same
bean*, and is not the last piece of code in the calling method.
/*
* 1. if tripDate changed, then update Google Calendar for
original trip date
* 2. update Google Calendar for current trip date
*/
if (new
DateTime(current.getReportDateTime()).toString(MM/dd/).equals(
new
DateTime(tripDateBeforeEdit).toString(MM/dd/))
== false) {
updateGoogleCalendarPostEditAsync(tripDateBeforeEdit);
}
Re: Migrating to CDI: @Asynchronous
oh, if you are using OpenEJB/TomEE/ other EE server then you can also use
@Timeout in an EJB instead of Quartz.
LieGrue,
strub
- Original Message -
From: Mark Struberg strub...@yahoo.de
To: MyFaces Discussion users@myfaces.apache.org; us...@openejb.apache.org
us...@openejb.apache.org
Cc:
Sent: Tuesday, November 20, 2012 3:36 PM
Subject: Re: Migrating to CDI: @Asynchronous
Hi!
One of my first advice is to make sure that beans.xml is really there for the
container.
I've seen this pretty often if someone starts the webapp directly from
Eclipse. In that case the CDI container sometimes cannot find
WEB-INF/beans.xml
as eclipse doesn't set the classpath entries correctly.
Sometimes it helps to add a META-INF/beans.xml to the webapp classpath. This
will end up in WEB-INF/classes/META-INF/beans.xml and is perfectly fine from
a
spec perspective.
There's a 30% chance that this is your problem ;)
For the @Asynchronous:
In general I do not really like @Asynchronous in webapps. It's really very
seldom useful as you need to wait for the result anyway. It also doesn't get
any Session, Request or Transaction information propagated over and it's not
guaranteed to succeed. Think about what happens if an Exception gets hit in
the
asynchronous bean?
This is really only useful in 2 cases:
* fire and forget. If you don't take care if the job succeeds or not, then
you might use it.
* spawning off multiple jobs and waiting for all of them before returning.
Still you need to take a lot of care about error handling and similar stuff.
In our big application where we really need asynchronous tasks to be
guaranteed
to get executed we went the classic route which works on the Host since the
60s:
we just write the job into an own 'Tasks' table and process it via an
own Quartz job. On success, it updates the status. On error it sets the task
to
a failure status and adds information about the cause.
That way we have a failure safe and restartable implementation.
LieGrue,
strub
- Original Message -
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: us...@openejb.apache.org; MyFaces Discussion
users@myfaces.apache.org
Cc:
Sent: Tuesday, November 20, 2012 3:06 PM
Subject: Re: Migrating to CDI: @Asynchronous
MyFaces Users,
Please read OP (or my original email below), and then read this email, and
advise.
Romain,
Yes, I have a code snippet; please continue reading beyond/below first code
snippet.
Below is the code that is called by multiple beans as well as the bean
where this method is defined.
/*
* Is it safe to start a new thread in a JSF managed bean?
* Look at answers by BalusC and David Blevins
*
http://stackoverflow.com/questions/6149919/is-it-safe-to-start-a-new-thread-in-a-jsf-managed-bean
*
* Java EE 6 Tutorial Chapter 27 Using Asynchronous Method Invocation
in Session Beans
* http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html
*/
@Asynchronous
public FutureDate updateGoogleCalendarPostEditAsync(Date
tripDateToBePlacedInQueue) {
String log;
Date tripDate =
usersController.queueDateAndOrUpdateGoogleCalendar(tripDateToBePlacedInQueue);
if (tripDate == null) {
return new AsyncResult(tripDate);
}
performingGoogleCalendarMaintenace = true;
try {
if (usersController.googleCalendarHasEvents()) {
usersController.deleteEvents(tripDate, tripDate);
}
String tripDateFrom = displayUtil.getDateFromDateTime(tripDate,
false);
String tripDateTo = displayUtil.getDateFromDateTime(tripDate,
false);
ListOrders list =
getFacade().findAllConfirmed(tripDateFrom,
tripDateTo, true);
if (list != null) {
for (Orders o : list) {
usersController.addEventToCalendar(newGoogleCalendarEvent(o));
}
}
log =
pf_OrdersController.updateGoogleCalendarPostEditAsync():
+
new DateTime(tripDate).toString(MM/dd/) +
processed successfully;
} catch (Exception e) {
e.printStackTrace();
messages.addFormErrorMsg(Error updating Google
Calendar,
(e.getMessage() != null) ? e.getMessage() : );
log =
pf_OrdersController.updateGoogleCalendarPostEditAsync():
+
new DateTime(tripDate).toString(MM/dd/) +
processing failed due to exception;
} finally {
performingGoogleCalendarMaintenace = false;
}
System.out.println(log);
// Return our result
return new AsyncResult(tripDate);
}
Below, is code where the @Asynchronous method is *called within the same
bean*,
Re: Migrating to CDI: @Asynchronous
Mark, Cool beans and agreed about @Asynchronous! Since I read about @Asynchronous on Stackoverflow.com (a post by David Blevins), I decided to give it a try, but I think I did read that 'asynchronous' (runnable, etc...) tasks are not all that good in web application. So, while you were writing your reply, I was already commenting out the call to the @Asynchronous method, and I reverted to the synchronous version of the method to update Google Calendar. After adding @Asynchronous, I added some logic that works better than @Asynchronous, it will not do a google calendar update on 'every' database update; I have some strategic processing in place that brought the # of google calendar requests down by hundreds and even thousands on a daily average. You know what? I attempted to add to META-INF as well as WEB-INF (some days ago), and I already reported (in an earlier post) that that didn't allow my web app to start in TomEE (or Glassfish, if I was still using Glassfish when I reported that earlier...smile). In response to Eclipse...hopefully, no offense will be taken, i'm not a user of eclipse, I've been a user of NetBeans ever since I started developing JSF web application (since last summer, 2011), and I can be the loyal type if something or someone treats me good. I was 'loyal' to Mojarra, but then I heard about the Mojarra issues updating components via AJAX, so I migrated to MyFaces Core (when I heard MyFaces Core 2.1.7+ performs better than Mojarra), and then reading one of your posts, Mark, about OpenWebBeans performing fast, and JIRA's and many people mentioning that CDI is better than JSF managed beans, I decided to migrate to CDI, and determined to use any/all features available that is offered by CDI, like events, SSE (server sent events), push (like Atmosphere), etc... Was having trouble using Atmosphere with Glassfish, so decided to give TomEE a whirl, since you, Andy Bailey (a friend in PrimeFaces forum), and others recommended TomEE. I like all that Glassfish 'markets' (or tries to sell) to JSF developers, but I'm liking what I see and hear about TomEE, OpenWebBeans, OpenEJB, etc... What is a good example or use case for using CDI events? Thanks, Howard On Tue, Nov 20, 2012 at 9:36 AM, Mark Struberg strub...@yahoo.de wrote: Hi! One of my first advice is to make sure that beans.xml is really there for the container. I've seen this pretty often if someone starts the webapp directly from Eclipse. In that case the CDI container sometimes cannot find WEB-INF/beans.xml as eclipse doesn't set the classpath entries correctly. Sometimes it helps to add a META-INF/beans.xml to the webapp classpath. This will end up in WEB-INF/classes/META-INF/beans.xml and is perfectly fine from a spec perspective. There's a 30% chance that this is your problem ;) For the @Asynchronous: In general I do not really like @Asynchronous in webapps. It's really very seldom useful as you need to wait for the result anyway. It also doesn't get any Session, Request or Transaction information propagated over and it's not guaranteed to succeed. Think about what happens if an Exception gets hit in the asynchronous bean? This is really only useful in 2 cases: * fire and forget. If you don't take care if the job succeeds or not, then you might use it. * spawning off multiple jobs and waiting for all of them before returning. Still you need to take a lot of care about error handling and similar stuff. In our big application where we really need asynchronous tasks to be guaranteed to get executed we went the classic route which works on the Host since the 60s: we just write the job into an own 'Tasks' table and process it via an own Quartz job. On success, it updates the status. On error it sets the task to a failure status and adds information about the cause. That way we have a failure safe and restartable implementation. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 3:06 PM Subject: Re: Migrating to CDI: @Asynchronous MyFaces Users, Please read OP (or my original email below), and then read this email, and advise. Romain, Yes, I have a code snippet; please continue reading beyond/below first code snippet. Below is the code that is called by multiple beans as well as the bean where this method is defined. /* * Is it safe to start a new thread in a JSF managed bean? * Look at answers by BalusC and David Blevins * http://stackoverflow.com/questions/6149919/is-it-safe-to-start-a-new-thread-in-a-jsf-managed-bean * * Java EE 6 Tutorial Chapter 27 Using Asynchronous Method Invocation in Session Beans * http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html */ @Asynchronous public FutureDate
Re: Migrating to CDI: @Asynchronous
I am considering @Timeout or @Schedule, but I think I want @Timeout (which
offers more control), as I didn't like how @Schedule was behaving when I
undeploy app on Glassfish, since I shutdown derby server via shutdown hook
or @predestroy (forgot how I did it).
On Tue, Nov 20, 2012 at 9:51 AM, Mark Struberg strub...@yahoo.de wrote:
oh, if you are using OpenEJB/TomEE/ other EE server then you can also use
@Timeout in an EJB instead of Quartz.
LieGrue,
strub
- Original Message -
From: Mark Struberg strub...@yahoo.de
To: MyFaces Discussion users@myfaces.apache.org;
us...@openejb.apache.org us...@openejb.apache.org
Cc:
Sent: Tuesday, November 20, 2012 3:36 PM
Subject: Re: Migrating to CDI: @Asynchronous
Hi!
One of my first advice is to make sure that beans.xml is really there
for the
container.
I've seen this pretty often if someone starts the webapp directly from
Eclipse. In that case the CDI container sometimes cannot find
WEB-INF/beans.xml
as eclipse doesn't set the classpath entries correctly.
Sometimes it helps to add a META-INF/beans.xml to the webapp classpath.
This
will end up in WEB-INF/classes/META-INF/beans.xml and is perfectly fine
from a
spec perspective.
There's a 30% chance that this is your problem ;)
For the @Asynchronous:
In general I do not really like @Asynchronous in webapps. It's really
very
seldom useful as you need to wait for the result anyway. It also doesn't
get
any Session, Request or Transaction information propagated over and it's
not
guaranteed to succeed. Think about what happens if an Exception gets hit
in the
asynchronous bean?
This is really only useful in 2 cases:
* fire and forget. If you don't take care if the job succeeds or not,
then
you might use it.
* spawning off multiple jobs and waiting for all of them before
returning.
Still you need to take a lot of care about error handling and similar
stuff.
In our big application where we really need asynchronous tasks to be
guaranteed
to get executed we went the classic route which works on the Host since
the 60s:
we just write the job into an own 'Tasks' table and process it via an
own Quartz job. On success, it updates the status. On error it sets the
task to
a failure status and adds information about the cause.
That way we have a failure safe and restartable implementation.
LieGrue,
strub
- Original Message -
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: us...@openejb.apache.org; MyFaces Discussion
users@myfaces.apache.org
Cc:
Sent: Tuesday, November 20, 2012 3:06 PM
Subject: Re: Migrating to CDI: @Asynchronous
MyFaces Users,
Please read OP (or my original email below), and then read this email,
and
advise.
Romain,
Yes, I have a code snippet; please continue reading beyond/below first
code
snippet.
Below is the code that is called by multiple beans as well as the bean
where this method is defined.
/*
* Is it safe to start a new thread in a JSF managed bean?
* Look at answers by BalusC and David Blevins
*
http://stackoverflow.com/questions/6149919/is-it-safe-to-start-a-new-thread-in-a-jsf-managed-bean
*
* Java EE 6 Tutorial Chapter 27 Using Asynchronous Method
Invocation
in Session Beans
* http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html
*/
@Asynchronous
public FutureDate updateGoogleCalendarPostEditAsync(Date
tripDateToBePlacedInQueue) {
String log;
Date tripDate =
usersController.queueDateAndOrUpdateGoogleCalendar(tripDateToBePlacedInQueue);
if (tripDate == null) {
return new AsyncResult(tripDate);
}
performingGoogleCalendarMaintenace = true;
try {
if (usersController.googleCalendarHasEvents()) {
usersController.deleteEvents(tripDate, tripDate);
}
String tripDateFrom =
displayUtil.getDateFromDateTime(tripDate,
false);
String tripDateTo =
displayUtil.getDateFromDateTime(tripDate,
false);
ListOrders list =
getFacade().findAllConfirmed(tripDateFrom,
tripDateTo, true);
if (list != null) {
for (Orders o : list) {
usersController.addEventToCalendar(newGoogleCalendarEvent(o));
}
}
log =
pf_OrdersController.updateGoogleCalendarPostEditAsync():
+
new DateTime(tripDate).toString(MM/dd/) +
processed successfully;
} catch (Exception e) {
e.printStackTrace();
messages.addFormErrorMsg(Error updating Google
Calendar,
(e.getMessage() != null) ? e.getMessage() : );
log =
pf_OrdersController.updateGoogleCalendarPostEditAsync():
+
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
I want to know why it didn't work either. I am using latest version of TomEE (1.5 SNAPSHOT), Myfaces 2.1.9, and CODI. Didn't work almost 12 hours ago, when I was attempting to use it. Did you all test @Advanced with @FacesConverter(forClass=someClass.class)? That's how I was using it, and bean was not injected inside of the converter. I read in at least 2 places that stated that @FacesConverter is not an elligble injection point, and I think you already told me (within last few hours) that this will be available in JSF 2.2. :) On Tue, Nov 20, 2012 at 9:22 AM, Mark Struberg strub...@yahoo.de wrote: CDI injection using @Advanced should work perfectly fine. We tested this excessively and use it on several containers in production. I'm curious why it doesn't work for you. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano rmpest...@yahoo.com.br Cc: Sent: Tuesday, November 20, 2012 3:13 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i'm still not clear about your goal and where you need injection maybe share a (runnable) sample to show us what you are talking about side note: myfaces list can help you a lot about it too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Interesting, that will allow you to get instance of beans, if already instantiated, and that could have helped in converter, only if beans already injected earlier? On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: was thinking to http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html getAttributes() method (depend a bit on your real need) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com
Re: Migrating to CDI: @Asynchronous
Dropping OpenEJB as we are now back to core JSF and related. I don't want to spam them ;) 1.): each container has pros and cons. And each of them needs different workarounds in edge cases :) 2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1]. What is a good example or use case for using CDI events? Oh there are plenty! You just need to understand that CDI events != messages. CDI events are _always_ synchronous and only get delivered to beans in currently active contexts. E.g. if you fire a CDI event and have a public @SessionScoped class User then only the contextual instance 'User' from the current session will receive the event. You can think about CDI events as a method invocation where you do not know on which (and how many) instances you invoke it. A practical use case. In our application we have a big fat menu. The menu content is depending on the language of the user and his privileges. Since this can change on a language change or if the user logs in/out, etc most apps always re-calculate the whole MenuItem tree from the database. What we did in our application is the following: Menu is a @SessionScoped cdi bean and we do NOT re-calculate the items for every request. Instead we fire a UserSettingsChangedEvent on each language change and login/logout. In the Menu bean (and a lot other places) we @Observes UserSettingsChangedEvent and reload the menu in that case. This performs vastly better and allows us to radically cache lots of things. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-218 From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: us...@openejb.apache.org us...@openejb.apache.org Sent: Tuesday, November 20, 2012 3:56 PM Subject: Re: Migrating to CDI: @Asynchronous Mark, Cool beans and agreed about @Asynchronous! Since I read about @Asynchronous on Stackoverflow.com (a post by David Blevins), I decided to give it a try, but I think I did read that 'asynchronous' (runnable, etc...) tasks are not all that good in web application. So, while you were writing your reply, I was already commenting out the call to the @Asynchronous method, and I reverted to the synchronous version of the method to update Google Calendar. After adding @Asynchronous, I added some logic that works better than @Asynchronous, it will not do a google calendar update on 'every' database update; I have some strategic processing in place that brought the # of google calendar requests down by hundreds and even thousands on a daily average. You know what? I attempted to add to META-INF as well as WEB-INF (some days ago), and I already reported (in an earlier post) that that didn't allow my web app to start in TomEE (or Glassfish, if I was still using Glassfish when I reported that earlier...smile). In response to Eclipse...hopefully, no offense will be taken, i'm not a user of eclipse, I've been a user of NetBeans ever since I started developing JSF web application (since last summer, 2011), and I can be the loyal type if something or someone treats me good. I was 'loyal' to Mojarra, but then I heard about the Mojarra issues updating components via AJAX, so I migrated to MyFaces Core (when I heard MyFaces Core 2.1.7+ performs better than Mojarra), and then reading one of your posts, Mark, about OpenWebBeans performing fast, and JIRA's and many people mentioning that CDI is better than JSF managed beans, I decided to migrate to CDI, and determined to use any/all features available that is offered by CDI, like events, SSE (server sent events), push (like Atmosphere), etc... Was having trouble using Atmosphere with Glassfish, so decided to give TomEE a whirl, since you, Andy Bailey (a friend in PrimeFaces forum), and others recommended TomEE. I like all that Glassfish 'markets' (or tries to sell) to JSF developers, but I'm liking what I see and hear about TomEE, OpenWebBeans, OpenEJB, etc... What is a good example or use case for using CDI events? Thanks, Howard On Tue, Nov 20, 2012 at 9:36 AM, Mark Struberg strub...@yahoo.de wrote: Hi! One of my first advice is to make sure that beans.xml is really there for the container. I've seen this pretty often if someone starts the webapp directly from Eclipse. In that case the CDI container sometimes cannot find WEB-INF/beans.xml as eclipse doesn't set the classpath entries correctly. Sometimes it helps to add a META-INF/beans.xml to the webapp classpath. This will end up in WEB-INF/classes/META-INF/beans.xml and is perfectly fine from a spec perspective. There's a 30% chance that this is your problem ;) For the @Asynchronous: In general I do not really like @Asynchronous in webapps. It's really very seldom
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
Nope, I'm mostly using it with @JsfPhaseListeners. We also don't have unit tests in CODI for converters. Please try BeanManagerProvider.getInstance().getContextualReference(Yourclass.class); inside the converter if you need it. If it's a NormalScoped bean (Request-, Application-, SessionScoped, CODI scopes) then you only need to do this once as you only get a proxy anyway. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Tuesday, November 20, 2012 4:03 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext I want to know why it didn't work either. I am using latest version of TomEE (1.5 SNAPSHOT), Myfaces 2.1.9, and CODI. Didn't work almost 12 hours ago, when I was attempting to use it. Did you all test @Advanced with @FacesConverter(forClass=someClass.class)? That's how I was using it, and bean was not injected inside of the converter. I read in at least 2 places that stated that @FacesConverter is not an elligble injection point, and I think you already told me (within last few hours) that this will be available in JSF 2.2. :) On Tue, Nov 20, 2012 at 9:22 AM, Mark Struberg strub...@yahoo.de wrote: CDI injection using @Advanced should work perfectly fine. We tested this excessively and use it on several containers in production. I'm curious why it doesn't work for you. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano rmpest...@yahoo.com.br Cc: Sent: Tuesday, November 20, 2012 3:13 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i'm still not clear about your goal and where you need injection maybe share a (runnable) sample to show us what you are talking about side note: myfaces list can help you a lot about it too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Interesting, that will allow you to get instance of beans, if already instantiated, and that could have helped in converter, only if beans already injected earlier? On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: was thinking to
Re: Migrating to CDI: @Asynchronous
Well, you and others 'sold' me onto TomEE, so here I am. If I can get this migration to TomEE and CDI complete, and my endusers are happy, then more than likely, I will remain TomEE (supporter and user) for life, and will not plan to return to Glassfish. :) In production, my (PrimeFaces 3.4.1) app is running so fast with Glassfish 3.1.2.2 and MyFaces Core 2.1.9, and JUEL (on an old Windows Server 2003 Dell server), so I hope TomEE and CDI will beat out the performance I currently have in production, and I'm positive that it will...since OpenWebBeans is fast (like you said in one of your blogs/posts). :) Since I started using TomEE, it seems as though you all recommend HSQLDB; I'm currently using 'Apache' Derby and that's working great, but I saw some benchmark tests that OpenJPA and HSQLDB performs much better than OpenJPA/Derby and EclipseLink/Derby. Right now, I'm using EclipseLink. I may look into migrating from Derby to HSQL when I have plenty of time to do so, but I rather do more fun 'java' programming than SQL programming right now. I'm sure you can understand that. I think the biggest bottleneck in my app is the database and probably the machine it's running on. And trust me, I've read how to tune Derby for performance and I think I did all I could to tune my Derby database. :) Wow, interesting. Thanks for sharing that about CDI events. It's funny that you said that CDI events != messages. :) I need to study the CDI tutorials and blogs a bit, so I can learn how to use CDI events. I really would like to use it whereever possible/applicable. :) On Tue, Nov 20, 2012 at 10:18 AM, Mark Struberg strub...@yahoo.de wrote: Dropping OpenEJB as we are now back to core JSF and related. I don't want to spam them ;) 1.): each container has pros and cons. And each of them needs different workarounds in edge cases :) 2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1]. What is a good example or use case for using CDI events? Oh there are plenty! You just need to understand that CDI events != messages. CDI events are _always_ synchronous and only get delivered to beans in currently active contexts. E.g. if you fire a CDI event and have a public @SessionScoped class User then only the contextual instance 'User' from the current session will receive the event. You can think about CDI events as a method invocation where you do not know on which (and how many) instances you invoke it. A practical use case. In our application we have a big fat menu. The menu content is depending on the language of the user and his privileges. Since this can change on a language change or if the user logs in/out, etc most apps always re-calculate the whole MenuItem tree from the database. What we did in our application is the following: Menu is a @SessionScoped cdi bean and we do NOT re-calculate the items for every request. Instead we fire a UserSettingsChangedEvent on each language change and login/logout. In the Menu bean (and a lot other places) we @Observes UserSettingsChangedEvent and reload the menu in that case. This performs vastly better and allows us to radically cache lots of things. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-218 From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: us...@openejb.apache.org us...@openejb.apache.org Sent: Tuesday, November 20, 2012 3:56 PM Subject: Re: Migrating to CDI: @Asynchronous Mark, Cool beans and agreed about @Asynchronous! Since I read about @Asynchronous on Stackoverflow.com (a post by David Blevins), I decided to give it a try, but I think I did read that 'asynchronous' (runnable, etc...) tasks are not all that good in web application. So, while you were writing your reply, I was already commenting out the call to the @Asynchronous method, and I reverted to the synchronous version of the method to update Google Calendar. After adding @Asynchronous, I added some logic that works better than @Asynchronous, it will not do a google calendar update on 'every' database update; I have some strategic processing in place that brought the # of google calendar requests down by hundreds and even thousands on a daily average. You know what? I attempted to add to META-INF as well as WEB-INF (some days ago), and I already reported (in an earlier post) that that didn't allow my web app to start in TomEE (or Glassfish, if I was still using Glassfish when I reported that earlier...smile). In response to Eclipse...hopefully, no offense will be taken, i'm not a user of eclipse, I've been a user of NetBeans ever since I started developing JSF web application (since last summer, 2011), and I can be the loyal type if
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
Okay. I've already completed 'hours' of work having a java package filled with JSF (requestscoped) managed beans that 'only' contain @FacesConverter(forClass=someClass.class) for each of my database entity classes; did that last night. I may try to test what you recommended below for injecting beans in @Facesconverter. Question, in the foreseeable future (JSF 2.2+), what kind of performance issues will I have if 99% of my app is CDI and only @FacesConverter is defined/implemented in JSF requestscoped managed beans? Your answer may motivate me to use your suggestion below and add the @Facesconverters back to the CDI @SessionScoped beans (where the @FacesConverter's originally were defined). Thanks! On Tue, Nov 20, 2012 at 10:24 AM, Mark Struberg strub...@yahoo.de wrote: Nope, I'm mostly using it with @JsfPhaseListeners. We also don't have unit tests in CODI for converters. Please try BeanManagerProvider.getInstance().getContextualReference(Yourclass.class); inside the converter if you need it. If it's a NormalScoped bean (Request-, Application-, SessionScoped, CODI scopes) then you only need to do this once as you only get a proxy anyway. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Tuesday, November 20, 2012 4:03 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext I want to know why it didn't work either. I am using latest version of TomEE (1.5 SNAPSHOT), Myfaces 2.1.9, and CODI. Didn't work almost 12 hours ago, when I was attempting to use it. Did you all test @Advanced with @FacesConverter(forClass=someClass.class)? That's how I was using it, and bean was not injected inside of the converter. I read in at least 2 places that stated that @FacesConverter is not an elligble injection point, and I think you already told me (within last few hours) that this will be available in JSF 2.2. :) On Tue, Nov 20, 2012 at 9:22 AM, Mark Struberg strub...@yahoo.de wrote: CDI injection using @Advanced should work perfectly fine. We tested this excessively and use it on several containers in production. I'm curious why it doesn't work for you. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano rmpest...@yahoo.com.br Cc: Sent: Tuesday, November 20, 2012 3:13 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau
Re: Migrating to CDI: @Asynchronous
Sorry for the off topic, but if you think that your biggest bottleneck is in your data-layer, you should give batoo jpa a try ;) 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Well, you and others 'sold' me onto TomEE, so here I am. If I can get this migration to TomEE and CDI complete, and my endusers are happy, then more than likely, I will remain TomEE (supporter and user) for life, and will not plan to return to Glassfish. :) In production, my (PrimeFaces 3.4.1) app is running so fast with Glassfish 3.1.2.2 and MyFaces Core 2.1.9, and JUEL (on an old Windows Server 2003 Dell server), so I hope TomEE and CDI will beat out the performance I currently have in production, and I'm positive that it will...since OpenWebBeans is fast (like you said in one of your blogs/posts). :) Since I started using TomEE, it seems as though you all recommend HSQLDB; I'm currently using 'Apache' Derby and that's working great, but I saw some benchmark tests that OpenJPA and HSQLDB performs much better than OpenJPA/Derby and EclipseLink/Derby. Right now, I'm using EclipseLink. I may look into migrating from Derby to HSQL when I have plenty of time to do so, but I rather do more fun 'java' programming than SQL programming right now. I'm sure you can understand that. I think the biggest bottleneck in my app is the database and probably the machine it's running on. And trust me, I've read how to tune Derby for performance and I think I did all I could to tune my Derby database. :) Wow, interesting. Thanks for sharing that about CDI events. It's funny that you said that CDI events != messages. :) I need to study the CDI tutorials and blogs a bit, so I can learn how to use CDI events. I really would like to use it whereever possible/applicable. :) On Tue, Nov 20, 2012 at 10:18 AM, Mark Struberg strub...@yahoo.de wrote: Dropping OpenEJB as we are now back to core JSF and related. I don't want to spam them ;) 1.): each container has pros and cons. And each of them needs different workarounds in edge cases :) 2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1]. What is a good example or use case for using CDI events? Oh there are plenty! You just need to understand that CDI events != messages. CDI events are _always_ synchronous and only get delivered to beans in currently active contexts. E.g. if you fire a CDI event and have a public @SessionScoped class User then only the contextual instance 'User' from the current session will receive the event. You can think about CDI events as a method invocation where you do not know on which (and how many) instances you invoke it. A practical use case. In our application we have a big fat menu. The menu content is depending on the language of the user and his privileges. Since this can change on a language change or if the user logs in/out, etc most apps always re-calculate the whole MenuItem tree from the database. What we did in our application is the following: Menu is a @SessionScoped cdi bean and we do NOT re-calculate the items for every request. Instead we fire a UserSettingsChangedEvent on each language change and login/logout. In the Menu bean (and a lot other places) we @Observes UserSettingsChangedEvent and reload the menu in that case. This performs vastly better and allows us to radically cache lots of things. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-218 From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: us...@openejb.apache.org us...@openejb.apache.org Sent: Tuesday, November 20, 2012 3:56 PM Subject: Re: Migrating to CDI: @Asynchronous Mark, Cool beans and agreed about @Asynchronous! Since I read about @Asynchronous on Stackoverflow.com (a post by David Blevins), I decided to give it a try, but I think I did read that 'asynchronous' (runnable, etc...) tasks are not all that good in web application. So, while you were writing your reply, I was already commenting out the call to the @Asynchronous method, and I reverted to the synchronous version of the method to update Google Calendar. After adding @Asynchronous, I added some logic that works better than @Asynchronous, it will not do a google calendar update on 'every' database update; I have some strategic processing in place that brought the # of google calendar requests down by hundreds and even thousands on a daily average. You know what? I attempted to add to META-INF as well as WEB-INF (some days ago), and I already reported (in an earlier post) that that didn't allow my web app to start in TomEE (or Glassfish, if I was
Re: Migrating to CDI: @Asynchronous
Thomas, I'm trying to use batoo-jpa now, but the dependencies include transaction JAR that may be 'ignored' by TomEE container. Everytime I start TomEE (or deploy to app from NetBeans 7.2), the following shows up in my server log: Nov 20, 2012 11:44:43 AM org.apache.tomee.catalina.TomEEClassLoaderEnricher validateJarFile WARNING: jar 'C:\Users\Public\NetBeansProjects\mcms\build\web\WEB-INF\lib\transaction-api-1.1.jar' contains offending class: javax.transaction.Transaction. It will be ignored. Also, there are so many dependencies for batoo-jpa. Still trying... On Tue, Nov 20, 2012 at 10:43 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Sorry for the off topic, but if you think that your biggest bottleneck is in your data-layer, you should give batoo jpa a try ;) 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Well, you and others 'sold' me onto TomEE, so here I am. If I can get this migration to TomEE and CDI complete, and my endusers are happy, then more than likely, I will remain TomEE (supporter and user) for life, and will not plan to return to Glassfish. :) In production, my (PrimeFaces 3.4.1) app is running so fast with Glassfish 3.1.2.2 and MyFaces Core 2.1.9, and JUEL (on an old Windows Server 2003 Dell server), so I hope TomEE and CDI will beat out the performance I currently have in production, and I'm positive that it will...since OpenWebBeans is fast (like you said in one of your blogs/posts). :) Since I started using TomEE, it seems as though you all recommend HSQLDB; I'm currently using 'Apache' Derby and that's working great, but I saw some benchmark tests that OpenJPA and HSQLDB performs much better than OpenJPA/Derby and EclipseLink/Derby. Right now, I'm using EclipseLink. I may look into migrating from Derby to HSQL when I have plenty of time to do so, but I rather do more fun 'java' programming than SQL programming right now. I'm sure you can understand that. I think the biggest bottleneck in my app is the database and probably the machine it's running on. And trust me, I've read how to tune Derby for performance and I think I did all I could to tune my Derby database. :) Wow, interesting. Thanks for sharing that about CDI events. It's funny that you said that CDI events != messages. :) I need to study the CDI tutorials and blogs a bit, so I can learn how to use CDI events. I really would like to use it whereever possible/applicable. :) On Tue, Nov 20, 2012 at 10:18 AM, Mark Struberg strub...@yahoo.de wrote: Dropping OpenEJB as we are now back to core JSF and related. I don't want to spam them ;) 1.): each container has pros and cons. And each of them needs different workarounds in edge cases :) 2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1]. What is a good example or use case for using CDI events? Oh there are plenty! You just need to understand that CDI events != messages. CDI events are _always_ synchronous and only get delivered to beans in currently active contexts. E.g. if you fire a CDI event and have a public @SessionScoped class User then only the contextual instance 'User' from the current session will receive the event. You can think about CDI events as a method invocation where you do not know on which (and how many) instances you invoke it. A practical use case. In our application we have a big fat menu. The menu content is depending on the language of the user and his privileges. Since this can change on a language change or if the user logs in/out, etc most apps always re-calculate the whole MenuItem tree from the database. What we did in our application is the following: Menu is a @SessionScoped cdi bean and we do NOT re-calculate the items for every request. Instead we fire a UserSettingsChangedEvent on each language change and login/logout. In the Menu bean (and a lot other places) we @Observes UserSettingsChangedEvent and reload the menu in that case. This performs vastly better and allows us to radically cache lots of things. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-218 From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: us...@openejb.apache.org us...@openejb.apache.org Sent: Tuesday, November 20, 2012 3:56 PM Subject: Re: Migrating to CDI: @Asynchronous Mark, Cool beans and agreed about @Asynchronous! Since I read about @Asynchronous on Stackoverflow.com (a post by David Blevins), I decided to give it a try, but I think I did read that 'asynchronous' (runnable,
Re: Migrating to CDI: @Asynchronous
Also, my persistence.xml has the following: persistence version=2.0 xmlns=http://java.sun.com/xml/ns/persistence; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd; persistence-unit name=mcmsPU transaction-type=JTA !--providerorg.eclipse.persistence.jpa.PersistenceProvider/provider-- providerorg.batoo.jpa.core.BatooPersistenceProvider/provider jta-data-sourcejdbc/mcms/jta-data-source exclude-unlisted-classesfalse/exclude-unlisted-classes properties/ /persistence-unit /persistence On Tue, Nov 20, 2012 at 11:50 AM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Thomas, I'm trying to use batoo-jpa now, but the dependencies include transaction JAR that may be 'ignored' by TomEE container. Everytime I start TomEE (or deploy to app from NetBeans 7.2), the following shows up in my server log: Nov 20, 2012 11:44:43 AM org.apache.tomee.catalina.TomEEClassLoaderEnricher validateJarFile WARNING: jar 'C:\Users\Public\NetBeansProjects\mcms\build\web\WEB-INF\lib\transaction-api-1.1.jar' contains offending class: javax.transaction.Transaction. It will be ignored. Also, there are so many dependencies for batoo-jpa. Still trying... On Tue, Nov 20, 2012 at 10:43 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Sorry for the off topic, but if you think that your biggest bottleneck is in your data-layer, you should give batoo jpa a try ;) 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Well, you and others 'sold' me onto TomEE, so here I am. If I can get this migration to TomEE and CDI complete, and my endusers are happy, then more than likely, I will remain TomEE (supporter and user) for life, and will not plan to return to Glassfish. :) In production, my (PrimeFaces 3.4.1) app is running so fast with Glassfish 3.1.2.2 and MyFaces Core 2.1.9, and JUEL (on an old Windows Server 2003 Dell server), so I hope TomEE and CDI will beat out the performance I currently have in production, and I'm positive that it will...since OpenWebBeans is fast (like you said in one of your blogs/posts). :) Since I started using TomEE, it seems as though you all recommend HSQLDB; I'm currently using 'Apache' Derby and that's working great, but I saw some benchmark tests that OpenJPA and HSQLDB performs much better than OpenJPA/Derby and EclipseLink/Derby. Right now, I'm using EclipseLink. I may look into migrating from Derby to HSQL when I have plenty of time to do so, but I rather do more fun 'java' programming than SQL programming right now. I'm sure you can understand that. I think the biggest bottleneck in my app is the database and probably the machine it's running on. And trust me, I've read how to tune Derby for performance and I think I did all I could to tune my Derby database. :) Wow, interesting. Thanks for sharing that about CDI events. It's funny that you said that CDI events != messages. :) I need to study the CDI tutorials and blogs a bit, so I can learn how to use CDI events. I really would like to use it whereever possible/applicable. :) On Tue, Nov 20, 2012 at 10:18 AM, Mark Struberg strub...@yahoo.de wrote: Dropping OpenEJB as we are now back to core JSF and related. I don't want to spam them ;) 1.): each container has pros and cons. And each of them needs different workarounds in edge cases :) 2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1]. What is a good example or use case for using CDI events? Oh there are plenty! You just need to understand that CDI events != messages. CDI events are _always_ synchronous and only get delivered to beans in currently active contexts. E.g. if you fire a CDI event and have a public @SessionScoped class User then only the contextual instance 'User' from the current session will receive the event. You can think about CDI events as a method invocation where you do not know on which (and how many) instances you invoke it. A practical use case. In our application we have a big fat menu. The menu content is depending on the language of the user and his privileges. Since this can change on a language change or if the user logs in/out, etc most apps always re-calculate the whole MenuItem tree from the database. What we did in our application is the following: Menu is a @SessionScoped cdi bean and we do NOT re-calculate the items for every request. Instead we fire a UserSettingsChangedEvent on each language change and login/logout. In the Menu bean (and a lot other places) we @Observes
Re: Migrating to CDI: @Asynchronous
Mark, I confirmed and 'opted' to do the same as what you mentioned below, and web app is working fine. I 'moved' beans.xml from WEB-INF to META-INF, and app is running well, and running same as when beans.xml was in WEB-INF. I'll keep beans.xml in META-INF as per your recommendation. *2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1].* Please note, (temporarily) commenting out @Asynchronous method calls in my app most likely resolved the issue in OP. Thanks, Howard On Tue, Nov 20, 2012 at 10:18 AM, Mark Struberg strub...@yahoo.de wrote: Dropping OpenEJB as we are now back to core JSF and related. I don't want to spam them ;) 1.): each container has pros and cons. And each of them needs different workarounds in edge cases :) 2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1]. What is a good example or use case for using CDI events? Oh there are plenty! You just need to understand that CDI events != messages. CDI events are _always_ synchronous and only get delivered to beans in currently active contexts. E.g. if you fire a CDI event and have a public @SessionScoped class User then only the contextual instance 'User' from the current session will receive the event. You can think about CDI events as a method invocation where you do not know on which (and how many) instances you invoke it. A practical use case. In our application we have a big fat menu. The menu content is depending on the language of the user and his privileges. Since this can change on a language change or if the user logs in/out, etc most apps always re-calculate the whole MenuItem tree from the database. What we did in our application is the following: Menu is a @SessionScoped cdi bean and we do NOT re-calculate the items for every request. Instead we fire a UserSettingsChangedEvent on each language change and login/logout. In the Menu bean (and a lot other places) we @Observes UserSettingsChangedEvent and reload the menu in that case. This performs vastly better and allows us to radically cache lots of things. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-218 From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: us...@openejb.apache.org us...@openejb.apache.org Sent: Tuesday, November 20, 2012 3:56 PM Subject: Re: Migrating to CDI: @Asynchronous Mark, Cool beans and agreed about @Asynchronous! Since I read about @Asynchronous on Stackoverflow.com (a post by David Blevins), I decided to give it a try, but I think I did read that 'asynchronous' (runnable, etc...) tasks are not all that good in web application. So, while you were writing your reply, I was already commenting out the call to the @Asynchronous method, and I reverted to the synchronous version of the method to update Google Calendar. After adding @Asynchronous, I added some logic that works better than @Asynchronous, it will not do a google calendar update on 'every' database update; I have some strategic processing in place that brought the # of google calendar requests down by hundreds and even thousands on a daily average. You know what? I attempted to add to META-INF as well as WEB-INF (some days ago), and I already reported (in an earlier post) that that didn't allow my web app to start in TomEE (or Glassfish, if I was still using Glassfish when I reported that earlier...smile). In response to Eclipse...hopefully, no offense will be taken, i'm not a user of eclipse, I've been a user of NetBeans ever since I started developing JSF web application (since last summer, 2011), and I can be the loyal type if something or someone treats me good. I was 'loyal' to Mojarra, but then I heard about the Mojarra issues updating components via AJAX, so I migrated to MyFaces Core (when I heard MyFaces Core 2.1.7+ performs better than Mojarra), and then reading one of your posts, Mark, about OpenWebBeans performing fast, and JIRA's and many people mentioning that CDI is better than JSF managed beans, I decided to migrate to CDI, and determined to use any/all features available that is offered by CDI, like events, SSE (server sent events), push (like Atmosphere), etc... Was having trouble using Atmosphere with Glassfish, so decided to give TomEE a whirl, since you, Andy Bailey (a friend in PrimeFaces forum), and others recommended TomEE. I like all that Glassfish 'markets' (or tries to sell) to JSF developers, but I'm liking what I see and hear about TomEE, OpenWebBeans, OpenEJB, etc... What is a good example or use case for
Re: Migrating to CDI: @Asynchronous
Doh, NetBeans is probably not following the specification, because NetBeans has squiggly line under the bean class name, and has the following as a tip: CDI artifact is found but there is no beans.xml file. So, to avoid this, I need to have beans.xml in WEB-INF instead of META-INF. Per what I read in Java EE 6 tutorial (CDI) and other articles online, it seems as though beans.xml is supposed to be placed in META-INF, if you have JARs that you've developed that is referenced by the app. I could be saying this incorrectly. :) On Tue, Nov 20, 2012 at 1:57 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Mark, I confirmed and 'opted' to do the same as what you mentioned below, and web app is working fine. I 'moved' beans.xml from WEB-INF to META-INF, and app is running well, and running same as when beans.xml was in WEB-INF. I'll keep beans.xml in META-INF as per your recommendation. *2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1].* Please note, (temporarily) commenting out @Asynchronous method calls in my app most likely resolved the issue in OP. Thanks, Howard On Tue, Nov 20, 2012 at 10:18 AM, Mark Struberg strub...@yahoo.de wrote: Dropping OpenEJB as we are now back to core JSF and related. I don't want to spam them ;) 1.): each container has pros and cons. And each of them needs different workarounds in edge cases :) 2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1]. What is a good example or use case for using CDI events? Oh there are plenty! You just need to understand that CDI events != messages. CDI events are _always_ synchronous and only get delivered to beans in currently active contexts. E.g. if you fire a CDI event and have a public @SessionScoped class User then only the contextual instance 'User' from the current session will receive the event. You can think about CDI events as a method invocation where you do not know on which (and how many) instances you invoke it. A practical use case. In our application we have a big fat menu. The menu content is depending on the language of the user and his privileges. Since this can change on a language change or if the user logs in/out, etc most apps always re-calculate the whole MenuItem tree from the database. What we did in our application is the following: Menu is a @SessionScoped cdi bean and we do NOT re-calculate the items for every request. Instead we fire a UserSettingsChangedEvent on each language change and login/logout. In the Menu bean (and a lot other places) we @Observes UserSettingsChangedEvent and reload the menu in that case. This performs vastly better and allows us to radically cache lots of things. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-218 From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: us...@openejb.apache.org us...@openejb.apache.org Sent: Tuesday, November 20, 2012 3:56 PM Subject: Re: Migrating to CDI: @Asynchronous Mark, Cool beans and agreed about @Asynchronous! Since I read about @Asynchronous on Stackoverflow.com (a post by David Blevins), I decided to give it a try, but I think I did read that 'asynchronous' (runnable, etc...) tasks are not all that good in web application. So, while you were writing your reply, I was already commenting out the call to the @Asynchronous method, and I reverted to the synchronous version of the method to update Google Calendar. After adding @Asynchronous, I added some logic that works better than @Asynchronous, it will not do a google calendar update on 'every' database update; I have some strategic processing in place that brought the # of google calendar requests down by hundreds and even thousands on a daily average. You know what? I attempted to add to META-INF as well as WEB-INF (some days ago), and I already reported (in an earlier post) that that didn't allow my web app to start in TomEE (or Glassfish, if I was still using Glassfish when I reported that earlier...smile). In response to Eclipse...hopefully, no offense will be taken, i'm not a user of eclipse, I've been a user of NetBeans ever since I started developing JSF web application (since last summer, 2011), and I can be the loyal type if something or someone treats me good. I was 'loyal' to Mojarra, but then I heard about the Mojarra issues updating components via AJAX, so I migrated to MyFaces Core (when I heard MyFaces Core 2.1.7+ performs better than Mojarra), and then reading one of your posts, Mark, about OpenWebBeans performing fast,
Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans
hi howard, @ codi (documentation and setup): see [1] (and e.g. [2]) + you can generate a simple demo e.g. with mvn archetype:generate -DarchetypeCatalog= http://people.apache.org/~gpetracek/myfaces/ (it's a subset of mvn archetype:generate -DarchetypeCatalog= http://myfaces.apache.org) and as suggested by mark, you can have a look at tomee. regards, gerhard [1] https://cwiki.apache.org/confluence/display/EXTCDI/Index [2] https://cwiki.apache.org/confluence/display/EXTCDI/Module+Overview 2012/11/17 Howard W. Smith, Jr. smithh032...@gmail.com Web application details: JSF 2.1, MyFaces 2.1.9, PrimeFaces 3.4.1 (or 3.5-SNAPSHOT), Glassfish 3.1.2.2 (build 5), JUEL 2.2.5 From server log: INFO: WELD-000900 1.1.8 (Final) Yesterday, I started migrating from JSF Managed Beans to CDI Managed Beans. I referred to Chapter 28 (CDI) of Oracle's Java EE 6 Tutorialhttp://docs.oracle.com/javaee/6/tutorial/doc/giwhb.htmlas well as many other pages I found on the internet. Finally, the app starts, as I think I completed most steps necessary to migrate to CDI managed beans, but now it seems as though my beans are not accessible from facelets. As per MYFACES-3104https://issues.apache.org/jira/browse/MYFACES-3104, I am already using *JUEL 2.2.5* (that is working well with JSF Managed Beans in production), so I already had * org.apache.myfaces.EXPRESSION_FACTORY* set in web.xml, as well as *org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL *to *false*, and the last thing I did was add the following to web.xml: context-param param-nameorg.apache.myfaces.annotation.SCAN_PACKAGES/param-name param-valuepf,jsf.users,jsf.orders/param-value /context-param Which are just a 'few' of the packages that contained beans referenced by the initial page of the app (login.xhtml). My questions: 1. Can someone please advise me of blog/tutorials that list any/all steps necessary to migrate MyFaces 2.1.9 / Glassfish 3.1.2.2 web app from JSF Managed Beans to CDI? 2. I am not using MyFaces CODI or OpenWebBeans (yet). I've seen OpenWebBeans recommended with MyFaces Core (2.1.7+) for performance reasons, and in PrimeFaces forum, I've seen MyFaces Core and MyFaces CODI used together by some people. If I should use MyFaces CODI or OpenWebBeans, please reply with blog/tutorial/instruction URLs. My next steps will probably be any/all of the following: 1. Remove JUEL 2.2.5 from the project, and see if I can successfully get my pages to render via CDI 2. Add MyFaces CODI (need to search for a good set of instructions on how to do so) 3. Add OpenWebBeans (same as above, need good set of instructions) Please confirm/advise. If you need any more details from me (for example, for me to reply with my web.xml), then please let me know. Thanks, Howard
Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans
Gerhard, Thanks for the response. I've actually progressed quite well with migration to TomEE and CDI. I'm sure you will see my emails here on this mailing list of any/all questions that I have. I want to thank you all for the responses. This actually is the first forum where I get responses almost immediately and almost with every email that I send to the mailing list. I am still in the progress of migrating from Glassfish 3.1.2.2 and JSF managed beans to TomEE/OpenEJB/OpenWebBeans/CDI, and apache user groups have been a huge help so far. So thanks! :) Howard On Tue, Nov 20, 2012 at 3:23 PM, Gerhard Petracek gpetra...@apache.orgwrote: hi howard, @ codi (documentation and setup): see [1] (and e.g. [2]) + you can generate a simple demo e.g. with mvn archetype:generate -DarchetypeCatalog= http://people.apache.org/~gpetracek/myfaces/ (it's a subset of mvn archetype:generate -DarchetypeCatalog= http://myfaces.apache.org) and as suggested by mark, you can have a look at tomee. regards, gerhard [1] https://cwiki.apache.org/confluence/display/EXTCDI/Index [2] https://cwiki.apache.org/confluence/display/EXTCDI/Module+Overview 2012/11/17 Howard W. Smith, Jr. smithh032...@gmail.com Web application details: JSF 2.1, MyFaces 2.1.9, PrimeFaces 3.4.1 (or 3.5-SNAPSHOT), Glassfish 3.1.2.2 (build 5), JUEL 2.2.5 From server log: INFO: WELD-000900 1.1.8 (Final) Yesterday, I started migrating from JSF Managed Beans to CDI Managed Beans. I referred to Chapter 28 (CDI) of Oracle's Java EE 6 Tutorialhttp://docs.oracle.com/javaee/6/tutorial/doc/giwhb.htmlas well as many other pages I found on the internet. Finally, the app starts, as I think I completed most steps necessary to migrate to CDI managed beans, but now it seems as though my beans are not accessible from facelets. As per MYFACES-3104https://issues.apache.org/jira/browse/MYFACES-3104, I am already using *JUEL 2.2.5* (that is working well with JSF Managed Beans in production), so I already had * org.apache.myfaces.EXPRESSION_FACTORY* set in web.xml, as well as *org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL *to *false*, and the last thing I did was add the following to web.xml: context-param param-nameorg.apache.myfaces.annotation.SCAN_PACKAGES/param-name param-valuepf,jsf.users,jsf.orders/param-value /context-param Which are just a 'few' of the packages that contained beans referenced by the initial page of the app (login.xhtml). My questions: 1. Can someone please advise me of blog/tutorials that list any/all steps necessary to migrate MyFaces 2.1.9 / Glassfish 3.1.2.2 web app from JSF Managed Beans to CDI? 2. I am not using MyFaces CODI or OpenWebBeans (yet). I've seen OpenWebBeans recommended with MyFaces Core (2.1.7+) for performance reasons, and in PrimeFaces forum, I've seen MyFaces Core and MyFaces CODI used together by some people. If I should use MyFaces CODI or OpenWebBeans, please reply with blog/tutorial/instruction URLs. My next steps will probably be any/all of the following: 1. Remove JUEL 2.2.5 from the project, and see if I can successfully get my pages to render via CDI 2. Add MyFaces CODI (need to search for a good set of instructions on how to do so) 3. Add OpenWebBeans (same as above, need good set of instructions) Please confirm/advise. If you need any more details from me (for example, for me to reply with my web.xml), then please let me know. Thanks, Howard
Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans
yes - i sent this message a while ago from a different box (it looks like the sending process failed initially - so it was (re-)sent a bit too late...) you are welcome! regards, gerhard 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Gerhard, Thanks for the response. I've actually progressed quite well with migration to TomEE and CDI. I'm sure you will see my emails here on this mailing list of any/all questions that I have. I want to thank you all for the responses. This actually is the first forum where I get responses almost immediately and almost with every email that I send to the mailing list. I am still in the progress of migrating from Glassfish 3.1.2.2 and JSF managed beans to TomEE/OpenEJB/OpenWebBeans/CDI, and apache user groups have been a huge help so far. So thanks! :) Howard On Tue, Nov 20, 2012 at 3:23 PM, Gerhard Petracek gpetra...@apache.org wrote: hi howard, @ codi (documentation and setup): see [1] (and e.g. [2]) + you can generate a simple demo e.g. with mvn archetype:generate -DarchetypeCatalog= http://people.apache.org/~gpetracek/myfaces/ (it's a subset of mvn archetype:generate -DarchetypeCatalog= http://myfaces.apache.org) and as suggested by mark, you can have a look at tomee. regards, gerhard [1] https://cwiki.apache.org/confluence/display/EXTCDI/Index [2] https://cwiki.apache.org/confluence/display/EXTCDI/Module+Overview 2012/11/17 Howard W. Smith, Jr. smithh032...@gmail.com Web application details: JSF 2.1, MyFaces 2.1.9, PrimeFaces 3.4.1 (or 3.5-SNAPSHOT), Glassfish 3.1.2.2 (build 5), JUEL 2.2.5 From server log: INFO: WELD-000900 1.1.8 (Final) Yesterday, I started migrating from JSF Managed Beans to CDI Managed Beans. I referred to Chapter 28 (CDI) of Oracle's Java EE 6 Tutorialhttp://docs.oracle.com/javaee/6/tutorial/doc/giwhb.htmlas well as many other pages I found on the internet. Finally, the app starts, as I think I completed most steps necessary to migrate to CDI managed beans, but now it seems as though my beans are not accessible from facelets. As per MYFACES-3104https://issues.apache.org/jira/browse/MYFACES-3104, I am already using *JUEL 2.2.5* (that is working well with JSF Managed Beans in production), so I already had * org.apache.myfaces.EXPRESSION_FACTORY* set in web.xml, as well as *org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL *to *false*, and the last thing I did was add the following to web.xml: context-param param-nameorg.apache.myfaces.annotation.SCAN_PACKAGES/param-name param-valuepf,jsf.users,jsf.orders/param-value /context-param Which are just a 'few' of the packages that contained beans referenced by the initial page of the app (login.xhtml). My questions: 1. Can someone please advise me of blog/tutorials that list any/all steps necessary to migrate MyFaces 2.1.9 / Glassfish 3.1.2.2 web app from JSF Managed Beans to CDI? 2. I am not using MyFaces CODI or OpenWebBeans (yet). I've seen OpenWebBeans recommended with MyFaces Core (2.1.7+) for performance reasons, and in PrimeFaces forum, I've seen MyFaces Core and MyFaces CODI used together by some people. If I should use MyFaces CODI or OpenWebBeans, please reply with blog/tutorial/instruction URLs. My next steps will probably be any/all of the following: 1. Remove JUEL 2.2.5 from the project, and see if I can successfully get my pages to render via CDI 2. Add MyFaces CODI (need to search for a good set of instructions on how to do so) 3. Add OpenWebBeans (same as above, need good set of instructions) Please confirm/advise. If you need any more details from me (for example, for me to reply with my web.xml), then please let me know. Thanks, Howard
Re: Can start in debug, but not in release
The Hibernate serialisation issues look weird. What is your exact situation? Do you have an example of your app to share? LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Sent: Tuesday, November 20, 2012 8:16 PM Subject: Re: Can start in debug, but not in release hi ludovic, to get rid of ... no org.apache.myfaces.extensions.cdi.core.api.provider.BeanManagerProvider in place! ... you have to ensure that all config-files and owb jar-files you are using are packaged correctly. you can compare your war-file e.g. with a war-file of a generated demo generate it e.g. with #4 of: mvn archetype:generate -DarchetypeCatalog= http://people.apache.org/~gpetracek/myfaces/ regards, gerhard 2012/11/20 l.pe...@senat.fr l.pe...@senat.fr Dear all, I hope I am in the right forum as a Myfaces/CODI user, it seemed a natural entry point to me... I have a webapp which perfectly works in debug in eclipse, but does not start on the same tomcat 7.0.32 container. The app is build with maven. I am using Eclipse juno with wtp integration. In eclipse, tomcat startup parameters are : -Dcatalina.base=/home/lpenet/**workspace_cellule/.metadata/.** plugins/org.eclipse.wst.**server.core/tmp0 -Dcatalina.home=/opt/apache-* *tomcat-7.0.32 -Dwtp.deploy=/home/lpenet/**workspace_cellule/.metadata/. **plugins/org.eclipse.wst.**server.core/tmp0/wtpwebapps -Djava.endorsed.dirs=/opt/**apache-tomcat-7.0.32/endorsed -XX:MaxPermSize=512M -XX:+CMSClassUnloadingEnabled -Dorg.apache.el.parser.COERCE_**TO_ZERO=false (nothing special to me...) In bare tomcat, the following JAVA_OPTS are used : JAVA_OPTS=$JAVA_OPTS -XX:MaxPermSize=1024M -XX:+CMSClassUnloadingEnabled -Dorg.apache.el.parser.COERCE_**TO_ZERO=false (nothing special to me too...). Please find enclosed the corresponding logs. I also attach my web.xml, beans.xml and faces-context.xml. Do you have an idea ? Which logs can I turn on to get more info ? Thanks in advance. Ludovic Pénet | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
Mark, Please read/see below. Per your recommendation, Please try *BeanManagerProvider.getInstance().getContextualReference(Yourclass.class); inside the converter if you need it. If it's a NormalScoped bean (Request-, Application-, SessionScoped, CODI scopes) then you only need to do this once as you only get a proxy anyway. LieGrue, strub* I tried this, and this breaks PrimeFaces p:pickList p:ajax event=transfer. See/click URL below for my numerous tests, test results, and conclusion. :) Issue 4908 http://code.google.com/p/primefaces/issues/detail?id=4908 in PrimeFaces Issue Tracker Is this considered as an Apache CODI defect/issue or a lesson learned? Please confirm. Thanks, Howard On Tue, Nov 20, 2012 at 10:24 AM, Mark Struberg strub...@yahoo.de wrote: Nope, I'm mostly using it with @JsfPhaseListeners. We also don't have unit tests in CODI for converters. Please try BeanManagerProvider.getInstance().getContextualReference(Yourclass.class); inside the converter if you need it. If it's a NormalScoped bean (Request-, Application-, SessionScoped, CODI scopes) then you only need to do this once as you only get a proxy anyway. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Tuesday, November 20, 2012 4:03 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext I want to know why it didn't work either. I am using latest version of TomEE (1.5 SNAPSHOT), Myfaces 2.1.9, and CODI. Didn't work almost 12 hours ago, when I was attempting to use it. Did you all test @Advanced with @FacesConverter(forClass=someClass.class)? That's how I was using it, and bean was not injected inside of the converter. I read in at least 2 places that stated that @FacesConverter is not an elligble injection point, and I think you already told me (within last few hours) that this will be available in JSF 2.2. :) On Tue, Nov 20, 2012 at 9:22 AM, Mark Struberg strub...@yahoo.de wrote: CDI injection using @Advanced should work perfectly fine. We tested this excessively and use it on several containers in production. I'm curious why it doesn't work for you. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano rmpest...@yahoo.com.br Cc: Sent: Tuesday, November 20, 2012 3:13 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
please have a look at [1] and [2]. regards, gerhard [1] https://issues.apache.org/jira/browse/EXTCDI-302 [2] http://people.apache.org/~gpetracek/myfaces/codi/demos/ http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2012/11/20 Mark Struberg strub...@yahoo.de CDI injection using @Advanced should work perfectly fine. We tested this excessively and use it on several containers in production. I'm curious why it doesn't work for you. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano rmpest...@yahoo.com.br Cc: Sent: Tuesday, November 20, 2012 3:13 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i'm still not clear about your goal and where you need injection maybe share a (runnable) sample to show us what you are talking about side note: myfaces list can help you a lot about it too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Interesting, that will allow you to get instance of beans, if already instantiated, and that could have helped in converter, only if beans already injected earlier? On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: was thinking to http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html getAttributes() method (depend a bit on your real need) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Faces context? Please explain. On Nov 20, 2012 1:56 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: You cant use faces context? Le 20 nov. 2012 03:01, Howard W.
