/
@realpestano
Em Segunda-feira, 24 de Março de 2014 5:08, Thomas Andraschko
escreveu:
Ok. Rafael, could you create an issue?
2014-03-23 23:49 GMT+01:00 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).
Ok. Rafael, could you create an issue?
2014-03-23 23:49 GMT+01:00 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
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
20
> 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
> >
> >
&
; 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 :
>
> > Hi guys,
> >
> > i'm facing an issue
ulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
>
> 2014-03-23 18:23 GMT+01:00 Rafael Pestano :
>
> > Hi guys,
> >
> > i'm facing an issue with CODI on Glassfish 4 which i can't o
g, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
>
> 2014-03-23 18:23 GMT+01:00 Rafael Pestano :
>
> > Hi guys,
> >
> > i'm facing an issue with CODI on Glassfish 4 which i can't observe CDI
> >
German
Professional Support for Apache MyFaces
2014-03-23 18:23 GMT+01:00 Rafael Pestano :
> 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
>
> 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{
>
> @I
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
Event myEvent;
is no such thing for @NormalScoped beans, and for @Dependent it
> > >> will never work.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> >
there is no such thing for @NormalScoped beans, and for @Dependent it
> >> will never work.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >>
> >> >
> >> &g
___
>> > From: "Howard W. Smith, Jr."
>> >To: MyFaces Discussion ; Mark Struberg <
>> strub...@yahoo.de>
>> >Sent: Thursday, 31 October 2013, 0:12
>> >Subject: Re: Apache CODI x JEE7 Glassfish4
>> >
>> &g
thing for @NormalScoped beans, and for @Dependent it
> will
> > never work.
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> > >
> > > From: "Howard W. Smith, Jr."
> > >To: MyFaces Discussion ; Mark Struberg <
> > st
l
> never work.
>
> LieGrue,
> strub
>
>
>
>
>
> >
> > From: "Howard W. Smith, Jr."
> >To: MyFaces Discussion ; Mark Struberg <
> strub...@yahoo.de>
> >Sent: Thursday, 31 October 2013, 0:12
> >Subject: Re: Apache CODI x JEE7 Glassfish4
I'll try to substitute CODI to DeltaSpike using JEE7/GF4 for test...
thanks... I'll return the result here...
2013/10/31 Gerhard Petracek
> i haven't said something different.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF/JavaEE powerhouse
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
>
>
> yea, but that is minor tho wh
yea, but that is minor tho what CODI can do.
LieGrue,
strub
>
> From: Gerhard Petracek
>To: MyFaces Discussion ; Mark Struberg
>
>Sent: Thursday, 31 October 2013, 0:24
>Subject: Re: Apache CODI x JEE7 Glassfish4
>
>
ent: Thursday, 31 October 2013, 0:12
>Subject: Re: Apache CODI x JEE7 Glassfish4
>
>
>
>Mark,
>
>
>
>On Wed, Oct 30, 2013 at 7:05 PM, Mark Struberg wrote:
>
>
>>The main changes in CDI-1.1 have been clarifications. But most of them are
>>already impleme
g,
> etc in CDI-1.1.
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
> > From: Kay Wrobel
> > To: MyFaces Discussion
> > Cc:
> > Sent: Wednesday, 30 October 2013, 22:44
> > Subject: Re: Apache CODI x JEE7 Glassfish4
> >
>
Mark,
On Wed, Oct 30, 2013 at 7:05 PM, Mark Struberg wrote:
>
> 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,
>
CDI-1.1.
LieGrue,
strub
- Original Message -
> From: Kay Wrobel
> To: MyFaces Discussion
> 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
&g
Interesting conversation, and per your responses, Gerhard, I guess I can go
ahead and quote what I heard someone mentioned in another forum (or issue
tracker) about CODI being an inactive project...being superseded by
deltaspike.
I think Mark Struberg or one of your guys provided a slideshow
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
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 i
Thanks Gerhard.
I just Google'd the topic and also ran across DeltaSpike.
Sorry, I was a bit unaware of ConversationScoped and what it does and
that it was better implemented in CODI.
On 10/30/2013 04:33 PM, Gerhard Petracek wrote:
hi edilmar,
apache deltaspike is the official success
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 co
Yeah, I think CODI was a good for some features that either didn't exist
in CDI 1.0 (like ViewAccessScoped) or were better implemented in CODI.
That said, CDI in Java EE 7 is much improved, and switching over to an
EE 7 profile and taking advantage of it may require you to make code
ch
I think CODI is a great replacement for my actual environment, the only
problem is to deploy in GF4.
2013/10/30 Edilmar Alves
> Hi,
>
> I use CODI ConversationScoped and @Inject Conversation because it is
> better than original CDI implementation.
> I have many java files usi
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%,
becaus
ch 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> and ot looks like
@ConversationScope is already part of CDI 1.1, no CODI needed for th
I'm looking at CDI 1.1 spec
<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/> which is bundled
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
tibilities 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 Weld1.1 + CODI + JPA2 +
Hibernate4.2.6 + JSF2 + RichF
d 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 Weld1.1 + CODI + JPA2 +
>> Hibernate4.2.6 + JSF2 + RichFaces4.3.4.
>> Then, when I try
using Weld1.1 + CODI + JPA2 +
Hibernate4.2.6 + JSF2 + RichFaces4.3.4.
Then, when I try to deploy in GF4, server.log arises this error, and
searching on Internet, some people said this is a
problem with CODI, that is not compatible with JEE7 projects. Is this true?
If it is not compatible, is there
Hi,
I have an webapp that runs fine in GF3.1.1 using Weld1.1 + CODI + JPA2 +
Hibernate4.2.6 + JSF2 + RichFaces4.3.4.
Then, when I try to deploy in GF4, server.log arises this error, and
searching on Internet, some people said this is a
problem with CODI, that is not compatible with JEE7 projects
@ #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-sc
tank you for the link.
but what it is the fifference from the ViewScoped of codi and
ViewAccessScoped??? a real case of use both ??
Another questions: into tomee it is out of the box the bean validator.
now i ask : the myfacesEXT validator it is anoyher ? difference from bean
validator?
Il
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 -
J
Hi all.
Hi have read that i have to download the bundle jar for use codi ces into
tomee.
the myfaces-extcdi-bundle-jsf20-1.0.1.jar
But i not have found it.
I have only found many jars,
but it exists a jar that bundle all of codi
the link for download it???
readf at link below
When we declare a CODI ConversationScope producer in a CODI
ConversationScope bean, and we reference the object created by the
producer in a facelets page, the server enters an endless loop and
ends up with a StackOverFlowError
With this bean:
@Named("convScopeproducerInConvScop
rra 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
> r
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
> but basically it isn't an issue of codi ->
> please file an issue for WAS8.
+1 might probably be a problem of WAS using EJB proxies for CDI beans.
LieGrue,
strub
- Original Message -
> From: Gerhard Petracek
> To: MyFaces Discussion ; Adrian Gonzalez
>
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 MyFace
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'
ed 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
5.nxs1-SNAPSHOT]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
~[javax.j2ee.jsf.jar:na]
De : Mark Struberg
À : MyFaces Discussion ; Adrian Gonzalez
Envoyé le : Jeudi 21 mars 2013 22h01
Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
Hi folks!
a.) I hope
wrote:
> Hi all!
>
> I've got problem with CODI when i post the html form with cyrillic data.
>
> I've tested on simple JSF2 + CDI (Weld) application on JBoss AS7. So
> while I don't put myfaces-extcdi-bundle-jsf20-1.0.5.jar in lib directory of
> ear everythi
Hi all!
I've got problem with CODI when i post the html form with cyrillic data.
I've tested on simple JSF2 + CDI (Weld) application on JBoss AS7. So
while I don't put myfaces-extcdi-bundle-jsf20-1.0.5.jar in lib directory of
ear everything works fine. But if I do it, then afte
Glad to see it worked for you Aleksey, and thanks for the feeback !
Best regards,
Adrian
- Mail original -
De : Пестов Алексей
À : MyFaces Discussion
Cc :
Envoyé le : Vendredi 22 mars 2013 11h32
Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
Hi Adrian!
It works
h and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2013/3/22 Adrian Gonzalez
>
> > Hi Gerhard,
> >
> > Thanks, didn't know you already coded @JsfPhaseListener support in DS.
> >
> > Looking at your source code [1], it should work l
for Apache MyFaces
2013/3/22 Adrian Gonzalez
> 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
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
t;
> 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,
>
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
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: Пестов Алексей
> To: MyFaces Discussion ; Adrian Go
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 wrote:
> Hi Aleksey,
>
> Here's the patch file (my first one with git).
> I've obtained it executing [1]
>
> I've changed
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 lin
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 solutio
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
w
Hello,
Implemented solution 3 in my github repo [1].
I've tested it on JBoss 7.1.0.Final.
I need to test it on WAS 8.0.x now.
This solution is fine for my needs :
* EAR usage with 0..n webapps
* I don't use @JsfPhaseListener in my code
* I'm only using CODI JSF Scopes, no other
Thanks very much Christian for your help !
So this appears to be a bug/limitation related to CODI usage with an EAR
leading to a non portable issue between appservers.
I've begun testing some modifications in CODI source which corrects the problem
but leads to other limitations.
Modific
INFO [stdout] (http--0.0.0.0-8080-1) @PostConstruct
So ViewAccessScoped bean is reinstantiated.
I've tested it with both m2e-wtp, and packaging/deploying by hand (mvn clean
package).
Thanks very much for your help on this topic !
[1] https://github.com/gonzalad/codi-ear-viewaccesssco
hand (mvn clean
package).
Thanks very much for your help on this topic !
[1] https://github.com/gonzalad/codi-ear-viewaccessscoped/tree/ear
- Mail original -
De : Christian Beikov
À : users@myfaces.apache.org
Cc :
Envoyé le : Mercredi 20 mars 2013 3h07
Objet : Re: CODI ViewAccessScope
8 and ear packaging, everything is under
WEB-INF/lib (no EJB Timer for the moment).
BTW, updated sample app (moved codi to ear) : it's in ear branch
https://github.com/gonzalad/codi-ear-viewaccessscoped/tree/ear
If I don't find a packaging solution, perhaps I'll give a try modifying
h war)
Going to use your instructions for WAS in the future (I'm using both JBoss AS 7
and WAS 8).
For the moment, no problem with WAS 8 and ear packaging, everything is under
WEB-INF/lib (no EJB Timer for the moment).
BTW, updated sample app (moved codi to ear) : it's in ear branch
h
Maybe you should check my previous post named "CODI jar in ear/lib
with a WAR = fail in WebSphere v8.5" and then "Does CODI supports to
be deployed in a app server that uses multi-classloader..." started
January 17 because it seems that you have the same problem we have
with
I've just put myfaces-extcdi-bundle-jsf20-1.0.5.jar into ear (and removed it
from WEB-INF/lib), no more luck.
I'll try to update my sample tomorrow with ear packaging and debug it.
Thanks once more for the help Christian !
P.S. I'm wondering if the root cause of this bu
I used the xml file to be able to put the CODI bundle into EAR/lib.
The problem was that JSF is not on the classpath which the deployment
xml should fix.
My CODI bundle is currently in EAR/lib and it deploys successfully with
this configuration.
Am 19.03.2013 20:43, schrieb Adrian Gonzalez
the same setup ?
De : Christian Beikov
À : users@myfaces.apache.org
Envoyé le : Mardi 19 mars 2013 17h18
Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
Hey,
I had the same problem a time ago. Just add following
jboss-deployment-structure.xml into META
seListener
* class
org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecyclePhaseListener
Thanks for the help !
[1] Sample project here : https://github.com/gonzalad/codi-ear-viewaccessscoped
To reproduce it,
1. Testing the war
a. add the war on JBoss
b. http://localhost:8080/viewaccessscoped-web/test.faces
I say, bring it on. I'm currently using CODI 1.0.6 (very minimally) with
TomEE 1.5.2-SNAPSHOT and CDI beans. I haven't looked at the
issue/bug/new-feature list yet though. :)
On Wed, Jan 30, 2013 at 6:00 PM, Mark Struberg wrote:
> Hi folks!
>
> I'm tempted to relea
Hi folks!
I'm tempted to release a new version of CODI. There are a few bugs in the chain
which would be nice to ship.
If there is no objection, then I'd start with the release task sunday-ish...
txs and LieGrue,
strub
lared/produced?
Thanks
Denis
Le 2013-01-19 08:17, Mark Struberg a écrit :
Does anyone use CODI in such a way? in Glassfish or JBoss maybe? I think TomEE
uses a single classloader...
Yes, I use it that way. Well, we are not actually using a full EAR but a Tomcat
with catalina.sharedLoader set to we
> Does anyone use CODI in such a way? in Glassfish or JBoss maybe? I think
> TomEE
> uses a single classloader...
Yes, I use it that way. Well, we are not actually using a full EAR but a Tomcat
with catalina.sharedLoader set to webapps/lib. This means each WAR gets an own
WebAppCl
Just for test. Try to put codi dependencies in each webapp lib and not in
ear lib.
El 18/01/2013 02:07, "Thomas Herzog" escribió:
> Here I sent you our config:
>
> ** **
>
> **1. **application_xml_initilaize_in_order: we faced the iisue that
> codi wont
Take a look at this post. I googled a bit and it seems that all of the issues
got resolved by application classloader.
Maybe this helps you a little bit.
http://grokbase.com/p/myfaces/users/12cchrh53c/codi-codi-v1-0-5-websphere-v8-5-0-1-problem
https://www.ibm.com/developerworks/forums
way we found to have our apps working with CODI, PARENT_FIRSTx2 is ok for us as our
app is less complex (another way is to pack everything in WAR/WEB-INF/lib, codi and other dependents jar and the project EJB jars)
.
This...until I opened a PMR by IBM (PM80276 "CreationalContext Not Created
Here I sent you our config:
1. application_xml_initilaize_in_order: we faced the iisue that codi wont
start properly when the wars are not initialized in order.
2. application_xml_war_order: we ha to initiliaze the new war first
because it uses codi, jsf, cdi and so on.
3
policy
> module is supportet by cdi.
>
>
>
> Send via Samsung Galaxy S2titou10 titou10 hat
> geschrieben:- PARENT_FIRST on all classloaders: same here
> - In the very simple ear described before, we just have 1 war module
> and the codi jar in ear/lib. The application does
policy
> module is supportet by cdi.
>
>
>
> Send via Samsung Galaxy S2titou10 titou10 hat
> geschrieben:- PARENT_FIRST on all classloaders: same here
> - In the very simple ear described before, we just have 1 war module
> and the codi jar in ear/lib. The application does
the very simple ear described before, we just have 1 war module
and the codi jar in ear/lib. The application does not start. There is
no CNF or unsatisfied link exceptions. Just the NPE in
JsfRequestLifecycleBroadcaster due to "this.phaseEvent" being null.
Using "WAR classlo
- PARENT_FIRST on all classloaders: same here
- In the very simple ear described before, we just have 1 war module
and the codi jar in ear/lib. The application does not start. There is
no CNF or unsatisfied link exceptions. Just the NPE in
JsfRequestLifecycleBroadcaster due to "this.phase
We are working on was 8.0.0.1 and are using codi and deltaspike and we do have
the jars in ear lib.
We do have application classloader and parent first and works.
One problem was that tha modules must have manifest entries to their depended
modules.
E.g.: webmodule must have manifest entries
Hello,
I'm still experimenting with CODI and WebSphere v8.5.0.1 without success
Our "standard" ear deployements scheme is:
ear
- 1 ejb.jar module
- 1 war module
- lib
- 1 jpa.jar module
- dependent jar (like codi..)
WAS normally uses 2 levels of application class
inion, letting the controllers
access the db directly is no good idea. Why not put these data access
methods into your managers or so?
Because the EJB Container manage the transaction for us and SFSB are
the perfect construction for "stateful" data, assigned to one
"client". So
t these data access methods into your managers or so?
Because the EJB Container manage the transaction for us and SFSB are the perfect construction for "stateful" data, assigned to one
"client". So the controleur can acces many methods in different "managers" in the same
directly display in the presentation layer..
so you don't use "open session/entitymanager/connection in view" right? :D
Sean 2 automatically discard the SFSB when the conversation ends
Same for Codi conversation and the default CDI conversation, isn't it?
All our ap
-
*Christian Beikov*
Am 12.12.2012 22:39, schrieb Denis Forveille:
Bad news: In fact, in practice this does not work for us.
We are moving from seam 2/jsf1.2 to cdi/jsf2.0/codi and we use SLSB
(Stateless Session Beans) as JSF backing beans.
Those SLSB may be
s: In fact, in practice this does not work for us.
We are moving from seam 2/jsf1.2 to cdi/jsf2.0/codi and we use SLSB
(Stateless Session Beans) as JSF backing beans.
Those SLSB may be of scope "ViewScope" (= Seam 2 "PageScope") and need
to be injected at leats "FacesCont
Bad news: In fact, in practice this does not work for us.
We are moving from seam 2/jsf1.2 to cdi/jsf2.0/codi and we use SLSB
(Stateless Session Beans) as JSF backing beans.
Those SLSB may be of scope "ViewScope" (= Seam 2 "PageScope") and need
to be injected at leats &qu
I forgot to say that when I use the CDI @ConversationScoped standard
annotation, it works
The code fail if I use CODI @ConversationScoped annotation
Also If I remove the @Stateful annotation to use a plain POJO instead
of a SFSB, it works too..
2012/12/12 Denis Forveille :
> Hello,
> In Web
Thanks Thomas for the pointer
Yes it is a classloader problem
After lots of tries I finally managed to have it working
(FI our EAR projects are all split into a JPA module, an EJB module
and a WAR module)
How I did it:
- in ear/lib, define codi (api+impl) and message-module (api+impl)
- in web/WEB
We facwd the problem that codi and myfaces interffered together and myfaces
could not start.
We did the following, maybe it helps:
1. Manifest entry to codi in webapp.
2. codi placed in ear/lib or web-inf/lib
3. With two webapps in the application.xml 'start in order'
Websphere i
hi denis,
maybe rohit can provide further details.
regards,
gerhard
2012/12/10 Denis Forveille
> 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 rece
Mark Struberg writes:
> mail came through just fine
>
> LieGrue,
> strub
>
>>
>> From: "Howard W. Smith, Jr."
>>To: MyFaces Discussion ; Mark Struberg
>>
>>Sent: Wednesday, November 21, 2012 7:07 AM
>&g
I just created an application from scratch, and the problem went away.
Everything working fine for now.
Sorry for this wrong alert.
- Mail original -
De : Adrian Gonzalez
À : "users@myfaces.apache.org"
Cc :
Envoyé le : Mardi 4 décembre 2012 11h32
Objet : CODI ViewAc
h keep n Sessions in memory and
> if this number gets exceeded the LRU ones will get persisted to the file
> system. That way it's almost impossible to trash the Sessions in pure tomcat.
>
> I have no clue what GlassFish does to prevent this scenario, but this is for
>
1 - 100 of 517 matches
Mail list logo
