Re: How to make submit button only work if connection is available?

o far. LieGrue, strub > Am 19.01.2020 um 17:32 schrieb Thomas Andraschko > : > > Hi, > > I never needed something similar but i would do it the same. > Maybe there are nicer ways, i would try to Google about it first. > > > Mark Struberg schrieb am So.,

How to make submit button only work if connection is available?

Hi folks! I'm right now designing a small only survey form with JSF-2.3. The problem is that the survey should gather information from a cellar. And often there is no WiFi nor mobile connection in those rooms. Thus it should not loose data if the user presses the 'Save' button and the

Re: MyFaces 2.2.10 and Red Hat EAP 6.4.8 issue with memory leak of @viewscope

x in EAP 6.1.1 (I believe) related to leaking viewscopes >but for some reason I think that fix was done on mojarra side, nothing was >changed in JBossWeb (as far as I know). > > >Regards, >Thony > > >On 5 September 2016 at 08:02, Mark Struberg <strub...@yahoo.de> wrote:

Re: MyFaces 2.2.10 and Red Hat EAP 6.4.8 issue with memory leak of @viewscope

Having glanced over the jboss code, I suspect they will have mem leaks with Mojarra as well. Maybe that helps. I know a few people from JBoss, will try to ping one of them. LieGrue, Strub > Am 01.09.2016 um 15:24 schrieb Leonardo Uribe : > > Hi > > I'm cc to MyFaces users

Re: myfaces 2.2 foe replace myfaces 2.1 into tomee

btw if you use the tomee-maven-plugin then you can automatically 'tune' the lib folders with something like this: build     plugins     plugin     groupIdorg.apache.openejb.maven/groupId    

Re: myfaces 2.2 foe replace myfaces 2.1 into tomee

the jars starting with this string. --- how i can put the jars dor tomme plugin using the GAV coordinates? 2014-02-13 18:44 GMT+01:00 Mark Struberg [via MyFaces] ml-node+s10567n117170...@n7.nabble.com: btw if you use the tomee-maven-plugin then you can

Re: Apache CODI x JEE7 Glassfish4

Struberg strub...@yahoo.de Sent: 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 strub...@yahoo.de wrote: The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB

Re: Apache CODI x JEE7 Glassfish4

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

Re: Apache CODI x JEE7 Glassfish4

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

Re: [OT but still JSF]: Clustering, session replication, and database, too

DB replication basically works with the transaction log (IBM DB/2 terminology, in Oracle it's called transfer tables). Each update/insert/delete statement gets written into a file and you can pick this file up from another node. This secondary node then does exactly the same like the first

Re: [OT but still JSF]: Clustering, session replication, and database, too

. smithh032...@gmail.com escribió: I had a question or two, since I have been reading Java Summit - Pitfalls in EE[1] provided by Mark Struberg while having a discussion on tomee user list. The following page stated the following: Page 134 Clustering * We use

Re: [OT but still JSF]: Clustering, session replication, and database, too

David Blevins or Mark Struberg say that they reverted to caching much of the data from database (in memory, on startup, I guess/assume) to improve performance, but i wonder if caching the data is really (really) necessary/recommended... [1] http://ha-jdbc.github.io/

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

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

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

Re: EXTCDI - Specializing ClientConfig with different WindowHandlerHtml leads to endless loop?

Hi Heiko! Does this also happen on Firefox or only on IE? And if so, which IE version exactly? LieGrue, strub - Original Message - From: it-media.k...@daimler.com it-media.k...@daimler.com To: users@myfaces.apache.org Cc: Sent: Friday, February 1, 2013 8:20 AM Subject: EXTCDI

Re: Re: EXTCDI - Specializing ClientConfig with different WindowHandlerHtml leads to endless loop?

Hi Heiko! I'll create a unit test for it and test it before we kick off the build for the release. LieGrue, strub - Original Message - From: it-media.k...@daimler.com it-media.k...@daimler.com To: users@myfaces.apache.org Cc: Sent: Friday, February 1, 2013 1:26 PM Subject: Re:

[DISCUSS] new CODI release?

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

Re: security with JSF app

Hi Jim! You could use JAAS and users.xml in tomcat, but I personally would not recommend it as all the classic EE based security is (imo) way too complicated to handle for what it provides. You can look at CODI @Secured with an own security Voter [1][2], which is very easy to implement

Re: [CODI] Does CODI supports to be deployed in a app server that uses multi-classloader for EARs (was: CODI jar in ear/lib with a WAR = fail in WebSphere v8.5)

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 WebAppClassloader and

Re: CODI: Exclude windowId from certain pages

session Regards On Fri, Nov 30, 2012 at 8:26 AM, Leonardo Uribe lu4...@gmail.com wrote: Anyway, you can only solve the question trying to reduce the param and see what happens. 500*64 is a big number. On Nov 30, 2012 2:20 AM, Mark Struberg strub...@yahoo.de wrote: No Leo, cannot

Re: CODI: Exclude windowId from certain pages

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

Re: Migration to TomEE/CODI: very strange AJAX issue during regression testing

+1 Howard, as most other stuff is now working, we can continue with getting back JUEL in place. But please file a tomcat issue for the EL stuff first! For TomEE it's as easy as for tomcat7. A long time ago I wrote up a description in our wiki [1] which is basically still true. There is also

Re: CODI BeanManagerProvider in @FacesConverter breaks PrimeFaces p:pickList p:ajax event=transfer

mail came through just  fine LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Wednesday, November 21, 2012 7:07 AM Subject: CODI BeanManagerProvider

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

well, that should do :) We are serving up to 40.000 users with now 5GB RAM. But mostly due to lots of caches in our app. Oh and we have 16 webapps. Each user getting their own session in each webapp... So really nothing to worry about. LieGrue, strub - Original Message - From:

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

@SessionScoped has the downside that you cannot open multiple browser tabs with different data. Think about having a list of Cars and then opening 2 different car-edit dialoges in new browser tabs. That would not work using @SessionScoped and is the reason why we invented @WindowScoped and

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

please move this question to the openejb list as this might be a TomEE issue. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Wednesday, November 21

Re: TomEE/OpenEJB (OpenWebBeans) with Apache MyFaces CODI

Hi Howard! CODI is a portable CDI _Extension_ and not a CDI container! CODI runs on Weld, OpenWebBeans, resin, Glassfish, TomEE, JBossAS, etc LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Cc:

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

you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces

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

://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

Re: Migrating to CDI: @Asynchronous

Hi! One of my first advice is to make sure that beans.xml is really there for the container. I've seen this pretty often if someone starts the webapp directly from Eclipse. In that case the CDI container sometimes cannot find WEB-INF/beans.xml as eclipse doesn't set the classpath entries

Re: Migrating to CDI: @Asynchronous

oh, if you are using OpenEJB/TomEE/ other EE server then you can also use @Timeout in an EJB instead of Quartz. LieGrue, strub - Original Message - From: Mark Struberg strub...@yahoo.de To: MyFaces Discussion users@myfaces.apache.org; us...@openejb.apache.org us

Re: Migrating to CDI: @Asynchronous

. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: us...@openejb.apache.org us...@openejb.apache.org Sent: Tuesday, November 20, 2012 3:56 PM Subject: Re: Migrating to CDI: @Asynchronous Mark, Cool beans and agreed about @Asynchronous! Since

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

-, SessionScoped, CODI scopes) then you only need to do this once as you only get a proxy anyway. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Tuesday, November 20

Re: Can start in debug, but not in release

The Hibernate serialisation issues look weird. What is your exact situation? Do you have an example of your app to share? LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Sent: Tuesday,

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

Hi Howard! JUEL is an Expression Language implementation. It has nothing to do with CDI apart from CDI providing an ELResolver. JUEL is much faster than the EL interpreter in glassfish, so this is fine. For your beans getting recognized in EL expressions: 1.) Do you have a

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

, as a last-and-final option. :) On Sat, Nov 17, 2012 at 5:04 AM, Mark Struberg strub...@yahoo.de wrote: Hi Howard! JUEL is an Expression Language implementation. It has nothing to do with CDI apart from CDI providing an ELResolver. JUEL is much faster than the EL interpreter in glassfish, so

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

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

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

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

Re: Non existing views are rendered and throw an exception instead of 404 with myfaces 2.1.9

Hi! Please add your findings to https://issues.apache.org/jira/browse/MYFACES-3638 txs and LieGrue, strub From: Marcus Büttner buettner.mar...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Sent: Tuesday, November 13, 2012 5:50 PM Subject: Non

Re: [EXT-CDI] - ClientSideWindowHandler - Nag-Screen on every 'faces-redirect=true'.

Hi Heiko! Yes, this is perfectly possible @SessionScoped @Specializes public class YourClientConfig extends ClientConfig implements Serializable {   @Overrides   public boolean isClientSideWindowHandlerRequest(FacesContext facesContext) {     return false; // or implement your own logic based

a small CDI related survey

Hi folks! I have a slightly offtopic survey for you. The question is how the current @ApplicationScoped in CDI should behave. Should it be 1 instance per WAR or 1 instance per EAR? To make this more clear: in CDI-1.1 we will have both scopes at the end. Please also note that any scope broader

Re: Setting CODI project stage

Hi Ludovic! I'm using -Dfaces.PROJECT_STAGE=Development which works perfectly. In production we have set it via JNDI in tomcats conf/context.xml:     Environment name=jsf/ProjectStage value=SystemTest   type=java.lang.String override=false/ LieGrue, strub - Original Message

Re: MyFaces CODI within EAR

, Christian Am 06.09.2012 22:29, schrieb Mark Struberg: Hi christian! Yes, this is perfectly possible. You just have to move all your JSF deps which are needed by CODI to a shared jar  (in an EAR lib). myfaces-api.jar myfaces-impl.jar, el, etc. All the stuff which is (transitively) required

Re: MyFaces CODI within EAR

Hi christian! Yes, this is perfectly possible. You just have to move all your JSF deps which are needed by CODI to a shared jar  (in an EAR lib). myfaces-api.jar myfaces-impl.jar, el, etc. All the stuff which is (transitively) required on the classpath. I have this scenario running over here

Re: CODI Page

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

Re: Conversation Scope in JSF 2.0

Hi! I've not used weblogic 10.x in my projects so far, but Gerhard might know more about it. I would say that there are 2 areas which must get clarified: a.) is OWB fine storing the @SessionScoped beans in the http session at the end of the request? I think this works fine if you enable the

Re: Conversation Scope in JSF 2.0

Hi! All the CDI @ConversationScoped gets stored in a @SessionScoped bean managed by the CDI container. Finally this will somewhen end up in the session (the 'when' is implementation specific). LieGrue, strub - Original Message - From: tclam tc...@hkeaa.edu.hk To:

Re: Conversation Scope in JSF 2.0

The context for handling all CODI @ConversationScoped beans ALREADY get stored in a @SessionScoped bean. Thus it will end up in the Session somehow. But this is impl and situation depending! In OWB we do NOT store @SessionScoped beans directly in the Session, because the http session is _damn_

Re: Conversation Scope in JSF 2.0

Because of that, we're now in the process of switching to CODI that it's fully serializable, and allows the session to be persisted/distributed. Yes, but please be aware that the EntityManager is still NOT Serializable! Even if some JPA providers claim it, they will loose state on

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

Re: [CODI] ViewAccessScoped beans without windowId in URL

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.

Re: no parallel ajax requests anymore with JSF 2.1?

Not having the request/view token properly updated in a sequential way would also make it impossible to properly do cross request state forgery prevention. LieGrue, strub - Original Message - From: Werner Punz werner.p...@gmail.com To: users@myfaces.apache.org Cc: Sent: Monday,

Re: Problem with CODI/OWB and PrimeFaces 3.2

If you like to use EL-2.2 then you should switch to tomcat7-maven-plugin instead of using jetty. With jetty6 you need to exclude quite a few jetty dependencies from your plugin to prevent clashes. Jetty7 and 8 have been behaved completely broken at all. We now completely switched away to

Re: Problem with CODI/OWB and PrimeFaces 3.2

whoops, tomcat7-maven-plugin of course^^ LieGrue, strub - Original Message - From: Mark Struberg strub...@yahoo.de To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, April 17, 2012 2:40 PM Subject: Re: Problem with CODI/OWB and PrimeFaces 3.2 If you like

Re: Ajax update of a composite component within ui:repeat doesn't work

Hi Leo! Did you also try the stuff with composite components inside ui:repeat? Default components seem to work, but composite components are probably broken. Buett will upload a sample code later today. LieGrue, strub - Original Message - From: Leonardo Uribe lu4...@gmail.com To:

Re: problem compatibility Myfaces/Spring

We'd need the full stack trace. But I don't think it is a MyFaces version related issue... LieGrue, strub - Original Message - From: ayouB __ ayb-2...@hotmail.fr To: users@myfaces.apache.org Cc: Sent: Friday, April 13, 2012 1:54 PM Subject: RE: problem compatibility

Re: Problem with CODI/OWB and PrimeFaces 3.2

Hi! I think the origin of the problem is easy to fix. OpenWebBeans is built in a modular fashion. Unlike lots of other EE6 projects MyFaces and OWB also try to stay backward compatible with older spec variants. But you have to enable this backward compat mode manually because this

Re: OWB Decorators

Hi Christian! It is better we move this one over to the openwebbeans-dev list. LieGrue, strub - Original Message - From: Christian Beikov c.bei...@curecomp.com To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Monday, April 2, 2012 6:46 PM Subject: OWB Decorators

Re: MyFaces and CODI

and Courses in English and German Professional Support for Apache MyFaces 2012/3/9 Mark Struberg strub...@yahoo.de Hi Stephen! Well, the current approach in CODI is currently under discussion

Re: MyFaces and CODI

- Original Message - From: Mark Struberg strub...@yahoo.de To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Sunday, March 18, 2012 7:42 PM Subject: Re: MyFaces and CODI when i find out what's causing my bean to be instantiated on every ajax call i'll come back here to report

Re: MyFaces and CODI

don't think that it is such a basic 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/3/18 Mark Struberg strub...@yahoo.de Gerhard pinged

Re: MyFaces and CODI

and Courses in English and German Professional Support for Apache MyFaces 2012/3/18 Mark Struberg strub...@yahoo.de Gerhard pinged me that you are using @ViewAccessScoped. In that case I'd recomment to debug if the whole Context Extension gets properly registrated. If the CDI

Re: [CODI] ThreadScoped / EntityManager in a new Thread

Hi Thomas! Well, we had this problem as well in a Quartz scheduler Extension. And this did lead to the CdiControl approach implemented in OpenWebBeans Test and now moved to DeltaSpike cdise [1]. Please note that this is not yet finished, but will be soon! The functionality is currently in one

Re: [CODI] ThreadScoped / EntityManager in a new Thread

using a @TransactionScoped EM is possible, but if you already have all your Services using a @RequestScoped EM, then you will not come far... LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Cc:

Re: how to build a JSF 2.0 (MyFaces/Facelets) Project

Best is to use Maven. $ mvn archetype:generate -DarchetypeGroupId=org.apache.myfaces.buildtools -DarchetypeArtifactId=myfaces-archetype-helloworld20-owb LieGrue, strub - Original Message - From: ayouB __ ayb-2...@hotmail.fr To: users@myfaces.apache.org Cc: Sent: Wednesday,

Re: JSF 1.2: #{object.class.name} not allowed

Might be permitted due to security reasons? Just a guess... LieGrue, strub - Original Message - From: Milo van der Zee m...@vanderzee.org To: users@myfaces.apache.org Cc: Sent: Saturday, March 10, 2012 8:12 AM Subject: Re: JSF 1.2: #{object.class.name} not allowed Strange

Re: MyFaces and CODI

Hi Stephen! Well, the current approach in CODI is currently under discussion in the JSF EG. The whole windowId stuff of CODI might end up in the JSF-2.2 or 2.3 spec.  T hat seems to work fine when pasting into a new empty window, but it still allows you to copy-paste the url from one codi

Re: CODI+OWB+Scheduler, ContextNotActiveException

In fact, asynchronous tasks should not even rely on @SessionScoped or @RequestScoped because they do not exist outside a servlet request ;) LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Cc:

Re: CODI+OWB+Scheduler, ContextNotActiveException

Hi Manuel! Asynchronous Servlet requests are a bit different than manually forking a new Thread. Neither OWB nor Weld use asyncSupported atm. The CDI EG is already discussing this feature and I guess we will add official support for it in CDI-1.1. LieGrue, strub - Original Message

Re: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

Hi! the short answer is: no - it was never intended to support it. +1 To add a bit more info. This is not even intended/supported by JSF. You would need to hit the server for each and every css, img, js, etc served as resource. No caching on the browser side would be possible! By default all

Re: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

://cwiki.apache.org/MYFACES/myfaces-commons-resourcehandler.html - Original Message - From: Carlson, John W. carlso...@llnl.gov To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: Java Programmers List j...@llnl.gov Sent: Thursday, February 16, 2012 10:36 PM

Re: Skip the Validation Phase of JSF with ExtVal

Hi! Something I did sometimes is to use an explicit request parameter combined with f:validateBean : f:validateBean disabled=#{!empty param['check']}   your stuff and the button looks like the following: h:commandButton id=personAddBtn action=#{searchForm.startSearch()}

Re: Getting Spring beans from CODI bean

Hi! Check out the CDISource project https://github.com/cdisource It allows to @Inject CDI beans into Spring beans and the other way around. LieGrue, strub - Original Message - From: Jiayun jia...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Thursday,

Re: Weird PlexusContainer object in ViewRoot

MyFaces is faster, but I didn't think that Mojarra is so slow ^^. Our fat pages (~2000 lines in a complex h:dataTable - more than 300.000 ELResolver invocations) use to take up to 350ms. Small pages render in 17ms on our Server with OWB and MyFaces. I once tested the fat pages with Glassfish

Re: CODI on WebLogic 12c

yup, looks like the modularity bug Glassfish had as well. This got fixed by a new Weld version + some hacks in the integration code. For Glassfish it works if you unpack all your CDI dependencies to WEB-INF/classes and merge all the beans.xmls into WEB-INF/beans.xml LieGrue, strub -

Re: How to troubleshoot ViewExpiredException ?

Another problem can be when being on a Cluster, having ServerSideStateSaving enabled and session affinity and/or propagation doesn't work properly. Because the ViewState is stored in the Session in this case... LieGrue, strub - Original Message - From: Werner Punz

Re: JVM optimized memory setting for server

and please don't give more than 1,6 GB if using a 32 bit JVM! The more ram you give, the less threads you can spawn on 32 bit JVMs! This was so bad, that we couldn't even get 100 parallel threads when going near 1.8GB ;) I hope not many people need to deal with this stuff nowadays anymore though

Re: JSF2: Behavior change for ui:params

this is a pretty common problem. How does Mojarra (as RI) behave in such situations? LieGrue, strub - Original Message - From: Leonardo Uribe lu4...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Thursday, December 15, 2011 6:15 PM Subject: Re: JSF2:

Re: @Inject'ed protected base class member access problem

+1 It seems the Weld version shipping with Glassfish has quite a few problems with any 3-rd party scopes. Not only with CODI but generally with other non-spec scopes as well. E.g. a colleague experienced a complete crash when intercepting 3-rd party scoped beans. Not sure if this still applies

Re: CODI - turn off startup config logging?

In glassfish the best solution is to just use mvn dependency:unpack-dependencies into your target/classes before building the war. Then exclude all jars from WEB-INF/lib. See https://issues.jboss.org/browse/CDI-18 and other issues with BDAs. LieGrue, strub - Original Message -

Re: IBM RAD with JUnit and AbstractCdiAwareTest

Hi Christian! Since you added all WebSphere-8.0 libs you don't need the openwebbeans-* jars (WS includes them already). Btw, the myfaces-extcdi-test was developed to perform quick standalone tests. For testing a full EE server you might better use Arquillian. I'm not sure if there is

Re: IBM RAD with JUnit and AbstractCdiAwareTest

, Christian Am 24.11.2011 13:17, schrieb Mark Struberg: Hi Christian! Since you added all WebSphere-8.0 libs you don't need the openwebbeans-* jars (WS includes them already). Btw, the myfaces-extcdi-test was developed to perform quick standalone tests. For testing a full EE server you

Re: OWB Decorator problem

hi Christian! guess this was meant for u...@openwebbeans.apache.org? :) LieGrue, strub - Original Message - From: Christian Beikov christian.bei...@gmail.com To: users@myfaces.apache.org Cc: Sent: Monday, November 7, 2011 7:16 PM Subject: OWB Decorator problem Hello there!

Re: Warning with CODI and MyFaces

hi Thomas! Which CODI version are you using and which server environment (OWB or Weld)? Is there any example project to reproduce this issue? LieGrue, strub - Original Message - From: Thomas Andraschko zoi...@googlemail.com To: MyFaces Discussion users@myfaces.apache.org Cc:

Re: My Faces Tunning

- Set the NUMBER_OF_VIEWS_IN SESSION to 1 if your app does not support the browser back button! And once a user opens another browser tab all will crash :( The missing windowId support is really a pitty in the JSF spec, and we currently think hard about how to solve this (at least in

Re: My Faces Tunning

+1 mem is barely a problem these days. Actually we are serving 60.000++ users per day without any mem problems (w 100 views/session ServerSide-StateSaving). We need some low GB mem on our 48GB RAM server... Even if you have 1MB of session mem per user then you can serve tons of users.

RE: codi and webservices

Hi Pieter! This is more a CDI container question than a CODI question :) From the stacktrace you posted in an older post I saw that you are using Apache OpenWebBeans, right? good decision btw :D Since I know a little bit about OWB, I'll try to explain ;) Basically any Servlet inside your

Re: codi and webservices

the BeanManagerProvider and things are working well. I reckon I will have the same issue with regards to jms, when I get round to putting hornetq or ApacheMq into Jetty? Thanks Pieter On 09/07/2011 11:32, Mark Struberg wrote: Hi Pieter! This is more a CDI container question than a CODI question

Re: @Disposes and webapp shutdown and @Singleton/@ApplicationScope

Hi! Please note that javax.inject.Singleton is completely underspecified! I suggest to not use it at all ;) LieGrue, strub --- On Fri, 7/8/11, Gerhard Petracek gerhard.petra...@gmail.com wrote: From: Gerhard Petracek gerhard.petra...@gmail.com Subject: Re: @Disposes and webapp shutdown and

Re: MyFaces - Thread issues under High load

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

Re: @ViewAccessScoped PreDestroy

Just for making this clear: we do _not_ suggest to use a plain a href...! Please use h:outputLink instead (since JSF-2. This will render a a href for you but will also manage all the view params if you like, etc. You can also add f:param children to pass parameters without having to do some

Re: [FYI] testing CODI and Seam3 with glassfish

://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast * See you at JAX and JSF Summit 2011 June 20-23rd in San Jose: http://jaxconf.com/ On Sat, May 28, 2011 at 4:04 PM, arungupta arun.gu...@gmail.com wrote: Hi Mark, struberg wrote: The result

[FYI] testing CODI and Seam3 with glassfish

Hi folks! Since we got _lots_ of CODI bug reports recently in this area, I spent the afternoon with testing a few CDI projects with glassfish-3.1. Not only CODI but also Seam3 and a few private JSR-299 Extensions. The result: Please skip glassfish-3.1 ! It's really completely broken. It has

Re: AW: CODI @ViewAccessScoped not cleaned up?

I'm not really conviced that we should implement workarounds for such clearly broken weld issues. Thomas, did you already file a bug report in Weld marking this as blocker? Really, we should at least link to them in our sources (+jira) and asap get rid of this workaround in OUR source again.

Re: AW: CODI @ViewAccessScoped not cleaned up?

more weld bugs which are more important. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/5/21 Mark Struberg strub...@yahoo.de I'm not really conviced that we

Re: all-in-one dist package

Hi! This is due to a bug in the maven-shade-plugin. We will work on that but it's low prio atm. Please refer to the to the single package JavaDocs instead. And of course, if you have further questions, then just ping us back on this mailing list. We are happy about every feedback! LieGrue,

Re: Problem with @PageBean

Hi Robert! First, welcome to the myfaces list! Have you already tried to replace your weld-osgi-bundle in your glassfish with the on from the weld-1.1.1.Final distribution [1]? LieGrue, strub [1]

Re: JSF application very slow with HTTPS

I'm using jetty-6.1.22 for such things. LieGrue, strub --- On Mon, 4/11/11, Michael Heinen mhn4...@googlemail.com wrote: From: Michael Heinen mhn4...@googlemail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussion users@myfaces.apache.org Date: Monday, April 11,

Re: JSF application very slow with HTTPS

Btw another question: 1s local response time? How fat is this page? We have a really big page in production with 1400 lines in a dataTable - and it renders in 450 ms... How many back-and-forth requests do you see if you open firebug? Do you have some EL involved which isn't hitting the backing

Re: JSF application very slow with HTTPS

Oh yes, another probably useful info: whenever https is involved via http doing lots of subsequent resource requests, then make sure that SSL session wont get closed! This really drastically drops the performance if the SSL handshaking always needs to re-negotiated over and over again...

  1   2   >