Most importantly: which JDK/JRE are you running WebLogic under? And which
weblogic version do you use?
You have definitely checked diskfree? (df -h) and mem is also no concern?
Are you running a 32 or 64 bit JVM?
Under 32 bit JVMs you could easily run out of available threads (the higher you
I´m having trouble bootstrapping the CODI environment. I´ve deployed
the 0.9.5 version of CODI on WebSphere 8 running open webbeans but as
the JSF runtime initializes I get this stack trace:
[2011-07-05 09:50:29:809 CEST] 000c ClassUtilsE
hi hampus,
it looks like they bootstrap jsf before cdi which doesn't make sense.
we have to talk with the websphere team.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
short addition:
we could do this specific part lazily. however, we would have to test if
there are additional initialization tasks which are affected.
it's possible to deactivate the navigation handler with the deactivation
concept described in the wiki.
as an alternative (just for testing), you
fyi: i talked with a member of the websphere team and it looks like it is a
known issue of the owb integration.
the next fixpack should fix it. however, if you have time for testing it,
you can try what i wrote in my previous answer.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
Hi
So I got further with enabling the
org.apache.webbeans.application.useJSF2Extensions property to true (it´s
false by default) but now I´ve got some really strange ClassNotFound
problems (javax.faces.beans.ViewScoped) but I guess that it´s not
related to CODI.
I think I´ll open a PMR with IBM
hi hampus,
ok - thx. it looks like they also have a classloader issue.
we could bypass that as well but that's a jsf-api class used by codi. so if
this one doesn't work, i guess others won't work as well.
if you would like to test it, you can deactivate ViewScopedExtension with
the same approach
It looks like they don´t set the contextclassloader to the web app
loader before they start it up. Now they use the OSGI classloaders which
seems to be loading stuff above the jee loader, hence the error. I think
that this is a common regression from release to release. We´ve seen
this before.
Hi again,
We´re currently using Spring WebFlow for JSF navigation but I´m a bit
concerned about the future of WebFlow and wonder how you would compare
it to CODI pages/navigation? I see the CODI stuff to be more of a
natural fit for JSF flow/navigation but as I currently lack a complete
hi hampus,
you can think about it like implicit navigation (introduced in jsf2) but in
a type-safe way based on the view-config concept.
view-configs allow to provide configs e.g. for security, a view
controller,... in a type-safe, extensible and easy way (you can e.g. inherit
configs like it's
What about subflows? If I´ve got a navigation flow could I then
incorporate another flow (packaged in a jar for example) as a reusable
navigation flow that could participate in the conversation?
regards,
Hampus
On Tue, 5 Jul 2011 15:59:38 +0200, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
the conversation concepts are different - you don't have to think about
special things like sub-flows or nested conversations because you get the
concept of parallel conversations.
+ conversations are decoupled from the type-safe navigation (you can use
both but you don't have to).
if you don't
Ok, sounds great. I´ll have to try this out.
Thanks!
Regards,
Hampus
On Tue, 5 Jul 2011 16:45:31 +0200, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
the conversation concepts are different - you don't have to think about
special things like sub-flows or nested conversations because you
I am using http://myfaces.apache.org/core20/index.html and
http://myfaces.apache.org/tomahawk-project/tomahawk20/tagdoc/t_selectOneRadio.html
.
I have used tomahawk t:selectOneRadio in my jsf page.
t:selectOneRadio id=myScript value=#{bean.myScript} layout=spread
f:selectItem itemLabel=
14 matches
Mail list logo
