from:"Gerhard Petracek"

Re: EXTVAL - DefaultValidatorId will not be set

2016-09-29 Thread Gerhard Petracek

hi markus,

it's great that you have a workaround for your applications.
however, you will also see limitations once you need to use e.g. the
client-window-handling.
-> it would be great if you share the workaround (e.g. attach the class and
config to the jira-ticket) - maybe there are also other users who can
benefit from it.

regards,
gerhard



2016-09-29 7:38 GMT+02:00 md :

> Hi Gerhard,
> thanks for your response.
> Right now we use crossvalidators, also custom implementations, and some
> AbstractStartupListener implementations.
> Until now I only recognized the problem with bv.
>
> I can workaround it with my own implementation of application, registering
> the factory in the faces-config.xml in WEB-INF.
>
> I filed a jira-ticket, see [1].
>
> Maybe it's enough to add a configuration Option in
> ExtValApplicationFactory,
> to deactivate the wrapper, as already stated there.
>
> markus
>
> [1] https://issues.apache.org/jira/browse/EXTVAL-162
>
>
>
>
>
> --
> View this message in context: http://myfaces.10567.n7.nabble
> .com/EXTVAL-DefaultValidatorId-will-not-be-set-tp122266p122271.html
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>

Re: EXTVAL - DefaultValidatorId will not be set

2016-09-28 Thread Gerhard Petracek

hi markus,

jsf 2.2 introduced some incompatibilities impacting the (out-of-the-box)
forward compatibility of extval (as it was available for jsf 2.1).
if you are interested in it, please file a feature-request/jira-ticket.

regards,
gerhard



2016-09-28 6:56 GMT+02:00 md :

> Hi all,
> we use ExtVal especially for CrossValidation. We migrate an application
> from
> jsf 1.2 to 2.2 and we want to use BeanValidation.
> In cases of validation during ajax request, for every request another
> BeanValidator is added to the component. This leads to redundant
> validationerrors.
>
> This is because of ExtValAplicationWrapper's implementation of
> addDefaultValidatorId method, which prevents "javax.faces.Bean" added as
> defaultValidatorId.
>
> Is this expected behavior or should I file a bug?
>
> Thanks in advance.
>
> Markus
>
>
>
> --
> View this message in context: http://myfaces.10567.n7.nabble
> .com/EXTVAL-DefaultValidatorId-will-not-be-set-tp122266.html
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>

Re: [COMMUNITY] Thomas Andraschko - Committer

2015-07-03 Thread Gerhard Petracek

welcome!

regards,
gerhard



2015-07-02 23:16 GMT+02:00 Mike Kienenberger mkien...@gmail.com:

 The MyFaces PMC is proud to announce a new addition to our community.

 Please welcome Thomas Andraschko as the newest MyFaces committer!
 Thomas is a long-time active member of the MyFaces community,
 especially in MyFaces Core, and has worked in the past on MyFaces
 External Validator and MyFaces Extensions CDI.   Thomas is also part
 of the Apache DeltaSpike community, a related JSF project at the
 Apache Software Foundation.

 Welcome  regards,
 Mike

PMC chair rotation

2015-05-03 Thread Gerhard Petracek

Hi @ all,

I'm stepping back from being the Apache MyFaces PMC chair, because it's
time for a rotation after four years!

As usual there was an internal vote and the result was approved by the ASF
board during the previous meeting.

- Please join me in welcoming our new PMC chair: Mike Kienenberger

Regards,
Gerhard

Re: Custom converter as tag with attributes?

2015-02-16 Thread Gerhard Petracek

hi karl,

in deltaspike that should work since v1.1.0 once you add javassist.
at least we have tests for it which pass...

regards,
gerhard

http://www.irian.at

Your JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache
MyFaces, DeltaSpike and OpenWebBeans



2015-02-16 8:57 GMT+01:00 Karl Kildén karl.kil...@gmail.com:

 This is a bug in the Deltaspike and the Myfaces way of making @Inject work
 for a Converter. The wrapper thingy breaks it. If I remove my injection
 points it works. I will create a sample and then issues for both projects

 Cheers

 On 13 February 2015 at 10:50, Karl Kildén karl.kil...@gmail.com wrote:

  Hello,
 
  I want to create a converter and instead of having f:attributes (need
  many) I want to create my own tag. Using myfaces 2.2.x
 
  I did this:
 
  @FacesConverter(myconverter)
  public class MyConverter extends ConverterHandler implements Converter {
   public MyConverter(ConverterConfig config) {
  super(config);
  }
 
 
 
  tag
 
  tag-namemyconverter/tag-name
  converter
  converter-idmyconverter/converter-id
  handler-classse.raindance.mp.NumberConverter/handler-class
  /converter
  attribute
  nameminFraction/name
  namemaxFraction/name
  namedefaultValue/name
  /attribute
  /tag
 
 
  If I remove extends ConverterHandler I get exception that I need to
  implement TagHandler... But all I want is to be able to supply some
  attributes in my facelet. Anyways the problem is that my constructor is
  getting called but not getAsObject nor getAsString...
 
  I also have this:
 
  context-param
  param-namefacelets.LIBRARIES/param-name
  param-value/WEB-INF/my.taglib.xml/param-value
  /context-param
 
 
  What am I missing?

[ANNOUNCE] Release of Apache MyFaces Extensions Validator 2.0.8

2014-06-26 Thread Gerhard Petracek

The Apache MyFaces team is pleased to announce the 8th release of
Apache MyFaces Extensions Validator (for JSF 2.x).

Apache MyFaces Extensions Validator is an extensible framework to validate
user input based on annotations.

The release contains several improvements.

Apache MyFaces Extensions Validator is available in both binary and source
distributions:
http://myfaces.apache.org/extensions/validator/download.html

Apache MyFaces Extensions Validator is available in the central Maven
repository under
Group ID org.apache.myfaces.extensions.validator.*.

Release Notes:
http://s.apache.org/EXTVAL_208

Enjoy!

Gerhard Petracek

Re: BeanManager lookup returing null !

2014-06-12 Thread Gerhard Petracek

hi felipe,

you pass in a scope-annotation as qualifier.
- it can't work, since a scope is no qualifier.

(fyi: please ask questions about cdi on the list for openwebbeans.)

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-06-11 23:14 GMT+02:00 Felipe Pina fop@gmail.com:

 Why beans Set (bold read line ) is empty ?

 What is my mistake ?

 Could anybody help me ?



 *My bean.*

 @javax.enterprise.context.RequestScoped
 @javax.enterprise.inject.Default
 public class Permissao extends NegocioBasePermissaoDTO {
 
 }


 *context.xml*
  Resource name=BeanManager
 auth=Container
 type=javax.enterprise.inject.spi.BeanManager
 factory=org.apache.webbeans.container.ManagerObjectFactory/


 *web.xml*

 !-- I ran with and without this resource-env-ref section --
   resource-env-ref
 descriptionObject factory for the CDI Bean Manager/description
 resource-env-ref-nameBeanManager/resource-env-ref-name

 resource-env-ref-typejavax.enterprise.inject.spi.BeanManager/resource-env-ref-type
   /resource-env-ref

 *BeanFactory*

 public class BeanFactory {
  static BeanManager getBeanManager() {
 InitialContext context;
 Object result;
 try {
 context = new InitialContext();
 result = context.lookup(java:comp/env/BeanManager); //lookup in
 Tomcat
 } catch (NamingException e) {
 try {
 context = new InitialContext();
 result = context.lookup(java:comp/BeanManager); //lookup in
 JBossAS
 } catch (NamingException ex) {
 throw new RuntimeException(BeanManager could not be found in
 JNDI, e);
 }
 }
 return (BeanManager) result;
 }
  @SuppressWarnings(unchecked)
 public static T T getContextualInstance(final ClassT type) {
  BeanManager manager = getBeanManager();
 T result = null;
 *SetBean? beans = manager.getBeans(type,
 type.getAnnotation(RequestScoped.class));*
 *   why variable beans isEmpty !!!*
 BeanT bean = (BeanT) manager.resolve(beans);
 if (bean != null) {
 CreationalContextT context =
 manager.createCreationalContext(bean);
 if (context != null) {
 result = (T) manager.getReference(bean, type, context);
 }
 }
 return result;
 }
 }

 --
 Atenciosamente,
 Felipe Pina

Re: Problem with clientWindow id and Deltaspike 0.7

2014-05-21 Thread Gerhard Petracek

@thomas:
the bridge just gets active once you enable the client-window of jsf
(otherwise deltaspike continues as usual).

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-05-21 20:34 GMT+02:00 Thomas Andraschko andraschko.tho...@gmail.com:

 Hi,

 could you try to use DeltaSpikes window handling?
 I never faced any issues with JSF 2.0/2.1 and DeltaSpike.
 Maybe it's some incompatibly between JSF 2.2 and DS in some cases. Maybe we
 should ask Gerhard, he developed the bridge for JSF 2.2.

 Regards,
 Thomas


 2014-05-21 20:21 GMT+02:00 Karl Kildén karl.kil...@gmail.com:

  Hi,
 
  In my sandbox app Deltaspike fails with a TomEE that has been upgraded to
  2.2.3. Error:
 
  WebBeans context with scope type annotation @WindowScoped does not exist
  within current thread
 
 
 
  When I debug it is because Deltaspike asks ServletExternalContextImpl for
  the ClientWindow. It get's null and everything fails. I have put
  breakpoints everywhere that ClientWindow can be set and it is simply not
  set before deltaspike asks.
 
  Mark was able to reproduce it once and only once :(  Romain got
  stackoverflow error with that error when he tried against tomee trunk and
  with my sample project. I asks on myfaces list because I want to know
 this:
 
 
  When I boot TomEE and make a request to faces servlet, what should set
  ClientWindow in ServletExternalContextImpl? Any ideas why this is to late
  (or why deltaspike is to early?) Cheers

Re: Problem with clientWindow id and Deltaspike 0.7

2014-05-21 Thread Gerhard Petracek

hi karl,

that combination (extval + jsf 2.2 bridge of ds) is currently undefined due
to the undefined order of the different wrappers...

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-05-21 21:38 GMT+02:00 Karl Kildén karl.kil...@gmail.com:

 I can confirm that removing either:

 dependency
 groupIdorg.apache.myfaces.extensions.validator/groupId
 artifactIdmyfaces-extval-core/artifactId
 version2.0.7/version
 /dependency


 Or removing

 context-param
 param-namejavax.faces.CLIENT_WINDOW_MODE/param-name
 param-valueurl/param-value
 /context-param


 solves my problem


 On 21 May 2014 20:57, Gerhard Petracek gerhard.petra...@gmail.com wrote:

  @thomas:
  the bridge just gets active once you enable the client-window of jsf
  (otherwise deltaspike continues as usual).
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2014-05-21 20:34 GMT+02:00 Thomas Andraschko 
 andraschko.tho...@gmail.com
  :
 
   Hi,
  
   could you try to use DeltaSpikes window handling?
   I never faced any issues with JSF 2.0/2.1 and DeltaSpike.
   Maybe it's some incompatibly between JSF 2.2 and DS in some cases.
 Maybe
  we
   should ask Gerhard, he developed the bridge for JSF 2.2.
  
   Regards,
   Thomas
  
  
   2014-05-21 20:21 GMT+02:00 Karl Kildén karl.kil...@gmail.com:
  
Hi,
   
In my sandbox app Deltaspike fails with a TomEE that has been
 upgraded
  to
2.2.3. Error:
   
WebBeans context with scope type annotation @WindowScoped does not
  exist
within current thread
   
   
   
When I debug it is because Deltaspike asks ServletExternalContextImpl
  for
the ClientWindow. It get's null and everything fails. I have put
breakpoints everywhere that ClientWindow can be set and it is simply
  not
set before deltaspike asks.
   
Mark was able to reproduce it once and only once :(  Romain got
stackoverflow error with that error when he tried against tomee trunk
  and
with my sample project. I asks on myfaces list because I want to know
   this:
   
   
When I boot TomEE and make a request to faces servlet, what should
 set
ClientWindow in ServletExternalContextImpl? Any ideas why this is to
  late
(or why deltaspike is to early?) Cheers

Re: Subscribe

2014-05-05 Thread Gerhard Petracek

(DelegatingMetaTagHandler.java:120)
 
 javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
 
 com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
 
 com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
 
 com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
 
 com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
 
 com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
 
 com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
 
 com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:169)
 
 com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
 
 com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
 
 com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:161)
 
 com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:995)
 
 com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:99)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
 
 com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
 
 org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.render(DeltaSpikeLifecycleWrapper.java:111)
 
 javax.faces.lifecycle.LifecycleWrapper.render(LifecycleWrapper.java:92)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
 
 
 
  2014-05-04 2:46 GMT-03:00 Gerhard Petracek gerhard.petra...@gmail.com:
 
  hi felipe,
 
  the project-setup isn't complete.
  you can use e.g. the myfaces archetype to have a look at the correct
 setup
  of openwebbeans (= cdi implementation) + codi (= cdi extension) (see
 [1])
  or
  a basic project-template (see [2]) for openwebbeans and deltaspike.
  (+ fyi: you have mixed jsf annotations with @Named)
 
  regards,
  gerhard
 
  [1] http://s.apache.org/LJS
  [2] https://github.com/os890/javaweb-cdi-ds-project-template
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2014-05-04 5:47 GMT+02:00 Felipe Pina fop@gmail.com:
 
   Hello my name is Felipe and i have a CDI doubts.
  
   I have installed the tomee and i setup all the classes and it works
  fine,
   but my server has very little ram memory, and this reason led me to
 try
  to
   install only the apache
   codihttp://myfaces.apache.org/extensions/cdi/index.htmlcore into
   apache
   tomcat 7 http://tomcat.apache.org/download-70.cgi .
  
   The project *compiles successfully*, but *the red line below* remains
  null!
  
   Question:  Is it necessary to add some additional dependency in order
 to
   the dependency injection works ?
  
   *So, I followed the following steps:*
  
  
  1.
  
   *Using maven to include only the cdi core *
  
   !--  CODI CDI
   dependencies --
  
  
  
  
  
   dependency
  
  
   groupIdorg.apache.geronimo.specs/groupId
  
  
   artifactIdgeronimo-atinject_1.0_spec/artifactId
  
  
   version1.0/version
  
  
   /dependency
  
  
  
  
  
   dependency
  
  
   groupIdorg.apache.geronimo.specs/groupId
  
  
   artifactIdgeronimo-jcdi_1.0_spec/artifactId
  
  
   version1.0/version
  
  
   /dependency
  
  
  
  
  
   dependency
  
  
   groupIdorg.apache.myfaces.extensions.cdi.core/groupId
  
  
   artifactIdmyfaces-extcdi-core-api/artifactId
  
  
   version${codi.version}/version
  
  
  
  
   /dependency
  
  
  
  
  
   dependency
  
  
   groupIdorg.apache.myfaces.extensions.cdi.core/groupId
  
  
   artifactIdmyfaces-extcdi-core-impl/artifactId
  
  
   version${codi.version}/version
  
  
  
  
   /dependency
  
*2 Setup my producer.*
  
   @javax.enterprise.context.ApplicationScoped
   public class FacadeFactory {
  
   @javax.enterprise.inject.Produces
  
public GrowUpFacadeAdapter getFacade() {
  
   return new GrowUpFacade();
   }
   }
  
   public class GrowUpFacade implements GrowUpFacadeAdapter {
   
   }
  
   public interface GrowUpFacadeAdapter extends Serializable {
   
   }
  
   *3 My JSF bean*
  
  
  
  
  
  
   *@ManagedBean(name=pedidoMBean)
   @javax.faces.bean.SessionScoped@javax.enterprise.context.SessionScoped
   @javax.inject.Named
   public class PedidoMBean extends AutenticadorMBean  {
  @javax.inject.Inject
   private GrowUpFacadeAdapter facade; --  remains null 
   .}*
  
  
   public class AutenticadorMBean implements Serializable {
   .
   }
  
   *4 beans.xml*
  
  
   *beans xmlns=http://java.sun.com/xml/ns/javaee
   http://java.sun.com/xml/ns/javaee
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
   http://www.w3.org/2001/XMLSchema-instance
   xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
   http://java.sun.com/xml/ns/javaee

Re: Subscribe

2014-05-03 Thread Gerhard Petracek

hi felipe,

the project-setup isn't complete.
you can use e.g. the myfaces archetype to have a look at the correct setup
of openwebbeans (= cdi implementation) + codi (= cdi extension) (see [1]) or
a basic project-template (see [2]) for openwebbeans and deltaspike.
(+ fyi: you have mixed jsf annotations with @Named)

regards,
gerhard

[1] http://s.apache.org/LJS
[2] https://github.com/os890/javaweb-cdi-ds-project-template

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-05-04 5:47 GMT+02:00 Felipe Pina fop@gmail.com:

 Hello my name is Felipe and i have a CDI doubts.

 I have installed the tomee and i setup all the classes and it works fine,
 but my server has very little ram memory, and this reason led me to try to
 install only the apache
 codihttp://myfaces.apache.org/extensions/cdi/index.htmlcore into
 apache
 tomcat 7 http://tomcat.apache.org/download-70.cgi .

 The project *compiles successfully*, but *the red line below* remains null!

 Question:  Is it necessary to add some additional dependency in order to
 the dependency injection works ?

 *So, I followed the following steps:*


1.

 *Using maven to include only the cdi core *

 !--  CODI CDI
 dependencies --





 dependency


 groupIdorg.apache.geronimo.specs/groupId


 artifactIdgeronimo-atinject_1.0_spec/artifactId


 version1.0/version


 /dependency





 dependency


 groupIdorg.apache.geronimo.specs/groupId


 artifactIdgeronimo-jcdi_1.0_spec/artifactId


 version1.0/version


 /dependency





 dependency


 groupIdorg.apache.myfaces.extensions.cdi.core/groupId


 artifactIdmyfaces-extcdi-core-api/artifactId


 version${codi.version}/version




 /dependency





 dependency


 groupIdorg.apache.myfaces.extensions.cdi.core/groupId


 artifactIdmyfaces-extcdi-core-impl/artifactId


 version${codi.version}/version




 /dependency

  *2 Setup my producer.*

 @javax.enterprise.context.ApplicationScoped
 public class FacadeFactory {

 @javax.enterprise.inject.Produces

  public GrowUpFacadeAdapter getFacade() {

 return new GrowUpFacade();
 }
 }

 public class GrowUpFacade implements GrowUpFacadeAdapter {
 
 }

 public interface GrowUpFacadeAdapter extends Serializable {
 
 }

 *3 My JSF bean*






 *@ManagedBean(name=pedidoMBean)
 @javax.faces.bean.SessionScoped@javax.enterprise.context.SessionScoped
 @javax.inject.Named
 public class PedidoMBean extends AutenticadorMBean  { @javax.inject.Inject
 private GrowUpFacadeAdapter facade; --  remains null 
 .}*


 public class AutenticadorMBean implements Serializable {
 .
 }

 *4 beans.xml*


 *beans xmlns=http://java.sun.com/xml/ns/javaee
 http://java.sun.com/xml/ns/javaee
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
 http://www.w3.org/2001/XMLSchema-instance
 xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
 http://java.sun.com/xml/ns/javaee
 http://java.sun.com/xml/ns/javaee/beans_1_0.xsd
 http://java.sun.com/xml/ns/javaee/beans_1_0.xsd /beans*


  --
 Atenciosamente,
 Felipe Pina



 --
 Atenciosamente,
 Felipe Pina

Re: CODI issue with CDI Observer

2014-03-23 Thread Gerhard Petracek

hi rafael,

please test the same with deltaspike 0.6

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-03-23 18:23 GMT+01:00 Rafael Pestano rmpest...@yahoo.com.br:

 Hi guys,

 i'm facing an issue with CODI on Glassfish 4 which i can't observe CDI
 events with notifyObserver = Reception.IF_EXISTS if my bean uses a CODI
 scope, here is some code:

 @ViewAccessScoped
 @Named
 public class MyBean implements Serializable{

 @Inject
 EventMyEvent myEvent;


 public void fire(){
 myEvent.fire(new MyEvent());
 }
 }

 @ViewAccessScoped
 //@SessionScoped
 @Named
 public  class AnotherBean implements Serializable{

 protected Logger log = Logger.getLogger(getClass().getSimpleName());

 public void observe(@Observes(notifyObserver = Reception.IF_EXISTS)
 MyEvent event){
 log.fine(event received:+event);
 }


 i receive nullpointer exception when i fire the event:

 javax.faces.FacesException: #{myBean.fire}: java.lang.NullPointerException
 at
 com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118)
 at
 org.apache.myfaces.extensions.cdi.jsf.impl.security.SecurityViolationAwareActionListener.processAction(SecurityViolationAwareActionListener.java:56)
 at
 org.apache.myfaces.extensions.cdi.jsf.impl.config.view.ViewControllerActionListener.processAction(ViewControllerActionListener.java:68)
 at
 org.apache.myfaces.extensions.cdi.jsf.impl.listener.action.CodiActionListener.processAction(CodiActionListener.java:58)


 full stacktrace is here:http://pastebin.com/fMaMqS72

 Here is some observations:

 - if i replace ViewAccessScoped with SessionScope i get no errors.

 - if i remove notifyObserver = Reception.IF_EXISTS i receive the event
 without problems

 - I have no issue with JbossAS 7, wildfly and also Glassfish 3.1.1.2



 I pushed a simple project at github which reproduces the issue:

 github.com/rmpestano/codi-issue


 any help is appreciated.

 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://conventions.github.io/home/

 http://rpestano.wordpress.com/
 @realpestano

Re: CODI issue with CDI Observer

2014-03-23 Thread Gerhard Petracek

since the implementation in ds is different and it works with other
servers, it sounds like a general glassfish-issue with custom scopes.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-03-23 22:15 GMT+01:00 Rafael Pestano rmpest...@yahoo.com.br:

 Hi gerhard,

 same thing with ds 0.6:

 [2014-03-23T18:14:20.514-0300] [glassfish 4.0] [WARNING] []
 [javax.enterprise.web.core] [tid: _ThreadID=20
 _ThreadName=http-listener-1(1)] [timeMillis: 1395609260514] [levelValue:
 900] [[
   Servlet.service() for servlet FacesServlet threw exception
 java.lang.NullPointerException
 at
 org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:178)
 at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:157)
 at
 org.jboss.weld.context.ForwardingContextual.create(ForwardingContextual.java:27)
 at
 org.apache.deltaspike.core.util.context.ContextualStorage.createContextualInstance(ContextualStorage.java:117)
 at
 org.apache.deltaspike.core.util.context.AbstractContext.get(AbstractContext.java:124)
 at
 org.apache.deltaspike.core.impl.scope.viewaccess.ViewAccessContext.get(ViewAccessContext.java:83)
 at
 org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:67)





 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://conventions.github.io/home/

 http://rpestano.wordpress.com/
 @realpestano



 Em Domingo, 23 de Março de 2014 17:44, Gerhard Petracek 
 gerhard.petra...@gmail.com escreveu:
 hi rafael,

 please test the same with deltaspike 0.6

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces




 2014-03-23 18:23 GMT+01:00 Rafael Pestano rmpest...@yahoo.com.br:

  Hi guys,
 
  i'm facing an issue with CODI on Glassfish 4 which i can't observe CDI
  events with notifyObserver = Reception.IF_EXISTS if my bean uses a CODI
  scope, here is some code:
 
  @ViewAccessScoped
  @Named
  public class MyBean implements Serializable{
 
  @Inject
  EventMyEvent myEvent;
 
 
  public void fire(){
  myEvent.fire(new MyEvent());
  }
  }
 
  @ViewAccessScoped
  //@SessionScoped
  @Named
  public  class AnotherBean implements Serializable{
 
  protected Logger log = Logger.getLogger(getClass().getSimpleName());
 
  public void observe(@Observes(notifyObserver = Reception.IF_EXISTS)
  MyEvent event){
  log.fine(event received:+event);
  }
 
 
  i receive nullpointer exception when i fire the event:
 
  javax.faces.FacesException: #{myBean.fire}:
 java.lang.NullPointerException
  at
 
 com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118)
  at
 
 org.apache.myfaces.extensions.cdi.jsf.impl.security.SecurityViolationAwareActionListener.processAction(SecurityViolationAwareActionListener.java:56)
  at
 
 org.apache.myfaces.extensions.cdi.jsf.impl.config.view.ViewControllerActionListener.processAction(ViewControllerActionListener.java:68)
  at
 
 org.apache.myfaces.extensions.cdi.jsf.impl.listener.action.CodiActionListener.processAction(CodiActionListener.java:58)
 
 
  full stacktrace is here:http://pastebin.com/fMaMqS72
 
  Here is some observations:
 
  - if i replace ViewAccessScoped with SessionScope i get no errors.
 
  - if i remove notifyObserver = Reception.IF_EXISTS i receive the event
  without problems
 
  - I have no issue with JbossAS 7, wildfly and also Glassfish 3.1.1.2
 
 
 
  I pushed a simple project at github which reproduces the issue:
 
  github.com/rmpestano/codi-issue
 
 
  any help is appreciated.
 
  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://conventions.github.io/home/
 
  http://rpestano.wordpress.com/
  @realpestano

Re: CODI issue with CDI Observer

2014-03-23 Thread Gerhard Petracek

it isn't nice that we need such a workaround, however, we can add it easily
(in codi as well as in deltaspike).

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-03-23 23:07 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com:

 Gerhard, i would add the null check but we should do it in AbstractContext.
 Could it break anything?


 2014-03-23 22:57 GMT+01:00 Rafael Pestano rmpest...@yahoo.com.br:

  Hi again,
 
  i just solved it in my custom scope by checking the null contextual:
 
  @Override
  public T T get(final ContextualT contextual, final
  CreationalContextT creationalContext) {
  if(creationalContext == null){
  return null;
  }
 
  i dont know what the spec says about trying to get a bean which doesnt
  have to participate in an event but in my opinion the easiest way to get
 DS
  compatible with GF4 is to
  do that nullcheck in deltaspike instead of waiting for GF guys...
 
 
 https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/scope/viewaccess/ViewAccessContext.java#L79
 
 
 
  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://conventions.github.io/home/
 
  http://rpestano.wordpress.com/
  @realpestano
 
 
 
  Em Domingo, 23 de Março de 2014 18:48, Rafael Pestano 
  rmpest...@yahoo.com.br escreveu:
  Hi Gerhard,
 
  i can confirm its a GF4 issue, justed added a simple custom scope and
  received the same NPE in the scope GET method:
 
  @Override
  public T T get(final ContextualT contextual, final
  CreationalContextT creationalContext) {
  Bean bean = (Bean) contextual;
  if
  (customScopeContextHolder.getBeans().containsKey(bean.getBeanClass())) {
  return (T)
  customScopeContextHolder.getBean(bean.getBeanClass()).instance;
  } else {
  T t = (T) bean.create(creationalContext);//NPE here,
  contextual is null
 
 
  I'll open an issue at glassfish tracker.
 
  thanks for your help
 
 
 
 
  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://conventions.github.io/home/
 
  http://rpestano.wordpress.com/
  @realpestano
 
 
 
 
  Em Domingo, 23 de Março de 2014 18:25, Gerhard Petracek 
  gerhard.petra...@gmail.com escreveu:
  since the implementation in ds is different and it works with other
  servers, it sounds like a general glassfish-issue with custom scopes.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
 
  2014-03-23 22:15 GMT+01:00 Rafael Pestano rmpest...@yahoo.com.br:
 
   Hi gerhard,
  
   same thing with ds 0.6:
  
   [2014-03-23T18:14:20.514-0300] [glassfish 4.0] [WARNING] []
   [javax.enterprise.web.core] [tid: _ThreadID=20
   _ThreadName=http-listener-1(1)] [timeMillis: 1395609260514]
 [levelValue:
   900] [[
 Servlet.service() for servlet FacesServlet threw exception
   java.lang.NullPointerException
   at
  
 
 org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:178)
   at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:157)
   at
  
 
 org.jboss.weld.context.ForwardingContextual.create(ForwardingContextual.java:27)
   at
  
 
 org.apache.deltaspike.core.util.context.ContextualStorage.createContextualInstance(ContextualStorage.java:117)
   at
  
 
 org.apache.deltaspike.core.util.context.AbstractContext.get(AbstractContext.java:124)
   at
  
 
 org.apache.deltaspike.core.impl.scope.viewaccess.ViewAccessContext.get(ViewAccessContext.java:83)
   at
  
 
 org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:67)
  
  
  
  
  
   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://conventions.github.io/home/
  
   http://rpestano.wordpress.com/
   @realpestano
  
  
  
   Em Domingo, 23 de Março de 2014 17:44, Gerhard Petracek 
   gerhard.petra...@gmail.com escreveu:
   hi rafael,
  
   please test the same with deltaspike 0.6
  
   regards,
   gerhard
  
   http://www.irian.at
  
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
  
  
  
   2014-03-23 18:23 GMT+01:00 Rafael Pestano rmpest...@yahoo.com.br:
  
Hi guys,
   
i'm facing an issue with CODI on Glassfish 4 which i can't observe
 CDI
events with notifyObserver = Reception.IF_EXISTS if my bean uses a
 CODI
scope, here is some code

[ANNOUNCE] Release of Apache MyFaces Extensions CDI 1.0.6

2014-03-04 Thread Gerhard Petracek

The Apache MyFaces team is pleased to announce the 13th release of
Apache MyFaces Extensions CDI (aka CODI).

Apache MyFaces CODI provides portable CDI extensions for
the Java-Platform (SE and EE). CODI is a modularized and
extensible toolbox for CDI based applications.

The release of CODI v1.0.6 contains the following modules:
 - CODI Core
 - CODI JSF Module (for 1.2 and 2.x)
 - CODI JPA Module
 - CODI BV Module
 - CODI I18N-Message Module
 - CODI Scripting Module
 - CODI Trinidad Support Module (for 1.x and 2.x)
 - CODI Java-EE5 Support Modules
 - CODI Bundles
 - CODI OSGi Bundles
 - CODI Base Test-Infrastructure Module
 - CODI JUnit-Support Module
 - CODI Cargo-Support Module
 - CODI OpenWebBeans Test-Support Module
 - CODI JSF Test-Support Module
 - CODI JSF Example

Apache MyFaces CODI is available in both binary and source distributions:
http://myfaces.apache.org/extensions/cdi/download.html

Apache MyFaces CODI is available in the central Maven repository under
Group ID org.apache.myfaces.extensions.cdi.*.

Release Notes:
http://s.apache.org/CODI_106

Enjoy!

Gerhard Petracek

Re: @FlowScoped, @Named and @ManagedBean

2014-02-12 Thread Gerhard Petracek

hi ludovic,

@ProjectStageActivated is called @Exclude in deltaspike and you can just
drop @Advanced.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-02-12 9:29 GMT+01:00 l.pe...@senat.fr l.pe...@senat.fr:

 On 12/02/2014 00:42, Thomas Andraschko wrote:

 Can't you just switch to DS?

 I gave a look to «migrate codi 1.x to deltaspike 0.5» by someone who seems
 to know a bit on this topic, posts on this mailing list and is also known a
 Gerhard Petracek :-)

 http://os890.blogspot.fr/2013/10/migrate-codi-1x-to-deltaspike-05.html

 And so I try to apply the dependenc changes from
 https://raw.github.com/os890/tomee_mf_stack_001/master/pom.xml

 to

 https://raw.github.com/os890/tomee_mf_stack_001/codi2ds/pom.xml

 I was however stopped at build time by the lack of
 - @ProjectStageActivated
 - @Advanced

 I can easily live without @ProjectStageActivated (used to activate a phase
 listener in debug, something which help me a lot when I started to pla with
 JSF but that I do not need anymore) and I am now trying to figure how not
 to use @Advanced.

 I am using this annotation to make converters and validators eligible
 injection targets. I think I can also retrieve beans by EL-expressions,
 with simple code such as

 public class MyHelperClass {
 public static T T findBean(String name) {
 if ((name == null) || name.isEmpty()) {
 return null;
 }
 return evaluateExpression(#{ + name + });
 }

 @SuppressWarnings(unchecked)
 public static T T evaluateExpression(String expr) {
 if ((expr == null) || expr.isEmpty()) {
 return null;
 }
 FacesContext fc = FacesContext.getCurrentInstance();
 return (T) fc.getApplication().evaluateExpressionGet(fc,
 expr, Object.class);
 }
 }

 MyHelperClass.findBean(toto);

 I will try that and keep you posted.

 Thanks,


 Ludovic


 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: @FlowScoped, @Named and @ManagedBean

2014-02-12 Thread Gerhard Petracek

hi ludovic,

once you enable the window-handling for jsf 2.2+, deltaspike v0.6+ will use
it automatically.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-02-12 10:37 GMT+01:00 l.pe...@senat.fr l.pe...@senat.fr:

 On 12/02/2014 10:22, Gerhard Petracek wrote:

 hi ludovic,

 @ProjectStageActivated is called @Exclude in deltaspike and you can just
 drop @Advanced.


 ok, thank you.

 I still had the same situation with deltaspike (0.5 + your
 os890-cdi-ext-jsf2-module-api and os890-cdi-ext-jsf2-module-impl or
 0.6-SNAPSHOT).

 So, I digged the clientwindow topic... I read in
 https://weblogs.java.net/blog/edburns/archive/2013/10/07/
 jsf-22-clientwindow-links-and-open-new-tab

 that

 « Because the Faces Flows feature entirely depends on|ClientWindow|,
 the usage of Faces Flows will automatically enable|ClientWindow|if it is
 not enabled already»

 However, it is not in my case.

 So I explicitly enabled this with adding

   context-param
 param-namejavax.faces.CLIENT_WINDOW_MODE/param-name
param-valueurl/param-value
  /context-param

 in web.xml.


 It there some other required config that I should check ?

 Thanks in avdance,


 Ludovic

 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: @FlowScoped, @Named and @ManagedBean

2014-02-12 Thread Gerhard Petracek

@howard:
(as announced back then) codi is in maintenance-mode, because new features
will be added to deltaspike.
you might have seen the latest updates for using it with ee7.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-02-12 11:33 GMT+01:00 Howard W. Smith, Jr. smithh032...@gmail.com:

 On Feb 12, 2014 1:40 AM, Karl Kildén karl.kil...@gmail.com wrote:
 
  Deltaspike modules have consistently been usable off the shelf and would
 be
  a far better solution then doing tricks to make CODI work.

 +1

 
  However using JSF stuff would require you to use 0.6-SNAPSHOT. I would
  actually just use @SessionScoped, write a TODO and wait for 0.6 release
 if
  I could. Otherwise I would use SNAPSHOT since the JSF stuff is all fixed
  for 0.6 afaik.

 When I experimented with CODI, I used 1.0.6 snapshot and had the same thing
 in mind and then i heard that CODI was dead project, and most likely 1.0.6
 would not be released. And I did hear and recognize that deltaspike is
 recommended instead of CODI. Someone, please confirm.

 
 
  On 12 February 2014 02:44, Kito Mann kito.m...@virtua.com wrote:
 
   How mature is DeltaSpike? It's only at 0.05.

 +1 good question.

  
   On Tuesday, February 11, 2014, Thomas Andraschko 
   andraschko.tho...@gmail.com wrote:
  
Can't you just switch to DS?
   
   
2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com
 javascript:;
:
   
 Hi

 CDI implementations does not require to provide anything to JSF in
 order to make @FlowScoped to work. The code has been tested against
 OWB and Weld and it works in both cases.

 But the flow stuff relies on the new ClientWindow API, and that
 could
 cause a conflict with CODI, because CODI provides a solution for
 this
 part too. In fact, the solution introduced in the standard comes
 from
 CODI.

 In your particular case, the best option is provide a custom
 ClientWindowFactory / ClientWindow that implements
 ClientWindow.getId() method and grab the value generated by CODI.
 Theorically there is no need of the custom PhaseListener, because
 the
 attachWindow step is done in CODI. I haven't tried it but I
 suppose
 a custom ClientWindow will work.

 regards,

 Leonardo Uribe

 2014-02-11 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
  On 11/02/2014 14:51, l.pe...@senat.fr wrote:
 
  On 11/02/2014 10:28, l.pe...@senat.fr wrote:
 
  On 11/02/2014 03:30, Leonardo Uribe wrote:
 
 
  [...]
 
  @FlowScoped annotation is for CDI only, so it will not work
 for
   JSF
  managed beans. In your case, I believe the bean is
 instantiated
   but
it
  is not stored in any context, so once is created is discarded,
giving
  the impression that the bean is working but it is not.
 
  In MyFaces it is possible to create a custom flow scope
 annotation
for
  other containers that works just like @FlowScoped,
 implementing
  org.apache.myfaces.spi.FacesFlowProvider SPI interface. You
 are
  already in CDI, so you don't need to bother about that.
 
  I have seen @Named annotation working with Spring, so it is
 not
  something specific for CDI, but @FlowScoped depends of CDI
 API.
 
  I am using CODI 1.0.5 (I heavily use its @ViewAccessScoped
annotation)
  with OpenWebBeans 1.2.1.
 
  So, I thought  was ok on the CDI side...
 
  ...but after reading your mail, it seems to me that this CDI
  implementation was provided before JSF 2.2 release, and so that
 it
 must not
  include proper @FacesFlow support.
 
  Should I switch to another implementation, like DeltaSpike ?
 
  I must have misunderstood your mail from Sep 26 2013 (
 

   
  

 http://myfaces.10567.n7.nabble.com/JSF-2-2-status-amp-snapshot-usage-td115852.html
  ) inviting us to try Faces Flows in MyFaces 2.2.
 
  After some debugging, I found that :
  * beans are discovered and processed ok by
  org.apache.myfaces.flow.cdi.FlowScopeCDIExtension
  * -flow.xml is detected and processed with no errors ;
  * if I use an empty -flow.xml file, an exception is raised line
 716
   of
  org.apache.myfaces.config.DefaultFacesConfigurationProvider (on
  facesConfig.getFacesFlowDefinitions().add(flow); )
  * if I add a breakpoint in
  org.apache.myfaces.flow.FlowHandlerImpl#clientWindowTransition,
 I
   can
 see :
  ** my flow registered in _flowMapById (with flow1 key)
  ** my flow registered in _flowMapByDocumentId (with an empty
 key)
  ** that _facesFlowProvider is null
 
 
  ok, I think I got it. And, as I feared, it seems to be CODI
 related.
 
  In JSF2.2, a call to
 
  //JSF 2.2: attach window

Re: @FlowScoped, @Named and @ManagedBean

2014-02-12 Thread Gerhard Petracek

hi ludovic,

the add-on is for: codi 1.0.5 - deltaspike 0.5 (that's the reason for:
1.0.5_0.5_01)
please don't use it with 0.6 (currently only @ViewAccessScoped is missing
in ds)

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-02-12 14:38 GMT+01:00 l.pe...@senat.fr l.pe...@senat.fr:

 On 12/02/2014 10:37, l.pe...@senat.fr wrote:

 On 12/02/2014 10:22, Gerhard Petracek wrote:

 hi ludovic,

 @ProjectStageActivated is called @Exclude in deltaspike and you can just
 drop @Advanced.


 ok, thank you.

 I still had the same situation with deltaspike (0.5 + your
 os890-cdi-ext-jsf2-module-api and os890-cdi-ext-jsf2-module-impl or
 0.6-SNAPSHOT).

 So, I digged the clientwindow topic... I read in
 https://weblogs.java.net/blog/edburns/archive/2013/10/07/
 jsf-22-clientwindow-links-and-open-new-tab

 that

 « Because the Faces Flows feature entirely depends on|ClientWindow|,
 the usage of Faces Flows will automatically enable|ClientWindow|if it is
 not enabled already»

 However, it is not in my case.

 So I explicitly enabled this with adding

   context-param
 param-namejavax.faces.CLIENT_WINDOW_MODE/param-name
param-valueurl/param-value
  /context-param

 in web.xml.


 It there some other required config that I should check ?

 ok, so with:
 * deltaspike 0.6-SNAPSHOT
 * org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-{api,impl}
 :1.0.5_0.5_01}
 * javax.faces.CLIENT_WINDOW_MODE = url

 ... it is starting to work.

 In fact, I could trigger flow transitions only using a h:link for now.

 So neither
 * p:menuitem value=Let's test outcome=flow1 /  in a PF p:menubar
 * p:commandButton value=Let's test 2 action=flow1 /
 * h:commandButton value=Let's test 3 action=flow1 /
 * h:commandButton value=Let's test 4 action=/flow1 /
 * h:commandButton value=Let's test 5 action=/flow1/flow1 /
 * a direct transition to /flow1/flow1.xhtml (by typing the URL in the
 brower url bar)

 work.

 But
 * h:link outcome=flow1Test 6/h:link
 * h:link outcome=/flow1/flow1.xhtmlTest 7/h:link

 do work.

 By  working, I mean that the FlowHandler.FLOW_ID_REQUEST_PARAM_NAME
 (jffi) is defined, a transition is detected and FlowHandlerImpl processes
 it.

 I found only one place defining it in myfaces 2.2 impl source,
 myfaces-impl-2.2.0/org/apache/myfaces/shared/renderkit/html/
 util/OutcomeTargetUtils.java:145 , in
 OutcomeTargetUtils.getOutcomeTargetHref .


 Either I missed something big, either it does not fit my requirements.

 When I read «Java EE 7 tutorial - 16.3 Using Faces Flows»
 http://docs.oracle.com/javaee/7/tutorial/doc/jsf-configure003.htm

 syntaxes such as

 h:commandButton value=Exit Flow action=returnFromCheckoutFlow/

 seemed supported.

 Moreover, I state that it works because I see a flow transition taking
 place. But I could not figure how to make it finally work (without ).

 When I try to use an empty flow1-flow.xml, or to use a flow1-flow.xml such
 as


 ?xml version=1.0 encoding=UTF-8?
 faces-config
 xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
 xmlns='http://xmlns.jcp.org/xml/ns/javaee'
 xsi:schemaLocation='http://xmlns.jcp.org/xml/ns/javaee
 http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd'
 version='2.2' 
 flow-definition id=flow1
 display-nameTest display name/display-name
 descriptionTest description/description
 flow-return id=success
 from-outcome/accueil.xhtml/from-outcome
 /flow-return
 flow-return id=error
 from-outcome/versions.xhtml/from-outcome
 /flow-return
 /flow-definition
 /faces-config

 (dummy test returns...)

 there is a problem at the outcome computation step.

 When I use a configuration class such as

 public class Flow1 implements Serializable {

 @Produces
 @FlowDefinition
 public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder)
 {
 String flowId = flow1;
 flowBuilder.id(, flowId);
 flowBuilder.viewNode(flowId,
 / + flowId + / + flowId + .xhtml).
 markAsStartNode();
 return flowBuilder.getFlow();
 }
 }

 there is a first transition from no flow (being on /accueil.xhtml) to
 flow1 (going to /flow1/flow1.xhtml). flow1 is correctly stacked at this
 step.

 But then, another transition from /flow1/flow1.xhtml to /flow1/flow1.xhtml
 is immediatly triggered by an automatically generated (I think) navigation
 case.  During this transition, flow1 is popped from stack and a null
 pointer exception occurs.

 Any help welcomed... I would be glad to have a look at simple test cases
 using MyFaces 2.2.

 But I might switch back to good old @ViewAccessScoped for the time being -
 spent some days on this Faces Flows stuff already.

 Thanks for the help and work anyway. It is quite normal to me to have this
 kind of troubleshooting on new stuff

Re: JSF 2.2 Exit Flow

2014-01-18 Thread Gerhard Petracek

hi geoffrey,

just fyi (in addition to the answer from michael):
that's one of the major use-cases we had for codi/deltaspike
(grouped-)conversations.
you can use a listener (or an observer for PreViewConfigNavigateEvent +
custom view-config meta-data) which
just calls (WindowContext#closeConversations in case of codi or
GroupedConversationManager#closeConversations in case of deltaspike).

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014/1/18 Michael Kurz michi.k...@gmx.at

 Hi,

 as far as I know, this is currently not possible. JSF won't let you
 navigate to something that is not defined as a node in the current flow. I
 quickly talked to Ed Burns about this some time ago and he more or less
 confirmed that this is the case.

 Regards
 Michael

 Am 17.01.2014 02:10, schrieb Geoffrey Longo:

  I have an application that consists of a dropdown menu bar with many menu
 items.  Each menu item will initiate a new faces flow.  This is working
 correctly, however, once I am inside a flow, I would like any click on a
 menu item to exit the current flow, and then start a new one.  There are
 dozens of menu items in the application, so I was wondering if there is any
 way to have the current flow automatically exit when a menu item is clicked
 without having to define a flow-return for each menu item?

 Thanks,
 Geoff

Re: Apache ExtVal: Annotation @BeanValidation(useGroups = SkipValidation.class) has no effect for properties, annotated with @Column

2013-11-13 Thread Gerhard Petracek

that's correct. you can file a feature request for it (at [1]).
if we provide it in extval-core, we can support both with one annotation.

regards,
gerhard

[1] https://issues.apache.org/jira/browse/EXTVAL

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2013/11/13 Alexey Shakov alexey.sha...@menta.de

 Hi Gerhard,

 which version of extval-bypass add-on is compatible with extval 2.0.7?

 I'm trying to use following maven configuration:

 repository
   idgooglecode.com/id
 urlhttp://os890-m2-repository.googlecode.com/svn/tags/os890/url
 /repository

 dependency
   groupIdat.gp.web.jsf.extval /groupId
 artifactIdextval-annotation-based-bypass-validation/artifactId
   version1.2.2/version
 /dependency


 But it seems, like this version is not compatible with extval 2.0.7

 Best regards,

 Alexey

 Am 12.11.2013 16:12, schrieb Gerhard Petracek:

 hi alexey,

 if it used to work, it should still work - please file an issue and i'll
 check it.
 (it would be great, if you can provide a simple demo-app which illustrates
 the issue.)

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2013/11/12 Alexey Shakov alexey.sha...@menta.de

  Hi Gerhard,

 thank you for the explanation, i understand the background.

 But what would be the solution for my problem?
 I use validation constraints in the form of jpa, jsr-303 and also
 extval-specific annotations. All I need is just to skip JSF-Validation of
 empty fields for some GUI-Actions (immediate=true is not an option,
 since i
 need intermediately save the values in my conversation-scoped bean).

 Earlier (with MyFaces 1.2.x) I've used extval with bypass-addon for this
 purpose. Since MyFaces  2.1.x this combination does not work.

 Can you give please some hints? I think, it is a very common case for
 each
 more or less complicated web-app, when the user fills the properties of
 some session- (or conversation-) scoped) java-bean having intermediate
 Ajax-requests (JSF-Actions) at the background.

 Thank you in advance for your help.

 Best regards,

 Alexey

 Am 11.11.2013 23:40, schrieb Gerhard Petracek:

   hi alexey,

 #1 is supported by [1]
 and
 #2 is supported by [2]

 extval started with [1] and [2] was added later on (once bv was
 finished).
 extval itself doesn't force specific constraint-rules (- it was
 possible
 to support #1 with [1]).
 however, since [2] delegates most parts to the bv-implementation of your
 choice and bv forces specific constraint-rules, [2] can't support #1.
 (fyi: a jpa-provider can support #2 as well)

 regards,
 gerhard

 [1]
 http://svn.apache.org/repos/asf/myfaces/extensions/
 validator/trunk/validation-modules/property-validation/
 [2]
 http://svn.apache.org/repos/asf/myfaces/extensions/
 validator/trunk/validation-modules/bean-validation/

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2013/11/11 Alexey Shakov alexey.sha...@menta.de

   Hi Gerhard,

 thank you for a quick answer.

 I thought, that from JSF-Validation perspective following two notations
 must be the same:

 #1:


 @Column(name=NAME, length=80, nullable=false)
 private String name;

 #2

 @NotNull
 @Size (max=80)
 private String name;


 It is still not clear for me, why they are differently handled by
 @BeanValidation(useGroups = SkipValidation.class)

 Regards,
 Alexey

 Am 11.11.2013 15:12, schrieb Gerhard Petracek:

hi alexey,

  there are 2 different validation-modules:
 #1 property-validation (= extval-constraints + jpa-based validation)
 #2 bean-validation (= better jsf-integration of bv)

 they follow different concepts - with @BeanValidation (provided by
 #2)
 you
 can't control jpa-based validation (provided by #1).
 further details are available at [1].

 regards,
 gerhard

 [1] http://s.apache.org/EXTVAL_Chapter

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2013/11/11 Alexey Shakov alexey.sha...@menta.de

Hi *,

  I use Annotation @BeanValidation(useGroups = SkipValidation.class)
 on
 my
 action method to ignore the validation constraints, if it getting
 called
 from JSF-facelet.

 I've noticed, that this annotation works good for standalone
 constraints, such as @NotNull or @Size, but not for @Column.
 In my case, I have a Hibernate-Entity with a name-property, annotated
 like
 this:

 @Column(name=NAME, length=80, nullable=false)
 private String name;

 This property is getting always validated (length and not-null
 check),
 regardless of @BeanValidation(useGroups = SkipValidation.class)-
 annotation
 on corresponding action method.

 What is a reason

Re: Apache ExtVal: Annotation @BeanValidation(useGroups = SkipValidation.class) has no effect for properties, annotated with @Column

2013-11-12 Thread Gerhard Petracek

hi alexey,

if it used to work, it should still work - please file an issue and i'll
check it.
(it would be great, if you can provide a simple demo-app which illustrates
the issue.)

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/11/12 Alexey Shakov alexey.sha...@menta.de

 Hi Gerhard,

 thank you for the explanation, i understand the background.

 But what would be the solution for my problem?
 I use validation constraints in the form of jpa, jsr-303 and also
 extval-specific annotations. All I need is just to skip JSF-Validation of
 empty fields for some GUI-Actions (immediate=true is not an option, since i
 need intermediately save the values in my conversation-scoped bean).

 Earlier (with MyFaces 1.2.x) I've used extval with bypass-addon for this
 purpose. Since MyFaces  2.1.x this combination does not work.

 Can you give please some hints? I think, it is a very common case for each
 more or less complicated web-app, when the user fills the properties of
 some session- (or conversation-) scoped) java-bean having intermediate
 Ajax-requests (JSF-Actions) at the background.

 Thank you in advance for your help.

 Best regards,

 Alexey

 Am 11.11.2013 23:40, schrieb Gerhard Petracek:

  hi alexey,

 #1 is supported by [1]
 and
 #2 is supported by [2]

 extval started with [1] and [2] was added later on (once bv was finished).
 extval itself doesn't force specific constraint-rules (- it was possible
 to support #1 with [1]).
 however, since [2] delegates most parts to the bv-implementation of your
 choice and bv forces specific constraint-rules, [2] can't support #1.
 (fyi: a jpa-provider can support #2 as well)

 regards,
 gerhard

 [1]
 http://svn.apache.org/repos/asf/myfaces/extensions/
 validator/trunk/validation-modules/property-validation/
 [2]
 http://svn.apache.org/repos/asf/myfaces/extensions/
 validator/trunk/validation-modules/bean-validation/

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2013/11/11 Alexey Shakov alexey.sha...@menta.de

  Hi Gerhard,

 thank you for a quick answer.

 I thought, that from JSF-Validation perspective following two notations
 must be the same:

 #1:


 @Column(name=NAME, length=80, nullable=false)
 private String name;

 #2

 @NotNull
 @Size (max=80)
 private String name;


 It is still not clear for me, why they are differently handled by
 @BeanValidation(useGroups = SkipValidation.class)

 Regards,
 Alexey

 Am 11.11.2013 15:12, schrieb Gerhard Petracek:

   hi alexey,

 there are 2 different validation-modules:
 #1 property-validation (= extval-constraints + jpa-based validation)
 #2 bean-validation (= better jsf-integration of bv)

 they follow different concepts - with @BeanValidation (provided by #2)
 you
 can't control jpa-based validation (provided by #1).
 further details are available at [1].

 regards,
 gerhard

 [1] http://s.apache.org/EXTVAL_Chapter

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2013/11/11 Alexey Shakov alexey.sha...@menta.de

   Hi *,

 I use Annotation @BeanValidation(useGroups = SkipValidation.class) on
 my
 action method to ignore the validation constraints, if it getting
 called
 from JSF-facelet.

 I've noticed, that this annotation works good for standalone
 constraints, such as @NotNull or @Size, but not for @Column.
 In my case, I have a Hibernate-Entity with a name-property, annotated
 like
 this:

 @Column(name=NAME, length=80, nullable=false)
 private String name;

 This property is getting always validated (length and not-null check),
 regardless of @BeanValidation(useGroups = SkipValidation.class)-
 annotation
 on corresponding action method.

 What is a reason for this behavior? Did I misunderstand something?

 (I use MyFaces 2.1.13, MyFaces extval 2.0.7, hibernate-validator
 5.0.1.Final)

 Thanks for any help,

 Alexey

Re: Apache ExtVal: Annotation @BeanValidation(useGroups = SkipValidation.class) has no effect for properties, annotated with @Column

2013-11-11 Thread Gerhard Petracek

hi alexey,

there are 2 different validation-modules:
#1 property-validation (= extval-constraints + jpa-based validation)
#2 bean-validation (= better jsf-integration of bv)

they follow different concepts - with @BeanValidation (provided by #2) you
can't control jpa-based validation (provided by #1).
further details are available at [1].

regards,
gerhard

[1] http://s.apache.org/EXTVAL_Chapter

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/11/11 Alexey Shakov alexey.sha...@menta.de

 Hi *,

 I use Annotation @BeanValidation(useGroups = SkipValidation.class) on my
 action method to ignore the validation constraints, if it getting called
 from JSF-facelet.

 I've noticed, that this annotation works good for standalone
 constraints, such as @NotNull or @Size, but not for @Column.
 In my case, I have a Hibernate-Entity with a name-property, annotated like
 this:

 @Column(name=NAME, length=80, nullable=false)
 private String name;

 This property is getting always validated (length and not-null check),
 regardless of @BeanValidation(useGroups = SkipValidation.class)-annotation
 on corresponding action method.

 What is a reason for this behavior? Did I misunderstand something?

 (I use MyFaces 2.1.13, MyFaces extval 2.0.7, hibernate-validator
 5.0.1.Final)

 Thanks for any help,

 Alexey

Re: Apache ExtVal: Annotation @BeanValidation(useGroups = SkipValidation.class) has no effect for properties, annotated with @Column

2013-11-11 Thread Gerhard Petracek

hi alexey,

#1 is supported by [1]
and
#2 is supported by [2]

extval started with [1] and [2] was added later on (once bv was finished).
extval itself doesn't force specific constraint-rules (- it was possible
to support #1 with [1]).
however, since [2] delegates most parts to the bv-implementation of your
choice and bv forces specific constraint-rules, [2] can't support #1.
(fyi: a jpa-provider can support #2 as well)

regards,
gerhard

[1]
http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/validation-modules/property-validation/
[2]
http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/validation-modules/bean-validation/

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/11/11 Alexey Shakov alexey.sha...@menta.de

 Hi Gerhard,

 thank you for a quick answer.

 I thought, that from JSF-Validation perspective following two notations
 must be the same:

 #1:


 @Column(name=NAME, length=80, nullable=false)
 private String name;

 #2

 @NotNull
 @Size (max=80)
 private String name;


 It is still not clear for me, why they are differently handled by
 @BeanValidation(useGroups = SkipValidation.class)

 Regards,
 Alexey

 Am 11.11.2013 15:12, schrieb Gerhard Petracek:

  hi alexey,

 there are 2 different validation-modules:
 #1 property-validation (= extval-constraints + jpa-based validation)
 #2 bean-validation (= better jsf-integration of bv)

 they follow different concepts - with @BeanValidation (provided by #2)
 you
 can't control jpa-based validation (provided by #1).
 further details are available at [1].

 regards,
 gerhard

 [1] http://s.apache.org/EXTVAL_Chapter

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2013/11/11 Alexey Shakov alexey.sha...@menta.de

  Hi *,

 I use Annotation @BeanValidation(useGroups = SkipValidation.class) on
 my
 action method to ignore the validation constraints, if it getting called
 from JSF-facelet.

 I've noticed, that this annotation works good for standalone
 constraints, such as @NotNull or @Size, but not for @Column.
 In my case, I have a Hibernate-Entity with a name-property, annotated
 like
 this:

 @Column(name=NAME, length=80, nullable=false)
 private String name;

 This property is getting always validated (length and not-null check),
 regardless of @BeanValidation(useGroups = SkipValidation.class)-
 annotation
 on corresponding action method.

 What is a reason for this behavior? Did I misunderstand something?

 (I use MyFaces 2.1.13, MyFaces extval 2.0.7, hibernate-validator
 5.0.1.Final)

 Thanks for any help,

 Alexey

Re: Apache CODI x JEE7 Glassfish4

2013-10-31 Thread Gerhard Petracek

i haven't said something different.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/10/31 Mark Struberg strub...@yahoo.de



 yea, but that is minor tho what CODI can do.

 LieGrue,
 strub





 
  From: Gerhard Petracek gerhard.petra...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
 strub...@yahoo.de
 Sent: Thursday, 31 October 2013, 0:24
 Subject: Re: Apache CODI x JEE7 Glassfish4
 
 
 
 @mark:
 the parameter conversationPropagation was added in 1.1.
 
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 
 2013/10/31 Mark Struberg strub...@yahoo.de
 
 Nope, we didn't touch @ConversationScoped a bit in CDI-1.1.
 
 The main changes in CDI-1.1 have been clarifications. But most of them
 are already implemented in OWB and Weld, even in the CDI-1.0 targetting
 versions.
 There have been a few good Extensions in the Extension area, scanning,
 etc  in CDI-1.1.
 
 LieGrue,
 strub
 
 
 
 
 
 - Original Message -
  From: Kay Wrobel kay.wro...@gmx.net
  To: MyFaces Discussion users@myfaces.apache.org
  Cc:
  Sent: Wednesday, 30 October 2013, 22:44
  Subject: Re: Apache CODI x JEE7 Glassfish4
 
  One could still investigate if @ConversatioScoped has improved in CDI
  1.1 and is on par with how CODI 1.0.5 handles it. Again, I am not the
  right person to discuss that annotation, but it's a thought.
 
  On 10/30/2013 04:33 PM, Gerhard Petracek wrote:
   hi edilmar,
 
   apache deltaspike is the official successor of codi/seam/...
 (including
   support for ee7+).
   some parts (including codi-conversations) are still on our list,
 however,
   you can try it with [1] (it's the same code - just different packages
  and
   based on deltaspike).
 
   @kay (and your comment about conversations):
   std. cdi conversations are available since cdi 1.0 and have many
   disadvantages compared to codi-conversations.
   that was the reason for introducing codi-conversations at all (see
 e.g.
   [2]) - they are still useful.
 
   regards,
   gerhard
 
   [1]
 
 http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html
   [2]
 http://os890.blogspot.co.at/2011/04/slides-codi-conversations.html
 
   http://www.irian.at
 
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
 
   Professional Support for Apache MyFaces
 
 
 
   2013/10/30 Edilmar Alves edili...@gmail.com
 
   I think CODI is a great replacement for my actual environment, the
 only
   problem is to deploy in GF4.
 
 
   2013/10/30 Edilmar Alves edili...@gmail.com
 
   Hi,
 
   I use CODI ConversationScoped and @Inject Conversation because it
  is
   better than original CDI implementation.
   I have many java files using CODI at this time.
   Then, to go back to CDI, I will have to change many files, and I
  don't
   know if the webapp will continue to work 100%,
   because the management of the Conversation object made by CODI is
  great,
   for example it decreases problems like
   LazyException caused by Hibernate with JSF fields.
 
 
   2013/10/30 Kay Wrobel kay.wro...@gmx.net
 
   Also, you might want to check with RichFaces. I found this blog
  
   http://www.bleathem.ca/blog/**2013/09/richfaces-434final-**
   release-announcement.html
 
 
 http://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html
   and the moderator mentions that full JSF 2.2 support is planned
  for
   RichFaces 5. I had some of the same issues with PrimeFaces 3.5
  which was
   incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0
  to come
   out.
 
   On 10/30/2013 03:17 PM, Kay Wrobel wrote:
 
   I'm looking at CDI 1.1 spec
  http://docs.jboss.org/cdi/**
   spec/1.1/cdi-spec.html
   http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html
   and ot looks like @ConversationScope is already part of CDI
  1.1, no
   CODI
   needed for that.
 
   GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 
   http://www.cdi-spec.org/**download/
  http://www.cdi-spec.org/download/
   which is bundled inside the weld-osgi-bundle.jar.
 
   On 10/30/2013 02:55 PM, Edilmar Alves wrote:
 
   Hi friends,
 
   Thanks for help!
   Look at these situations...
   1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour.
  But I use in
   production 3.1.1 because there are many servers using
  my webapp with
   this
   version, and it is not simple to upgrade.
   2) I am testing Glassfish 4/JEE7 because Glassfish is
  the oficial
   server
   approved by the enterprise, I can't change for
  other server. Then, I
   test
   version 4 because there are some other functionalities
  I would like to
   use
   from JEE7 in my webapp, but with CODI it is not
  possible to deploy.
   3) I didn't

Re: Apache CODI x JEE7 Glassfish4

2013-10-30 Thread Gerhard Petracek

hi edilmar,

apache deltaspike is the official successor of codi/seam/... (including
support for ee7+).
some parts (including codi-conversations) are still on our list, however,
you can try it with [1] (it's the same code - just different packages and
based on deltaspike).

@kay (and your comment about conversations):
std. cdi conversations are available since cdi 1.0 and have many
disadvantages compared to codi-conversations.
that was the reason for introducing codi-conversations at all (see e.g.
[2]) - they are still useful.

regards,
gerhard

[1]
http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html
[2] http://os890.blogspot.co.at/2011/04/slides-codi-conversations.html

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/10/30 Edilmar Alves edili...@gmail.com

 I think CODI is a great replacement for my actual environment, the only
 problem is to deploy in GF4.


 2013/10/30 Edilmar Alves edili...@gmail.com

  Hi,
 
  I use CODI ConversationScoped and @Inject Conversation because it is
  better than original CDI implementation.
  I have many java files using CODI at this time.
  Then, to go back to CDI, I will have to change many files, and I don't
  know if the webapp will continue to work 100%,
  because the management of the Conversation object made by CODI is great,
  for example it decreases problems like
  LazyException caused by Hibernate with JSF fields.
 
 
  2013/10/30 Kay Wrobel kay.wro...@gmx.net
 
  Also, you might want to check with RichFaces. I found this blog 
  http://www.bleathem.ca/blog/**2013/09/richfaces-434final-**
  release-announcement.html
 http://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html
 
  and the moderator mentions that full JSF 2.2 support is planned for
  RichFaces 5. I had some of the same issues with PrimeFaces 3.5 which was
  incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0 to come
 out.
 
 
  On 10/30/2013 03:17 PM, Kay Wrobel wrote:
 
  I'm looking at CDI 1.1 spec http://docs.jboss.org/cdi/**
  spec/1.1/cdi-spec.html
 http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html
  and ot looks like @ConversationScope is already part of CDI 1.1, no
 CODI
  needed for that.
 
  GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 
  http://www.cdi-spec.org/**download/ http://www.cdi-spec.org/download/
 
  which is bundled inside the weld-osgi-bundle.jar.
 
  On 10/30/2013 02:55 PM, Edilmar Alves wrote:
 
  Hi friends,
 
  Thanks for help!
  Look at these situations...
  1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour. But I use in
  production 3.1.1 because there are many servers using my webapp with
  this
  version, and it is not simple to upgrade.
  2) I am testing Glassfish 4/JEE7 because Glassfish is the oficial
 server
  approved by the enterprise, I can't change for other server. Then, I
  test
  version 4 because there are some other functionalities I would like to
  use
  from JEE7 in my webapp, but with CODI it is not possible to deploy.
  3) I didn't understand the suggestion to use Myfaces 2.2. Has it a
  replacement for the CODI ConversationScoped, for example? Because this
  scope is used in many pages of my webapp, the main resource from CODI
  that
  I use and need an alternative. I can't use Myfaces, for example, to
  change
  Richfaces.
 
 
  2013/10/30 Kay Wrobel kay.wro...@gmx.net
 
   Or he can stick with Glassfish 3.1.2.2, which is GlassFish' last
 final
  release targeting Java EE 6. Unless he wants to incorporated new
  features
  that only Java EE 7 can provide, I'd say, stick with what currently
  works.
  Or try alternatives, such as TomEE 1.5.2 or TomEE 1.6 which still
  targets
  Java EE 6, or JBoss AS 7 which also targets Java EE 6.
 
 
  On 10/30/2013 02:08 PM, Howard W. Smith, Jr. wrote:
 
   Also, MyFaces 2.2 (beta, which has JavaEE7 JSF2.2 features) was
  just/recently released (yesterday, I think). Feel free to give that
 a
  try.
 
  TomEE and tomcat8 is and/or will be targeting JEE7.
 
  is it a requirement to deploy to Glassfish 4, or you just want to
  deploy
  to
  your local machine for testing purposes only?
 
  if for testing purposes only, download latest tomee 1.6 snapshot and
  Myfaces 2.2 (beta), drop MyFaces 2.2 api + impl JARs in tomee/lib
  folder,
  and give them a try. and if you have any tomee-related questions,
  please
  subscribe to tomee user list and ask questions there. they are
  'apache',
  too, and just as helpful there, 'too'. :)
 
 
 
  On Wed, Oct 30, 2013 at 2:59 PM, Kay Wrobel kay.wro...@gmx.net
  wrote:
 
Hi Edilmar.
 
  I had the same issues. There are incompatibilities apparently with
  JSF
  2.2
  that ships with GlassFish 4. And JSF 2.2 has some much improved CDI
  features, such as proper @ViewScope.
 
  Kay
 
 
  On 10/30/2013 01:03 PM, Edilmar Alves wrote:
 
Hi,
 
  I have an webapp that runs fine in GF3.1.1 using

Re: Apache CODI x JEE7 Glassfish4

2013-10-30 Thread Gerhard Petracek

those changes in v1.1 are better than nothing, but still not enough. codi
(grouped-)conversations follow quite different concepts.
most concepts provided by codi have been ported to deltaspike (with ee7 in
mind). however, ee7 only contains few of them out-of-the-box (and in some
cases just sub-sets).

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2013/10/30 Kay Wrobel kay.wro...@gmx.net

One could still investigate if @ConversatioScoped has improved in CDI 1.1
and is on par with how CODI 1.0.5 handles it. Again, I am not the right
person to discuss that annotation, but it's a thought.

On 10/30/2013 04:33 PM, Gerhard Petracek wrote:

hi edilmar,

apache deltaspike is the official successor of codi/seam/... (including
support for ee7+).
some parts (including codi-conversations) are still on our list, however,
you can try it with [1] (it's the same code - just different packages and
based on deltaspike).

@kay (and your comment about conversations):
std. cdi conversations are available since cdi 1.0 and have many
disadvantages compared to codi-conversations.
that was the reason for introducing codi-conversations at all (see e.g.
[2]) - they are still useful.

regards,
gerhard

[1]
http://os890.blogspot.co.at/**2013/07/add-on-codi-scopes-**
for-deltaspike.htmlhttp://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html
[2] http://os890.blogspot.co.at/**2011/04/slides-codi-**
conversations.htmlhttp://os890.blogspot.co.at/2011/04/slides-codi-conversations.html

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2013/10/30 Edilmar Alves edili...@gmail.com

I think CODI is a great replacement for my actual environment, the only
problem is to deploy in GF4.

2013/10/30 Edilmar Alves edili...@gmail.com

Hi,

I use CODI ConversationScoped and @Inject Conversation because it is
better than original CDI implementation.
I have many java files using CODI at this time.
Then, to go back to CDI, I will have to change many files, and I don't
know if the webapp will continue to work 100%,
because the management of the Conversation object made by CODI is great,
for example it decreases problems like
LazyException caused by Hibernate with JSF fields.

2013/10/30 Kay Wrobel kay.wro...@gmx.net

Also, you might want to check with RichFaces. I found this blog
http://www.bleathem.ca/blog/2013/09/richfaces-434final-**http://www.bleathem.ca/blog/**2013/09/richfaces-434final-**
release-announcement.html

http://www.bleathem.ca/blog/**2013/09/richfaces-434final-**
release-announcement.htmlhttp://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html

and the moderator mentions that full JSF 2.2 support is planned for
RichFaces 5. I had some of the same issues with PrimeFaces 3.5 which
was
incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0 to come

out.

On 10/30/2013 03:17 PM, Kay Wrobel wrote:

I'm looking at CDI 1.1 spec http://docs.jboss.org/cdi/**
spec/1.1/cdi-spec.html

http://docs.jboss.org/cdi/**spec/1.1/cdi-spec.htmlhttp://docs.jboss.org/cdi/spec/1.1/cdi-spec.html

and ot looks like @ConversationScope is already part of CDI 1.1, no

CODI

needed for that.

GlassFish 4 includes CDI 1.1 by way of Weld API 2.0
http://www.cdi-spec.org/download/http://www.cdi-spec.org/**download/
http://www.cdi-spec.org/**download/http://www.cdi-spec.org/download/
which is bundled inside the weld-osgi-bundle.jar.

On 10/30/2013 02:55 PM, Edilmar Alves wrote:

Hi friends,

Thanks for help!
Look at these situations...
1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour. But I use in
production 3.1.1 because there are many servers using my webapp with
this
version, and it is not simple to upgrade.
2) I am testing Glassfish 4/JEE7 because Glassfish is the oficial

server

approved by the enterprise, I can't change for other server. Then, I
test
version 4 because there are some other functionalities I would like
to
use
from JEE7 in my webapp, but with CODI it is not possible to deploy.
3) I didn't understand the suggestion to use Myfaces 2.2. Has it a
replacement for the CODI ConversationScoped, for example? Because
this
scope is used in many pages of my webapp, the main resource from CODI
that
I use and need an alternative. I can't use Myfaces, for example, to
change
Richfaces.

2013/10/30 Kay Wrobel kay.wro...@gmx.net

Or he can stick with Glassfish 3.1.2.2, which is GlassFish' last

final

release targeting Java EE 6. Unless he wants to incorporated new
features
that only Java EE 7 can provide, I'd say, stick with what currently
works.
Or try alternatives, such as TomEE 1.5.2 or TomEE 1.6 which still
targets
Java EE 6, or JBoss AS 7 which also

Re: Apache CODI x JEE7 Glassfish4

2013-10-30 Thread Gerhard Petracek

@mark:
the parameter conversationPropagation was added in 1.1.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/10/31 Mark Struberg strub...@yahoo.de

 Nope, we didn't touch @ConversationScoped a bit in CDI-1.1.

 The main changes in CDI-1.1 have been clarifications. But most of them are
 already implemented in OWB and Weld, even in the CDI-1.0 targetting
 versions.
 There have been a few good Extensions in the Extension area, scanning,
 etc  in CDI-1.1.

 LieGrue,
 strub




 - Original Message -
  From: Kay Wrobel kay.wro...@gmx.net
  To: MyFaces Discussion users@myfaces.apache.org
  Cc:
  Sent: Wednesday, 30 October 2013, 22:44
  Subject: Re: Apache CODI x JEE7 Glassfish4
 
  One could still investigate if @ConversatioScoped has improved in CDI
  1.1 and is on par with how CODI 1.0.5 handles it. Again, I am not the
  right person to discuss that annotation, but it's a thought.
 
  On 10/30/2013 04:33 PM, Gerhard Petracek wrote:
   hi edilmar,
 
   apache deltaspike is the official successor of codi/seam/... (including
   support for ee7+).
   some parts (including codi-conversations) are still on our list,
 however,
   you can try it with [1] (it's the same code - just different packages
  and
   based on deltaspike).
 
   @kay (and your comment about conversations):
   std. cdi conversations are available since cdi 1.0 and have many
   disadvantages compared to codi-conversations.
   that was the reason for introducing codi-conversations at all (see e.g.
   [2]) - they are still useful.
 
   regards,
   gerhard
 
   [1]
 
 http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html
   [2] http://os890.blogspot.co.at/2011/04/slides-codi-conversations.html
 
   http://www.irian.at
 
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
 
   Professional Support for Apache MyFaces
 
 
 
   2013/10/30 Edilmar Alves edili...@gmail.com
 
   I think CODI is a great replacement for my actual environment, the
 only
   problem is to deploy in GF4.
 
 
   2013/10/30 Edilmar Alves edili...@gmail.com
 
   Hi,
 
   I use CODI ConversationScoped and @Inject Conversation because it
  is
   better than original CDI implementation.
   I have many java files using CODI at this time.
   Then, to go back to CDI, I will have to change many files, and I
  don't
   know if the webapp will continue to work 100%,
   because the management of the Conversation object made by CODI is
  great,
   for example it decreases problems like
   LazyException caused by Hibernate with JSF fields.
 
 
   2013/10/30 Kay Wrobel kay.wro...@gmx.net
 
   Also, you might want to check with RichFaces. I found this blog
  
   http://www.bleathem.ca/blog/**2013/09/richfaces-434final-**
   release-announcement.html
 
 
 http://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html
   and the moderator mentions that full JSF 2.2 support is planned
  for
   RichFaces 5. I had some of the same issues with PrimeFaces 3.5
  which was
   incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0
  to come
   out.
 
   On 10/30/2013 03:17 PM, Kay Wrobel wrote:
 
   I'm looking at CDI 1.1 spec
  http://docs.jboss.org/cdi/**
   spec/1.1/cdi-spec.html
   http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html
   and ot looks like @ConversationScope is already part of CDI
  1.1, no
   CODI
   needed for that.
 
   GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 
   http://www.cdi-spec.org/**download/
  http://www.cdi-spec.org/download/
   which is bundled inside the weld-osgi-bundle.jar.
 
   On 10/30/2013 02:55 PM, Edilmar Alves wrote:
 
   Hi friends,
 
   Thanks for help!
   Look at these situations...
   1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour.
  But I use in
   production 3.1.1 because there are many servers using
  my webapp with
   this
   version, and it is not simple to upgrade.
   2) I am testing Glassfish 4/JEE7 because Glassfish is
  the oficial
   server
   approved by the enterprise, I can't change for
  other server. Then, I
   test
   version 4 because there are some other functionalities
  I would like to
   use
   from JEE7 in my webapp, but with CODI it is not
  possible to deploy.
   3) I didn't understand the suggestion to use
  Myfaces 2.2. Has it a
   replacement for the CODI ConversationScoped, for
  example? Because this
   scope is used in many pages of my webapp, the main
  resource from CODI
   that
   I use and need an alternative. I can't use Myfaces,
  for example, to
   change
   Richfaces.
 
 
   2013/10/30 Kay Wrobel kay.wro...@gmx.net
 
 Or he can stick with Glassfish 3.1.2.2, which is
  GlassFish' last
   final
   release targeting Java EE 6. Unless he wants to
  incorporated new
   features
   that only Java EE 7 can provide, I'd say, stick
  with what currently
   works.
   Or try

Re: [MyFaces 2.2] invoke @PreDestroy on (CDI) ViewScoped beans upon session expiration

2013-10-18 Thread Gerhard Petracek

@howard:
that's one of the issues i mentioned during the discussion for MYFACES-3797
and i was going to test it tomorrow.
- thx for testing it and starting this thread.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2013/10/18 Leonardo Uribe lu4...@gmail.com

You can check here:

https://builds.apache.org/view/M-R/view/MyFaces/job/myfaces-current22-1/

As soon as the job (#1164) is done, you can take the jars from that
location (which should be the same).

regards,

Leonardo Uribe

2013/10/17 Howard W. Smith, Jr. smithh032...@gmail.com

Okay, that is great. I'm waiting for the following folders to be updated
with the latest version:

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/myfaces-api/2.2.0-SNAPSHOT/

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/myfaces-impl/2.2.0-SNAPSHOT/

On Thu, Oct 17, 2013 at 10:47 PM, Leonardo Uribe lu4...@gmail.com
wrote:

I have found the bug. The problem was caused on a refactor, there was
an
old code that skip state saving when view map is empty, but now since
there
is a proxy for that implementing StateHolder, the map can be empty but
it
holds the view scope key. Since with CDI the beans are stored
internally,
the map keeps empty but the scope is not, and if the view scope key is
lost
the bean is recreated every time. But the beans are still in session,
and
with the session timeout bug the final result is @PreDestroy is not
called.

Please try again with the latest code, it should work. And please lets
us
know what happened, if it is working or not.

regards,

Leonardo Uribe

2013/10/17 Leonardo Uribe lu4...@gmail.com

I have committed a fix for the problem with the timeout. But I'm
curious
about this problem, because I tested this scope and specifically the
@PreDestroy stuff. It should work. But maybe there is a bug
somewhere

regards,

Leonardo Uribe

2013/10/17 Howard W. Smith, Jr. smithh032...@gmail.com

responses inline below,

On Thu, Oct 17, 2013 at 9:32 PM, Leonardo Uribe lu4...@gmail.com
wrote:

public void onSessionDestroyed()
{
// In CDI case, the best way to deal with this is use a
method
// with @PreDestroy annotation on a session scope bean
// ( ViewScopeBeanHolder.destroyBeans() ). There is no
need
// to do anything else in this location, but it is advised
// in CDI the beans are destroyed at the end of the
request,
// not when invalidateSession() is called.
FacesContext facesContext =
FacesContext.getCurrentInstance();
if (facesContext != null)
{

I suppose what's going on there is in the context the session
invalidation
is done, FacesContext is null and @PreDestroy is ignored.

I can agree with that.

To be clear two questions:

1. Is manual session expiration working ? I suppose yes.

hmmm does manual session expiration == HttpSession.invalidate()?

When user click Logout button, my app execute/triggers
HttpSession.invalidate(), and @PreDestroy (on CDI @ViewScoped bean)
is
not
executed.

2. Is session invalidation by a timeout working ? I suppose no.

correct, I just verified that in my app. see below.

- navigated to page that reference CDI @ViewScoped bean,
@PostConstruct
(below) executed

Oct 17, 2013 9:45:18 PM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@a9faef9

changed web.xml, session timeout = 1 minute, so tomee ended session
via/after timeout, and @PreDestroy on CDI @SessionScoped (below)
executed,

Oct 17, 2013 9:45:53 PM jsf.users.pf_UsersController sessionTimeout
INFO: administrator session ended at 10/17/2013 09:45 PM

but @PreDestroy on CDI @ViewScoped bean was not executed

I will try to provide an example to test.

Re: [MyFaces 2.2] invoke @PreDestroy on (CDI) ViewScoped beans upon session expiration

2013-10-18 Thread Gerhard Petracek

hi howard,

i just planned a short (re-)test for starting a discussion like this one.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2013/10/18 Howard W. Smith, Jr. smithh032...@gmail.com

Gerhard, you're welcome. since i don't have bandwidth (right now),
maybe/hopefully, you can develop test case(s) per what we're
discussing/testing/reporting here...if you have bandwidth to do so. :)

On Fri, Oct 18, 2013 at 5:14 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:

@howard:
that's one of the issues i mentioned during the discussion for
MYFACES-3797
and i was going to test it tomorrow.
- thx for testing it and starting this thread.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2013/10/18 Leonardo Uribe lu4...@gmail.com

You can check here:

https://builds.apache.org/view/M-R/view/MyFaces/job/myfaces-current22-1/

As soon as the job (#1164) is done, you can take the jars from that
location (which should be the same).

regards,

Leonardo Uribe

2013/10/17 Howard W. Smith, Jr. smithh032...@gmail.com

Okay, that is great. I'm waiting for the following folders to be
updated
with the latest version:

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/myfaces-api/2.2.0-SNAPSHOT/

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/myfaces-impl/2.2.0-SNAPSHOT/

On Thu, Oct 17, 2013 at 10:47 PM, Leonardo Uribe lu4...@gmail.com
wrote:

I have found the bug. The problem was caused on a refactor, there
was
an
old code that skip state saving when view map is empty, but now
since
there
is a proxy for that implementing StateHolder, the map can be empty
but
it
holds the view scope key. Since with CDI the beans are stored
internally,
the map keeps empty but the scope is not, and if the view scope key
is
lost
the bean is recreated every time. But the beans are still in
session,
and
with the session timeout bug the final result is @PreDestroy is not
called.

Please try again with the latest code, it should work. And please
lets
us
know what happened, if it is working or not.

regards,

Leonardo Uribe

2013/10/17 Leonardo Uribe lu4...@gmail.com

I have committed a fix for the problem with the timeout. But I'm
curious
about this problem, because I tested this scope and specifically
the
@PreDestroy stuff. It should work. But maybe there is a bug
somewhere

regards,

Leonardo Uribe

2013/10/17 Howard W. Smith, Jr. smithh032...@gmail.com

responses inline below,

On Thu, Oct 17, 2013 at 9:32 PM, Leonardo Uribe
lu4...@gmail.com

wrote:

public void onSessionDestroyed()
{
// In CDI case, the best way to deal with this is use
a
method
// with @PreDestroy annotation on a session scope bean
// ( ViewScopeBeanHolder.destroyBeans() ). There is no
need
// to do anything else in this location, but it is
advised
// in CDI the beans are destroyed at the end of the
request,
// not when invalidateSession() is called.
FacesContext facesContext =
FacesContext.getCurrentInstance();
if (facesContext != null)
{

I suppose what's going on there is in the context the session
invalidation
is done, FacesContext is null and @PreDestroy is ignored.

I can agree with that.

To be clear two questions:

1. Is manual session expiration working ? I suppose yes.

hmmm does manual session expiration == HttpSession.invalidate()?

When user click Logout button, my app execute/triggers
HttpSession.invalidate(), and @PreDestroy (on CDI @ViewScoped
bean)
is
not
executed.

2. Is session invalidation by a timeout working ? I suppose
no.

correct, I just verified that in my app. see below.

- navigated to page that reference CDI @ViewScoped bean,
@PostConstruct
(below) executed

Oct 17, 2013 9:45:18 PM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@a9faef9

changed web.xml, session timeout = 1 minute, so tomee ended
session
via/after timeout, and @PreDestroy on CDI @SessionScoped

Re: [MyFaces 2.2] invoke @PreDestroy on (CDI) ViewScoped beans upon session expiration

2013-10-18 Thread Gerhard Petracek

hi howard,

your test confirmed what i saw recently - we have already what i planned
to do (the confirmation of the issue).

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2013/10/18 Howard W. Smith, Jr. smithh032...@gmail.com

Cool! If your test works against Leonardo's latest changes/fixes, please
post/share your test results (and test steps). Thanks!

On Fri, Oct 18, 2013 at 3:45 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:

hi howard,

i just planned a short (re-)test for starting a discussion like this one.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2013/10/18 Howard W. Smith, Jr. smithh032...@gmail.com

Gerhard, you're welcome. since i don't have bandwidth (right now),
maybe/hopefully, you can develop test case(s) per what we're
discussing/testing/reporting here...if you have bandwidth to do so. :)

On Fri, Oct 18, 2013 at 5:14 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:

@howard:
that's one of the issues i mentioned during the discussion for
MYFACES-3797
and i was going to test it tomorrow.
- thx for testing it and starting this thread.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2013/10/18 Leonardo Uribe lu4...@gmail.com

You can check here:

https://builds.apache.org/view/M-R/view/MyFaces/job/myfaces-current22-1/

As soon as the job (#1164) is done, you can take the jars from that
location (which should be the same).

regards,

Leonardo Uribe

2013/10/17 Howard W. Smith, Jr. smithh032...@gmail.com

Okay, that is great. I'm waiting for the following folders to be
updated
with the latest version:

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/myfaces-api/2.2.0-SNAPSHOT/

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/myfaces-impl/2.2.0-SNAPSHOT/

On Thu, Oct 17, 2013 at 10:47 PM, Leonardo Uribe
lu4...@gmail.com

wrote:

I have found the bug. The problem was caused on a refactor,
there
was
an
old code that skip state saving when view map is empty, but now
since
there
is a proxy for that implementing StateHolder, the map can be
empty
but
it
holds the view scope key. Since with CDI the beans are stored
internally,
the map keeps empty but the scope is not, and if the view scope
key
is
lost
the bean is recreated every time. But the beans are still in
session,
and
with the session timeout bug the final result is @PreDestroy is
not
called.

Please try again with the latest code, it should work. And
please
lets
us
know what happened, if it is working or not.

regards,

Leonardo Uribe

2013/10/17 Leonardo Uribe lu4...@gmail.com

I have committed a fix for the problem with the timeout. But
I'm
curious
about this problem, because I tested this scope and
specifically
the
@PreDestroy stuff. It should work. But maybe there is a bug
somewhere

regards,

Leonardo Uribe

2013/10/17 Howard W. Smith, Jr. smithh032...@gmail.com

responses inline below,

On Thu, Oct 17, 2013 at 9:32 PM, Leonardo Uribe
lu4...@gmail.com

wrote:

public void onSessionDestroyed()
{
// In CDI case, the best way to deal with this is
use
a
method
// with @PreDestroy annotation on a session scope
bean
// ( ViewScopeBeanHolder.destroyBeans() ). There
is
no
need
// to do anything else in this location, but it is
advised
// in CDI the beans are destroyed at the end of
the
request,
// not when invalidateSession() is called.
FacesContext facesContext =
FacesContext.getCurrentInstance();
if (facesContext != null)
{

I suppose what's going on there is in the context the
session
invalidation
is done, FacesContext is null and @PreDestroy is ignored

Re: Future of MyFaces in non-CDI environments

2013-10-17 Thread Gerhard Petracek

hi moritz,

@myfaces-core:
the minimal goal is to be spec. compliant.

@osgi+cdi:
you might be interested in [1].

regards,
gerhard

[1] http://s.apache.org/Qu7

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/10/17 Moritz Bechler bech...@agno3.eu

 Hi,

 I've been recently working on proof of concept code to enable modular
 JSF applications in OSGI environments (artifacts spread over multiple
 bundles). Following the JCP discussion it very much seems that CDI will
 become the primary (potentially mandatory) injection and context
 management mechanism in future JSF spec versions. Unfortunately CDI
 seems very much ill-suited in this scenario. What is MyFaces' position
 on supporting non-CDI environments? What especially concerns me is that,
 at some point, context management might be externalized into CDI.

 with best regards

 Moritz Bechler
 --
 AgNO3 GmbH  Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
 Persönlich haftend:
 Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
 Vertreten durch Joachim Keltsch

Re: DOwnload codi bundle jar for use inot tomee

2013-08-05 Thread Gerhard Petracek

tomee shouldn't have issues with the separated jar-files, however, see e.g.
[1]

regards,
gerhard

[1]
http://repo2.maven.org/maven2/org/apache/myfaces/extensions/cdi/bundles/myfaces-extcdi-bundle-jsf20/1.0.5/myfaces-extcdi-bundle-jsf20-1.0.5.jar

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: DOwnload codi bundle jar for use inot tomee

2013-08-05 Thread Gerhard Petracek

@ #1: please have a look e.g. at [1]
@ #2: myfaces-extval doesn't implement the bv-spec. one part of it is a
thin bv-integration-layer needed for jsf 1.x which can be used also for jsf
2.x to benefit from additional features.

regards,
gerhard

[1]
http://os890.blogspot.co.at/2011/08/scopes-view-scope-vs-view-access-scope.html

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [ CODI ] redirect loop

2013-04-25 Thread Gerhard Petracek

hi stephen,

please try to reproduce it with a reduced session-timeout.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/4/22 Stephen More stephen.m...@gmail.com

 I am running mojarra 2.1.20 with + codi 1.0.5 + weld 1.1.10.Final with a
 org.apache.myfaces.extensions.cdi.core.api.activation.ClassDeactivator

 For the most part everything works fine until there is a lengthy idle time
 ( in this case it was over an hour ), then the client will display a
 redirect loop error, refresh 2 or 3 times then the issue seems to go away.
 I am not exactly sure what is causing it.

 Nothing shows up in catalina.out. What type of logging can I change so that
 I can determine if this is or is not a codi issue ?

 Here is the localhost_access_log

 192.168.7.56 - - [22/Apr/2013:12:16:57 -0400] GET
 /detail.jsf?mfRid=7160windowId=617 HTTP/1.1 200 85834
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET /list.jsf HTTP/1.1 200
 32771
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?mfRid=9836windowId=617 HTTP/1.1 200 32777
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?mfRid=8736windowId=617 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=a78mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=9damfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=957mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=c61mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=be3mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=88dmfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=4f6mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=1f2mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=d33mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=862mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=405mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=befmfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=c43mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=1e1mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=f46mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=9e4mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=9d5mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=7f3mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=c6fmfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:20:19 -0400] GET
 /list.jsf?windowId=b62mfRid=8736 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?mfRid=1065windowId=617 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=dbfmfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=9f4mfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=bfdmfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=c00mfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=6bemfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=51bmfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=543mfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=352mfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=31fmfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=329mfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=605mfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=105mfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=974mfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=df1mfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=fdemfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - - [22/Apr/2013:13:23:22 -0400] GET
 /list.jsf?windowId=8f9mfRid=1065 HTTP/1.1 302 -
 192.168.7.56 - -

Re: config web.xml myfaces for use with primefaces

2013-04-09 Thread Gerhard Petracek

hi,

@ #1:
it shouldn't be needed (myfaces-core is doing it automatically).
if you have issues after removing it, please report it to the team of tomee.

regards,
gerhard



http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2013/4/9 Thomas Andraschko andraschko.tho...@gmail.com

 1) it's necessary
 2) Just use google... It's a EL Implementation


 2013/4/8 maurojava mauro2java2...@gmail.com

  tank you for your response.
  When i create a new project with netbeans 7.3 and tomee server, and i add
  the JSF framework, i get automatically into web.xml the following
  configuration for myfaces:
 
  listener
 
 
 
 listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
  /listener
  servlet
  servlet-nameFaces Servlet/servlet-name
  servlet-classjavax.faces.webapp.FacesServlet/servlet-class
  load-on-startup1/load-on-startup
  /servlet
  servlet-mapping
  servlet-nameFaces Servlet/servlet-name
  url-pattern*.jsf/url-pattern
  /servlet-mapping
 
  from your response not says over listener
 
 
 
 listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
  /listener
 
 
  it is necessaries?
 
  what  it is the work of the listener
 
 
 
 listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
  /listener
  at startup of my web application??
 
 
  2)Other questions:
  from the link:
 
 http://tandraschko.blogspot.de/2012/08/increase-your-jsf-application.html
 
  i read :
 
  Use JUEL as EL implementation
 
  Add the newest JUEL API + implementation as depedency
  Configure MyFaces to use JUEL:
 
 
  context-param
 
 param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
 
 param-valuede.odysseus.el.ExpressionFactoryImpl/param-value
  /context-param
 
  Increase expression cache in JUEL
 
  Create src/main/resources/el.properties
  Add property javax.el.cacheSize with a custom size. The default size
 is
  1000. In my application i use a size of 3000.
 
  DO i can download the JUEL ? it is from myfaces core???
  ---
  If you use CDI, consider to use OpenWebBeans as implementation and
  configure
  this in your web.xml:
 
 
  context-param
  param-nameorg.apache.myfaces.EL_RESOLVER_COMPARATOR/param-name
 
 
 
 param-valueorg.apache.myfaces.el.unified.OpenWebBeansELResolverComparator/param-value
  /context-param
 
 
 
 
  --
  View this message in context:
 
 http://myfaces.10567.n7.nabble.com/config-web-xml-myfaces-for-use-with-primefaces-tp114536p114539.html
  Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x

2013-04-04 Thread Gerhard Petracek

hi adrian,

we can do EXTCDI-308 easily, but basically it isn't an issue of codi -
please file an issue for WAS8.

regards,
gerhard



http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2013/4/3 Adrian Gonzalez adr_gonza...@yahoo.fr

 Just created :
  * https://issues.apache.org/jira/browse/EXTCDI-307 (EAR support for
 JBoss)
  * https://issues.apache.org/jira/browse/EXTCDI-308 (EAR support for WAS)
 and attached the corresponding patches.

 Please note that these patches doesn't cover support for all the CODI
 modules (I've tested EAR support only for the JSF module).

 Regards,
 Adrian


 - Mail original -
 De : Adrian Gonzalez adr_gonza...@yahoo.fr
 À : MyFaces Discussion users@myfaces.apache.org
 Cc :
 Envoyé le : Mercredi 3 avril 2013 11h52
 Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x

 Hello,

 I just resolved java.lang.NullPointerException: null on Websphere
 (8.0.0.4) (see [2] below).

 This issue was due :
 When a client calls a method with package level access on a CDI bean, WAS
 8.0.0.4 doesn't execute the interceptor chain.
 The call is executed directly on the javassist class (and @Inject fields
 are null in the javassist class - so we get the NPE).
 For now, just setting method visibility to public on
 both JsfRequestLifecycleBroadcaster#broadcastBeforeEvent et
 JsfRequestLifecycleBroadcaster#broadcastAfterEvent resolves this issue.


 Question is : bug located in Websphere or in CODI ?
 In other workds, does CDI 1.0 supports calling methods with package level
 access ?
 I looked at the CDI spec, but didn't find anything on this matter.
 Interceptor spec 1.1 supports it (from chapter Method interceptors :
 'Around-invoke methods can have public, private, protected, or package
 level access. An
 around-invoke method must not be declared as final or static.')
 If it's in WAS, I can open a PMR for this.
  I will open 2 tickets for EAR support : one for JBoss and another one for
 Websphere and attach both patches.
 Sounds good ?


 Best regards,
 Adrian






 
 De : Adrian Gonzalez adr_gonza...@yahoo.fr
 À : MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
 strub...@yahoo.de
 Envoyé le : Mardi 26 mars 2013 17h22
 Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x

 Hello,

 Sorry for the late feedback.
 Currently struggling on making it work with Websphere 8 (as Denis before)
 before sending a patch.

 I've corrected locally the IllegalAccessError on DefaultBeanEntryFactory
 [1] (just making DefaultBeanEntryFactory  public corrects the issue).
 Now I get only the NullPointerException
 on JsfRequestLifecycleBroadcaster.broadcastBeforeEvent [2].
 I know I could set classloader to APPLICATION, but as Denis said, it is
 not officially supported by Websphere.
 So I prefer to modify CODI's code (if possible) to be able to use it on
 WAS.

 I don't have anymore time this week to work on these issues, so I'll
 follow up next week.

 Thanks,
 Adrian


 [1]
 [3/26/13 16:52:53:494 CET] 00bc
 webappE
 com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet
 Error]-[Faces Servlet]: java.lang.RuntimeException: by
 java.lang.IllegalAccessError:

 org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultBeanEntryFactory
 at
 javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:509)

 at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:486)

 at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:422)

 at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:394)

 [2] java.lang.NullPointerException: null

 at

 org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecycleBroadcaster.broadcastBeforeEvent(JsfRequestLifecycleBroadcaster.java:58)
 ~[myfaces-extcdi-bundle-jsf20-1.0.5.nxs1-SNAPSHOT.jar:1.0.5.nxs1-SNAPSHOT]

 at

 org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecyclePhaseListener.beforePhase(JsfRequestLifecyclePhaseListener.java:56)
 ~[myfaces-extcdi-bundle-jsf20-1.0.5.nxs1-SNAPSHOT.jar:1.0.5.nxs1-SNAPSHOT]

 at

 org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:76)
 ~[com.ibm.ws.jsf.myfaces.jar:na]

 at

 org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:159)
 ~[com.ibm.ws.jsf.myfaces.jar:na]

 at
 org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
 ~[com.ibm.ws.jsf.myfaces.jar:na]

 at

 org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.execute(CodiLifecycleWrapper.java:101)
 ~[myfaces-extcdi-bundle-jsf20-1.0.5.nxs1-SNAPSHOT.jar:1.0.5.nxs1-SNAPSHOT]

 at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
 ~[javax.j2ee.jsf.jar:na]

 
 De : Mark Struberg strub...@yahoo.de
 À : MyFaces

Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x

2013-03-21 Thread Gerhard Petracek

hi adrian,

you can try if the approach i used in deltaspike would help.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/3/21 Adrian Gonzalez adr_gonza...@yahoo.fr

 Hi Mark,

 I find CODI really usefull - great library (IMO the JSF scopes are a
 must-have for any JSF application).
 I'll test the patch on monday on websphere with CLASSLOADER SINGLE and
 MULTIPLE and wait for Aleksey feedback before opening the JIRA.


 Best regards,

 Adrian

 P.S. Please note that the patch doesn't solve all the problems (i.e. for
 multiple wars in the same ear all @JsfPhaseListener will be executed - even
 if one of them is only defined in one ear).
 I don't know how to fully resolve this CDI / EAR / WAR / Classloading
 issue, not sure it's even doable for now.


 - Mail original -
 De : Mark Struberg strub...@yahoo.de
 À : MyFaces Discussion users@myfaces.apache.org; Adrian Gonzalez 
 adr_gonza...@yahoo.fr
 Cc :
 Envoyé le : Jeudi 21 mars 2013 22h01
 Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x

 Hi folks!

 a.) I hope you find CODI useful nontheless ;)
 b.) if this fix solves the problems, can you please open a JIRA for the
 EXTCDI project and attach the patch?

 txs and LieGrue,
 strub




 - Original Message -
  From: Пестов Алексей pestov.ale...@gmail.com
  To: MyFaces Discussion users@myfaces.apache.org; Adrian Gonzalez 
 adr_gonza...@yahoo.fr
  Cc:
  Sent: Thursday, March 21, 2013 8:38 PM
  Subject: Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
 
  Adrian, thank you very much for quick response!
 
  I'll try to apply your patch.
 
 
  On Thu, Mar 21, 2013 at 9:38 PM, Adrian Gonzalez
  adr_gonza...@yahoo.frwrote:
 
   Hi Aleksey,
 
   Here's the patch file (my first one with git).
   I've obtained it executing [1]
 
   I've changed CODI version from 1.0.5 to 1.0.5.nxs1-SNAPSHOT in the same
   commit (so sorry, you have this modification with this patch).
 
 
   Hope this helps,
 
   [1] execute the following line after cloning
   https://github.com/gonzalad/myfaces-extcdi
   git diff d141ac555cb263c6413c6f4ddebbd41bd4768eac^
   d141ac555cb263c6413c6f4ddebbd41bd4768eac on my
 
 
 
 
   - Mail original -
   De : Пестов Алексей pestov.ale...@gmail.com
   À : users@myfaces.apache.org
   Cc :
   Envoyé le : Jeudi 21 mars 2013 18h22
   Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
 
   Hello. Today I decided to use it and got the same problem. This does
 not
   work in the EAR to JBoss 7.1.1.
 
   Adrian, could you please make a patch (*.diff) with your solution?
 
   I would also like to know about your option 2)
 
   2. remove @JsfPhaseListener and rely on classic phaseListeners
  configured
   with faces-config.xml
 
   Can do this in faces-config.xml of my application, not in
   myfaces-extcdi-bundle-jsf20-1.0.5.jar
   ?
 
   Best regards,
 
   Aleksey
 
 
 
 
  --
  С уважением,
  Алексей Пестов
  тел. +7 (925) 067-32-13

Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x

2013-03-21 Thread Gerhard Petracek

hi adrian,

we had a lot of discussions about such (ear-)topics (e.g. see the comments
at [1]).

regards,
gerhard

[1] https://issues.jboss.org/browse/CDI-129

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/3/22 Adrian Gonzalez adr_gonza...@yahoo.fr

 Hi Gerhard,

 Thanks, didn't know you already coded @JsfPhaseListener support in DS.

 Looking at your source code [1], it should work like my patch in CODI : it
 should work in EAR situation with JBoss 7.1.0, but 'for multiple wars in
 the same ear all @JsfPhaseListener will be executed - even if one of them
 is only defined in one ear'.

 I'll try DS JsfPhaseListener on Monday with my sample EAR.

 best regards,
 Adrian

 [1]
 https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=tree;f=deltaspike/modules/jsf/impl/src/main/java/org/apache/deltaspike/jsf/impl/listener/phase;hb=HEAD


 - Mail original -
 De : Gerhard Petracek gerhard.petra...@gmail.com
 À : MyFaces Discussion users@myfaces.apache.org
 Cc :
 Envoyé le : Vendredi 22 mars 2013 0h41
 Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x

 hi adrian,

 you can try if the approach i used in deltaspike would help.

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2013/3/21 Adrian Gonzalez adr_gonza...@yahoo.fr

  Hi Mark,
 
  I find CODI really usefull - great library (IMO the JSF scopes are a
  must-have for any JSF application).
  I'll test the patch on monday on websphere with CLASSLOADER SINGLE and
  MULTIPLE and wait for Aleksey feedback before opening the JIRA.
 
 
  Best regards,
 
  Adrian
 
  P.S. Please note that the patch doesn't solve all the problems (i.e. for
  multiple wars in the same ear all @JsfPhaseListener will be executed -
 even
  if one of them is only defined in one ear).
  I don't know how to fully resolve this CDI / EAR / WAR / Classloading
  issue, not sure it's even doable for now.
 
 
  - Mail original -
  De : Mark Struberg strub...@yahoo.de
  À : MyFaces Discussion users@myfaces.apache.org; Adrian Gonzalez 
  adr_gonza...@yahoo.fr
  Cc :
  Envoyé le : Jeudi 21 mars 2013 22h01
  Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
 
  Hi folks!
 
  a.) I hope you find CODI useful nontheless ;)
  b.) if this fix solves the problems, can you please open a JIRA for the
  EXTCDI project and attach the patch?
 
  txs and LieGrue,
  strub
 
 
 
 
  - Original Message -
   From: Пестов Алексей pestov.ale...@gmail.com
   To: MyFaces Discussion users@myfaces.apache.org; Adrian Gonzalez 
  adr_gonza...@yahoo.fr
   Cc:
   Sent: Thursday, March 21, 2013 8:38 PM
   Subject: Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
  
   Adrian, thank you very much for quick response!
  
   I'll try to apply your patch.
  
  
   On Thu, Mar 21, 2013 at 9:38 PM, Adrian Gonzalez
   adr_gonza...@yahoo.frwrote:
  
Hi Aleksey,
  
Here's the patch file (my first one with git).
I've obtained it executing [1]
  
I've changed CODI version from 1.0.5 to 1.0.5.nxs1-SNAPSHOT in the
 same
commit (so sorry, you have this modification with this patch).
  
  
Hope this helps,
  
[1] execute the following line after cloning
https://github.com/gonzalad/myfaces-extcdi
git diff d141ac555cb263c6413c6f4ddebbd41bd4768eac^
d141ac555cb263c6413c6f4ddebbd41bd4768eac on my
  
  
  
  
- Mail original -
De : Пестов Алексей pestov.ale...@gmail.com
À : users@myfaces.apache.org
Cc :
Envoyé le : Jeudi 21 mars 2013 18h22
Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
  
Hello. Today I decided to use it and got the same problem. This does
  not
work in the EAR to JBoss 7.1.1.
  
Adrian, could you please make a patch (*.diff) with your solution?
  
I would also like to know about your option 2)
  
2. remove @JsfPhaseListener and rely on classic phaseListeners
   configured
with faces-config.xml
  
Can do this in faces-config.xml of my application, not in
myfaces-extcdi-bundle-jsf20-1.0.5.jar
?
  
Best regards,
  
Aleksey
  
  
  
  
   --
   С уважением,
   Алексей Пестов
   тел. +7 (925) 067-32-13

[ANNOUNCE] Release of Apache MyFaces Extensions Validator 2.0.7

2013-03-10 Thread Gerhard Petracek

The Apache MyFaces team is pleased to announce the 7th release of
Apache MyFaces Extensions Validator (for JSF 2.x).

Apache MyFaces Extensions Validator is an extensible framework to validate
user input based on annotations.

The release contains several improvements.

Apache MyFaces Extensions Validator is available in both binary and source
distributions:
http://myfaces.apache.org/extensions/validator/download.html

Apache MyFaces Extensions Validator is available in the central Maven
repository under
Group ID org.apache.myfaces.extensions.validator.*.

Release Notes:
http://s.apache.org/EXTVAL_207

Enjoy!

Gerhard Petracek

Re: ExtVal with multiple RenderKit's (Primeface + Primeface Mobile) does not work correctly

2013-02-19 Thread Gerhard Petracek

hi @ all,

i've moved the renderkit-cache used in GenericRenderKitWrapperFactory to
AbstractRenderKitWrapperFactory and simplified the rest (see [1]).

regards,
gerhard

[1] https://issues.apache.org/jira/browse/EXTVAL-151



2013/1/30 Howard W. Smith, Jr. smithh032...@gmail.com

 On Tue, Jan 29, 2013 at 6:11 AM, Reto Weiss reto.we...@ivyteam.ch wrote:

  Hi
 
  I'm using MyFaces (2.1.10) with ExtVal (2.0.6). As RenderKit's I use
  Primefaces and Primefaces Mobile. This does not work because the class
 
 
 
 org.apache.myfaces.extensions.validator.core.renderkit.DefaultRenderKitWrapperFactory
 
  is not able to handle more than one RenderKit. This is because the method
  createWrapper caches the first RenderKit it wrappes. After that it
 returns
  the cached RenderKit even if the RenderKit to wrap is another one than
 the
  cached one.
 
  I have fixed this in my project by providing my own
  RenderKitWrapperFactory:
 
  class IvyExtValRenderKitWrapperFactory extends
  AbstractRenderKitWrapperFactory
  {
private HashMapRenderKit, ExtValRenderKit wrappers = new
  HashMapRenderKit, ExtValRenderKit();
 
@Override
protected synchronized RenderKit createWrapper(RenderKit renderKit)
{
  ExtValRenderKit wrapper = wrappers.get(renderKit);
  if (wrapper == null)
  {
wrapper = new ExtValRenderKit(renderKit);
wrappers.put(renderKit, wrapper);
  }
  return wrapper;
}
 
  }
 
 
  Yes, please report and thanks for providing that patch! I was in a very
 lengthy discussion with someone else about this issue...almost a year
 ago.[1] This is good news! I hope you shared the same in PrimeFaces Mobile
 (community) forum as well.

 [1] http://forum.primefaces.org/viewtopic.php?f=8t=19910start=10#p62149

Re: ExtVal with multiple RenderKit's (Primeface + Primeface Mobile) does not work correctly

2013-01-29 Thread Gerhard Petracek

hi reto,

first of all: welcome @ myfaces!

you are welcome to provide the patch for such an improvement (just attach
it to a jira ticket).

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/1/29 Reto Weiss reto.we...@ivyteam.ch

 Hi

 I'm using MyFaces (2.1.10) with ExtVal (2.0.6). As RenderKit's I use
 Primefaces and Primefaces Mobile. This does not work because the class


 org.apache.myfaces.extensions.validator.core.renderkit.DefaultRenderKitWrapperFactory

 is not able to handle more than one RenderKit. This is because the method
 createWrapper caches the first RenderKit it wrappes. After that it returns
 the cached RenderKit even if the RenderKit to wrap is another one than the
 cached one.

 I have fixed this in my project by providing my own
 RenderKitWrapperFactory:

 class IvyExtValRenderKitWrapperFactory extends
 AbstractRenderKitWrapperFactory
 {
   private HashMapRenderKit, ExtValRenderKit wrappers = new
 HashMapRenderKit, ExtValRenderKit();

   @Override
   protected synchronized RenderKit createWrapper(RenderKit renderKit)
   {
 ExtValRenderKit wrapper = wrappers.get(renderKit);
 if (wrapper == null)
 {
   wrapper = new ExtValRenderKit(renderKit);
   wrappers.put(renderKit, wrapper);
 }
 return wrapper;
   }

 }

 Do I make something wrong or is this a bug? Should I report an issue?

 Regards

 Reto Weiss
 Product Owner / Developer Xpert.ivy

 ivyTeam AG
 Alpenstrasse 9
 6300 Zug

[ANNOUNCE] Release of Apache MyFaces Extensions Validator 1.2.6 and 2.0.6

2012-12-15 Thread Gerhard Petracek

The Apache MyFaces team is pleased to announce the 6th release of
Apache MyFaces Extensions Validator (for JSF 1.2 and 2.0).

Apache MyFaces Extensions Validator is an extensible framework to validate
user input based on annotations.

The release contains several improvements.

Apache MyFaces Extensions Validator is available in both binary and source
distributions:
http://myfaces.apache.org/extensions/validator/download.html

Apache MyFaces Extensions Validator is available in the central Maven
repository under
Group ID org.apache.myfaces.extensions.validator.*.

Release Notes:
http://s.apache.org/EXTVAL_126
http://s.apache.org/EXTVAL_206

Enjoy!

Gerhard Petracek

Re: [CODI] CODI v1.0.5 + WebSphere v8.5.0.1 problem

2012-12-10 Thread Gerhard Petracek

hi denis,

maybe rohit can provide further details.

regards,
gerhard



2012/12/10 Denis Forveille denis.forvei...@gmail.com

 Hello

 I'm trying to use CODI v1.0.5 in WebSphere v8.5.0.1 with a very simple
 application, Even if the applications deploys and starts well, on the
 first page I receive a NPE
 It seems to be caused by some javassist exception while creating a proxy ..
 Internally, WAS v8.5 uses MyFaces and OpenWebBeans ,and JDK 1.7


 Anyone has success using CODI in WAS v8.5?

 The stack trace is very long ... Here are some pieces of it

 [10/12/12 11:04:34:639 EST] 00e3 ErrorPageWrit E   An exception
 occurred
  javax.faces.FacesException:
 java.lang.NullPointerException
 at
 org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
 at
 org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
 at
 org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:191)
 at
 org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
 at
 org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.execute(CodiLifecycleWrapper.java:95)
 at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
 [truncated]
 Caused by: java.lang.NullPointerException
 at
 org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecycleBroadcaster.broadcastBeforeEvent(JsfRequestLifecycleBroadcaster.java:58)
 at
 org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecyclePhaseListener.beforePhase(JsfRequestLifecyclePhaseListener.java:56)
 at
 org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:76)
 at
 org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:159)
 ... 29 more
 [10/12/12 11:04:34:639 EST] 00e3 servlet   E
 com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: An
 exception was thrown by one of the service methods of the servlet
 [Faces Servlet] in application [CODITest]. Exception created :
 [java.lang.RuntimeException: by java.lang.IllegalAccessError:

 org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultBeanEntryFactory
 at
 javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:509)
 at
 javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:486)
 at
 javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:422)
 at
 javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:394)
 at
 org.apache.webbeans.util.SecurityUtil$PrivilegedActionForProxyFactory.run(SecurityUtil.java:301)
 at
 java.security.AccessController.doPrivileged(AccessController.java:229)
 at
 org.apache.webbeans.util.SecurityUtil.doPrivilegedCreateClass(SecurityUtil.java:184)
 at
 org.apache.webbeans.proxy.JavassistProxyFactory.getProxyClass(JavassistProxyFactory.java:429)
 at
 org.apache.webbeans.proxy.JavassistProxyFactory.createNormalScopedBeanProxy(JavassistProxyFactory.java:213)
 at
 org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:870)
 at
 com.ibm.ws.webbeans.services.IBMBeanManagerImpl.getReference(IBMBeanManagerImpl.java:204)
 at
 org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215)
 at
 org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179)
 at
 org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139)
 at
 org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:124)
 at
 org.apache.myfaces.extensions.cdi.jsf.impl.util.RequestCache.getBeanEntryFactory(RequestCache.java:106)
 at
 org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.GroupedConversationContext.resolveBeanEntryFactory(GroupedConversationContext.java:162)
 at
 org.apache.myfaces.extensions.cdi.core.impl.scope.conversation.AbstractGroupedConversationContext.create(AbstractGroupedConversationContext.java:92)
 at
 org.apache.myfaces.extensions.cdi.core.impl.scope.conversation.ConversationContextAdapter.get(ConversationContextAdapter.java:81)
 at
 org.apache.webbeans.context.CustomContextImpl.get(CustomContextImpl.java:43)
 at
 org.apache.webbeans.context.CustomPassivatingContextImpl.get(CustomPassivatingContextImpl.java:41)
 at
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:135)
 at
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:95)
 at

Re: Bug EXTVAL-130?

2012-12-05 Thread Gerhard Petracek

hi howard,

please ensure that you are using the current snapshot from [1].

if you still have issues, please provide a link to a simple demo.
(maybe you are facing an issue which affects codi but which isn't an issue
of codi itself.)

regards,
gerhard

[1] https://repository.apache.org/content/groups/snapshots

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2012/12/5 Howard W. Smith, Jr. smithh032...@gmail.com

I love and use forClass= Please take a look at [1] below, when you
get a chance to see all the chatter/discussion I had related to this topic.
Sometime after this topic, I tried 'again' to use @Advanced and still
didn't work. That is why I went with JSF @RequestScopedBeans that contain
'only' @FacesConverter forClass=...

[1] Migrating to CDI: injecting stateless/facade in Converter via
facescontext
http://openejb.979440.n4.nabble.com/Migrating-to-CDI-injecting-stateless-facade-in-Converter-via-facescontext-td4658693.html

On Tue, Dec 4, 2012 at 10:51 PM, Gerald Turner gtur...@unzane.com wrote:

Howard W. Smith, Jr. smithh032...@gmail.com writes:

I can confirm the same about CODI @Advanced not working in/with JSF
@FacesConverter. My workaround (in a TomEE/CDI/MyFaces-CODI project)
was to only add the @FacesConverter to JSF @RequestScoped managed
beans, and they are working great in/with TomEE 1.5.1 SNAPSHOT.

Thanks Howard, I'll probably go with that approach after more time
experimenting with @Advanced.

Do you get to use the 'forClass' annotation attribute of
@FacesConverter, or do you have to link them by name (I forget the
mechanism, been spoiled by 'forClass').

--
Gerald Turner Email: gtur...@unzane.com JID: gtur...@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5

Re: Bug EXTVAL-130?

2012-12-05 Thread Gerhard Petracek

hi gerald,

@ veto:
ClassDeactivator is just for classes which are listed in config files of
cdi, jsf,... (and the specs. don't provide a possibility to disable them).
in your case you just need the std. ProcessAnnotatedType#veto provided by
cdi itself.

@ BeanValidation#modelValidation

i wrote both (the annotation as well as the add-on) - i'm happy if you can
use one of both.
however, please note that they work differently.
the add-on triggers class-level validation (for special classes) at the end
of the validation-phase of the request-lifecycle and
BeanValidation#modelValidation is just the integration of class-level
validation which gets triggered at the end of the update-model-values
phase.

@ snapshot repository:
see [1]

regards,
gerhard

[1] https://repository.apache.org/content/groups/snapshots

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/12/5 Gerald Turner gtur...@unzane.com

 Hi Gerhard, thanks for the response!


 Gerhard Petracek gerhard.petra...@gmail.com writes:

  @codi + seam
  yes - that's possible.
  it depends on what you are using from both.
  e.g. in case of the jsf-module of codi + seam-faces you have to veto
  one of the producers for the FacesContext.

 Exactly, jsf/faces modules from both.  Is vetoing done with
 ClassDeactivator and writing a service-loader file?

  @ No CreationalContext registered for EL evaluation, it is likely
  that the the expression factory has not been wrapped by the CDI
  BeanManager, which must be done to use the ELResolver from CDI:
 
  ... sounds like an as7 issue. it occurs during the rendering process
  (see e.g. UIComponentBase#encodeBegin) - as7 has to ensure that all
  parts of cdi and jsf are up and running.

 I spent some time digging around the issue going on a tip from JIRA
 issue EXTVAL-140 (thanks Igor Guimaraes) - looks like it's a Weld bug.
 Weld ELResolver#getValue implementation will fail unless it's nested in
 a stack evaluating a Weld ValueExpression or MethodExpression.  OTOH,
 ValueExpression#getValue works every time.  Even stranger is that when I
 revert the project from CODI to Seam3, Weld ELResolver#getValue will
 return nulls instead of throwing an exception.  Attached is a dummy
 RENDER_RESPONSE PhaseListener that exhibits the bug (all the
 tryELResolver tests fail while all the tryValueExpression tests
 succeed).  I'll work on reporting this to Weld.  Is there any chance a
 work-around could be added to ExtVal 2.0.7-SNAPSHOT? (i.e. using a
 ValueExpression instead of ELResolver for BV startup)

  @enabling injection via @Advanced:
  the only known (and already fixed) issue is [1].

 Is there a public maven repository where I can link 1.0.6-SNAPSHOT?

  just fyi (since you wrote JSR-303 cross-field validation).
  annotations like @DateIs were introduced before the bv-spec. was
  released and don't use the bv-api at all (that's the reason why they
  are in a different validation module).
  you would need e.g. [2] to use the bv-api with a thin layer to allow
  bv based cross-field validation.

 I was wrong about my original statement that cross-field validation
 wasn't working (whereas @DateIs was working)… they're both working.

 I had this question on the mailing list in March and you pointed me at
 the extension then too.  I didn't have to use the extension you wrote.
 I'm using the following ExtVal-BV annotation on the fields of a CDI bean
 that I want cross-validation:
   @BeanValidation(modelValidation=@ModelValidation(isActive=true))
 …this has been working great - am I missing something?

 --
 Gerald Turner   Email: gtur...@unzane.com   JID: gtur...@unzane.com
 GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5

Re: el issue with weld (was: Bug EXTVAL-130?)

2012-12-05 Thread Gerhard Petracek

hi gerald,

@ el issue with weld:
that sounds like a serious weld bug.
extval is just using the std. jsf-api (in this
case: javax.faces.application.Application#evaluateExpressionGet).
brian leathem confirmed the weld-issue - maybe jozef can provide further
details.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/12/6 Gerhard Petracek gerhard.petra...@gmail.com

 hi gerald,

 @ veto:
 ClassDeactivator is just for classes which are listed in config files of
 cdi, jsf,... (and the specs. don't provide a possibility to disable them).
 in your case you just need the std. ProcessAnnotatedType#veto provided by
 cdi itself.

 @ BeanValidation#modelValidation

 i wrote both (the annotation as well as the add-on) - i'm happy if you
 can use one of both.
 however, please note that they work differently.
 the add-on triggers class-level validation (for special classes) at the
 end of the validation-phase of the request-lifecycle and
 BeanValidation#modelValidation is just the integration of class-level
 validation which gets triggered at the end of the update-model-values
 phase.

 @ snapshot repository:
 see [1]

 regards,
 gerhard

 [1] https://repository.apache.org/content/groups/snapshots

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2012/12/5 Gerald Turner gtur...@unzane.com

 Hi Gerhard, thanks for the response!


 Gerhard Petracek gerhard.petra...@gmail.com writes:

  @codi + seam
  yes - that's possible.
  it depends on what you are using from both.
  e.g. in case of the jsf-module of codi + seam-faces you have to veto
  one of the producers for the FacesContext.

 Exactly, jsf/faces modules from both.  Is vetoing done with
 ClassDeactivator and writing a service-loader file?

  @ No CreationalContext registered for EL evaluation, it is likely
  that the the expression factory has not been wrapped by the CDI
  BeanManager, which must be done to use the ELResolver from CDI:
 
  ... sounds like an as7 issue. it occurs during the rendering process
  (see e.g. UIComponentBase#encodeBegin) - as7 has to ensure that all
  parts of cdi and jsf are up and running.

 I spent some time digging around the issue going on a tip from JIRA
 issue EXTVAL-140 (thanks Igor Guimaraes) - looks like it's a Weld bug.
 Weld ELResolver#getValue implementation will fail unless it's nested in
 a stack evaluating a Weld ValueExpression or MethodExpression.  OTOH,
 ValueExpression#getValue works every time.  Even stranger is that when I
 revert the project from CODI to Seam3, Weld ELResolver#getValue will
 return nulls instead of throwing an exception.  Attached is a dummy
 RENDER_RESPONSE PhaseListener that exhibits the bug (all the
 tryELResolver tests fail while all the tryValueExpression tests
 succeed).  I'll work on reporting this to Weld.  Is there any chance a
 work-around could be added to ExtVal 2.0.7-SNAPSHOT? (i.e. using a
 ValueExpression instead of ELResolver for BV startup)

  @enabling injection via @Advanced:
  the only known (and already fixed) issue is [1].

 Is there a public maven repository where I can link 1.0.6-SNAPSHOT?

  just fyi (since you wrote JSR-303 cross-field validation).
  annotations like @DateIs were introduced before the bv-spec. was
  released and don't use the bv-api at all (that's the reason why they
  are in a different validation module).
  you would need e.g. [2] to use the bv-api with a thin layer to allow
  bv based cross-field validation.

 I was wrong about my original statement that cross-field validation
 wasn't working (whereas @DateIs was working)… they're both working.

 I had this question on the mailing list in March and you pointed me at
 the extension then too.  I didn't have to use the extension you wrote.
 I'm using the following ExtVal-BV annotation on the fields of a CDI bean
 that I want cross-validation:
   @BeanValidation(modelValidation=@ModelValidation(isActive=true))
 …this has been working great - am I missing something?

 --
 Gerald Turner   Email: gtur...@unzane.com   JID: gtur...@unzane.com
 GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5

Re: el issue with weld (was: Bug EXTVAL-130?)

2012-12-05 Thread Gerhard Petracek

short addition:
in this case it's actually Application#getELResolver#getValue
(brian confirmed it for Application#evaluateExpressionGet which is needed
by extval as well)

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/12/6 Gerhard Petracek gerhard.petra...@gmail.com

 hi gerald,

 @ el issue with weld:
 that sounds like a serious weld bug.
 extval is just using the std. jsf-api (in this
 case: javax.faces.application.Application#evaluateExpressionGet).
 brian leathem confirmed the weld-issue - maybe jozef can provide further
 details.

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2012/12/6 Gerhard Petracek gerhard.petra...@gmail.com

 hi gerald,

 @ veto:
 ClassDeactivator is just for classes which are listed in config files of
 cdi, jsf,... (and the specs. don't provide a possibility to disable them).
 in your case you just need the std. ProcessAnnotatedType#veto provided by
 cdi itself.

 @ BeanValidation#modelValidation

 i wrote both (the annotation as well as the add-on) - i'm happy if you
 can use one of both.
 however, please note that they work differently.
 the add-on triggers class-level validation (for special classes) at the
 end of the validation-phase of the request-lifecycle and
 BeanValidation#modelValidation is just the integration of class-level
 validation which gets triggered at the end of the update-model-values
 phase.

 @ snapshot repository:
 see [1]

 regards,
 gerhard

 [1] https://repository.apache.org/content/groups/snapshots

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2012/12/5 Gerald Turner gtur...@unzane.com

 Hi Gerhard, thanks for the response!


 Gerhard Petracek gerhard.petra...@gmail.com writes:

  @codi + seam
  yes - that's possible.
  it depends on what you are using from both.
  e.g. in case of the jsf-module of codi + seam-faces you have to veto
  one of the producers for the FacesContext.

 Exactly, jsf/faces modules from both.  Is vetoing done with
 ClassDeactivator and writing a service-loader file?

  @ No CreationalContext registered for EL evaluation, it is likely
  that the the expression factory has not been wrapped by the CDI
  BeanManager, which must be done to use the ELResolver from CDI:
 
  ... sounds like an as7 issue. it occurs during the rendering process
  (see e.g. UIComponentBase#encodeBegin) - as7 has to ensure that all
  parts of cdi and jsf are up and running.

 I spent some time digging around the issue going on a tip from JIRA
 issue EXTVAL-140 (thanks Igor Guimaraes) - looks like it's a Weld bug.
 Weld ELResolver#getValue implementation will fail unless it's nested in
 a stack evaluating a Weld ValueExpression or MethodExpression.  OTOH,
 ValueExpression#getValue works every time.  Even stranger is that when I
 revert the project from CODI to Seam3, Weld ELResolver#getValue will
 return nulls instead of throwing an exception.  Attached is a dummy
 RENDER_RESPONSE PhaseListener that exhibits the bug (all the
 tryELResolver tests fail while all the tryValueExpression tests
 succeed).  I'll work on reporting this to Weld.  Is there any chance a
 work-around could be added to ExtVal 2.0.7-SNAPSHOT? (i.e. using a
 ValueExpression instead of ELResolver for BV startup)

  @enabling injection via @Advanced:
  the only known (and already fixed) issue is [1].

 Is there a public maven repository where I can link 1.0.6-SNAPSHOT?

  just fyi (since you wrote JSR-303 cross-field validation).
  annotations like @DateIs were introduced before the bv-spec. was
  released and don't use the bv-api at all (that's the reason why they
  are in a different validation module).
  you would need e.g. [2] to use the bv-api with a thin layer to allow
  bv based cross-field validation.

 I was wrong about my original statement that cross-field validation
 wasn't working (whereas @DateIs was working)… they're both working.

 I had this question on the mailing list in March and you pointed me at
 the extension then too.  I didn't have to use the extension you wrote.
 I'm using the following ExtVal-BV annotation on the fields of a CDI bean
 that I want cross-validation:
   @BeanValidation(modelValidation=@ModelValidation(isActive=true))
 …this has been working great - am I missing something?

 --
 Gerald Turner   Email: gtur...@unzane.com   JID: gtur...@unzane.com
 GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5

Re: Bug EXTVAL-130?

2012-12-04 Thread Gerhard Petracek

hi gerald,

@codi + seam
yes - that's possible.
it depends on what you are using from both.
e.g. in case of the jsf-module of codi + seam-faces you have to veto one of
the producers for the FacesContext.

@ No CreationalContext registered for EL evaluation, it is likely that the
the expression factory has not been wrapped by the CDI BeanManager, which
must be done to use the ELResolver from CDI:

... sounds like an as7 issue. it occurs during the rendering process (see
e.g. UIComponentBase#encodeBegin) - as7 has to ensure that all parts of
cdi and jsf are up and running.

@enabling injection via @Advanced:
the only known (and already fixed) issue is [1].

just fyi (since you wrote JSR-303 cross-field validation).
annotations like @DateIs were introduced before the bv-spec. was released
and don't use the bv-api at all (that's the reason why they are in a
different validation module).
you would need e.g. [2] to use the bv-api with a thin layer to allow bv
based cross-field validation.

regards,
gerhard

[1] https://issues.apache.org/jira/browse/EXTCDI-302
[2]
http://os890.blogspot.co.at/2010/06/multi-field-form-validation-with-jsr.html

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/12/4 Gerald Turner gtur...@unzane.com

 Hello, I'm in the process of converting a JSF2/CDI application from
 Seam3 to MyFaces ExtCDI/CODI.  The application had been using MyFaces
 ExtVal-BV so that JSR-303 cross-field validation would work in the
 front-end.  Simply replacing Seam3 with CODI evoked the following
 stacktrace during the first page view (during MyFaces EXT* lazy init),
 and ExtVal-BV doesn't seem to be working entirely (annotations like
 @DateIs work, but my ConstraintValidators aren't being executed).
 Things actually get worse than that, some injection points no longer
 work, particularly on an abstract superclass - but I figure I should
 solve this warning before exploring that issue.  Also injection in
 FacesConverter and ConstraintValidators (when triggered by JPA) don't
 work even after annotating with @Advanced - again, probably a secondary
 effect.  Also yet another tangent - I've heard that CODI and Seam3 can
 be deployed together, but under JBoss 7.1.1.Final the app doesn't deploy
 due to Weld errors with ambiguous producers - I haven't found any
 documentation that describes any Veto-esque configuration.

 This looks exactly like JIRA issue EXTVAL-130, only I'm using JBoss
 7.1.1.Final instead of Glassfish, but they both share Weld, and I am
 using ExtVal 2.0.6, which is the fixed version.

 Relevant parts of my pom.xml:

 !-- CDI  MyFaces ExtCDI/CODI --
 dependency
   groupIdjavax.enterprise/groupId
   artifactIdcdi-api/artifactId
   version1.0-SP4/version
   scopeprovided/scope
 /dependency
 dependency
   groupIdorg.apache.myfaces.extensions.cdi.bundles/groupId
   artifactIdmyfaces-extcdi-bundle-jsf20/artifactId
   version1.0.5/version
 /dependency

 !-- MyFaces ExtVal --
 dependency

 groupIdorg.apache.myfaces.extensions.validator.validation-modules/groupId
   artifactIdmyfaces-extval-property-validation/artifactId
   version2.0.6/version
   exclusions
 exclusion
   groupIdjavax.persistence/groupId
   artifactIdpersistence-api/artifactId
 /exclusion
   /exclusions
 /dependency
 dependency

 groupIdorg.apache.myfaces.extensions.validator.validation-modules/groupId
   artifactIdmyfaces-extval-bean-validation/artifactId
   version2.0.6/version
   exclusions
 exclusion
   groupIdjavax.validation/groupId
   artifactIdvalidation-api/artifactId
 /exclusion
   /exclusions
 /dependency

 Some bits of the CODI startup version output (need to see the booleans
 too?):

   10:56:32,600 INFO
 [org.apache.myfaces.extensions.cdi.jsf2.impl.Jsf2ModuleStartupObserver]
 (http--0.0.0.0-8080-1) [Started] MyFaces CODI JSF-Module v1.0.5 for JSF 2.0
 Used JSF implementation: Mojarra vnull

   10:56:32,611 INFO
 [org.apache.myfaces.extensions.cdi.jpa.impl.JpaModuleStartupObserver]
 (http--0.0.0.0-8080-1) [Started] MyFaces CODI JPA-Module v1.0.5

   10:56:32,620 INFO
 [org.apache.myfaces.extensions.cdi.core.impl.CoreStartupObserver]
 (http--0.0.0.0-8080-1) [Started] MyFaces CODI (Extensions CDI) Core v1.0.5
 Used CDI implementation: Weld v2012-02-10 15:31

 The stacktrace:

   10:56:33,838 WARNING
 [org.apache.myfaces.extensions.validator.beanval.ValidatorFactoryProxy]
 (http--0.0.0.0-8080-1) failed to lookup a bean with the name
 contextAwareValidatorFactory: java.lang.IllegalStateException: No
 CreationalContext registered for EL evaluation, it is likely that the the
 expression factory has not been wrapped by the CDI BeanManager, which must
 be done to use the ELResolver from CDI
 at

Re: CODI: Exclude windowId from certain pages

2012-11-30 Thread Gerhard Petracek

i agree with mark.

in one of our first benchmarks we used gf (v3.1.1 - i can't confirm it for
v.3.2.x), as7 and tomcat. back then gf always had the worst results and
sometimes it just broke down completely. however, afair we heard about codi
based projects which do load-tests with a way higher load.

- imo you would see the same issue with the std. session scope (just a bit
later).

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/11/30 Mark Struberg strub...@yahoo.de

 No Leo, cannot be a problem!

 As Gerhard already explained we only keep a configurable number of
 'windows' per Session. Once this limit is exceeded the LRU one will get
 destroyed. It's really a non-issue. The problem Andreas faces must be
 another one. Or it's a bug, but this is really well tested imo.

 LieGrue,
 strub




 - Original Message -
  From: Leonardo Uribe lu4...@gmail.com
  To: MyFaces Discussion users@myfaces.apache.org
  Cc:
  Sent: Friday, November 30, 2012 5:47 AM
  Subject: Re: CODI: Exclude windowId from certain pages
 
  Hi
 
  Are you invalidating the session (logout) in some point? Maybe that
 could be
  related to the problem, because if you keep the session active and create
  hundreds of different windows, since the session is not released that
 memory
  will not be restored and the stress testing will not be accurate (or
 realistic).
 
  regards,
 
  Leonardo Uribe
 
  2012/11/29 Gerhard Petracek gerhard.petra...@gmail.com:
   hi andreas,
 
   please have a look at WindowContextConfig - see e.g.
   #isUnknownWindowIdsAllowed and #getMaxWindowContextCount
   - it shouldn't be an issue (since you can customize the default
  behaviour).
 
   btw:
   we are doing a lot of such tests (without
 windowId=automatedEntryPoint) and
   never saw an issue - but we don't use glassfish ;)
 
   regards,
   gerhard
 
   http://www.irian.at
 
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
 
   Professional Support for Apache MyFaces
 
 
 
   2012/11/29 Andreas Kaiser kaiser.andr...@gmail.com
 
   Hi
   thanks for the answer
 
   I will have a look at this.
   BTW. it seems that the the windowId is a potential security issue.
 
   For instance call a side with an unknown windowId. CODI will generate
 a
  new
   valid one. Just change the generated one to a new invalid id. CODI
 will
   generate a new one again. Repeat this until you are out of ids or the
   server is out of memory ;-)
 
   This is whats happend in my application due to stress testing
 
   Regards
 
 
   On Thu, Nov 29, 2012 at 11:03 PM, Gerhard Petracek 
   gerhard.petra...@gmail.com wrote:
 
hi andreas,
   
first of all: welcome @ myfaces!
   
there are different approaches - e.g. you can use urls with
  windowId=automatedEntryPoint
(see the javadoc in WindowContextManager)
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
2012/11/29 Andreas Kaiser kaiser.andr...@gmail.com
   
 Hi everybody

 I have following setup :

 Glassfish 3.1.2.2
 Weld
 Java EE6 + JSF + CDI + JPA
 CODI: 1.0.5

 My problem:

 We use and like the windowId Feature from CODI. But it causes
  some big
 problems on some pages which are specially created for stress
  testing.

 These pages are accessed from 500+ clients generated from
  JMeter.
 Every client acts as a own browser.

 This pages (RequestScoped) can be accessed without login.
  Therefore
   CODI
 generates a new windowId for every client.

 The problem is that the JMeter tests run multiple times. Due
  to this
   the
 Hashmap in JSFWindowContext.java consums a lot of memory
  until the
 Glassfish has no space left which leads into a 100 % CPU
  usage because
the
 garbage collector tries to free a even the last few bytes.

 My question is
 1. Is it possible to create windowIds only a user is logged
  in
 2. Is there an option to change the default behavior
 3. Can i exclude some pages being handled by the codi
  JSFWindowManager




 Regards

Re: CODI: Exclude windowId from certain pages

2012-11-29 Thread Gerhard Petracek

hi andreas,

first of all: welcome @ myfaces!

there are different approaches - e.g. you can use urls with
  windowId=automatedEntryPoint
(see the javadoc in WindowContextManager)

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/11/29 Andreas Kaiser kaiser.andr...@gmail.com

 Hi everybody

 I have following setup :

 Glassfish 3.1.2.2
 Weld
 Java EE6 + JSF + CDI + JPA
 CODI: 1.0.5

 My problem:

 We use and like the windowId Feature from CODI. But it causes some big
 problems on some pages which are specially created for stress testing.

 These pages are accessed from 500+ clients generated from JMeter.
 Every client acts as a own browser.

 This pages (RequestScoped) can be accessed without login. Therefore CODI
 generates a new windowId for every client.

 The problem is that the JMeter tests run multiple times. Due to this the
 Hashmap in JSFWindowContext.java consums a lot of memory until the
 Glassfish has no space left which leads into a 100 % CPU usage because the
 garbage collector tries to free a even the last few bytes.

 My question is
 1. Is it possible to create windowIds only a user is logged in
 2. Is there an option to change the default behavior
 3. Can i exclude some pages being handled by the codi JSFWindowManager




 Regards

Re: CODI: Exclude windowId from certain pages

2012-11-29 Thread Gerhard Petracek

hi andreas,

please have a look at WindowContextConfig - see e.g.
#isUnknownWindowIdsAllowed and #getMaxWindowContextCount
- it shouldn't be an issue (since you can customize the default behaviour).

btw:
we are doing a lot of such tests (without windowId=automatedEntryPoint) and
never saw an issue - but we don't use glassfish ;)

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/11/29 Andreas Kaiser kaiser.andr...@gmail.com

 Hi
 thanks for the answer

 I will have a look at this.
 BTW. it seems that the the windowId is a potential security issue.

 For instance call a side with an unknown windowId. CODI will generate a new
 valid one. Just change the generated one to a new invalid id. CODI will
 generate a new one again. Repeat this until you are out of ids or the
 server is out of memory ;-)

 This is whats happend in my application due to stress testing

 Regards


 On Thu, Nov 29, 2012 at 11:03 PM, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:

  hi andreas,
 
  first of all: welcome @ myfaces!
 
  there are different approaches - e.g. you can use urls with
windowId=automatedEntryPoint
  (see the javadoc in WindowContextManager)
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/11/29 Andreas Kaiser kaiser.andr...@gmail.com
 
   Hi everybody
  
   I have following setup :
  
   Glassfish 3.1.2.2
   Weld
   Java EE6 + JSF + CDI + JPA
   CODI: 1.0.5
  
   My problem:
  
   We use and like the windowId Feature from CODI. But it causes some big
   problems on some pages which are specially created for stress testing.
  
   These pages are accessed from 500+ clients generated from JMeter.
   Every client acts as a own browser.
  
   This pages (RequestScoped) can be accessed without login. Therefore
 CODI
   generates a new windowId for every client.
  
   The problem is that the JMeter tests run multiple times. Due to this
 the
   Hashmap in JSFWindowContext.java consums a lot of memory until the
   Glassfish has no space left which leads into a 100 % CPU usage because
  the
   garbage collector tries to free a even the last few bytes.
  
   My question is
   1. Is it possible to create windowIds only a user is logged in
   2. Is there an option to change the default behavior
   3. Can i exclude some pages being handled by the codi JSFWindowManager
  
  
  
  
   Regards

Re: Injection into filters with Tomcat

2012-11-26 Thread Gerhard Petracek

hi laurent,

first of all: welcome @ myfaces!

that isn't supported out-of-the-box (for filters).
if you would like to do it on your own, you can have a look at the
implementation of CodiUtils#tryToInjectFields .

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/11/26 Laurent Cottereau laur...@cottereau.name

 Hello,

 I have been trying without success to inject an EntityManager into a Filter
 on Tomcat 6. Is that supposed to be possible with CODI ? If so, is there
 anything special I should look into ? Is @Advanced the correct annotation I
 should use on the filter ?

 Thank you in advance for any help you will be able to provide me,

 --
   Laurent Cottereau
   laur...@cottereau.name
   http://laurent.cottereau.name

Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext

2012-11-21 Thread Gerhard Petracek

hi howard,

yes - i've fixed EXTCDI-302 already - if you like, you can test it with
the current snapshot (just ensure that you have the latest snapshot).
if you have an apache-jira account, i'll update the ticket so that you are
listed as the reporter of it.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com

 Gerhard,

 Interesting.


- MyFaces CODI https://issues.apache.org/jira/browse/EXTCDI
- EXTCDI-302 https://issues.apache.org/jira/browse/EXTCDI-302


 is a new issue that you just created and resolved per this email I just
 sent? :)

 Thanks,
 Howard



 On Wed, Nov 21, 2012 at 2:55 AM, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:

 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

Re: Can start in debug, but not in release

2012-11-21 Thread Gerhard Petracek

hi ludovic,

then we would need a link to a package example which illustrates the issue.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/11/21 l.pe...@senat.fr l.pe...@senat.fr

 On 20/11/2012 20:16, Gerhard Petracek wrote:

 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/http://people.apache.org/~gpetracek/myfaces/

 regards,
 gerhard

 Dear Gerhard,

 thank you for this quick reply.

 I, in fact, copied my dependencies from a pom.xml generation using your
 artifact. So, they are pretty much the same, excepted on the following
 point. I define MyFaces/OWB/PrimeFaces/other-**JSF-related-stuff in a
 helper package, which I add as a dependency to my project.

 So, in the mvn dependency:tree of my project,

 [INFO] +- org.apache.geronimo.specs:**geronimo-servlet_2.5_spec:jar:**
 1.2:provided
 [INFO] +- org.apache.geronimo.specs:**geronimo-el_1.0_spec:jar:1.0.**
 2:provided

 is not listed.

 But, as far as I understand, it should not be a problem. And it does not
 seem to be, as adding them in my top level pom.xml does not help.

 Thanks again,

 Ludovic

 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext

2012-11-21 Thread Gerhard Petracek

hi howard,

#1:
i've updated the ticket - thx!

#2:
via maven (to update a local snapshot build your application with
the maven-parameter -U)
or
download it from [1]
or
checkout codi and build it locally (see the description in the wiki)

regards,
gerhard

[1]
https://repository.apache.org/content/groups/snapshots/org/apache/myfaces/extensions/cdi/

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com

 Gerhard,

 I just registered with username that matches username of my email address
 (above).

 Hmmm, now I need to find out how I can get the latest snapshot. Can I
 locate on Maven Central repository?

 Thanks,
 Howard


 On Wed, Nov 21, 2012 at 4:13 AM, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:

 hi howard,

 yes - i've fixed EXTCDI-302 already - if you like, you can test it with
 the current snapshot (just ensure that you have the latest snapshot).
 if you have an apache-jira account, i'll update the ticket so that you
 are listed as the reporter of it.

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces


 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com

 Gerhard,

 Interesting.


- MyFaces CODI https://issues.apache.org/jira/browse/EXTCDI
- EXTCDI-302 https://issues.apache.org/jira/browse/EXTCDI-302


 is a new issue that you just created and resolved per this email I just
 sent? :)

 Thanks,
 Howard



 On Wed, Nov 21, 2012 at 2:55 AM, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:

 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

Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext

2012-11-21 Thread Gerhard Petracek

the jsf2 module of codi is tested with jsf 2.0.x and 2.1.x

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com

Gerhard,

I definitely prefer [1] (JAR download), thanks.

Interesting...I must have been multitasking big time while migrating to
TomEE/CDI, because I downloaded jsf1.2 1.0.5 version of CODI; that's the
filename of the JAR I downloaded.

This 1.0.6 SNAPSHOT that is now available, is this jsf1.2 or jsf2.0? I
hope jsf2.0, since my app has been jsf2.1 ever since the start (a little
over 1 year ago).

Thanks,
Howard

On Wed, Nov 21, 2012 at 4:40 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:

hi howard,

#1:
i've updated the ticket - thx!

#2:
via maven (to update a local snapshot build your application with
the maven-parameter -U)
or
download it from [1]
or
checkout codi and build it locally (see the description in the wiki)

regards,
gerhard

[1]
https://repository.apache.org/content/groups/snapshots/org/apache/myfaces/extensions/cdi/

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com

Gerhard,

I just registered with username that matches username of my email
address (above).

Hmmm, now I need to find out how I can get the latest snapshot. Can I
locate on Maven Central repository?

Thanks,
Howard

On Wed, Nov 21, 2012 at 4:13 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:

hi howard,

yes - i've fixed EXTCDI-302 already - if you like, you can test it
with the current snapshot (just ensure that you have the latest snapshot).
if you have an apache-jira account, i'll update the ticket so that you
are listed as the reporter of it.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com

Gerhard,

Interesting.

- MyFaces CODI https://issues.apache.org/jira/browse/EXTCDI
- EXTCDI-302 https://issues.apache.org/jira/browse/EXTCDI-302

is a new issue that you just created and resolved per this email I
just sent? :)

Thanks,
Howard

On Wed, Nov 21, 2012 at 2:55 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:

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

Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped

2012-11-21 Thread Gerhard Petracek

hi howard,

you can have a look at [1] (e.g. slide #9)
the mentioned public application is using codi scopes like
@ViewAccessScoped without any performance and/or memory issue.

regards,
gerhard

[1] http://os890.blogspot.co.at/2012/11/slides-apache-myfaces-universe.html

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com

 The most users that will be using the app concurrently is 4 to 5 users (my
 family), and there are times that they are doing some 'heavy lifting'
 (database retrievals/updates, as well as PDF files generated in memory and
 printed/viewed/emailed/faxed, and occasional data push to Google Calendar
 via Google Calendar API). Next, planning to automatically insert data into
 database from public website's form results.  Hoping to expand the services
 of the 'app' to customers via the public website...one day.

 The (JSF/HTML5) web app is accessed in and out of the office on multiple
 platforms (laptops, iPad, multiple Android devices).


 On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko 
 andraschko.tho...@gmail.com wrote:

  Can i ask you how much users serves your app?
  Currently our app takes only 20mb session size with 200 (or 100, can't
  remember exactly) concurrent users and we don't use that much
  View(Access)Scoped beans.
 
  2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
 
   Thomas,
  
   Well, for now, I opt to do/use CDI @RequestScoped, ASAP, since
 production
   box/server is running Windows 2003 Server, where 4GB RAM is
 max...shaking
   my head. I'm sure we will upgrade when necessary, but right now that
 app
  is
   lighting fast now with Glassfish 3.1.2.2 and MyFaces Core 2.1.9 and
 JUEL
   2.2.5. :)
  
   Looking forward to the performance advantages/gains of OpenWebBeans. :)
  
   Also, this Batoo JPA that you mentioned earlier, because
  EclipseLink/Derby
   and Google Calendar requests/updates are the only 2 bottlenecks in the
  app.
  
   Thanks,
   Howard
  
   On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko 
   andraschko.tho...@gmail.com wrote:
  
Howard, there is nothing against ViewScoped/ViewAccessScoped.
But many data in ViewScoped/ViewAccessScoped leads to high memory
  usage,
   so
it's better to use RequestScoped if possible.
   
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
   
 I'd like to take time to thank you all that helped me migrate from
 Glassfish 3.1.2.2 and JSF Managed beans to TomEE and CDI managed
   beans. I
 think the migration is complete. I am in regression testing
  phase/mode
now.
 :)

 Special shout out to Thomas Andraschko, as his inputs in PrimeFaces
forums
 and blogs, lead/motivated me to migrate from Mojarra 2.1.7 to
 MyFaces
Core
 2.1.8 for fast (AJAX) rendering performance, and then he even
   recommended
 MyFaces Core, OpenWebBeans, JUEL for huge performance gains, and
 even
 today, he encouraged me to consider Batoo JPA, and because of that,
 TomEE/OpenEJB and Batoo JPA are now discussing integration! :)

 Anyway, Jose, here, recommended CODI @ViewAccessScoped. I think
  Thomas
and
 some other expert users in PrimeFaces Core forum recommended
@RequestScoped
 as much as possible throughout app, and recommended against JSF
@ViewScoped
 as well as CODI @ViewAccessScoped (I hope I'm not misquoting
them...smile).

 Honestly, I have no CDI @RequestScoped beans in my app; I need to
  take
time
 to move some of my code from CDI @SessionScoped to CDI
  @RequestScoped.
 Also, due to issues I experienced injecting EJBs inside of
@FacesConverter
 (which were added to CDI @SessionScoped beans) caused me to move
 all
  my
 @FacesConverter classes to JSF @RequestScoped beans; that seems to
 be
 working great, but Mark and Gerhard has already recommended CODI
 @Advanced/etc... to inject beans in @FacesConverter classes. I need
  to
give
 them a try even though I spent hours moving @FacesConverter classes
   from
 CDI beans to JSF Managed beans...during this migration to CDI.

 So, please advise on whether I should use @ViewAccessScoped; pros,
   cons,
 promote/hinder performance, etc...

 OR, should I move to CDI @RequestScoped, ASAP??? :)

 Oh, Romain informed me that tomee.xml JDBC resources automatically
  have
 pooling. I hope that is the case, because as soon as regression
  testing
is
 complete, I would like to push the new CDI version of my JSF web
 app
  to
 production, and start using some of the other/neat features of CDI,
   like
 CDI events where possible. :)

 Thanks,
 Howard

Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans

2012-11-20 Thread Gerhard Petracek

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

2012-11-20 Thread Gerhard Petracek

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: Migrating to CDI: injecting stateless/facade in Converter via facescontext

2012-11-20 Thread Gerhard Petracek

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.

Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans

2012-11-17 Thread Gerhard Petracek

hi jose,

just fyi:
with tomee you don't need weld, because you get openwebbeans out-of-the-box.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2012/11/17 José Luis Cetina maxtorz...@gmail.com

Hi let me tell you my experience.
I migrate from managedbeans + mojarra + glassfish to myfaces + WELD + TomEE
and now I'm so happy to did so.

Now my app use:
-Apache TomEE 1.5
-Apache MyFaces
-Apache CODI
-Primefaces 3.4.2
-Primefaces Mobile
-Primefaces Extensions 0.6.1
-PrettyFaces 3.3.3
-OpenJPA 2.2
-EJB
-JdbcRealm for login (my own query for login using any tables in my mysql
database).
-WELD
-And all the excellent Apache stuff
Etc...

And I'm so happy with this change, the this are more easy to config, use
more standards, is very very fast, use myfaces and with this you can forget
speed issues.

This project is a maven project, in netbeans 7.2.

If you need some example project I can send you a simple example.

I enhance my jpa entities so easy with maven plugin, run in every IDE and
other stuff that are excellents

Seriously if have the opportunity and time to migrate do it now you will be
happy.

And one tip maybe you don't need CODI at the beginning. CODI can help in
many things like type-safe navigations, security, validations, prerenders
events and so on.

Al most forget to tell you the easy Way for drop your jars in lib folder
and with this decrease your war size, I remember in glassfish sometimes it
wasn't easy.

I recommend you to be alert for changes and fixes in TomEE, because they
fix issues and update in they trunk svn everyday.

Please suscribe to TomEE mailing lists. Rommain is a great commiter guy who
help immediately with other people.

I hope this experience can help you.

SCJA. Jose Luis Cetina
maxtorzito
El 17/11/2012 06:06, Mark Struberg strub...@yahoo.de escribió:

Hi!

If you look for docs, here they are:

http://tomee.apache.org/documentation.html

LieGrue,
strub

From: Howard W. Smith, Jr. smithh032...@gmail.com
To: Mark Struberg strub...@yahoo.de
Cc: MyFaces Discussion users@myfaces.apache.org
Sent: Saturday, November 17, 2012 1:02 PM
Subject: Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI
Managed
Beans

Great, thanks Mark. I did download TomEE, and looking at examples
(referenced on same page as TomEE downloads) and I'm looking at this
guide
below to ensure I am injecting beans correctly.

http://docs.jboss.org/weld/reference/1.0.0/en-US/html/injection.html

On Sat, Nov 17, 2012 at 6:50 AM, Mark Struberg strub...@yahoo.de
wrote:

If you have troubles starting tomee then don't hesitate to ping us via
IRC on irc.freenode.net in channel #openejb (tomee s hosted there).

LieGrue,
strub

From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg
strub...@yahoo.de
Sent: Saturday, November 17, 2012 12:06 PM
Subject: Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI
Managed Beans

Mark,

Thank you for the response.

1. Yes, I did add an 'empty' beans.xml to WEB-INF as advised by many
places on the internet, and the app starts up successfully. I did 'not'
have beans.xml added to META-INF, since all of my code is in the web app
(I
created no JARs of my own). I just added beans.xml to META-INF (while
beans.xhtml already exists in WEB-INF), attempted to start glassfish,
and I
get the following error:

INFO: WELD-000900 1.1.8 (Final)
SEVERE: Exception while invoking class org.glassfish.weld.WeldDeployer
load method
java.lang.NullPointerException
at

org.glassfish.weld.BeanDeploymentArchiveImpl.handleEntry(BeanDeploymentArchiveImpl.java:504)
at

org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:482)
at

org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:422)

I'm sure the error above means that my web app does not need 'empty'
beans.xml in META-INF (and WEB-INF), so I will remove beans.xml from
META-INF.

2. Yes, all CDI beans (accessed via EL) have @Named annotation, and I
am using @Inject along with Qualifiers (for classes that extend ancestor
classes). Below are notes from what I did/completed yesterday for this
migration:

Migrate from JSF Managed Beans to CDI Managed Beans

Replace
javax.faces.bean.ManagedBean
with
javax.inject.Named

replace
javax.faces.bean.ManagedProperty
with
javax.inject.Inject

replace
javax.faces.bean.SessionScoped
with
javax.enterprise.context.SessionScoped

replace
javax.faces.bean.ApplicationScoped
with

Re: @BeanValidation annotation at class level

2012-10-19 Thread Gerhard Petracek

hi manuel,

thx for providing the details.
please file a jira ticket (improvement) for it at [1].

regards,
gerhard

[1] https://issues.apache.org/jira/browse/EXTVAL

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/10/19 manuel.gamerdin...@t-systems.com

 Update: It works when I use the @RequestScoped Annotation from
 javax.faces.bean instead of javax.enterprise.context. In that case there is
 no byte code proxy returned (objectToInspect.getClass()).
 But anyways I expect that it should also run with the CDI scopes.

 Manuel Gamerdinger

 T-Systems GEI GmbH
 Systems Integration
 Industry Application Solutions
 Project Center Industry Applications
 Manuel Gamerdinger
 Software Architect
 Fasanenweg 5, 70771 Leinfelden-Echterdingen
 +49 711 999-8704 (Tel.)
 +49 160 8224185 (Mobil)
 E-Mail: manuel.gamerdin...@t-systems.com
 Internet: http://www.t-systems.de

 T-Systems GEI GmbH
 Supervisory Board: Dr. Ferri Abolhassan (Chairman)
 Board of Management: Hans-Jörg Glaß (Chairman), Jan Krellner
 Commercial register: Amtsgericht Aachen HRB 7106
 Registered office: Aachen
 Int. VAT No. DE 811 137 130

 Notice: This transmittal and/or attachments may be privileged or
 confidential. It is intended solely for the addressee named above. Any
 review, dissemination, or copying is strictly prohibited. If you received
 this transmittal in error, please notify us immediately by reply and
 immediately delete this message and all its attachments. Thank you.

 Big changes start small - conserve resources by not printing every e-mail.


 -Ursprüngliche Nachricht-
 Von: Gamerdinger, Manuel
 Gesendet: Freitag, 19. Oktober 2012 12:38
 An: users@myfaces.apache.org
 Betreff: AW: @BeanValidation annotation at class level

 Hi Gerhard,

 thanx for quick response. I tracked down the problem that the Annotation
 (@BeanValidation) is not available on objectToInspect.getClass() in
 ExtValBeanValidationMetaDataInternals#transferGroupValidationInformationToFoundGroups.

 objectToInspect.getClass() returns a bytecode enhanced proxy class
 (...Dlg_$$_javassist_85) where I can see only the @RequestScoped Annotation
 from CDI. Besides @BeanValidation also the @Named Annotation from CDI is
 missing.
 I don't know if this behavior of a byte code proxy is correct!? I would
 expect that at least Annotations from Retention CLASS and RUNTIME are also
 available on the proxies.

 I also wonder a little why
 ExtValBeanValidationMetaDataInternals#processClass does not use the
 classToInspect (Unproxied Class) to gather the Annotations. If this method
 would pass classToInspect instead of objectToInspect to the
 #transferGroupValidationInformationToFoundGroups everything should be fine.

 Any help with this issue is appreciated!
 Regards,
 Manuel

 -Ursprüngliche Nachricht-
 Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
 Gesendet: Donnerstag, 18. Oktober 2012 21:49
 An: MyFaces Discussion
 Betreff: Re: @BeanValidation annotation at class level

 hi manuel,

 you can check it in ExtValBeanValidationMetaDataInternals#
 extractExtValBeanValidationMetaData
 (see #inspectFirstBean (= class level), #inspectFirstProperty,
 #inspectBaseOfProperty (= class level) and #inspectLastProperty)

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2012/10/18 manuel.gamerdin...@t-systems.com

  Hello MyFaces ExtVal users,
 
  I've a question regarding group validation together with
  @BeanValidation annotation. In my example the @BeanValidation
  annotation only works on page bean fields. On class level it seems that
 the annotation is ignored.
 
  This works:
  @BeanValidation(useGroups=IUiGroupStage2.class)
  private String wmc;
 
  This doesn't work:
  @BeanValidation(useGroups=IUiGroupStage2.class)
  public class HomeDlg implements Serializable {
 
  The following documentation states that it should be possible to
  declare the annotation at class level:
  http://wiki.apache.org/myfaces/Extensions/Validator/DevDoc
  But now how can I make it run? Is there some configuration to be done?
 
  Thanx in advance!
  Manuel

Re: @BeanValidation annotation at class level

2012-10-19 Thread Gerhard Petracek

hi manuel,

i guess - you are using weld...
you can register a custom ProxyHelper to get rid of the issue.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/10/19 manuel.gamerdin...@t-systems.com

 Hi Gerhard,

 I created an issue. My further analysis showed that this is a bug and not
 an improvement. The byte code proxy is correct. The @BeanValidation
 annotation is not marked as @Inherited and therefore not populated to its
 subclasses. But the proxy is a subclass.
 So for me there are 2 possibilities to correct:
 1) Make the Annotation inherited. But I think that would validate ExtVal's
 concept of additive groups within a class hierarchy.
 2) The suggested solution from my mail before.

 It would be great if we could get a patch soon!
 Thanx,
 Manuel



 -Ursprüngliche Nachricht-
 Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
 Gesendet: Freitag, 19. Oktober 2012 13:19
 An: MyFaces Discussion
 Betreff: Re: @BeanValidation annotation at class level

 hi manuel,

 thx for providing the details.
 please file a jira ticket (improvement) for it at [1].

 regards,
 gerhard

 [1] https://issues.apache.org/jira/browse/EXTVAL

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2012/10/19 manuel.gamerdin...@t-systems.com

  Update: It works when I use the @RequestScoped Annotation from
  javax.faces.bean instead of javax.enterprise.context. In that case
  there is no byte code proxy returned (objectToInspect.getClass()).
  But anyways I expect that it should also run with the CDI scopes.
 
  Manuel Gamerdinger
 
  T-Systems GEI GmbH
  Systems Integration
  Industry Application Solutions
  Project Center Industry Applications
  Manuel Gamerdinger
  Software Architect
  Fasanenweg 5, 70771 Leinfelden-Echterdingen
  +49 711 999-8704 (Tel.)
  +49 160 8224185 (Mobil)
  E-Mail: manuel.gamerdin...@t-systems.com
  Internet: http://www.t-systems.de
 
  T-Systems GEI GmbH
  Supervisory Board: Dr. Ferri Abolhassan (Chairman) Board of
  Management: Hans-Jörg Glaß (Chairman), Jan Krellner Commercial
  register: Amtsgericht Aachen HRB 7106 Registered office: Aachen Int.
  VAT No. DE 811 137 130
 
  Notice: This transmittal and/or attachments may be privileged or
  confidential. It is intended solely for the addressee named above. Any
  review, dissemination, or copying is strictly prohibited. If you
  received this transmittal in error, please notify us immediately by
  reply and immediately delete this message and all its attachments. Thank
 you.
 
  Big changes start small - conserve resources by not printing every
 e-mail.
 
 
  -Ursprüngliche Nachricht-
  Von: Gamerdinger, Manuel
  Gesendet: Freitag, 19. Oktober 2012 12:38
  An: users@myfaces.apache.org
  Betreff: AW: @BeanValidation annotation at class level
 
  Hi Gerhard,
 
  thanx for quick response. I tracked down the problem that the
  Annotation
  (@BeanValidation) is not available on objectToInspect.getClass() in
 
 ExtValBeanValidationMetaDataInternals#transferGroupValidationInformationToFoundGroups.
 
  objectToInspect.getClass() returns a bytecode enhanced proxy class
  (...Dlg_$$_javassist_85) where I can see only the @RequestScoped
  Annotation from CDI. Besides @BeanValidation also the @Named
  Annotation from CDI is missing.
  I don't know if this behavior of a byte code proxy is correct!? I
  would expect that at least Annotations from Retention CLASS and
  RUNTIME are also available on the proxies.
 
  I also wonder a little why
  ExtValBeanValidationMetaDataInternals#processClass does not use the
  classToInspect (Unproxied Class) to gather the Annotations. If this
  method would pass classToInspect instead of objectToInspect to the
  #transferGroupValidationInformationToFoundGroups everything should be
 fine.
 
  Any help with this issue is appreciated!
  Regards,
  Manuel
 
  -Ursprüngliche Nachricht-
  Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
  Gesendet: Donnerstag, 18. Oktober 2012 21:49
  An: MyFaces Discussion
  Betreff: Re: @BeanValidation annotation at class level
 
  hi manuel,
 
  you can check it in ExtValBeanValidationMetaDataInternals#
  extractExtValBeanValidationMetaData
  (see #inspectFirstBean (= class level), #inspectFirstProperty,
  #inspectBaseOfProperty (= class level) and #inspectLastProperty)
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/10/18 manuel.gamerdin...@t-systems.com
 
   Hello MyFaces ExtVal users,
  
   I've a question regarding group validation together with
   @BeanValidation annotation. In my example the @BeanValidation
   annotation only works on page bean fields

Re: @BeanValidation annotation at class level

2012-10-19 Thread Gerhard Petracek

hi manuel,

ok - i just know that weld changed something in that area.
we tested the DefaultProxyHelper with owb, but maybe websphere uses
something special here.

see:
Class classToInspect =
ProxyUtils.getUnproxiedClass(objectToInspect.getClass());
in #processClass

to customize it, you can provide a custom implementation of
org.apache.myfaces.extensions.validator.core.proxy.ProxyHelper
(also see e.g. DefaultExtValCoreConfiguration#proxyHelper)

however, you should get the real class in the next iteration
(see #getSuperclass in #processClass) in any case.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/10/19 manuel.gamerdin...@t-systems.com

 Hi Gerhard,

 no, we're using the standard WebSphere 8.0 stack which uses OpenWebBeans
 1.1.0.
 Anyways can you give me more information about the ProxyHelper?

 Regards,
 Manuel


 -Ursprüngliche Nachricht-
 Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
 Gesendet: Freitag, 19. Oktober 2012 16:01
 An: MyFaces Discussion
 Betreff: Re: @BeanValidation annotation at class level

 hi manuel,

 i guess - you are using weld...
 you can register a custom ProxyHelper to get rid of the issue.

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2012/10/19 manuel.gamerdin...@t-systems.com

  Hi Gerhard,
 
  I created an issue. My further analysis showed that this is a bug and
  not an improvement. The byte code proxy is correct. The
  @BeanValidation annotation is not marked as @Inherited and therefore
  not populated to its subclasses. But the proxy is a subclass.
  So for me there are 2 possibilities to correct:
  1) Make the Annotation inherited. But I think that would validate
  ExtVal's concept of additive groups within a class hierarchy.
  2) The suggested solution from my mail before.
 
  It would be great if we could get a patch soon!
  Thanx,
  Manuel
 
 
 
  -Ursprüngliche Nachricht-
  Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
  Gesendet: Freitag, 19. Oktober 2012 13:19
  An: MyFaces Discussion
  Betreff: Re: @BeanValidation annotation at class level
 
  hi manuel,
 
  thx for providing the details.
  please file a jira ticket (improvement) for it at [1].
 
  regards,
  gerhard
 
  [1] https://issues.apache.org/jira/browse/EXTVAL
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/10/19 manuel.gamerdin...@t-systems.com
 
   Update: It works when I use the @RequestScoped Annotation from
   javax.faces.bean instead of javax.enterprise.context. In that case
   there is no byte code proxy returned (objectToInspect.getClass()).
   But anyways I expect that it should also run with the CDI scopes.
  
   Manuel Gamerdinger
  
   T-Systems GEI GmbH
   Systems Integration
   Industry Application Solutions
   Project Center Industry Applications Manuel Gamerdinger Software
   Architect Fasanenweg 5, 70771 Leinfelden-Echterdingen
   +49 711 999-8704 (Tel.)
   +49 160 8224185 (Mobil)
   E-Mail: manuel.gamerdin...@t-systems.com
   Internet: http://www.t-systems.de
  
   T-Systems GEI GmbH
   Supervisory Board: Dr. Ferri Abolhassan (Chairman) Board of
   Management: Hans-Jörg Glaß (Chairman), Jan Krellner Commercial
   register: Amtsgericht Aachen HRB 7106 Registered office: Aachen Int.
   VAT No. DE 811 137 130
  
   Notice: This transmittal and/or attachments may be privileged or
   confidential. It is intended solely for the addressee named above.
   Any review, dissemination, or copying is strictly prohibited. If you
   received this transmittal in error, please notify us immediately by
   reply and immediately delete this message and all its attachments.
   Thank
  you.
  
   Big changes start small - conserve resources by not printing every
  e-mail.
  
  
   -Ursprüngliche Nachricht-
   Von: Gamerdinger, Manuel
   Gesendet: Freitag, 19. Oktober 2012 12:38
   An: users@myfaces.apache.org
   Betreff: AW: @BeanValidation annotation at class level
  
   Hi Gerhard,
  
   thanx for quick response. I tracked down the problem that the
   Annotation
   (@BeanValidation) is not available on objectToInspect.getClass() in
  
 
 ExtValBeanValidationMetaDataInternals#transferGroupValidationInformationToFoundGroups.
  
   objectToInspect.getClass() returns a bytecode enhanced proxy class
   (...Dlg_$$_javassist_85) where I can see only the @RequestScoped
   Annotation from CDI. Besides @BeanValidation also the @Named
   Annotation from CDI is missing.
   I don't know if this behavior of a byte code proxy is correct!? I
   would expect that at least Annotations from Retention CLASS and
   RUNTIME are also available on the proxies.
  
   I also

Re: @BeanValidation annotation at class level

2012-10-19 Thread Gerhard Petracek

hi manuel,

that's right - in my quick-check i haven't checked the parameters...
- i'll fix it.

thx  regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/10/19 manuel.gamerdin...@t-systems.com

 Hi Gerhard,

 ProxyUtils.getUnproxiedClass(objectToInspect.getClass()) works fine in my
 case. But I think the bug is exactly in this while loop. In this loop
 always the objectToInspect is passed to the
 #transferGroupValidationInformationToFoundGroups. A second iteration will
 result in same result as objectToInspect is not changed in the loop. From
 my point of view the classToInspect should be passed the
 #transferGroupValidationInformationToFoundGroups.

 while (!Object.class.getName().equals(classToInspect.getName()))
 {

 transferGroupValidationInformationToFoundGroups(objectToInspect,
 foundGroupsForPropertyValidation,
 restrictedGroupsForPropertyValidation,
 modelValidationEntryList,
 restrictedGroupsForModelValidation,
 activeViewId,
 processModelValidation);

 processInterfaces(objectToInspect.getClass(), objectToInspect,
 foundGroupsForPropertyValidation,
 restrictedGroupsForPropertyValidation,
 modelValidationEntryList,
 restrictedGroupsForModelValidation,
 activeViewId,
 processModelValidation);

 classToInspect = classToInspect.getSuperclass();
 }

 Regards,
 Manuel

 -Ursprüngliche Nachricht-
 Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
 Gesendet: Freitag, 19. Oktober 2012 17:08
 An: MyFaces Discussion
 Betreff: Re: @BeanValidation annotation at class level

 hi manuel,

 ok - i just know that weld changed something in that area.
 we tested the DefaultProxyHelper with owb, but maybe websphere uses
 something special here.

 see:
 Class classToInspect =
 ProxyUtils.getUnproxiedClass(objectToInspect.getClass());
 in #processClass

 to customize it, you can provide a custom implementation of
 org.apache.myfaces.extensions.validator.core.proxy.ProxyHelper
 (also see e.g. DefaultExtValCoreConfiguration#proxyHelper)

 however, you should get the real class in the next iteration (see
 #getSuperclass in #processClass) in any case.

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2012/10/19 manuel.gamerdin...@t-systems.com

  Hi Gerhard,
 
  no, we're using the standard WebSphere 8.0 stack which uses
  OpenWebBeans 1.1.0.
  Anyways can you give me more information about the ProxyHelper?
 
  Regards,
  Manuel
 
 
  -Ursprüngliche Nachricht-
  Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
  Gesendet: Freitag, 19. Oktober 2012 16:01
  An: MyFaces Discussion
  Betreff: Re: @BeanValidation annotation at class level
 
  hi manuel,
 
  i guess - you are using weld...
  you can register a custom ProxyHelper to get rid of the issue.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/10/19 manuel.gamerdin...@t-systems.com
 
   Hi Gerhard,
  
   I created an issue. My further analysis showed that this is a bug
   and not an improvement. The byte code proxy is correct. The
   @BeanValidation annotation is not marked as @Inherited and therefore
   not populated to its subclasses. But the proxy is a subclass.
   So for me there are 2 possibilities to correct:
   1) Make the Annotation inherited. But I think that would validate
   ExtVal's concept of additive groups within a class hierarchy.
   2) The suggested solution from my mail before.
  
   It would be great if we could get a patch soon!
   Thanx,
   Manuel
  
  
  
   -Ursprüngliche Nachricht-
   Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
   Gesendet: Freitag, 19. Oktober 2012 13:19
   An: MyFaces Discussion
   Betreff: Re: @BeanValidation annotation at class level
  
   hi manuel,
  
   thx for providing the details.
   please file a jira ticket (improvement) for it at [1].
  
   regards,
   gerhard
  
   [1] https://issues.apache.org/jira/browse/EXTVAL
  
   http://www.irian.at
  
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
  
  
   2012/10/19 manuel.gamerdin...@t-systems.com
  
Update: It works when I use the @RequestScoped Annotation from
javax.faces.bean instead of javax.enterprise.context. In that case
there is no byte code proxy returned (objectToInspect.getClass()).
But anyways I

Re: @BeanValidation annotation at class level

2012-10-18 Thread Gerhard Petracek

hi manuel,

you can check it in ExtValBeanValidationMetaDataInternals#
extractExtValBeanValidationMetaData
(see #inspectFirstBean (= class level), #inspectFirstProperty,
#inspectBaseOfProperty (= class level) and #inspectLastProperty)

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/10/18 manuel.gamerdin...@t-systems.com

 Hello MyFaces ExtVal users,

 I've a question regarding group validation together with @BeanValidation
 annotation. In my example the @BeanValidation annotation only works on page
 bean fields. On class level it seems that the annotation is ignored.

 This works:
 @BeanValidation(useGroups=IUiGroupStage2.class)
 private String wmc;

 This doesn't work:
 @BeanValidation(useGroups=IUiGroupStage2.class)
 public class HomeDlg implements Serializable {

 The following documentation states that it should be possible to declare
 the annotation at class level:
 http://wiki.apache.org/myfaces/Extensions/Validator/DevDoc
 But now how can I make it run? Is there some configuration to be done?

 Thanx in advance!
 Manuel

Re: MyFaces ExtVal at WAS 8.0.0.4 - Call in violation of protocol

2012-10-08 Thread Gerhard Petracek

hi heiko,

imo it isn't an issue in extval.

you can check if both jar-files (extval-core and extval-bv-module) are
packaged correctly (in the application).

regards,
gerhard



http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2012/10/8 it-media.k...@daimler.com

 Hello everybody,

 I'm currently porting an application and wanted to use MyFaces ExtVal for
 Bean Validation. Our application needs to run under WebSphere Application
 Server 8.0.0.4. I'm currently using the following maven dependency within
 the WAR project:

 dependency
 groupIdorg.apache.myfaces.extensions.validator.validation-modules/
 groupId
 artifactIdmyfaces-extval-bean-validation/artifactId
 version2.0.5/version
 exclusions
 exclusion
 artifactIdvalidation-api/artifactId
 groupIdjavax.validation/groupId
 /exclusion
 /exclusions
 /dependency

 It occured weird to me that I have to exclude the validation API but
 WebSphere seems to bring it's own which is somehow incompatible. However
 that is not the problem. When deploying the application, I get multiple
 messages of the following kind:

 [08.10.12 07:44:30:883 CEST] 0008 visitor   W
 com.ibm.ws.amm.scan.util.AnnotationInfoDefaultVisitor visitAnnotation [
 com.ibm.ws.amm.scan.util.InfoVisitor@1546284787 ] for method [
 com.ibm.ws.amm.scan.util.info.impl.MethodInfoImpl@1496780783 (

 org.apache.myfaces.extensions.validator.beanval.annotation.BeanValidation.modelValidation
 ) ] Name [ null ] Description [

 Lorg/apache/myfaces/extensions/validator/beanval/annotation/ModelValidation;
 ] Call in violation of protocol
 [08.10.12 07:44:32:836 CEST] 0008 visitor   W
 com.ibm.ws.amm.scan.util.AnnotationInfoDefaultVisitor visitAnnotation [
 com.ibm.ws.amm.scan.util.InfoVisitor@-16051367 ] for method [
 com.ibm.ws.amm.scan.util.info.impl.MethodInfoImpl@1207608866 (

 org.apache.myfaces.extensions.validator.beanval.annotation.BeanValidation.modelValidation
 ) ] Name [ null ] Description [

 Lorg/apache/myfaces/extensions/validator/beanval/annotation/ModelValidation;
 ] Call in violation of protocol

 The application itself works fine, as these are only warnings, BUT the
 deployment and start process of the application is heavily slowed down. It
 seems, WAS does not like something within the validation classes. I've
 tried to get some more information about what kind of 'call in validation
 of protocol' this might be, but did not find anything. Could this be a bug
 within WAS, or is something wrong here within the validation modules.

 It would be great if some of the developers can help. If this is a bug
 within WAS, I can open a PMR with IBM, but they obviously request some
 more information about this and I'm not quite sure what leads to this
 problem.

 Thank you very much,

 Best regards,

 Heiko

 --
 Dr.-Ing. Heiko Kopp

 If you are not the intended addressee, please inform us immediately that
 you have received this e-mail in error, and delete it. We thank you for
 your cooperation.

Re: CODI scoped beans @PreDestroy not running after redirect

2012-09-07 Thread Gerhard Petracek

hi brendan,

in case of @javax.faces.bean.ViewScoped it looks like
javax.faces.event.PreDestroyViewMapEvent doesn't get fired.
in case of @ViewAccessScoped it's just not possible by definition to do it
autom. (before the session expires) if you redirect to an external page,
but you can use WindowContext#close (or #closeConversations) manually
before you do the redirect.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/9/7 oversteer brendanhealey...@yahoo.co.uk



 I have a simple page with a backing bean which redirects
 (FacesContext.getCurrentInstance().getExternalContext().redirect(target))
 to
 an external website when a commandButton is pushed.

 I notice that when using @ViewAccessScoped or @javax.faces.bean.ViewScoped
 the predestroy method only runs at session expiration time. It's fine with
 @javax.enterprise.context.RequestScoped.

 Based on the contracts for @View*Scoped I'd expect the predestroy to run
 and
 the beans to be garbage collected, is this expected behavior or a memory
 leak?

 Regards,
 Brendan.

 p.s. I'm using JSF 2.1.12  CODI 1.05
 --
 View this message in context:
 http://old.nabble.com/CODI-scoped-beans-%40PreDestroy-not-running-after-redirect-tp34402504p34402504.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: EXTCDI/CODI: Message: Posibility to use messageContext.message() for a specific componentId?

2012-09-04 Thread Gerhard Petracek

hi heiko,

first of all: welcome @ myfaces!

currently it isn't supported out-of-the-box.
(you would have to implement an own payload-type and a custom
MessageHandler which is aware of the payload-type.)
however, you are welcome to share your (concrete) use-case with us - we
can think about adding such a feature.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/9/4 it-media.k...@daimler.com

 Hello everybody,

 I'm trying to get familiar with the power CODI / EXTCDI gives me as JSF
 developer. I'm currently trying to replace an application that sometimes
 creates component specific faces messages, e.g.

 facesContext.addMessage(componentId, facesMessage).

 I'm trying to achive this by utilizing an injected MessageContext via @Jsf
 and @Inject.

 However, I've no chance to specify a component Id anywhere. Is this simply
 not possible or do I miss something important here.

 Thank you very much.

 Heiko

 --
 Heiko Kopp

 If you are not the intended addressee, please inform us immediately that
 you have received this e-mail in error, and delete it. We thank you for
 your cooperation.

Re: Apache CODI Bug in version 1.0.5

2012-08-28 Thread Gerhard Petracek

hi christian,

please file a jira ticket and attach the demo there.

thx  regards,
gerhard



2012/8/28 Christian Beikov christian.bei...@gmail.com

 Hello guys!

 I just found a bug in the CODI code and wanted to report that to you. In
 The attachment you can find a maven WAR project that will show the error
 when you try to access the page.
 This occurs, because the session cookie of the webapp is configured to be
 secure, but if you don't access the application via https you get
 redirected forever.
 The reason for that is of course, that no session is available at the
 server side when the redirected request arrives at the server side.
 The only solution to that is, to supply a specialized WindowContextConfig#
 **isUrlParameterSupported that returns false, but that results in
 ViewExpiredException on Postback.

 In my opinion CODI should somehow forward to an error page or so when this
 kind of configuration happens or don't redirect to use window ids at all.

 Regards,
 Christian

Re: [EXTVAL] Disable ExtVal for specific pages

2012-07-10 Thread Gerhard Petracek

hi thomas,

thx - i'll have a look at it.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/7/10 Thomas Andraschko zoi...@googlemail.com

 Hi,

 I created EXTVAL-145 and EXTVAL-146 with patch and the overhead is now
 ~100-150ms instead of ~400ms.

 Regards,
 Thomas


 2012/7/10 Thomas Andraschko zoi...@googlemail.com

  Hi,
 
  is it possible to disable ExtVal for specific pages?
 
  We have some lists with ~2000 items in ui:repeat, without inputs and
  without any ExtVal feature.
  The rendertime with ExtVal is arround 1,2seconds, without ~800ms.
 
  Thanks!
 
  Regards,
  Thomas

Re: CODI addParameter problem while using PrettyFaces and windowId is null

2012-07-04 Thread Gerhard Petracek

hi glister,

first of all: welcome @ myfaces!

you can compare your setup with [1].
also see threads like [2] and [3].

regards,
gerhard

[1] http://s.apache.org/0IZ
[2] http://s.apache.org/bzs
[3] http://s.apache.org/6WK

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/7/4 Anicz Pichler ichbinn...@googlemail.com

 Hey,

 in my project :

 - codi 1.0.5
 - mojarra 2.1.6
 - primefaces 3.3.1
 - prettyfaces 3.3.3
 - weld 1.1.4
 - omnifaces 1.0

 i use CODI with ViewAccessScoped beans. it works like a charm !! but if i
 add prettyfaces to my project and
 open a url like : http://server.de:8080/project/name/john

 where john is a RequestParameter for PrettyFaces, CODI produces following
 url:

 http://server.de:8080/project/name/john?windowId=3c2name=john

 at the first moment i thought it was prettyfaces which adds these parameter
 at the end (see
 http://ocpsoft.org/support/topic/beginner-question-regarding-comocpsoftvp_0
 )
  but while debugging
 CODI,  the addParameter-method in DefaultWindowHandler.java append this
 parameter.

 i tried to set isUnknownWindowIdsAllowed() to true but no success. If i
 open the url with an active windowId, the request parameter from
 ExternalContext doesn't get appended, its all fine.

 Okay now to my question, if windowId is null is it possible that CODI
 creates only a new WindowContext without adding request parameter because
 prettyfaces filter catch the /john value and not the name=john.

 Regards, glister

Re: Apache CODI and TomEE problem

2012-07-04 Thread Gerhard Petracek

hi martin,

first of all: welcome @ myfaces!

that's a tomee issue - there is nothing we can do about it in codi.
please contact the tomee team.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2012/7/4 Martin Kjær Jørgensen m...@gotu.dk

I'm developing a Maven+JSF+CDI application for TomEE in NetBeans, and
have recently added the Apache CODI extensions
(myfaces-extcdi-bundle-jsf20). When I deploy the application from
NetBeans I get the following exception in my browser and in the server log:

Caused by: java.lang.IllegalStateException: No bean found for type:
org.apache.myfaces.extensions.cdi.jsf.api.config.JsfModuleConfig
at

org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getOrCreateBeanByClass(CodiUtils.java:198)
at

org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:174)
at

org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139)
at

org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:124)

To fix this i restart TomEE. After the restart I can access the pages
with no exceptions. I even get the:

config implementation:
org.apache.myfaces.extensions.cdi.core.api.config.CodiCoreConfig
method:isAdvancedQualifierRequiredForDependencyInjection
value:true

method:isConfigurationLoggingEnabled
value:true

method:isInvalidBeanCreationEventEnabled
value:false

... messages etc etc.

When I build/debug from NetBeans, it first undeploy the application then
deploy the new build, after which the same exception (Caused by:
java.lang.IllegalStateException: No bean found for type) occurs again.
Then I restart TomEE again and it works. It seems I have to restart
TomEE every time I deploy for it to work.

Do you have any idea why this happens?

/Martin

Re: Extval ClassCastException when displaying entities

2012-07-03 Thread Gerhard Petracek

hi,

that might happen due to the missing shared-lib-support.
(it wasn't done so far because there are also other basic issues related to
it (with some servers).)

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/7/2 bmajsak bartosz.maj...@gmail.com


 Have you managed to find the solution? I'm using ExtVal 2.0.5 with CODI
 1.0.5
 on WAS 8.0.0.2 and suddenly this problem appeared.  As described in the
 original message - it works nice after server restart but every
 redeployment
 is causing this error.


 Gerhard Petracek wrote:
 
  hi markus,
 
  it looks like an issue with your environment (see [1]). however, please
  try
  the current snapshot of extval.
 
  regards,
  gerhard
 
  [1] http://goo.gl/cfS7m
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
  2011/12/12 markuslachat markuslac...@gmail.com
 
 
  Hi!
 
  I am using CODI Snapshot 1.0.3 and ExtVal 2.0.4 on IBM Websphere v8
 
  Everything works as expected, but when I do a clean on the server within
  RAD
  (version 8.0.3), the following exception message shows up.
 
  Original Exception:
  Error Message: javax.servlet.ServletException:
 
 
 org.apache.myfaces.extensions.validator.core.storage.DefaultRendererInterceptorPropertyStorage
  incompatible with
 
 
 org.apache.myfaces.extensions.validator.core.storage.RendererInterceptorPropertyStorage
  Error Code: 500
  Target Servlet: Faces Servlet
  Error Stack:
  java.lang.ClassCastException:
 
 
 org.apache.myfaces.extensions.validator.core.storage.DefaultRendererInterceptorPropertyStorage
  incompatible with
 
 
 org.apache.myfaces.extensions.validator.core.storage.RendererInterceptorPropertyStorage
  at
 
 
 org.apache.myfaces.extensions.validator.core.interceptor.AbstractValidationInterceptor.getRendererInterceptorPropertyStorage(AbstractValidationInterceptor.java:477)
  at
 
 
 org.apache.myfaces.extensions.validator.core.interceptor.AbstractValidationInterceptor.setRendererInterceptorProperties(AbstractValidationInterceptor.java:456)
  at
 
 
 org.apache.myfaces.extensions.validator.core.interceptor.AbstractValidationInterceptor.beforeGetConvertedValue(AbstractValidationInterceptor.java:166)
  at
 
 
 org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.getConvertedValue(ExtValRendererWrapper.java:361)
  at
 
 
 org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRendererWrapper.intercept(ExtValGenericRendererWrapper.java:64)
  at
 
 
 org.apache.myfaces.renderkit.html.HtmlTextRenderer$$EnhancerByCGLIB$$63f007d7.getConvertedValue(generated)
  at
 
 
 javax.faces.component.UIViewParameter.getConvertedValue(UIViewParameter.java:248)
  at javax.faces.component.UIInput.validate(UIInput.java:556)
  at javax.faces.component.UIInput.processValidators(UIInput.java:247)
  at
 
 
 javax.faces.component.UIViewParameter.processValidators(UIViewParameter.java:218)
  at
 
 
 javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1218)
  at
 
 
 javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1218)
  at
 
 
 javax.faces.component.UIViewRoot._processValidatorsDefault(UIViewRoot.java:1326)
  at javax.faces.component.UIViewRoot.access$500(UIViewRoot.java:75)
  at
 
 
 javax.faces.component.UIViewRoot$ProcessValidatorPhaseProcessor.process(UIViewRoot.java:1401)
  at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1282)
  at
  javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:758)
  at
 
 
 org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:34)
  at
 
 
 org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171)
  at
 
 org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
  at
 
 
 org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.execute(CodiLifecycleWrapper.java:95)
  at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
  at
 
 
 com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1147)
  at
 
 
 com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:722)
  at
 
 
 com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:449)
  at
 
 
 com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
  at
 
 
 com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:125)
  at
 
 
 com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:92)
 
 
  This does never happen on server restart. Did anyone ever experience
 this
  behavior? I have

Re: DefaultErrorView

2012-06-26 Thread Gerhard Petracek

hi jose,

exceptions during the rendering process are always special.
- everything which could lead to an exception should be done before the
rendering process.
in this case you can't switch to an error-view, if you are in the middle of
the rendering process of a page.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/26 José Luis Cetina maxtorz...@gmail.com

 Sorry, but i dont understand, i only set my @Secured in my managed bean.

 Do you mean with: your secured bean should always get accessed before the
 rendering starts that i have to call the checkPermission method in a
 PreRenderView method in my managedbean?

 like this:

 @Named
 @ViewAccessScoped
 @SecurityModule(codigoModulo = ModuloPantallaEnum.CURSOS)
 public class CursosMBean implements Serializable{

 }



 2012/6/25 Gerhard Petracek gerhard.petra...@gmail.com

  hi jose,
 
  your secured bean should always get accessed before the rendering starts
  (e.g. via a PreRenderView callback).
  otherwise you get the exception during the rendering process.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/6/25 José Luis Cetina maxtorz...@gmail.com
 
   My denied page never shown, i always get Cannot set content type.
  Response
   already committed.
  
  
   I have this:
  
   @Page
   public class Denegado extends DefaultErrorView{
  
   }
  
   @Stereotype
   @Target(value = {ElementType.TYPE})
   @Retention(value = RetentionPolicy.RUNTIME)
  
  
 
 @Secured(value=PermissionAccessDecisionVoter.class,errorView=Denegado.class)
   public @interface SecurityModule {
  ModuloPantallaEnum codigoModulo();
   }
  
   my bean:
   @Named
   @ViewAccessScoped
   @SecurityModule(codigoModulo = ModuloPantallaEnum.CURSOS)
   public class CursosMBean implements Serializable{
   }
  
   THEN I ADD SecurityViolation
   @Override
  protected void checkPermission(InvocationContext ic,
   SetSecurityViolation violations) {
violations.add(newSecurityViolation(DENIED.));
   }
  
   But i always see in my page this:
  
   An Error Occurred:
  
  
 org.apache.myfaces.extensions.cdi.core.api.security.AccessDeniedException
  
   viewId=/web/portal_academico/control_escolar/cursos.xhtml
  
  
 
 location=/home/maxtorzito/repositorio/grupo_kx/project-rhino/trunk/project-rhino/target/project-rhino-0.9-SNAPSHOT/web/portal_academico/control_escolar/cursos.xhtml
   phaseId=RENDER_RESPONSE(6)
  
   Caused by:
  
 org.apache.myfaces.extensions.cdi.core.api.security.AccessDeniedException
   at
  
  
 
 org.apache.myfaces.extensions.cdi.core.impl.util.SecurityUtils.invokeVoters(SecurityUtils.java:95)
  
  
  
   And in the log:
  
   org.apache.myfaces.context.servlet.ServletExternalContextImpl
   setResponseContentType
   SEVERE: Cannot set content type. Response already committed
  
   What is wrong?
  
   --
   ---
   *SCJA. José Luis Cetina*
   ---
  
 



 --
 ---
 *SCJA. José Luis Cetina*
 ---

Re: DefaultErrorView

2012-06-26 Thread Gerhard Petracek

hi jose,

yes - in a view-config @Secured is a simple annotation and not an
interceptor (because there is nothing to intercept)
- currently no @Stereotype support.

@ custom (additional) meta-data:
see [1].

regards,
gerhard

[1]
https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-Customviewmetadata

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/26 José Luis Cetina maxtorz...@gmail.com

 If i use my own annotation

 @Stereotype
 @Target(value = {ElementType.TYPE})
 @Retention(value = RetentionPolicy.RUNTIME)
 @Secured(value=PermissionAccessDecisionVoter.class)
 public @interface SecurityModule {
ModuloPantallaEnum codigoModulo();
 }

 and then

 @Page(navigation = Page.NavigationMode.REDIRECT)
 public interface Pages extends ViewConfig {

  public @Page class MyError extends DefaultErrorView implements Pages {}

  @SecurityModule(codigoModulo = ModuloPantallaEnum.CURSOS) //doesnt work
  public @Page class Private implements Pages{}

 }


 @javax.enterprise.context.ApplicationScoped
 public class PermissionAccessDecisionVoter implements AccessDecisionVoter {
 .
 }

 If i use my @SecurityModule in ViewConfig my checkPermission never been
 called, but if i use my @SecurityModule as interceptor (in my managedbean)
 it works, this is normal?

 2012/6/26 Gerhard Petracek gerhard.petra...@gmail.com

  hi jose,
 
  exceptions during the rendering process are always special.
  - everything which could lead to an exception should be done before the
  rendering process.
  in this case you can't switch to an error-view, if you are in the middle
 of
  the rendering process of a page.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/6/26 José Luis Cetina maxtorz...@gmail.com
 
   Sorry, but i dont understand, i only set my @Secured in my managed
 bean.
  
   Do you mean with: your secured bean should always get accessed before
  the
   rendering starts that i have to call the checkPermission method in a
   PreRenderView method in my managedbean?
  
   like this:
  
   @Named
   @ViewAccessScoped
   @SecurityModule(codigoModulo = ModuloPantallaEnum.CURSOS)
   public class CursosMBean implements Serializable{
  
   }
  
  
  
   2012/6/25 Gerhard Petracek gerhard.petra...@gmail.com
  
hi jose,
   
your secured bean should always get accessed before the rendering
  starts
(e.g. via a PreRenderView callback).
otherwise you get the exception during the rendering process.
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
2012/6/25 José Luis Cetina maxtorz...@gmail.com
   
 My denied page never shown, i always get Cannot set content type.
Response
 already committed.


 I have this:

 @Page
 public class Denegado extends DefaultErrorView{

 }

 @Stereotype
 @Target(value = {ElementType.TYPE})
 @Retention(value = RetentionPolicy.RUNTIME)


   
  
 
 @Secured(value=PermissionAccessDecisionVoter.class,errorView=Denegado.class)
 public @interface SecurityModule {
ModuloPantallaEnum codigoModulo();
 }

 my bean:
 @Named
 @ViewAccessScoped
 @SecurityModule(codigoModulo = ModuloPantallaEnum.CURSOS)
 public class CursosMBean implements Serializable{
 }

 THEN I ADD SecurityViolation
 @Override
protected void checkPermission(InvocationContext ic,
 SetSecurityViolation violations) {
  violations.add(newSecurityViolation(DENIED.));
 }

 But i always see in my page this:

 An Error Occurred:


  
 org.apache.myfaces.extensions.cdi.core.api.security.AccessDeniedException

 viewId=/web/portal_academico/control_escolar/cursos.xhtml


   
  
 
 location=/home/maxtorzito/repositorio/grupo_kx/project-rhino/trunk/project-rhino/target/project-rhino-0.9-SNAPSHOT/web/portal_academico/control_escolar/cursos.xhtml
 phaseId=RENDER_RESPONSE(6)

 Caused by:

  
 org.apache.myfaces.extensions.cdi.core.api.security.AccessDeniedException
 at


   
  
 
 org.apache.myfaces.extensions.cdi.core.impl.util.SecurityUtils.invokeVoters(SecurityUtils.java:95)



 And in the log:

 org.apache.myfaces.context.servlet.ServletExternalContextImpl
 setResponseContentType
 SEVERE: Cannot set content type. Response already committed

 What is wrong?

 --
 ---
 *SCJA. José Luis Cetina

Re: DefaultErrorView

2012-06-26 Thread Gerhard Petracek

hi jose,

that's a different topic (and we talked about it already).

@ view-configs:
you just use @Secured + a separated (custom) annotation e.g.
@CustomMetaData (meta-annotated with @ViewMetaData)

e.g.:
@Page
@Secured(CustomAccessDecisionVoter.class)
@CustomMetaData(...)
public final class MySecuredPage implements ViewConfig
{
}

- your AccessDecisionVoter queries the custom meta-data for the current
view:

//...
@Inject
private ViewConfigResolver viewConfigResolver;
//...
String currentViewId =
FacesContext.getCurrentInstance().getViewRoot().getViewId();

viewConfigResolver.getViewConfigDescriptor(currentViewId).getMetaData();
or
viewConfigResolver.getViewConfigDescriptor(currentViewId).getMetaData(CustomMetaData.class);

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/26 José Luis Cetina maxtorz...@gmail.com

 Ok, but when i use my own annottation as interpcetor and my checkPermission
 method add a SecurityViolation my page never redirect to my
 DefaultErrorView, i always get:

 PM org.apache.myfaces.context.servlet.ServletExternalContextImpl
 setResponseContentType
 SEVERE: Cannot set content type. Response already committed

 My Managedbean:

 @Named
 @ViewAccessScoped
 @SecurityModule(codigoModulo = ModuloPantallaEnum.CURSOS)
 public class CursosMBean implements Serializable{
 }

 its possible to use an interceptor (CODI Security) win a DefaultErrorView,
 if yes why i alway's get Response already committed?

 Thanks


 2012/6/26 Gerhard Petracek gerhard.petra...@gmail.com

  hi jose,
 
  yes - in a view-config @Secured is a simple annotation and not an
  interceptor (because there is nothing to intercept)
  - currently no @Stereotype support.
 
  @ custom (additional) meta-data:
  see [1].
 
  regards,
  gerhard
 
  [1]
 
 
 https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-Customviewmetadata
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/6/26 José Luis Cetina maxtorz...@gmail.com
 
   If i use my own annotation
  
   @Stereotype
   @Target(value = {ElementType.TYPE})
   @Retention(value = RetentionPolicy.RUNTIME)
   @Secured(value=PermissionAccessDecisionVoter.class)
   public @interface SecurityModule {
  ModuloPantallaEnum codigoModulo();
   }
  
   and then
  
   @Page(navigation = Page.NavigationMode.REDIRECT)
   public interface Pages extends ViewConfig {
  
public @Page class MyError extends DefaultErrorView implements Pages
 {}
  
@SecurityModule(codigoModulo = ModuloPantallaEnum.CURSOS) //doesnt
 work
public @Page class Private implements Pages{}
  
   }
  
  
   @javax.enterprise.context.ApplicationScoped
   public class PermissionAccessDecisionVoter implements
  AccessDecisionVoter {
   .
   }
  
   If i use my @SecurityModule in ViewConfig my checkPermission never been
   called, but if i use my @SecurityModule as interceptor (in my
  managedbean)
   it works, this is normal?
  
   2012/6/26 Gerhard Petracek gerhard.petra...@gmail.com
  
hi jose,
   
exceptions during the rendering process are always special.
- everything which could lead to an exception should be done before
  the
rendering process.
in this case you can't switch to an error-view, if you are in the
  middle
   of
the rendering process of a page.
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
2012/6/26 José Luis Cetina maxtorz...@gmail.com
   
 Sorry, but i dont understand, i only set my @Secured in my managed
   bean.

 Do you mean with: your secured bean should always get accessed
  before
the
 rendering starts that i have to call the checkPermission method
 in a
 PreRenderView method in my managedbean?

 like this:

 @Named
 @ViewAccessScoped
 @SecurityModule(codigoModulo = ModuloPantallaEnum.CURSOS)
 public class CursosMBean implements Serializable{

 }



 2012/6/25 Gerhard Petracek gerhard.petra...@gmail.com

  hi jose,
 
  your secured bean should always get accessed before the rendering
starts
  (e.g. via a PreRenderView callback).
  otherwise you get the exception during the rendering process.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/6/25 José Luis Cetina maxtorz...@gmail.com
 
   My denied page never shown, i always get Cannot set content
 type.
  Response

Re: [EXTVAL] @Column.lenght - h:inputText

2012-06-25 Thread Gerhard Petracek

hi thomas,

+1 for adding it - please create a jira ticket (improvement).

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/25 Thomas Andraschko zoi...@googlemail.com

 Hi Gerhard,

 i implemented this in my app but without an custom ComponentInitializer.

 I just overwritten the AbstractHtmlCoreComponentsComponentInitializer.
 If a maxlenght attribute is defined (and greater than 0), ExtVal does not
 override it.
 Could this be a part of ExtVal?

 Regards,
 Thomas

 2012/4/12 Thomas Andraschko zoi...@googlemail.com

  Hi,
 
  ok cool - i will try it!
 
  Thanks!
 
 
  2012/4/12 Gerhard Petracek gerhard.petra...@gmail.com
 
  hi thomas,
 
  that isn't supported by default (intentionally).
 
  however, you can provide a custom ComponentInitializer.
  (implement the interface or extend
 HtmlCoreComponentsComponentInitializer
  and override #configureMaxLengthAttribute)
  - register it via an extval startup listener.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/4/12 Thomas Andraschko zoi...@googlemail.com
 
   Hi Gerhard,
  
   yep i could but the value depends on the current logged in user/user
   groups. So it can't use a static value - ValueBinding on maxlenght
   attribute would be an easy solution.
   Ok, so there is no possiblity to disable this behavior?
  
   Why ExtVal does override the default attributes? IMO the component
   attributes should have a higher prio.
  
   Thanks!
  
   Best regards,
   Thomas
  
   2012/4/12 Gerhard Petracek gerhard.petra...@gmail.com
  
hi thomas,
   
you can use Column#length with the correct value or a different
  property
for your value-binding (without @Column) .
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
2012/4/12 Thomas Andraschko zoi...@googlemail.com
   
 Hi,

 we have a value binding on an h:inputText. The binded variable has
@Column
 and the default value of length is 255.
 I try to overwrite this via maxlength attribute on the
 h:inputText
   but
 the rendered maxlenght is 255.

 How can disable this behavior for a single input field?

 Best regards,
 Thomas

Re: @Secured CODI

2012-06-25 Thread Gerhard Petracek

hi jose,

we wrap ViewHandler#createView - if your config is correct, it should work
(you can check e.g. [1]).

regards,
gerhard

[1] http://s.apache.org/SBP

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/25 José Luis Cetina maxtorz...@gmail.com

 In the CODI Wiki page says:

 https://cwiki.apache.org/confluence/display/EXTCDI/Core+Usage#CoreUsage-SecurityViolation

 The rest is done by CODI. Please note that there is a natural overhead if
 the @Secured annotation is used as interceptor. In combination with the JSF
 module, we recommend to us it for the ViewConfig instead of beans because
 the performance overhead is minimal compared to an interceptor.

 But if i set the @Secured annotation in ViewConfig and i enter directly to
 the URL (without a navigation link, of course i dont use CODI if i access
 in this way) the checkPermission method was never invoked, as i can see the
 only way you can use @Secured annotation in a viewconfig is when you never
 expected the user can access to your page with the URL in a  directly way,
 am i right?


 --
 ---
 *SCJA. José Luis Cetina*
 ---

Re: DefaultErrorView

2012-06-25 Thread Gerhard Petracek

hi jose,

your secured bean should always get accessed before the rendering starts
(e.g. via a PreRenderView callback).
otherwise you get the exception during the rendering process.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/25 José Luis Cetina maxtorz...@gmail.com

 My denied page never shown, i always get Cannot set content type. Response
 already committed.


 I have this:

 @Page
 public class Denegado extends DefaultErrorView{

 }

 @Stereotype
 @Target(value = {ElementType.TYPE})
 @Retention(value = RetentionPolicy.RUNTIME)

 @Secured(value=PermissionAccessDecisionVoter.class,errorView=Denegado.class)
 public @interface SecurityModule {
ModuloPantallaEnum codigoModulo();
 }

 my bean:
 @Named
 @ViewAccessScoped
 @SecurityModule(codigoModulo = ModuloPantallaEnum.CURSOS)
 public class CursosMBean implements Serializable{
 }

 THEN I ADD SecurityViolation
 @Override
protected void checkPermission(InvocationContext ic,
 SetSecurityViolation violations) {
  violations.add(newSecurityViolation(DENIED.));
 }

 But i always see in my page this:

 An Error Occurred:

 org.apache.myfaces.extensions.cdi.core.api.security.AccessDeniedException

 viewId=/web/portal_academico/control_escolar/cursos.xhtml

 location=/home/maxtorzito/repositorio/grupo_kx/project-rhino/trunk/project-rhino/target/project-rhino-0.9-SNAPSHOT/web/portal_academico/control_escolar/cursos.xhtml
 phaseId=RENDER_RESPONSE(6)

 Caused by:
 org.apache.myfaces.extensions.cdi.core.api.security.AccessDeniedException
 at

 org.apache.myfaces.extensions.cdi.core.impl.util.SecurityUtils.invokeVoters(SecurityUtils.java:95)



 And in the log:

 org.apache.myfaces.context.servlet.ServletExternalContextImpl
 setResponseContentType
 SEVERE: Cannot set content type. Response already committed

 What is wrong?

 --
 ---
 *SCJA. José Luis Cetina*
 ---

Fwd: No active contexts for CODI on Weblogic 12c

2012-06-21 Thread Gerhard Petracek

-- Forwarded message --
From: Rudy De Busscher rdebussc...@gmail.com
Date: 2012/6/21
Subject: Re: No active contexts for CODI on Weblogic 12c
To: Gerhard Petracek gerhard.petra...@gmail.com


Hi maicon,

I have no access to the test machine for the moment.  I'll have a look in
the weekend what I changed/did to make it work on WLS12C.

Regards
Rudy


On 21 June 2012 00:01, Gerhard Petracek gerhard.petra...@gmail.com wrote:

 hi maicon,

 rudy did some tests with wls12c and afaik it worked for him.
 maybe he can provide further details.

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2012/6/20 Maicon pnpinformat...@gmail.com

 Gerhard when I use @SessionScoped instead of @ConversationScoped the page
 is loaded ok.


 The code of the UserMBean is:

 @Named(userMBean)
 @ConversationScoped
 public class UserMBean implements Serializable {

private static final long serialVersionUID = 3140959503723849518L;

private String nome, password;

public UserMBean() {
}

public String doLogin() {
return maicon.faces;
}

public String getNome() {
return nome;
}

public void setNome(String nome) {
this.nome = nome;
}

public String getPassword() {
return password;
}

public void setPassword(String password) {
this.password = password;
}

 }

 And login.xhtml
 h:form
table
tr
Usuario:
h:inputText value=#{userMBean.nome} /
/tr
tr
Senha:
h:inputText value=#{userMBean.password} /
/tr
tr
h:commandButton action=#{userMBean.dologin}
value=Entrar /
/tr
/table
/h:form

 Thanks


 On Wed, Jun 20, 2012 at 6:10 PM, Maicon pnpinformat...@gmail.com wrote:

  Hi gerhard, the full stack provided by weblogic
 
  javax.el.ELException:
 
 //C:/Java/wls1211_dev/user_projects/domains/dev_domain/autodeploy/testeFramework/login.xhtml
  @18,48 value=#{userMBean.nome}:
  org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active
  contexts for scope type
 
 org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped
  at
 
 com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:114)
  at
 
 javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
  at
 
 javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182)
  at javax.faces.component.UIOutput.getValue(UIOutput.java:169)
  at
 
 com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:205)
  Truncated. see log file for complete stacktrace
  Caused By: org.jboss.weld.context.ContextNotActiveException: WELD-001303
  No active contexts for scope type
 
 org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped
 
  at
 
 org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:600)
  at
 
 org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71)
  at
 
 org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
  at
 
 com.mycompany.tst.UserMBean$Proxy$_$$_WeldClientProxy.getNome(UserMBean$Proxy$_$$_WeldClientProxy.java)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  Truncated. see log file for complete stacktrace
 
 
 
  On Wed, Jun 20, 2012 at 5:40 PM, Gerhard Petracek 
  gerhard.petra...@gmail.com wrote:
 
  hi maicon,
 
  that's fine.
  if you access the conversation-scoped bean within the
  jsf-request-lifecycle, we need the full stacktrace to see where the
 call
  comes from.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/6/20 Maicon pnpinformat...@gmail.com
 
   Hi gerhard, my Faces Servlet is mapped to *.faces. I tried
  mypage.faces
  
   I need other configuration?
  
   My web.xml
   servlet
  servlet-nameFaces Servlet/servlet-name
  servlet-classjavax.faces.webapp.FacesServlet/servlet-class
  load-on-startup1/load-on-startup
  /servlet
  
  servlet-mapping
  servlet-nameFaces Servlet/servlet-name
  url-pattern*.faces/url-pattern
  /servlet-mapping
  
   thanks
  
  
  
 hi maicon,
   
it looks like you are trying to access the conversation-scope
 outside
  of
   a
faces-request.
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses

Re: No active contexts for CODI on Weblogic 12c

2012-06-21 Thread Gerhard Petracek

hi maicon,

sounds like a wls12c bug with custom cdi scopes and auto-deployment.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/21 Maicon pnpinformat...@gmail.com

 Hi guys.

 CODI works fine on weblogic 12c, but not working under directory
 *autodeploy
 * (for development).

 gerhard / rudy do you know something about it?

 On Wed, Jun 20, 2012 at 7:01 PM, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:

  hi maicon,
 
  rudy did some tests with wls12c and afaik it worked for him.
  maybe he can provide further details.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/6/20 Maicon pnpinformat...@gmail.com
 
   Gerhard when I use @SessionScoped instead of @ConversationScoped the
 page
   is loaded ok.
  
  
   The code of the UserMBean is:
  
   @Named(userMBean)
   @ConversationScoped
   public class UserMBean implements Serializable {
  
  private static final long serialVersionUID = 3140959503723849518L;
  
  private String nome, password;
  
  public UserMBean() {
  }
  
  public String doLogin() {
  return maicon.faces;
  }
  
  public String getNome() {
  return nome;
  }
  
  public void setNome(String nome) {
  this.nome = nome;
  }
  
  public String getPassword() {
  return password;
  }
  
  public void setPassword(String password) {
  this.password = password;
  }
  
   }
  
   And login.xhtml
   h:form
  table
  tr
  Usuario:
  h:inputText value=#{userMBean.nome} /
  /tr
  tr
  Senha:
  h:inputText value=#{userMBean.password} /
  /tr
  tr
  h:commandButton action=#{userMBean.dologin}
  value=Entrar /
  /tr
  /table
  /h:form
  
   Thanks
  
  
   On Wed, Jun 20, 2012 at 6:10 PM, Maicon pnpinformat...@gmail.com
  wrote:
  
Hi gerhard, the full stack provided by weblogic
   
javax.el.ELException:
   
  
 
 //C:/Java/wls1211_dev/user_projects/domains/dev_domain/autodeploy/testeFramework/login.xhtml
@18,48 value=#{userMBean.nome}:
org.jboss.weld.context.ContextNotActiveException: WELD-001303 No
 active
contexts for scope type
   
  
 
 org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped
at
   
  
 
 com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:114)
at
   
  
 
 javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at
   
  
 
 javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182)
at javax.faces.component.UIOutput.getValue(UIOutput.java:169)
at
   
  
 
 com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:205)
Truncated. see log file for complete stacktrace
Caused By: org.jboss.weld.context.ContextNotActiveException:
  WELD-001303
No active contexts for scope type
   
  
 
 org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped
   
at
   
  
 
 org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:600)
at
   
  
 
 org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71)
at
   
  
 
 org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
at
   
  
 
 com.mycompany.tst.UserMBean$Proxy$_$$_WeldClientProxy.getNome(UserMBean$Proxy$_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Truncated. see log file for complete stacktrace
   
   
   
On Wed, Jun 20, 2012 at 5:40 PM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:
   
hi maicon,
   
that's fine.
if you access the conversation-scoped bean within the
jsf-request-lifecycle, we need the full stacktrace to see where the
  call
comes from.
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
2012/6/20 Maicon pnpinformat...@gmail.com
   
 Hi gerhard, my Faces Servlet is mapped to *.faces. I tried
mypage.faces

 I need other configuration?

 My web.xml
 servlet
servlet-nameFaces Servlet/servlet-name

   servlet-classjavax.faces.webapp.FacesServlet/servlet-class
load-on-startup1/load-on-startup

Re: No active contexts for CODI on Weblogic 12c

2012-06-20 Thread Gerhard Petracek

hi maicon,

rudy did some tests with wls12c and afaik it worked for him.
maybe he can provide further details.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/20 Maicon pnpinformat...@gmail.com

 Gerhard when I use @SessionScoped instead of @ConversationScoped the page
 is loaded ok.


 The code of the UserMBean is:

 @Named(userMBean)
 @ConversationScoped
 public class UserMBean implements Serializable {

private static final long serialVersionUID = 3140959503723849518L;

private String nome, password;

public UserMBean() {
}

public String doLogin() {
return maicon.faces;
}

public String getNome() {
return nome;
}

public void setNome(String nome) {
this.nome = nome;
}

public String getPassword() {
return password;
}

public void setPassword(String password) {
this.password = password;
}

 }

 And login.xhtml
 h:form
table
tr
Usuario:
h:inputText value=#{userMBean.nome} /
/tr
tr
Senha:
h:inputText value=#{userMBean.password} /
/tr
tr
h:commandButton action=#{userMBean.dologin}
value=Entrar /
/tr
/table
/h:form

 Thanks


 On Wed, Jun 20, 2012 at 6:10 PM, Maicon pnpinformat...@gmail.com wrote:

  Hi gerhard, the full stack provided by weblogic
 
  javax.el.ELException:
 
 //C:/Java/wls1211_dev/user_projects/domains/dev_domain/autodeploy/testeFramework/login.xhtml
  @18,48 value=#{userMBean.nome}:
  org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active
  contexts for scope type
 
 org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped
  at
 
 com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:114)
  at
 
 javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
  at
 
 javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182)
  at javax.faces.component.UIOutput.getValue(UIOutput.java:169)
  at
 
 com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:205)
  Truncated. see log file for complete stacktrace
  Caused By: org.jboss.weld.context.ContextNotActiveException: WELD-001303
  No active contexts for scope type
 
 org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped
 
  at
 
 org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:600)
  at
 
 org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71)
  at
 
 org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
  at
 
 com.mycompany.tst.UserMBean$Proxy$_$$_WeldClientProxy.getNome(UserMBean$Proxy$_$$_WeldClientProxy.java)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  Truncated. see log file for complete stacktrace
 
 
 
  On Wed, Jun 20, 2012 at 5:40 PM, Gerhard Petracek 
  gerhard.petra...@gmail.com wrote:
 
  hi maicon,
 
  that's fine.
  if you access the conversation-scoped bean within the
  jsf-request-lifecycle, we need the full stacktrace to see where the call
  comes from.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/6/20 Maicon pnpinformat...@gmail.com
 
   Hi gerhard, my Faces Servlet is mapped to *.faces. I tried
  mypage.faces
  
   I need other configuration?
  
   My web.xml
   servlet
  servlet-nameFaces Servlet/servlet-name
  servlet-classjavax.faces.webapp.FacesServlet/servlet-class
  load-on-startup1/load-on-startup
  /servlet
  
  servlet-mapping
  servlet-nameFaces Servlet/servlet-name
  url-pattern*.faces/url-pattern
  /servlet-mapping
  
   thanks
  
  
  
 hi maicon,
   
it looks like you are trying to access the conversation-scope
 outside
  of
   a
faces-request.
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
   
2012/6/20 Maicon pnpinformat...@gmail.com
   
 Hi guys,

 I tried run the Myfaces CODI on Weblogic 12c following these
 links:
 -


   
  
 
 http://jsfcorner.blogspot.com.br/2012/01/codi-on-oracle-weblogic-server-12c.html
 -
  http://www.mail-archive.com/users@myfaces.apache.org/msg58208.html

 I'm using CODI 1.0.5 and weblogic

Re: [CODI] redirect to ErrorView instead of Forward

2012-06-19 Thread Gerhard Petracek

hi thomas,

you can use:
@Page(navigation = Page.NavigationMode.REDIRECT) for any view-config.

regards,
gerhard

2012/6/19, Thomas Andraschko zoi...@googlemail.com:
 Hi,

 is it possible to send a redirect instead of forward for the ErrorView?
 We cache some of our pages and sometimes the ErrorView will be cached
 instead of the real view.

 Regards,
 Thomas



-- 

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [CODI] redirect to ErrorView instead of Forward

2012-06-19 Thread Gerhard Petracek

hi thomas,

the ViewConfigAwareNavigationHandler will do the redirect (if needed).
however, a navigation isn't possible at any point in the lifecycle -
depending on the value of 'allowNavigation' in
SecurityUtils#processApplicationSecurityException you can use it.

regards,
gerhard

2012/6/19, Thomas Andraschko zoi...@googlemail.com:
 Hi Gerhard,

 yes i know but i mean:

 @Secured(value = LoginAccessDecisionVoter.class, errorView =
 SessionExpired.class)

 I can't define if redirect or forward should be used for this error view.
 Right?
 AFAICS CODI always use the NavigationHandler in
 Security.processApplicationSecurityException which does a forward.

 Thanks,
 Thomas

 2012/6/19 Gerhard Petracek gerhard.petra...@gmail.com

 hi thomas,

 you can use:
 @Page(navigation = Page.NavigationMode.REDIRECT) for any view-config.

 regards,
 gerhard

 2012/6/19, Thomas Andraschko zoi...@googlemail.com:
  Hi,
 
  is it possible to send a redirect instead of forward for the ErrorView?
  We cache some of our pages and sometimes the ErrorView will be cached
  instead of the real view.
 
  Regards,
  Thomas
 


 --

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces




-- 

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [CODI] redirect to ErrorView instead of Forward

2012-06-19 Thread Gerhard Petracek

hi thomas,

it used to cause issues with some constellations/use-cases/component-libs/... .

before we do something about it:
it would be nice if you just remove the check of 'allowNavigation' in
SecurityUtils#processApplicationSecurityException and test it with
your application.

regards,
gerhard

2012/6/19, Thomas Andraschko zoi...@googlemail.com:
 Hi Gerhard,

 why isn't possible to redirect?
 I though it should be possible every time :)

 Currently i just throw my own RuntimeException in the AccessDecisionVoter
 and do an redirect in my ExceptionHandler.
 This works fine but it's only a workaround.

 Regards,
 Thomas

 2012/6/19 Gerhard Petracek gerhard.petra...@gmail.com

 hi thomas,

 the ViewConfigAwareNavigationHandler will do the redirect (if needed).
 however, a navigation isn't possible at any point in the lifecycle -
 depending on the value of 'allowNavigation' in
 SecurityUtils#processApplicationSecurityException you can use it.

 regards,
 gerhard

 2012/6/19, Thomas Andraschko zoi...@googlemail.com:
  Hi Gerhard,
 
  yes i know but i mean:
 
  @Secured(value = LoginAccessDecisionVoter.class, errorView =
  SessionExpired.class)
 
  I can't define if redirect or forward should be used for this error
  view.
  Right?
  AFAICS CODI always use the NavigationHandler in
  Security.processApplicationSecurityException which does a forward.
 
  Thanks,
  Thomas
 
  2012/6/19 Gerhard Petracek gerhard.petra...@gmail.com
 
  hi thomas,
 
  you can use:
  @Page(navigation = Page.NavigationMode.REDIRECT) for any view-config.
 
  regards,
  gerhard
 
  2012/6/19, Thomas Andraschko zoi...@googlemail.com:
   Hi,
  
   is it possible to send a redirect instead of forward for the
 ErrorView?
   We cache some of our pages and sometimes the ErrorView will be
   cached
   instead of the real view.
  
   Regards,
   Thomas
  
 
 
  --
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 


 --

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces




-- 

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [CODI] redirect to ErrorView instead of Forward

2012-06-19 Thread Gerhard Petracek

hi thomas,

yes - that's what i had in mind.
please create a jira ticket (improvement).

thx  regards,
gerhard

2012/6/19, Thomas Andraschko zoi...@googlemail.com:
 Hi,

 i tested it and it works fine :)
 Is it possible to add an config option to CODI to allow navigation in all
 cases?

 Regards,
 Thomas

 2012/6/19 Gerhard Petracek gerhard.petra...@gmail.com

 hi thomas,

 it used to cause issues with some
 constellations/use-cases/component-libs/... .

 before we do something about it:
 it would be nice if you just remove the check of 'allowNavigation' in
 SecurityUtils#processApplicationSecurityException and test it with
 your application.

 regards,
 gerhard

 2012/6/19, Thomas Andraschko zoi...@googlemail.com:
  Hi Gerhard,
 
  why isn't possible to redirect?
  I though it should be possible every time :)
 
  Currently i just throw my own RuntimeException in the
  AccessDecisionVoter
  and do an redirect in my ExceptionHandler.
  This works fine but it's only a workaround.
 
  Regards,
  Thomas
 
  2012/6/19 Gerhard Petracek gerhard.petra...@gmail.com
 
  hi thomas,
 
  the ViewConfigAwareNavigationHandler will do the redirect (if needed).
  however, a navigation isn't possible at any point in the lifecycle -
  depending on the value of 'allowNavigation' in
  SecurityUtils#processApplicationSecurityException you can use it.
 
  regards,
  gerhard
 
  2012/6/19, Thomas Andraschko zoi...@googlemail.com:
   Hi Gerhard,
  
   yes i know but i mean:
  
   @Secured(value = LoginAccessDecisionVoter.class, errorView =
   SessionExpired.class)
  
   I can't define if redirect or forward should be used for this error
   view.
   Right?
   AFAICS CODI always use the NavigationHandler in
   Security.processApplicationSecurityException which does a forward.
  
   Thanks,
   Thomas
  
   2012/6/19 Gerhard Petracek gerhard.petra...@gmail.com
  
   hi thomas,
  
   you can use:
   @Page(navigation = Page.NavigationMode.REDIRECT) for any
   view-config.
  
   regards,
   gerhard
  
   2012/6/19, Thomas Andraschko zoi...@googlemail.com:
Hi,
   
is it possible to send a redirect instead of forward for the
  ErrorView?
We cache some of our pages and sometimes the ErrorView will be
cached
instead of the real view.
   
Regards,
Thomas
   
  
  
   --
  
   http://www.irian.at
  
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
  
 
 
  --
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 


 --

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces




-- 

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: CODI Page

2012-06-15 Thread Gerhard Petracek

hi jose,

basically it's possible via a custom ViewConfigExtractor (you can even wrap
the default implementation easily - if you just have to post-process the
result).
instead of adding further complexity right now, we will re-visit the
current features before adding it to deltaspike and we will add or drop
parts based on detailed discussions.
- thx for providing your use-case. we keep it in mind for deltaspike.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/15 José Luis Cetina maxtorz...@gmail.com

 Ok no problem for that, it was only a suggestion.
 Thanks and CODI has an very important role in my webapp.
 El 15/06/2012 02:04, Mark Struberg strub...@yahoo.de escribió:

  Hi José!
 
 
  Well, interface and class naming is a topic which gets discussed since 25
  years now (starting with Smalltalk) and I can tell you that there is _no_
  common view about a naming schema ;)
 
  Anyway, glad it worked out for you and hope you find CODI useful!
 
  LieGrue,
  strub
 
 
 
  - Original Message -
   From: José Luis Cetina maxtorz...@gmail.com
   To: MyFaces Discussion users@myfaces.apache.org
   Cc:
   Sent: Thursday, June 14, 2012 1:51 PM
   Subject: Re: CODI Page
  
   I didn't see it, Thanks a lot, i will remove the I prefix.
   Can be a good idea  that CODI support  (with base path) the use of the
   I
   prefix or the able postfix for interfaces, as you know this is the
   rigth
   way to name an interface.
   For now ill remove the I prefix and name ny interface as my page using
  the
   naming convention.
  
   Thanks
   El 14/06/2012 04:01, Gerhard Petracek
   gerhard.petra...@gmail.com
   escribió:
  
hi jose,
  
the link [1] i provided shows it already:
e.g. Pages.Vip.VipContent.class leads to /pages/vip/vipContent.xhtml
  
(if you have to keep the 'I' prefix for interfaces, you have to
   provide the
full base-path (with the current implementation))
  
regards,
gerhard
  
[1] http://s.apache.org/SBP
  
http://www.irian.at
  
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
  
Professional Support for Apache MyFaces
  
  
  
2012/6/14 José Luis Cetina maxtorz...@gmail.com
  
 Is there a way to do it without basepath? I mean, its possible to
 use
type
 safe navigation in  CODI with more than one level folder structure?
 El 13/06/2012 21:35, Gerhard Petracek
   gerhard.petra...@gmail.com
 escribió:

  hi jose,
 
  right now it isn't supported (it doesn't get aggregated),
   because
 basePath
  is more for exceptional/special cases.
  typically the used style is more like [1] (as you can see
   it's a
simpler
  style - e.g. you don't need an explicit usage of
  @Page(name=myPageClassName) due to the default naming
   convention).
 
  regards,
  gerhard
 
  [1] http://s.apache.org/SBP
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/6/13 José Luis Cetina maxtorz...@gmail.com
 
   Hi i have this folder structure
  
   web/
   public/
   index.xhtml
  
   then i use this:
  
   @Page(navigation = Page.NavigationMode.REDIRECT,
basePath=web/public)
   public interface IPublic extends ViewConfig{
public @Page(name=index) class Index
   implements IPublic{}
   }
  
   this works great.
  
   But i dont like to use the basePath=web/public,
   how can i separate?
   What i did, was create an interface like this:
  
   my root folder:
   @Page(navigation = Page.NavigationMode.REDIRECT,
   basePath=web)
   public interfaces IWeb extends ViewConfig{
   }
  
   my folder under root (like web/public)
   @Page(navigation = Page.NavigationMode.REDIRECT,
   basePath=public)
   public interfaces IPublic extends IWeb{
 //then the page
 public @Page(name=index) class Index
   implements IPublic{}
   }
  
   but this doesnt work.
  
   What is the best way to do it?. Im using CODI 1.0.5
  
  
  
   Thanks
   --
  
   ---
   *SCJA. José Luis Cetina*
  
   ---

Re: CODI Page

2012-06-14 Thread Gerhard Petracek

hi jose,

the link [1] i provided shows it already:
e.g. Pages.Vip.VipContent.class leads to /pages/vip/vipContent.xhtml

(if you have to keep the 'I' prefix for interfaces, you have to provide the
full base-path (with the current implementation))

regards,
gerhard

[1] http://s.apache.org/SBP

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/14 José Luis Cetina maxtorz...@gmail.com

 Is there a way to do it without basepath? I mean, its possible to use type
 safe navigation in  CODI with more than one level folder structure?
 El 13/06/2012 21:35, Gerhard Petracek gerhard.petra...@gmail.com
 escribió:

  hi jose,
 
  right now it isn't supported (it doesn't get aggregated), because
 basePath
  is more for exceptional/special cases.
  typically the used style is more like [1] (as you can see it's a simpler
  style - e.g. you don't need an explicit usage of
  @Page(name=myPageClassName) due to the default naming convention).
 
  regards,
  gerhard
 
  [1] http://s.apache.org/SBP
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/6/13 José Luis Cetina maxtorz...@gmail.com
 
   Hi i have this folder structure
  
   web/
   public/
   index.xhtml
  
   then i use this:
  
   @Page(navigation = Page.NavigationMode.REDIRECT, basePath=web/public)
   public interface IPublic extends ViewConfig{
public @Page(name=index) class Index implements IPublic{}
   }
  
   this works great.
  
   But i dont like to use the basePath=web/public, how can i separate?
   What i did, was create an interface like this:
  
   my root folder:
   @Page(navigation = Page.NavigationMode.REDIRECT, basePath=web)
   public interfaces IWeb extends ViewConfig{
   }
  
   my folder under root (like web/public)
   @Page(navigation = Page.NavigationMode.REDIRECT, basePath=public)
   public interfaces IPublic extends IWeb{
 //then the page
 public @Page(name=index) class Index implements IPublic{}
   }
  
   but this doesnt work.
  
   What is the best way to do it?. Im using CODI 1.0.5
  
  
  
   Thanks
   --
   ---
   *SCJA. José Luis Cetina*
   ---

Re: CODI Page

2012-06-13 Thread Gerhard Petracek

hi jose,

right now it isn't supported (it doesn't get aggregated), because basePath
is more for exceptional/special cases.
typically the used style is more like [1] (as you can see it's a simpler
style - e.g. you don't need an explicit usage of
@Page(name=myPageClassName) due to the default naming convention).

regards,
gerhard

[1] http://s.apache.org/SBP

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/6/13 José Luis Cetina maxtorz...@gmail.com

 Hi i have this folder structure

 web/
 public/
 index.xhtml

 then i use this:

 @Page(navigation = Page.NavigationMode.REDIRECT, basePath=web/public)
 public interface IPublic extends ViewConfig{
  public @Page(name=index) class Index implements IPublic{}
 }

 this works great.

 But i dont like to use the basePath=web/public, how can i separate?
 What i did, was create an interface like this:

 my root folder:
 @Page(navigation = Page.NavigationMode.REDIRECT, basePath=web)
 public interfaces IWeb extends ViewConfig{
 }

 my folder under root (like web/public)
 @Page(navigation = Page.NavigationMode.REDIRECT, basePath=public)
 public interfaces IPublic extends IWeb{
   //then the page
   public @Page(name=index) class Index implements IPublic{}
 }

 but this doesnt work.

 What is the best way to do it?. Im using CODI 1.0.5



 Thanks
 --
 ---
 *SCJA. José Luis Cetina*
 ---

Re: CODI No bean found for type

2012-05-17 Thread Gerhard Petracek

hi jose,

it looks like myfaces-core gets started before owb in your case.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/5/18 José Luis Cetina maxtorz...@gmail.com

 Im chanching my web app from glassfish to TomEE 1.0 (i want to use all the
 Apache Stuff).

 I have problem when i add CODI to my pom.xml


 Im getting this error:
 Caused by: java.lang.IllegalStateException: No bean found for type:
 org.apache.myfaces.extensions.cdi.jsf.api.config.JsfModuleConfig


 pom.xml
 .
 .
 !-- MyFaces CODI --
dependency
groupIdorg.apache.myfaces.extensions.cdi.bundles/groupId
artifactIdmyfaces-extcdi-bundle-jsf20/artifactId
version${apache.myfaces.codi.version}/version
scopecompile/scope
/dependency
 .
 .

 Here is my log:

 may 17, 2012 5:23:58 PM org.apache.myfaces.shared.util.ClassUtils
 buildApplicationObject
 Grave: null
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at

 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 at

 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
 at

 org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:561)
 at

 org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:532)
 at

 org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:419)
 at

 org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:355)
 at

 org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73)
 at

 org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:142)
 at

 org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:119)
 at

 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4779)
 at

 org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5273)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 at

 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:895)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:871)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
 at

 org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:649)
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:530)
 at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1471)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at

 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at

 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at

 org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301)
 at

 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
 at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
 at
 org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1436)
 at
 org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:856)
 at
 org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:353)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
 at

 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
 at

 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at

 org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
 at

 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at

 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at

 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
 at

 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
 at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:44)
 at

 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581)
 at

 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
 at

 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
 at
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
 at

 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at

Re: CODI + TomEE

2012-05-17 Thread Gerhard Petracek

please contact [1] the tomee community.

regards,
gerhard

[1] http://openejb.apache.org/support.html

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/5/18 maxtorzito maxtorz...@gmail.com



 Using TomEE 1.0.0 and the problem still!!!

 What is the status of this?



 maxtorzito wrote:
 
  Thanks, i renamed the jars and add it into my WEB-INF/lib folder
 
  CODI-myfaces-extcdi-core-api-1.0.5.jar
  CODI-myfaces-extcdi-core-impl-1.0.5.jar
  CODI-myfaces-extcdi-jsf20-module-api-1.0.5.jar
  CODI-myfaces-extcdi-jsf20-module-impl-1.0.5.jar
  CODI-myfaces-extcdi-message-module-api-1.0.5.jar
  CODI-myfaces-extcdi-message-module-impl-1.0.5.jar
 
  Thanks again
 
 
  2012/4/26 Gerhard Petracek gerhard.petra...@gmail.com
 
  hi jose,
 
  that's a known (and fixed) issue in tomee - details are available at
 [1].
  (it's also mentioned in our wiki at [2]).
 
  regards,
  gerhard
 
  [1] http://os890.blogspot.com/2012/01/codi-meets-tomee.html
  [2]
  https://cwiki.apache.org/confluence/display/EXTCDI/Intro#Intro-Servers
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
  2012/4/26 José Luis Cetina maxtorz...@gmail.com
 
   Im trying to configure a new web app with TomEE+ beta2 with CODI (need
   messages,security, navigation) but when i add the dependencies in my
   pom.xml i get this error:
  
   log file:
  
   Using CATALINA_BASE:   C:\Program Files\Apache Software
   Foundation\apache-tomee-plus-1.0.0-beta-2
   Using CATALINA_HOME:   C:\Program Files\Apache Software
   Foundation\apache-tomee-plus-1.0.0-beta-2
   Using CATALINA_TMPDIR: C:\Program Files\Apache Software
   Foundation\apache-tomee-plus-1.0.0-beta-2\temp
   Using JRE_HOME:C:\Program Files\Java\jdk1.7.0_03
   Using CLASSPATH:   C:\Program Files\Apache Software
   Foundation\apache-tomee-plus-1.0.0-beta-2\bin\bootstrap.jar;C:\Program
   Files\Apache Software
   Foundation\apache-tomee-plus-1.0.0-beta-2\bin\tomcat-juli.jar
   abr 26, 2012 1:37:13 PM org.apache.catalina.core.AprLifecycleListener
  init
   Información: La biblioteca nativa de Apache Tomcat basada en ARP que
   permite un rendimiento óptimo en entornos de desarrollo no ha sido
  hallada
   en java.library.path: C:\Program
  
  
 
 Files\Java\jdk1.7.0_03\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
   Files\Intel\WiFi\bin\;C:\Program Files\Common
   Files\Intel\WirelessCommon\;C:\Program Files\MySQL\MySQL Server
   5.5\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\IVI
   Foundation\VISA\WinNT\Bin;C:\Program Files\Intel\WiFi\bin\;C:\Program
   Files\Common Files\Intel\WirelessCommon\;C:\Program
   Files\Java\jdk1.7.0_03;C:\Program Files\Java\jdk1.7.0_03\bin;.
   ERROR: OpenEJB webapp was not found
   abr 26, 2012 1:37:13 PM org.apache.coyote.AbstractProtocol init
   Información: Initializing ProtocolHandler [http-bio-8080]
   abr 26, 2012 1:37:13 PM org.apache.coyote.AbstractProtocol init
   Información: Initializing ProtocolHandler [ajp-bio-8009]
   abr 26, 2012 1:37:14 PM org.apache.openejb.cdi.CdiBuilder
 initializeOWB
   Información: Created new singletonService
   org.apache.openejb.cdi.ThreadSingletonServiceImpl@d14b190
   abr 26, 2012 1:37:14 PM org.apache.openejb.cdi.CdiBuilder
 initializeOWB
   Información: succeeded in installing singleton service
   Apache OpenEJB 4.0.0-beta-2build: 20120115-08:26
   http://openejb.apache.org/
   abr 26, 2012 1:37:18 PM org.apache.openejb.cdi.CdiBuilder build
   Información: existing thread singleton service in SystemInstance()
   org.apache.openejb.cdi.ThreadSingletonServiceImpl@d14b190
   abr 26, 2012 1:37:18 PM org.apache.openejb.cdi.OpenEJBLifecycle
   startApplication
   Información: OpenWebBeans Container is starting...
   abr 26, 2012 1:37:18 PM org.apache.webbeans.plugins.PluginLoader
  startUp
   Información: Adding OpenWebBeansPlugin : [CdiPlugin]
   abr 26, 2012 1:37:18 PM org.apache.webbeans.plugins.PluginLoader
  startUp
   Información: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin]
   abr 26, 2012 1:37:18 PM org.apache.openejb.cdi.BeansDeployer
   validateInjectionPoints
   Información: All injection points were validated successfully.
   abr 26, 2012 1:37:18 PM org.apache.openejb.cdi.OpenEJBLifecycle
   startApplication
   Información: OpenWebBeans Container has started, it took [134] ms.
   abr 26, 2012 1:37:18 PM org.apache.catalina.startup.Catalina load
   Información: Initialization processed in 5459 ms
   abr 26, 2012 1:37:18 PM org.apache.catalina.core.StandardService
   startInternal
   Información: Arrancando servicio Catalina
   abr 26, 2012 1:37:18 PM org.apache.catalina.core.StandardEngine
   startInternal
   Información: Starting

Re: CODI No bean found for type

2012-05-17 Thread Gerhard Petracek

yes - they fixed the issue, added test-cases which should ensure the
compatibility and we deployed several demos successfully.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/5/18 José Luis Cetina maxtorz...@gmail.com

 Gerhard, in my old post you told me this was a bug:

 [1] http://os890.blogspot.com/2012/01/codi-meets-tomee.html
 [2] https://cwiki.apache.org/confluence/display/EXTCDI/Intro#Intro-Servers


 http://old.nabble.com/CODI-%2B-TomEE-td33754910.html


 This is fixed in TomEE 1.0??



 2012/5/17 Gerhard Petracek gerhard.petra...@gmail.com

  hi jose,
 
  it looks like myfaces-core gets started before owb in your case.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/5/18 José Luis Cetina maxtorz...@gmail.com
 
   Im chanching my web app from glassfish to TomEE 1.0 (i want to use all
  the
   Apache Stuff).
  
   I have problem when i add CODI to my pom.xml
  
  
   Im getting this error:
   Caused by: java.lang.IllegalStateException: No bean found for type:
   org.apache.myfaces.extensions.cdi.jsf.api.config.JsfModuleConfig
  
  
   pom.xml
   .
   .
   !-- MyFaces CODI --
  dependency
  groupIdorg.apache.myfaces.extensions.cdi.bundles/groupId
  artifactIdmyfaces-extcdi-bundle-jsf20/artifactId
  version${apache.myfaces.codi.version}/version
  scopecompile/scope
  /dependency
   .
   .
  
   Here is my log:
  
   may 17, 2012 5:23:58 PM org.apache.myfaces.shared.util.ClassUtils
   buildApplicationObject
   Grave: null
   java.lang.reflect.InvocationTargetException
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
   at
  
  
 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
   at
  
  
 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
   at
  
  
 
 org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:561)
   at
  
  
 
 org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:532)
   at
  
  
 
 org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:419)
   at
  
  
 
 org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:355)
   at
  
  
 
 org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73)
   at
  
  
 
 org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:142)
   at
  
  
 
 org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:119)
   at
  
  
 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4779)
   at
  
  
 
 org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5273)
   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
   at
  
  
 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:895)
   at
  org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:871)
   at
 org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
   at
  
  
 
 org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:649)
   at
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:530)
   at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1471)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
  
  
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at
  
  
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:601)
   at
  
  
 
 org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301)
   at
  
  
 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
   at
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
   at
  
 
 org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1436)
   at
  
 
 org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:856)
   at
  
 org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:353)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
   at
  
  
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
   at
  
  
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210

Re: CODI No bean found for type

2012-05-17 Thread Gerhard Petracek

yes tomee v1.0 - before you contact the tomee community, please ensure that
your setup is correct (e.g. CATALINA_HOME).

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/5/18 José Luis Cetina maxtorz...@gmail.com

 fixed in TomEE 1.0?? im using it and the problem still

 2012/5/17 Gerhard Petracek gerhard.petra...@gmail.com

  yes - they fixed the issue, added test-cases which should ensure the
  compatibility and we deployed several demos successfully.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/5/18 José Luis Cetina maxtorz...@gmail.com
 
   Gerhard, in my old post you told me this was a bug:
  
   [1] http://os890.blogspot.com/2012/01/codi-meets-tomee.html
   [2]
  https://cwiki.apache.org/confluence/display/EXTCDI/Intro#Intro-Servers
  
  
   http://old.nabble.com/CODI-%2B-TomEE-td33754910.html
  
  
   This is fixed in TomEE 1.0??
  
  
  
   2012/5/17 Gerhard Petracek gerhard.petra...@gmail.com
  
hi jose,
   
it looks like myfaces-core gets started before owb in your case.
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
2012/5/18 José Luis Cetina maxtorz...@gmail.com
   
 Im chanching my web app from glassfish to TomEE 1.0 (i want to use
  all
the
 Apache Stuff).

 I have problem when i add CODI to my pom.xml


 Im getting this error:
 Caused by: java.lang.IllegalStateException: No bean found for type:
 org.apache.myfaces.extensions.cdi.jsf.api.config.JsfModuleConfig


 pom.xml
 .
 .
 !-- MyFaces CODI --
dependency

   groupIdorg.apache.myfaces.extensions.cdi.bundles/groupId
artifactIdmyfaces-extcdi-bundle-jsf20/artifactId
version${apache.myfaces.codi.version}/version
scopecompile/scope
/dependency
 .
 .

 Here is my log:

 may 17, 2012 5:23:58 PM org.apache.myfaces.shared.util.ClassUtils
 buildApplicationObject
 Grave: null
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
   Method)
 at


   
  
 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 at


   
  
 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
 at


   
  
 
 org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:561)
 at


   
  
 
 org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:532)
 at


   
  
 
 org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:419)
 at


   
  
 
 org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:355)
 at


   
  
 
 org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73)
 at


   
  
 
 org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:142)
 at


   
  
 
 org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:119)
 at


   
  
 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4779)
 at


   
  
 
 org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5273)
 at
  org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 at


   
  
 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:895)
 at
   
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:871)
 at
   org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
 at


   
  
 
 org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:649)
 at
   org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:530)
 at
 org.apache.catalina.startup.HostConfig.check(HostConfig.java:1471)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at


   
  
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at


   
  
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601

Re: Re[2]: [CODI] ViewAccessScoped beans without windowId in URL

2012-05-13 Thread Gerhard Petracek

hi pavel,

you can use ServerSideWindowHandler (see [1] which provides additional
details - i linked the whole thread in my previous answer [2]).

regards,
gerhard

[1] http://markmail.org/message/2chkos7y2vjmjpzy
[2] http://s.apache.org/k4

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/5/10 Pavel Arnošt pavel.arn...@loutka.cz

 Hi all,
  first, I apologize for double post, it looks like that Nabble gateway
 does not work very well, it nagged me with could not deliver messages and
 even now your messages are not available at Nabble (http://old.nabble.com/
 **MyFaces---Users-f181.htmlhttp://old.nabble.com/MyFaces---Users-f181.html
 ).
  Thanks for all your replies.
  WindowContextConfig#**isUrlParameterSupported is really sufficient for
 working ViewAccessScope without windowId in URL, I confused creates new
 beans with invokes @PostConstruct at every request. And thats expected,
 as discussed at http://stackoverflow.com/**questions/2797231/why-does-**
 postconstruct-callback-fire-**every-time-even-though-bean-**is-viewscopedhttp://stackoverflow.com/questions/2797231/why-does-postconstruct-callback-fire-every-time-even-though-bean-is-viewscoped
 .
  I believe that windowId functionality is great, but on simple public
 pages such as Give us feedback or Register with us, windowId parameter
 is a little ugly, losing of context with reload is not a problem here and
 ViewAccessScope is very handy for AJAX feedback.
  Regards,
 Pavel

 -- Původní zpráva --
 Od: Mark Struberg strub...@yahoo.de
 Komu: MyFaces Discussion users@myfaces.apache.org
 Odesláno: 10.5.2012 16:03:08
 Předmět: Re: [CODI] ViewAccessScoped beans without windowId in URL

  Hi folks!

 We've done some intense testing and I really suggest to use the windowId
 url parameter and also to use the ClientSideWindowhandler with the
 windowhandler.js and windowhandler.html stuff. If you have customers/users
 which are used to open multiple browser tabs, then this is the only
 perfectly working solution.

 Btw, the windowId in the URL doesn't make any problem because it will get
 checked against the window.name. And if those doesn't fit then we just
 request a new windowId.

 LieGrue,
 strub



 - Original Message -


 From: Rafael Pestano rmpest...@yahoo.com.br
 To: MyFaces Discussion users@myfaces.apache.org; Pavel Arnošt 
 pavel.arn...@loutka.cz
 Cc:
 Sent: Thursday, May 10, 2012 3:20 PM
 Subject: Re: [CODI] ViewAccessScoped beans without windowId in URL

 Hi Pavel,

 WindowContextConfig#**isUrlParameterSupported should be enough, does
 serverside
 demo  work for you?

 http://people.apache.org/~**gpetracek/myfaces/codi/demos/**
 serverside_demo_jsf12.ziphttp://people.apache.org/~gpetracek/myfaces/codi/demos/serverside_demo_jsf12.zip


 keep in mind that the bean will not survive to a redirect.
 I hope it helps.

 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://code.google.com/p/jsf-**conventions-framework/http://code.google.com/p/jsf-conventions-framework/
 http://rpestano.wordpress.com
 @realpestano



 __**__
 De: Pavel Arnošt pavel.arn...@loutka.cz
 Para: users@myfaces.apache.org
 Enviadas: Quinta-feira, 10 de Maio de 2012 9:41
 Assunto: [CODI] ViewAccessScoped beans without windowId in URL

 Hi,

 I already read documentation in the wiki and several old posts, but I
 don't still get it - is it possible to use ViewAccessScoped beans
 without windowId in URL? When I disable
 WindowContextConfig#**isUrlParameterSupported, windowId is gone but AJAX
 calls now creates new bean instances on requests. In javadoc, there is
 a note about server-side window-handler, how can I use it?

 Thanks,
 Regards,
 Pavel Arnost

Re: [CODI] ViewAccessScoped beans without windowId in URL

2012-05-08 Thread Gerhard Petracek

hi pavel,

you can have a look at a thread which starts at [1].

regards,
gerhard

[1] http://s.apache.org/Vv6

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/5/8 Mark Struberg strub...@yahoo.de

 Hi Pavel!

 Welcome to the MyFaces list!

 The windodwId gets propagated in 2 ways:

 1.) for GET requests we use the windowId parameter
 2.) for POST requests we have it in our viewState.



 Thus the windowId should also be available in AJAX requests. But you don't
 need the URL parameter for it.

 LieGrue,
 strub



 - Original Message -
  From: Pavel Arnost pavel.arn...@loutka.cz
  To: users@myfaces.apache.org
  Cc:
  Sent: Tuesday, May 8, 2012 12:07 AM
  Subject: [CODI] ViewAccessScoped beans without windowId in URL
 
 
  Hi,
 
  I already read documentation in the wiki and several old posts, but I
 don't
  still get it - is it possible to use ViewAccessScoped beans without
 windowId
  in URL? When I disable WindowContextConfig#isUrlParameterSupported,
 windowId
  is gone but AJAX calls now creates new bean instances on requests. In
  javadoc, there is a note about server-side window-handler, how can I
  use
  it?
 
  Thanks,
  Regards,
  Pavel Arnost
  --
  View this message in context:
 
 http://old.nabble.com/-CODI--ViewAccessScoped-beans-without-windowId-in-URL-tp33763549p33763549.html
  Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: CODI + TomEE

2012-04-26 Thread Gerhard Petracek

hi jose,

that's a known (and fixed) issue in tomee - details are available at [1].
(it's also mentioned in our wiki at [2]).

regards,
gerhard

[1] http://os890.blogspot.com/2012/01/codi-meets-tomee.html
[2] https://cwiki.apache.org/confluence/display/EXTCDI/Intro#Intro-Servers

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2012/4/26 José Luis Cetina maxtorz...@gmail.com

 Im trying to configure a new web app with TomEE+ beta2 with CODI (need
 messages,security, navigation) but when i add the dependencies in my
 pom.xml i get this error:

 log file:

 Using CATALINA_BASE:   C:\Program Files\Apache Software
 Foundation\apache-tomee-plus-1.0.0-beta-2
 Using CATALINA_HOME:   C:\Program Files\Apache Software
 Foundation\apache-tomee-plus-1.0.0-beta-2
 Using CATALINA_TMPDIR: C:\Program Files\Apache Software
 Foundation\apache-tomee-plus-1.0.0-beta-2\temp
 Using JRE_HOME:C:\Program Files\Java\jdk1.7.0_03
 Using CLASSPATH:   C:\Program Files\Apache Software
 Foundation\apache-tomee-plus-1.0.0-beta-2\bin\bootstrap.jar;C:\Program
 Files\Apache Software
 Foundation\apache-tomee-plus-1.0.0-beta-2\bin\tomcat-juli.jar
 abr 26, 2012 1:37:13 PM org.apache.catalina.core.AprLifecycleListener init
 Información: La biblioteca nativa de Apache Tomcat basada en ARP que
 permite un rendimiento óptimo en entornos de desarrollo no ha sido hallada
 en java.library.path: C:\Program

 Files\Java\jdk1.7.0_03\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
 Files\Intel\WiFi\bin\;C:\Program Files\Common
 Files\Intel\WirelessCommon\;C:\Program Files\MySQL\MySQL Server
 5.5\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\IVI
 Foundation\VISA\WinNT\Bin;C:\Program Files\Intel\WiFi\bin\;C:\Program
 Files\Common Files\Intel\WirelessCommon\;C:\Program
 Files\Java\jdk1.7.0_03;C:\Program Files\Java\jdk1.7.0_03\bin;.
 ERROR: OpenEJB webapp was not found
 abr 26, 2012 1:37:13 PM org.apache.coyote.AbstractProtocol init
 Información: Initializing ProtocolHandler [http-bio-8080]
 abr 26, 2012 1:37:13 PM org.apache.coyote.AbstractProtocol init
 Información: Initializing ProtocolHandler [ajp-bio-8009]
 abr 26, 2012 1:37:14 PM org.apache.openejb.cdi.CdiBuilder initializeOWB
 Información: Created new singletonService
 org.apache.openejb.cdi.ThreadSingletonServiceImpl@d14b190
 abr 26, 2012 1:37:14 PM org.apache.openejb.cdi.CdiBuilder initializeOWB
 Información: succeeded in installing singleton service
 Apache OpenEJB 4.0.0-beta-2build: 20120115-08:26
 http://openejb.apache.org/
 abr 26, 2012 1:37:18 PM org.apache.openejb.cdi.CdiBuilder build
 Información: existing thread singleton service in SystemInstance()
 org.apache.openejb.cdi.ThreadSingletonServiceImpl@d14b190
 abr 26, 2012 1:37:18 PM org.apache.openejb.cdi.OpenEJBLifecycle
 startApplication
 Información: OpenWebBeans Container is starting...
 abr 26, 2012 1:37:18 PM org.apache.webbeans.plugins.PluginLoader startUp
 Información: Adding OpenWebBeansPlugin : [CdiPlugin]
 abr 26, 2012 1:37:18 PM org.apache.webbeans.plugins.PluginLoader startUp
 Información: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin]
 abr 26, 2012 1:37:18 PM org.apache.openejb.cdi.BeansDeployer
 validateInjectionPoints
 Información: All injection points were validated successfully.
 abr 26, 2012 1:37:18 PM org.apache.openejb.cdi.OpenEJBLifecycle
 startApplication
 Información: OpenWebBeans Container has started, it took [134] ms.
 abr 26, 2012 1:37:18 PM org.apache.catalina.startup.Catalina load
 Información: Initialization processed in 5459 ms
 abr 26, 2012 1:37:18 PM org.apache.catalina.core.StandardService
 startInternal
 Información: Arrancando servicio Catalina
 abr 26, 2012 1:37:18 PM org.apache.catalina.core.StandardEngine
 startInternal
 Información: Starting Servlet Engine: Apache Tomcat/7.0.21
 abr 26, 2012 1:37:18 PM org.apache.catalina.startup.HostConfig
 deployDescriptor
 Información: Desplieque del descriptor de configuración grupokx.xml
 TomcatWebAppBuilder.start /grupokx
 abr 26, 2012 1:37:22 PM org.apache.openejb.cdi.CdiBuilder build
 Información: existing thread singleton service in SystemInstance()
 org.apache.openejb.cdi.ThreadSingletonServiceImpl@d14b190
 abr 26, 2012 1:37:22 PM org.apache.openejb.cdi.OpenEJBLifecycle
 startApplication
 Información: OpenWebBeans Container is starting...
 abr 26, 2012 1:37:22 PM org.apache.webbeans.plugins.PluginLoader startUp
 Información: Adding OpenWebBeansPlugin : [CdiPlugin]
 abr 26, 2012 1:37:22 PM org.apache.webbeans.plugins.PluginLoader startUp
 Información: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin]
 abr 26, 2012 1:37:22 PM
 org.apache.myfaces.extensions.cdi.core.api.provider.ServiceProvider
 clinit
 Información:
 org.apache.myfaces.extensions.cdi.core.impl.provider.DefaultServiceProvider

Re: @Secured and Stereotypes

2012-04-21 Thread Gerhard Petracek

hi jose,

i tested it with weld (via glassfish 3.1.2 and as7) and it works without an
issue.

since you haven't listed it:
with weld you have to configure the security-interceptor in your
application explicitly.
- within the beans-tag in your beans.xml you have to add:

interceptors

classorg.apache.myfaces.extensions.cdi.jsf.impl.security.SecurityInterceptor/class
/interceptors

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/4/20 Gerhard Petracek gerhard.petra...@gmail.com

 hi jose,

 i've tested it with owb. i'll test if there is a bug in weld which blocks
 this feature.

 regards,
 gerhard

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2012/4/20 José Luis Cetina maxtorz...@gmail.com

 This example doesnt work for me too:

  https://issues.apache.org/jira/browse/EXTCDI-262



 El 20 de abril de 2012 09:57, José Luis Cetina maxtorz...@gmail.com
 escribió:

  This dont work for me, here are my small test:
 
  *//DECISION VOTER*
  import java.util.Set;
  import javax.interceptor.InvocationContext;
  import
 
 org.apache.myfaces.extensions.cdi.core.api.security.AbstractAccessDecisionVoter;
  import
  org.apache.myfaces.extensions.cdi.core.api.security.AccessDecisionVoter;
  import
  org.apache.myfaces.extensions.cdi.core.api.security.SecurityViolation;
 
  @javax.enterprise.context.ApplicationScoped
  public class PermissionAccessDecisionVoter extends
  AbstractAccessDecisionVoter implements AccessDecisionVoter{
 
  @Override
  protected void checkPermission(InvocationContext ic,
  SetSecurityViolation violations) {
  System.out.println(verifying ..);
  }
  }
 
 ---
 
  *//Interface for annotation*
 
  import java.lang.annotation.ElementType;
  import java.lang.annotation.Retention;
  import java.lang.annotation.RetentionPolicy;
  import java.lang.annotation.Target;
  import javax.enterprise.inject.Stereotype;
  import org.apache.myfaces.extensions.cdi.core.api.security.Secured;
 
  @Stereotype
  @Target(value = {ElementType.METHOD, ElementType.FIELD,
 ElementType.TYPE})
  @Retention(value = RetentionPolicy.RUNTIME)
  @Secured(PermissionAccessDecisionVoter.class)
  public @interface ModuloPantallaBinding {
 
  }
 
 
 ---
  *//ViewConfig*
  import
 org.apache.myfaces.extensions.cdi.core.api.config.view.ViewConfig;
  import org.apache.myfaces.extensions.cdi.jsf.api.config.view.Page;
 
  @Page(navigation = Page.NavigationMode.REDIRECT)
  public class Index implements ViewConfig{
 
  }
 
 ---
 
  *//BEAN*
  import java.io.Serializable;
  import javax.faces.application.FacesMessage;
  import javax.faces.context.FacesContext;
  import javax.faces.event.ActionEvent;
  import javax.inject.Named;
  import org.apache.myfaces.extensions.cdi.core.api.config.view.View;
  import
 
 org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ViewAccessScoped;
  import org.apache.myfaces.extensions.cdi.jsf.api.config.view.InitView;
 
  @Named
  @View(Index.class)
  @ViewAccessScoped
  @ModuloPantallaBinding
  public class MyBean implements Serializable{
 
  @InitView
  public void init(){
  System.out.println(init method);
  }
 
  public void test(ActionEvent e){
  FacesContext.getCurrentInstance().addMessage(null, new
  FacesMessage(FacesMessage.SEVERITY_INFO, msg, msg detail));
  }
  }
 
 
 ---
 
 
  *//XHTML*
  I Have only a commandbutton in a form:
 
  p:commandButton value=Test update=public_messages
  actionListener=#{myBean.test} /
 
 
 
 
 ---
 
  *//LOG*
  Información:
 
 org.apache.myfaces.extensions.cdi.core.impl.provider.DefaultServiceProvider
  installed successfully.
  Información:
 
 org.apache.myfaces.extensions.cdi.core.impl.provider.DefaultServiceProviderContext
  installed successfully.
  Información: Computed the following CODI ProjectStage: Production
  Información: abc.Index will be used as page-definition.
  Información: abc.MyBean will be used as page-bean.
  Información: Initializing Mojarra 2.1.6 (SNAPSHOT 20111206) for context
  '/WebApplication2'
  Información: [Started] MyFaces CODI (Extensions CDI) alternative config

Re: @Secured and Stereotypes

2012-04-20 Thread Gerhard Petracek

 value: false
 method: isUrlParameterSupported
 value: true
 method: isUnknownWindowIdsAllowed
 value: false
 method: getMaxWindowContextCount
 value: 64
  config implementation:
 
 org.apache.myfaces.extensions.cdi.core.alternative.scope.conversation.config.AlternativeConversationConfig$Proxy$_$$_WeldClientProxy
  config implementation:
 
 org.apache.myfaces.extensions.cdi.core.alternative.scope.conversation.config.AlternativeConversationConfig
  config implementation:
 
 org.apache.myfaces.extensions.cdi.core.api.scope.conversation.config.ConversationConfig
 method: isConversationRequiredEnabled
 value: true
 method: isRestartConversationEventEnabled
 value: false
 method: isCloseConversationEventEnabled
 value: false
 method: isStartConversationEventEnabled
 value: false
 method: getConversationTimeoutInMinutes
 value: 30
 method: isScopeBeanEventEnabled
 value: false
 method: isAccessBeanEventEnabled
 value: false
 method: isUnscopeBeanEventEnabled
 value: false
  MessageContextConfig class:
 
 org.apache.myfaces.extensions.cdi.message.impl.DefaultMessageContextConfig
 MessageInterpolator class: class
 
 org.apache.myfaces.extensions.cdi.jsf.impl.message.FacesMessageInterpolator
 MessageResolver class: class
 
 org.apache.myfaces.extensions.cdi.jsf.impl.message.JsfAwareApplicationMessagesMessageResolver
 MessageHandler class: class
  org.apache.myfaces.extensions.cdi.jsf.impl.message.JsfAwareMessageHandler
 LocaleResolver class: class
  org.apache.myfaces.extensions.cdi.jsf.impl.message.JsfAwareLocaleResolver
 FormatterFactory class: class
  org.apache.myfaces.extensions.cdi.message.impl.DefaultFormatterFactory
 
  Información: [Started] MyFaces CODI JPA-Module v1.0.4
 
  Información: [Started] MyFaces CODI (Extensions CDI) Core v1.0.4
  Used CDI implementation: Weld v2022-2001
  project-stage: Production
  project-stage class:
 
 org.apache.myfaces.extensions.cdi.core.api.projectstage.ProjectStage$Production
  application-parameters:
 name: com.sun.faces.forceLoadConfiguration
 value: true
 name: com.sun.faces.validateXml
 value: true
 name: javax.faces.PROJECT_STAGE
 value: Development
  config implementation:
 
 org.apache.myfaces.extensions.cdi.core.alternative.config.AlternativeCodiCoreConfig$Proxy$_$$_WeldClientProxy
  config implementation:
 
 org.apache.myfaces.extensions.cdi.core.alternative.config.AlternativeCodiCoreConfig
  config implementation:
  org.apache.myfaces.extensions.cdi.core.api.config.CodiCoreConfig
 method: isAdvancedQualifierRequiredForDependencyInjection
 value: true
 method: isConfigurationLoggingEnabled
 value: true
 method: isInvalidBeanCreationEventEnabled
 value: false
 
  Advertencia: The value of the JSF 2 project stage (Development) is
  different from the CODI project stage (Production)
  Información: [Started] MyFaces CODI Scripting-Module v1.0.4
 
  Información: [Started] MyFaces CODI Bean-Validation-Module v1.0.4
  *Información: verifying ..*
  *Información: verifying ..*
  *Información: init method*
  *Información: verifying ..*
  *Información: verifying ..*
  *
  *
  *
  *
  *
  *
  *
  *
  *
  *
 
 ---
 
  *
  *
  *
  *
  *Why? Thanks*
  *
  *
 
  2012/4/19 Gerhard Petracek gerhard.petra...@gmail.com
 
  hi jose,
 
  here it works without an issue - please provide the codi startup-log
  about
  the configuration you are using.
 
  @ package:
  please use: javax.enterprise.context
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/4/19 José Luis Cetina maxtorz...@gmail.com
 
   Thanks Gerhard, but i have a problem.
   My checkpermision method never get called, i dont know why, i have
 this:
  
   *//ANOTATION*
   @Stereotype
   @Target(value = {ElementType.METHOD, ElementType.FIELD,
  ElementType.TYPE})
   @Retention(value = RetentionPolicy.RUNTIME)
   @Secured(PermissionAccessDecisionVoter.class)
   public @interface ModuloPantallaBinding {
  ModulosPantallasEnum codigoModulo();
   }
  
   *//MANAGED BEAN*
   @Named
   @ViewAccessScoped
   @View(IInicio.SeleccionRoles.class)
  
  
 
 @ModuloPantallaBinding(codigoModulo=ModulosPantallasEnum.SELECCION_ROLES_INICIO)
   public class SeleccionRolesMBean implements Serializable {
   .
   .
   .
   }
  
   *//Secure class*
   import javax.faces.bean.ApplicationScoped;
   @ApplicationScoped
   public class PermissionAccessDecisionVoter extends
   AbstractAccessDecisionVoter implements AccessDecisionVoter{
   .
  
   protected void checkPermission(InvocationContext ic,
  SetSecurityViolation
   violations) {
*ModuloPantallaBinding obj

1 2 3 4 5 >

1 - 100 of 485 matches

Mail list logo