AW: [jira] Created: (EXTCDI-57) revisit Conversation#end
+1 for #1 Yes, is is obvious that close() closes immediately. Ciao, Mario Von: Gerhard [mailto:gerhard.petra...@gmail.com] Gesendet: Samstag, 18. September 2010 17:52 An: MyFaces Development Betreff: Re: [jira] Created: (EXTCDI-57) revisit Conversation#end +1 for #1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/9/18 Gerhard Petracek (JIRA) dev@myfaces.apache.org revisit Conversation#end Key: EXTCDI-57 URL: https://issues.apache.org/jira/browse/EXTCDI-57 Project: MyFaces CODI Issue Type: Task Components: JEE-JSF12-Module, JEE-JSF20-Module Reporter: Gerhard Petracek we should think about the naming of this important api, because std. cdi conversations offer the same method. codi conversations are very similar to orchestra conversations. in orchestra #end means that the conversation gets terminated immediately. currently we have the same with codi conversations. if we would like to add an additional api which terminates the conversation after the rendering process (= behavior of std. cdi conversations), we would have to introduce a name which might confuse users. we have the following options: #1: renaming #end to #close - it's more clear to users that it works differently (compared to std. cdi conversations). so we still have #end if we add an additional api for terminating the conversation at the end of the request. if we won't introduce the additional api, we still have a method which indicates that the termination process works differently compared to std. cdi conversations. the only disadvantage is that it isn't intuitive for users who used orchestra. #2: keeping the current api (#end) for terminating the conversation immediately. so we will need a name for an api which ends the conversation after the rendering process. (we could use #close. but then we have #end which works differently (compared to std. cdi conversations) and #close also doesn't really express the difference (and other names might sound strange). so we might end up with confused users.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (ORCHESTRA-42) Unresolved dependency of org.apache.commons.el.Logger
[ https://issues.apache.org/jira/browse/ORCHESTRA-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845215#action_12845215 ] Mario Ivankovits commented on ORCHESTRA-42: --- Hmmm ... The shared_* packages are generated out of the common myfaces shared stuff. So, this needs to be fixed in myfaces - if this can be fixed at all. I'll move this issue. Unresolved dependency of org.apache.commons.el.Logger - Key: ORCHESTRA-42 URL: https://issues.apache.org/jira/browse/ORCHESTRA-42 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.3.1 Environment: Deploying to Glassfish v2 Reporter: Bart Kummel Priority: Minor When deploying an application that uses Orchestra Core 1.3.1, I get a ClassNotFoundException on org.apache.commons.el.Logger. The work around is of course to manually download Apache Commons EL and add is as a dependency. The solution to this bug can be: - removing the dependency - mentioning the dependency in the docs. Stack trace: java.lang.NoClassDefFoundError: org/apache/commons/el/Logger at org.apache.myfaces.shared_orchestra.util.ClassUtils.clinit(ClassUtils.java:44) at org.apache.myfaces.orchestra.annotation.spring.AnnotationsInfoInitializer.postProcessBeanFactory(AnnotationsInfoInitializer.java:93) at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:553) at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:536) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:362) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4523) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5184) at com.sun.enterprise.web.WebModule.start(WebModule.java:326) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222) at com.sun.enterprise.web.WebContainer.loadJ2EEApplicationWebModules(WebContainer.java:1147) at com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:141) at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244) at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336) at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210) at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645) at com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:928) at com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:912) at com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:461) at com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176) at com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308) at com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226) at com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298) at com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132) at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108) at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:276) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:294
[jira] Commented: (MYFACES-2604) Unresolved dependency of org.apache.commons.el.Logger
[ https://issues.apache.org/jira/browse/MYFACES-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845216#action_12845216 ] Mario Ivankovits commented on MYFACES-2604: --- Could someone of the MyFaces masters please have a look at it. Thanks! :-) Unresolved dependency of org.apache.commons.el.Logger - Key: MYFACES-2604 URL: https://issues.apache.org/jira/browse/MYFACES-2604 Project: MyFaces Core Issue Type: Bug Environment: Deploying to Glassfish v2 Reporter: Bart Kummel Priority: Minor When deploying an application that uses Orchestra Core 1.3.1, I get a ClassNotFoundException on org.apache.commons.el.Logger. The work around is of course to manually download Apache Commons EL and add is as a dependency. The solution to this bug can be: - removing the dependency - mentioning the dependency in the docs. Stack trace: java.lang.NoClassDefFoundError: org/apache/commons/el/Logger at org.apache.myfaces.shared_orchestra.util.ClassUtils.clinit(ClassUtils.java:44) at org.apache.myfaces.orchestra.annotation.spring.AnnotationsInfoInitializer.postProcessBeanFactory(AnnotationsInfoInitializer.java:93) at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:553) at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:536) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:362) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4523) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5184) at com.sun.enterprise.web.WebModule.start(WebModule.java:326) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222) at com.sun.enterprise.web.WebContainer.loadJ2EEApplicationWebModules(WebContainer.java:1147) at com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:141) at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244) at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336) at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210) at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645) at com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:928) at com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:912) at com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:461) at com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176) at com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308) at com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226) at com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298) at com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132) at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108) at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:276) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:294) at com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.deploy(ApplicationsConfigMBean.java:555) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method
RE: Google SoC
Hi! - Extend Orchestra use Conversations based on the JSF 2.0 custom scope API, Extend Orchestra to work with Spring Conversations, to do File-New Window Handling Any idea how this should work? What magic is Spring Conversations using here? Ciao, Mario
RE: Google SoC
Hi! From: Leonardo Uribe [mailto:lu4...@gmail.com] Sent: Tuesday, March 09, 2010 7:54 PM To: MyFaces Development Subject: Re: Google SoC - Extend Orchestra use Conversations based on the JSF 2.0 custom scope API, Extend Orchestra to work with Spring Conversations, to do File-New Window Handling I was thinking based on a suggestion done on JSFDays to take advantage on trinidad pageFlowScope code (like we did with flash scope on myfaces 2.0), and refactor that code to allow orchestra conversation scope work without spring (using the new JSF 2.0 custom scope). [Mario Ivankovits] Orchestra without Spring, that surely would be great. One thing to keep in mind is that we need AOP or at least proxying to inject the current conversation into the bean. Not too complicated, though. But what does this have to do with trinidad's pageFlowScope? If we leave the EntityManager thing out of line, we just need a JSF 2.0 scope impl and the proxying/interception stuff which is handled by Spring currently. Ciao, Mario
AW: [VOTE] codi as a new myfaces extensions sub-project
+1 Von: gerhard.petra...@gmail.com [mailto:gerhard.petra...@gmail.com] Im Auftrag von Gerhard Petracek Gesendet: Dienstag, 16. Februar 2010 12:01 An: MyFaces Development Betreff: [VOTE] codi as a new myfaces extensions sub-project hi @ all, we have collected a lot of possible features for ext-cdi/codi and we have several people who are interested in working on it [1]. so we should vote about the new module officially. --- [ ] +1 for: codi should become a myfaces extensions sub-project [ ] +0 [ ] -1 for: codi shouldn't become a myfaces extensions sub-project --- the module should be hosted at [2]. i think we have a clear winner for the name: MyFaces CODI (svn and jira will use (ext-)cdi to be consistent with the other extension modules.) regards, gerhard [1] http://wiki.apache.org/myfaces/Extensions/CDI/DevDoc/Drafts [2] http://svn.apache.org/repos/asf/myfaces/extensions/cdi/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces smime.p7s Description: S/MIME cryptographic signature
AW: [ANNOUNCE] release of myfaces orchestra 1.4
Great to see a new release!! :-) Thanks Leonardo! Von: Leonardo Uribe [mailto:lu4...@gmail.com] Gesendet: Samstag, 19. Dezember 2009 01:09 An: annou...@apache.org; annou...@myfaces.apache.org Cc: MyFaces Development; MyFaces Discussion Betreff: [ANNOUNCE] release of myfaces orchestra 1.4 The Apache MyFaces team is pleased to announce the release of Apache MyFaces Orchestra Core 1.4 This release add support for portlets and new modules for compile orchestra with jsf 1.2 and 2.0 implementations. Also, orchestra core15 was merged in orchestra core module, because JDK 1.4 has reached its End of Life. Get a full overview at Orchestra's homepage [1]. The release notes for 1.4 can be found here: * http://svn.apache.org/repos/asf/myfaces/orchestra/tags/core-1_4/RELEASE-NOTE S.txt The distribution is available at * http://myfaces.apache.org/orchestra/download.html Apache MyFaces Orchestra is available in the central Maven repository under Group ID org.apache.myfaces.orchestra. Regards, Leonardo Uribe [1] http://myfaces.apache.org/orchestra smime.p7s Description: S/MIME cryptographic signature
RE: [orchestra] could we do a release of this artifacts?
As far as I know, a release should be fine! Ciao, Mario Von: Leonardo Uribe [mailto:lu4...@gmail.com] Gesendet: Dienstag, 01. Dezember 2009 23:46 An: MyFaces Development Betreff: [orchestra] could we do a release of this artifacts? Hi I would like to add a module for orchestra and jsf 2.0 and do a release of orchestra in the next days. Is any special step required to do it? or there is some issue that needs to be solved before release it? regards, Leonardo Uribe smime.p7s Description: S/MIME cryptographic signature
RE: [orchestra] latest code in core project is not JDK 1.4 compatible
Hi! Even if you advertised at the beginning, I too think that JDK 1.4 compatibility is no longer a must. Merging core15 might then be the logical step. Are you going to volunteer? ;-) Ciao, Mario Von: Leonardo Uribe [mailto:lu4...@gmail.com] Gesendet: Mittwoch, 14. Oktober 2009 01:21 An: MyFaces Development Betreff: [orchestra] latest code in core project is not JDK 1.4 compatible Hi Checking some stuff in orchestra, I have seen that some code in core project is not JDK 1.4 compatible. The question is given JDK 1.4 has reached its end of service life, shouldn't we move forward and make orchestra JDK 1.5 and upper compatible? That means also merge core15 code with core. Note that if this is not true, we have to change/revert some code already committed to make it JDK 1.4 compatible (for example, do not make the call to ThreadLocal.remove() on FrameworkAdapter). regards Leonardo Uribe
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763854#action_12763854 ] Mario Ivankovits commented on ORCHESTRA-40: --- I think we all agree, having a decent handling for this thing is a long missing feature here in JSF land. I also agree that it is much more a virulent problem when you use a conversation framework as it is much likely that you run into problems with the database else. The question is if we need it strongly integrated into Orchestra. I've looked at the patch, and beside that something gets stored into the conversationContext I can not see anything which can not be solved using normal JSF phase listeners. And for storing into the conversationContext we can create a scope which does this (instead of accessing it directly). You also gain the ability to decide on which level the tokens are kept. If you do not use Orchestra you simply can the manager bean into the session then. I'd say this component qualifies for its own project, e.g. within our ext (sorry, lost the name) project. On the other hand, I understand that - compared to seam and webflow - people await such functionality from Orchestra too. If we add this to Orchestra, I'd like to see it in a separated module, e.g. orchestra-jsfext. Would this be feasible? As for the technical aspect of this patch, I have some notes: 1) Does this solution work with ajax, or will an ajax request trigger a DOUBLE_SUBMIT_OR_RELOAD_TYPE notification? I think ajax detection needs to be added, at least to detect JSF 2.0 alike ajax requests. 2) I see you store the token in the request parameter. Probably - in the context of ajax - storing it as attribute on the UIViewRoot might be better. If you have to deal with ajax requests you are able to update this value then with the new token. I am also constantly thinking about moving the conversationContext paramter into the UIViewRoot - but this is another story. 3) We should also add a default TransactionTokenListener which behaves in a way we think an application should react on these events.People than can use it to jump start the system. Probably something like MyTransactionTokenListener with a faces message added so the user will get some feedback. 4) I'd like to have a way to ignore some requests. E.g. if you issue an jsf action which will just stream a PDF to the user (without page change), the browser stay on the page, but the token has been used then. The current token needs to be added to the list of used tokens at the end of the request then. Probably an API like TransactionTokenManager.getInstance().ignoreRequest() suppress this addittion then for the current request. The token can then be used again. Also trinidad has at least two components which open a window and just report the value back to the main window. Probably we also need a way to ignore requests based on an URL pattern to deal with that? Ciao, Mario A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The transaction token is to be used for enforcing a single request for a particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [VOTE] use of jul or commons logging on myfaces core 2.0
IMHO configuring the logger has to be solved by the used container. Ciao, Mario Von: Simon Lessard [mailto:simon.lessar...@gmail.com] Gesendet: Donnerstag, 01. Oktober 2009 16:57 An: MyFaces Development Betreff: Re: [VOTE] use of jul or commons logging on myfaces core 2.0 +1 for jul. However, I think we should add an utility class (ServletContextListnener? This is the easiest way I know of, if it qualifies for easiest at all) in myfaces-shared or extension to make it easier to configure the logger because it's way more annoying to configure than commons-logging backed with log4j imho. Regards, ~ Simon On Thu, Oct 1, 2009 at 1:25 AM, Mario Ivankovits ma...@ops.co.atmailto:ma...@ops.co.at wrote: +1 for jul reduces dependencies - and sun also use it, no? Von: Leonardo Uribe [mailto:lu4...@gmail.commailto:lu4...@gmail.com] Gesendet: Donnerstag, 01. Oktober 2009 04:06 An: MyFaces Development Betreff: [VOTE] use of jul or commons logging on myfaces core 2.0 Hi Right now, facelets code added to myfaces core 2.0.x branch uses jul in this form: protected final static Logger log = Logger.getLogger(facelets.viewhandler); But the original myfaces code uses commons logging, (so if there is no agreement about use jul, we should unify logging code using commons-logging). It is necessary to unify in one way or another the code of 2.0.x branch, but before that, it is necessary to ask the community about this issue. So, please vote in this way: +1 for jul +1 for commons-logging +0 -1 and let the code as is (and a reason why). regards, Leonardo Uribe
RE: [VOTE] use of jul or commons logging on myfaces core 2.0
+1 for jul reduces dependencies - and sun also use it, no? Von: Leonardo Uribe [mailto:lu4...@gmail.com] Gesendet: Donnerstag, 01. Oktober 2009 04:06 An: MyFaces Development Betreff: [VOTE] use of jul or commons logging on myfaces core 2.0 Hi Right now, facelets code added to myfaces core 2.0.x branch uses jul in this form: protected final static Logger log = Logger.getLogger(facelets.viewhandler); But the original myfaces code uses commons logging, (so if there is no agreement about use jul, we should unify logging code using commons-logging). It is necessary to unify in one way or another the code of 2.0.x branch, but before that, it is necessary to ask the community about this issue. So, please vote in this way: +1 for jul +1 for commons-logging +0 -1 and let the code as is (and a reason why). regards, Leonardo Uribe
[jira] Commented: (ORCHESTRA-43) IllegalStateException on application startup when using conversations with beans that implement ApplicationListener
[ https://issues.apache.org/jira/browse/ORCHESTRA-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12735612#action_12735612 ] Mario Ivankovits commented on ORCHESTRA-43: --- Does it makes sense to have a conversation scoped bean implementing the ApplicationListener? I'd suggest to make a separate bean for the ApplicationListener use case, and then, inject that bean (I assume you need some informations from this event) into the conversation scoped bean. Starting a conversation from within an application-start-event is not possible. IllegalStateException on application startup when using conversations with beans that implement ApplicationListener --- Key: ORCHESTRA-43 URL: https://issues.apache.org/jira/browse/ORCHESTRA-43 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.3.1 Environment: Spring 2.5.6 Reporter: Jose Luis Freire Priority: Critical If we have a bean with conversation scope that implements ApplicationListener, on application startup we get a java.lang.IllegalStateException: FrameworkAdapter not found. This happens because a application start event is fired and at that time no HTTP session is in progress. The stack trace is: java.lang.IllegalStateException: FrameworkAdapter not found at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:120) at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:96) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.getRealBean(AbstractSpringOrchestraScope.java:330) at org.apache.myfaces.orchestra.conversation.spring.ScopedBeanTargetSource.getTarget(ScopedBeanTargetSource.java:73) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:666) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:616) at com.vianobis.campaign.web.activity.ActivityListBackend$$EnhancerByCGLIB$$975174a6.onApplicationEvent(generated) at org.springframework.context.event.SimpleApplicationEventMulticaster$1.run(SimpleApplicationEventMulticaster.java:78) at org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:76) at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:274) at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:736) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:383) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
AW: Shale Annotations
Hmmm … it might be worth looking at using Orchestra without Spring. Guice is not an option for your clients either, is it? If you do not use Spring, you also do not use its persistence capabilities ;-) So then, using a CGLIB based (or whatever enhancer lib) approach which simply enhances the beans in a way which is required by Orchestra might be enough. Sure, we can not yet use the faces-config.xml to configure the managed beans for Orchestra. But probably we can introduce something like a orchestra-config.xml for the scope and managed bean configuration. @community: What do you think? Is it worth it? Ciao, Mario Von: Kito Mann [mailto:kito.m...@virtua.com] Gesendet: Dienstag, 07. Juli 2009 23:45 An: MyFaces Development Betreff: Re: Shale Annotations The problem with using Orchestra is that it requires Spring, which is an extra framework that some organizations don't necessarily need. Although JSF managed beans aren't that great, sometimes they're a better choice than integrating Spring into the project. --- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://twitter.com/jsfcentral http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 On Tue, Jul 7, 2009 at 4:46 PM, Bruno Aranda brunoara...@gmail.commailto:brunoara...@gmail.com wrote: Hi, What about just using MyFaces Orchestra? It does many of the thing the shale tiger extensions used to do (and even includes lots of useful features). You have the Orchestra view controller annotations and if you want more annotations, you can use the Spring ones to register backing beans and so on... Cheers, Bruno 2009/7/7 Kito Mann kito.m...@virtua.commailto:kito.m...@virtua.com: Hello everyone, I know that MyFaces is in the process of swallowing Shale Test. What do you guys think about swallowing Shale Annotations, too? I know it's a dead-end add-on considering JSF 2, but I run into enough clients that aren't going to be using JSF 2 for a lng time, and could use annotation support today. Given Shale's retired status, they're never going to touch it. Thoughts? --- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://twitter.com/jsfcentral http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3
RE: AW: slf4j and myfaces
Start voting? ;-) From: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Sent: Saturday, June 06, 2009 11:45 AM To: MyFaces Development Subject: Re: AW: slf4j and myfaces yes the -1 vote would be a veto in view of slf4j - no agreement - we would vote about jul. or as mario suggested - let's start voting about jul. @mario: yes - i'll wait until monday for sure. and we should vote a bit longer than usual - due to holidays (+ it's an important topic for all myfaces projects) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/6/6 Ganesh gan...@j4fry.orgmailto:gan...@j4fry.org Hi, we could also vote first about slf4j and everybody who prefers jul should vote -1 if we don't have a majority for slf4j, we have to vote about jul. is that ok for everybody? From http://www.apache.org/foundation/voting.html my understanding of a -1 vote is different from this. Vetos A code-modification proposal may be stopped dead in its tracks by a -1 vote by a qualified voter. This constitutes a veto, and it cannot be overruled nor overridden by anyone. Vetos stand until and unless withdrawn by their casters. To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc.). A veto without a justification is invalid and has no weight. Better use the fraction system for voting on the logging system: * +0: 'I don't feel strongly about it, but I'm okey with this.' * -0: 'I won't get in the way, but I'd rather we didn't do this.' * -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' * ++1: 'Wow! I like this! Let's do it!' * -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' Best regards, Ganesh
AW: [VOTE] jul instead of commons-logging
+1 Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Gesendet: Dienstag, 09. Juni 2009 20:33 An: MyFaces Development Betreff: [VOTE] jul instead of commons-logging hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html
AW: slf4j and myfaces
Sorry, for top-posting, but Outlook makes it too hard to do it right ;-) Well, yet another configuration option for configuring our logging facade (yes, you are right, it is a facade) is for sure also not a good option. As a last note to this discussion I'd like to say, that not dealing with the class loader issue does not mean that the webapp-reloading-memory-leak has been addressed in some way. Anyway, if you think it (slf4j) is a good way to go, I'll not stand in between :-) Ciao, Mario -Ursprüngliche Nachricht- Von: Manfred Geiler [mailto:manfred.gei...@gmail.com] Gesendet: Freitag, 05. Juni 2009 20:50 An: MyFaces Development Betreff: Re: slf4j and myfaces On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits ma...@ops.co.at wrote: Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Pros: No class loader ambiguousness (as you mentioned) You get what you define (especially when using maven): compile-dependency to slf4j-api runtime-dependency to slf4j-adapter of YOUR choice -- that's it! No wild guessing like with JCL: Use Log4j if it is anywhere in the (web container) classpath, else use Java logging... What, if I want to use Java logging although there is Log4j in the classpath?! Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not again... Yes, I know commons-logging.properties solves this, but that's awful... (BTW, I hate properties files in the root package namespace!) Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part that reroutes JCL calls to the slf4j API. Yes, that is a possible solution, but keep in mind that this is kind of a hack. It is actually a reimplementation of the JCL API (namespace) that routes all calls to SLF4J. It's meant as runtime solution for legacy libs. Using it as compile time dependency might be a shortcut, but my feeling says it's not the nicest solution. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). yet another logging wrapper WHY do so many people feel they must write such a thing? JCL and slf4j ARE ready-to-use logging wrappers. So??? I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. They CAN use JCL if myfaces uses slf4j. They just define a slf4j-jcl-x.x.x.jar runtime-dependency and everything is fine. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. slf4j DOES solve the problem by avoiding highly sophisticated classloader magic! Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. yet another logging wrapper... (see above) How would you implement such a pluggable wrapper? Yet another (mandatory) config parameter. System property? Servlet context param? Come on! What about this: looking for existing well-known logging implementations and define some priority rules... Dejavu. See the problem? As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? You buy this good thing by re-implementing SLF4J and/or JCL. Serious. I cannot imagine a wrapper (actually a facade, right?) implementation that is versatile for the developers and pluggable for the users and has less source code than any of the well-known logging facade APIs (slf4j and jcl). They both are actually meant to heal the java world from proprietary yet another logging facades/wrappers! +1 for using SLF4J as logging facade for future MyFaces developments (JSF 2.0, ...) +0 for replacing JCL by SLF4J for all existing code (if someone is volunteering to do the job I have no problem with that...) --Manfred anfred
AW: slf4j and myfaces
But why not use java.util.logging then at all. There is an example [1] which shows how to reroute it to any other logging impl. This too will remove the need of any logging dependency then. Look, with slf4j you will end with three dependencies. * the slf4j api * the commons-logging to slf4j bridge (for all the other libraries your app is going to use and which still are using commons-logging) * the slf4j impl (an since the impl itself provides nothing than the bridge, you need the logging impl to) If you are going to use java.util.logging - which is a pain to setup, but sufficient for many use-cases - these are three (up to four) dependencies too much - just for logging! I think, this will not be a bad move - and moves us completely out of line of this question once and for all I think. The java.util.logging api itself provides the same possibilities than we have today in our libraries - just different namings. Ciao, Mario [1] http://wiki.apache.org/myfaces/Trinidad_and_Common_Logging -Ursprüngliche Nachricht- Von: Mario Ivankovits [mailto:ma...@ops.co.at] Gesendet: Samstag, 06. Juni 2009 08:08 An: 'MyFaces Development' Betreff: AW: slf4j and myfaces Sorry, for top-posting, but Outlook makes it too hard to do it right ;-) Well, yet another configuration option for configuring our logging facade (yes, you are right, it is a facade) is for sure also not a good option. As a last note to this discussion I'd like to say, that not dealing with the class loader issue does not mean that the webapp-reloading-memory-leak has been addressed in some way. Anyway, if you think it (slf4j) is a good way to go, I'll not stand in between :-) Ciao, Mario -Ursprüngliche Nachricht- Von: Manfred Geiler [mailto:manfred.gei...@gmail.com] Gesendet: Freitag, 05. Juni 2009 20:50 An: MyFaces Development Betreff: Re: slf4j and myfaces On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits ma...@ops.co.at wrote: Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Pros: No class loader ambiguousness (as you mentioned) You get what you define (especially when using maven): compile-dependency to slf4j-api runtime-dependency to slf4j-adapter of YOUR choice -- that's it! No wild guessing like with JCL: Use Log4j if it is anywhere in the (web container) classpath, else use Java logging... What, if I want to use Java logging although there is Log4j in the classpath?! Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not again... Yes, I know commons-logging.properties solves this, but that's awful... (BTW, I hate properties files in the root package namespace!) Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part that reroutes JCL calls to the slf4j API. Yes, that is a possible solution, but keep in mind that this is kind of a hack. It is actually a reimplementation of the JCL API (namespace) that routes all calls to SLF4J. It's meant as runtime solution for legacy libs. Using it as compile time dependency might be a shortcut, but my feeling says it's not the nicest solution. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). yet another logging wrapper WHY do so many people feel they must write such a thing? JCL and slf4j ARE ready-to-use logging wrappers. So??? I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. They CAN use JCL if myfaces uses slf4j. They just define a slf4j-jcl-x.x.x.jar runtime-dependency and everything is fine. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. slf4j DOES solve the problem by avoiding highly sophisticated classloader magic! Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. yet another logging wrapper... (see above) How would you implement such a pluggable wrapper? Yet another (mandatory) config parameter. System property? Servlet context param? Come on! What about this: looking for existing well-known logging implementations and define some priority rules... Dejavu. See the problem? As a plus, this then will remove a dependency
AW: slf4j and myfaces
Hi!
There are two pros of slf4j I did not mention yet:
1. parameterized messages, which make it possible to omit those ugly
if (logger.isDebugEnabled()) {... conditions, without performance
issue: see http://www.slf4j.org/faq.html#logging_performance
http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Logger.html
Seems that JUL support this too if we use the log() methods.
I've looked at the java source. JUL is using MessageFormat.Format then in the
formatter only if there is a placeholder in the message ({0-{4).
Not that bad.
2. it's no longer possible to forget the log message by writing
logger.error(exc) instead of logger.error(an error has occured,
exc). This is because the slf4j api is strict and only allows a
String (and not an Object) as first argument.
Funny, JUL also has no log(ex) method, just log(String, ex) (+ level for sure).
Seems the JUL API is not that bad :-)
What I'm not sure is
if the JUL to other logging impl bridge is multiple application
friendly. What happens if the JUL root handler is replaced (thats what
these bridges seem to do). Does this influence the servlet container
logging and other apps as well?
Seems to be true, JUL is not container friendly by default. But this needs to
be addressed by the container (and the Java Spec guys ;-) ).
It seems, this is the reason for JULI, the Tomcat logging impl.
Also JBoss solved that (as they use Tomcat ?!). See for a documentation here:
http://www.jboss.org/file-access/default/members/jbossweb/freezone/docs/latest/logging.html
They replace the LogManager by a container friendly LogManager. The JUL using
app does not need to know that.
Yeah, seems JUL can be our salvation finally ;-)
Ciao,
Mario
Re: slf4j and myfaces
that would be possible as well. i just started with slf4j since we already discussed it and udo wrote about the switch to slf4j in the next release... we could also vote first about slf4j and everybody who prefers jul should vote -1 Just wait until Monday if possible, then enough developers should have commented on the thread already. Probably it is clear then already that a vote for JUL is enough. (i don't like the idea that every myfaces project ends up with its special logging framework dependency.) Yes, thats true. Ciao, Mario
AW: slf4j and myfaces
Hi! The only downside I see is that we might break compatibility for java 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand is it really important anymore? Which projects still have to be on 1.4 In 1.4.2 the log methods in question were already there. So - as a logging user only - this might not be a problem. http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html Ciao, Mario
Re: Myfaces 2.0 PPR ResponseWriter impl
Hi! Not sure if this adds any value to this discussion, but The only question is how facelets handles this case, but I assume faclets simply skips comments and passes it through with out.write! I'm talking about !-- on the page level, not on the component level. Facelets will treat !-- as markup. Tags nested inside will still be evaluated. With the writeElement/writeAttribute solution this could end up in script being evaluated though nested inside !-- --. You can configure this using facelets.SKIP_COMMENTS=true (what we did). Comments are comments then (and skipped) Hopefully mojarra will provide a setting for this too, and, even better, have true as default. Ciao, Mario
AW: slf4j and myfaces
Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? Ciao, Mario Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Gesendet: Freitag, 05. Juni 2009 17:18 An: MyFaces Development Betreff: slf4j and myfaces hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html
AW: slf4j and myfaces
Why? I think our wrapper can do pretty much the same than slf4j does. Having a public static Log log = LogFactory.getLog(MyClass.class) can easily be supported by our logging framework. Then, any known logging framework has the most possible information available, whatever it does with it. If a logging framework use a static position of the stack trace, to gather its information, is bound to fail anyway and has to be considered a bad implementation, no? AFAIK, in terms of cl class loader issues, having a static log ist not bad if the logging facade has been loaded with the same class-loader than the library were loaded. Which should always be the case with our own wrapper. Yes, I know, we end up having a slf4j within myfaces. But I see no point having a dependency to such a simple API - which exactly adds no value, but forces every cl user to setup the sfl4j-over-cl bridge. IMHO, the java way to do it is to provide our own simple logging wrapper, by using jul as default impl. I know that jul sucks, but this then can easily be customized by the developer. Mojarra also uses jul, no? So good or bad, this i something we have to deal with anyway - providing a pluggable logging api is fair enough then. I think, most of the time the user will not care and just start using jul. Too bad that SUN did not manage to provide a logging api which has been widely accepted :-( Ciao, Mario Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Gesendet: Freitag, 05. Juni 2009 20:22 An: MyFaces Development Betreff: Re: slf4j and myfaces @mario: which logging frameworks would be supported by such a wrapper. i can just mention that there are logging frameworks out there which internally force an exception and statically use entry x of the call hierarchy - so such a wrapper would lead to wrong logging information. regards, gerhard (after reformulating the previous mail quite quickly the text wasn't perfect - but i think you know what i mean...) 2009/6/5 Gerhard Petracek gerhard.petra...@gmail.commailto:gerhard.petra...@gmail.com @matthias: yes - that's the reason for my comment: ...external logging framework... @udo: imo we should discuss the logging topic before we have a release which already uses slf4j - especially the suggestion of mario sounds interesting. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/6/5 Mario Ivankovits ma...@ops.co.atmailto:ma...@ops.co.at Hi! Could one please eloberate a little bit more in detail what the pros are of slf4j? Notice, I switched to it in our company project - but always using the commons-logging api and just used the slf4j-over-cl wrapper. This is something wich is possible for each and ever user of myfaces already, just by adjusting the depencendcies correctly. Lately I even switched to my own logging wrapper, but this is another story. In the end, everything still uses the cl API which is proven to work fine. (I created the org.apache.commons.logging package structure with my own classes - which for sure is not possible for myfaces!). I still think, that using the cl api is the best we can do for our users. If they then use cl as implementation - and if this is considered good - is another story, but nothing WE should anticipate. As far as I can say the cl api is rock solid, just the class-loader stuff is a pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it. Before we start using any other logging api I'd suggest to build our own thin myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java utils ogging) or whatever - we do not even have to provide any other impl than for jul. As a plus, this then will remove a dependency - a dependency to any logging framework - which - in terms of dependencies can be considered as a good thing, no? Ciao, Mario Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.commailto:gerhard.petra...@gmail.com] Gesendet: Freitag, 05. Juni 2009 17:18 An: MyFaces Development Betreff: slf4j and myfaces hello all, again the logging-framework topic :) there were several discussions about it and i'm not aware of an agreement. udo wrote [1]: replace commons-logging with slf4j as i know we agreed on using one logging framework dependency for all myfaces projects. if i remember correctly, most of us prefer slf4j. - i suggest to vote about using slf4j in all myfaces projects. (at least if a project is using an external logging framework.) regards, gerhard [1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html
RE: [VOTE] Orchestra 1.3.1 release candidate
+1 Checked it now and looks good! --- Mario visit my blog at http://copy-con.blogspot.com/ -Original Message- From: Mario Ivankovits [mailto:ma...@ops.co.at] Sent: Tuesday, March 03, 2009 8:12 AM To: 'MyFaces Development' Subject: RE: [VOTE] Orchestra 1.3.1 release candidate +0 (I trust you made a high quality package again :-) ) -Original Message- From: Simon Kitching [mailto:skitch...@apache.org] Sent: Monday, March 02, 2009 9:58 PM To: MyFaces Development Subject: [VOTE] Orchestra 1.3.1 release candidate Hi All, I think it's time to release an update to Orchestra Core; we have about half-a-dozen minor/medium bugs fixed. Therefore I have created a release candidate for orchestra-core 1.3.1. Please have a look at these artifacts and vote: [1] http://people.apache.org/builds/myfaces/m2-staging- repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3.1 [2] http://people.apache.org/~skitching/orchestra-core- 1.3.1/index.html [3] https://svn.apache.org/repos/asf/myfaces/orchestra/branches/core- 1_3_1-prepare/RELEASE-NOTES.txt Note that the link from the site to the 1.3.1 release notes isn't there yet - it can't be done until after the vote has passed and the release- branch has been made a tag :-). But that's just a trivial site update.. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks! Simon
RE: [VOTE] Orchestra 1.3.1 release candidate
+0 (I trust you made a high quality package again :-) ) -Original Message- From: Simon Kitching [mailto:skitch...@apache.org] Sent: Monday, March 02, 2009 9:58 PM To: MyFaces Development Subject: [VOTE] Orchestra 1.3.1 release candidate Hi All, I think it's time to release an update to Orchestra Core; we have about half-a-dozen minor/medium bugs fixed. Therefore I have created a release candidate for orchestra-core 1.3.1. Please have a look at these artifacts and vote: [1] http://people.apache.org/builds/myfaces/m2-staging- repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3.1 [2] http://people.apache.org/~skitching/orchestra-core-1.3.1/index.html [3] https://svn.apache.org/repos/asf/myfaces/orchestra/branches/core- 1_3_1-prepare/RELEASE-NOTES.txt Note that the link from the site to the 1.3.1 release notes isn't there yet - it can't be done until after the vote has passed and the release- branch has been made a tag :-). But that's just a trivial site update.. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks! Simon
RE: Scanning for annotated classes in MyFaces 2
Hi! -Original Message- From: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com] Mario, I've been looking at the Shale code that handles the annotation scanning, but I saw it uses Reflection and standard Java ClassLoaders for scanning the classpath for JSF artifacts. What's your experience with the performance of this? Does Shale heavily rely on specifying a base package to be efficient? Hmmm, it is a long time back we used it at least during development times it was very annoying not having specified the packages. If I remember correctly, with defining it, scanning-time drop down from something aroung 30 seconds to under 1 second. Wouldn't it be sufficient to do it that way for a first version of MyFaces 2.0? Do you think Mojarra will come up with a more sophisticated solution which bypasses the standard reflection stuff and uses something like Javasisst? I doubt. Ciao, Mario
RE: Scanning for annotated classes in MyFaces 2
Hi! not sure on the PERF, but if it is really (proven) the case, I am with you. Well... startup time isn't really a big problem, right? :-) Is that ironic? In projects with 3000 classes and 60 jar files you are up to 30 seconds, or even more, scanning time. Under load, with shale, I saw scanning times of 60 seconds. This _will_ drive you crazy! Ciao, Mario
RE: Scanning for annotated classes in MyFaces 2
Hi! But there are some issues with this: First, what paths to scan? AFAIK the spec doesn't state the classpaths to scan. I suppose only /WEB-INF/lib and /WEB-INF/classes need to be checked, but I can't find it in the spec. What ever the spec says, we definitely should provide a configuration parameter in web.xml where one can configure the packages to scan, else startup times of your webapp will be VERY bad. I had this in the past with shale-annotation. There I added such configuration already. We can strip the scanning/parsing out there - I'll contribute if required. Ciao, Mario
RE: Scanning for annotated classes in MyFaces 2
-Original Message- From: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com] Sent: Wednesday, January 07, 2009 8:15 AM To: dev@myfaces.apache.org Subject: Re: Scanning for annotated classes in MyFaces 2 It might be smart to put this Shale code in a separate project. For example in Commons, since there are several Apache projects that need to scan for annotations, like EJB3 and JPA projects. Yeah, I thought the same too. What would be great would be some sort of annotation scanner where you can register a scanning job for system startup so that the classpath scanning has to take place only once and the scanning jobs get called back about the results. Sure, if a scanning job registers something like ** all packages get scanned and startup time is slow again, but this is on the responsibility of the developer then. I can help to startup a commons sandbox project and to work out a specification for the library, but my spare time for coding is very low :-( Ciao, Mario
[OT] Mesir
Hi! Just wanted to post a link to mesir [1]. Mainly a pom.xml and a few examples, but I like the idea of bundling all this together and state this a full stack. From the pom.xml I can say that we use many of these libraries already in our application and they turned out to be very stable. I think mesir is worth a look if you start a new project. Not sure if it is really a full JEE stack already, but the most important libraries are there. MyFaces Orchestra for example ;-) Ciao, Mario [1] http://code.google.com/p/mesir/ PS: I didn't send this mail to the MyFaces user group as I don't wanted to make it look like an official proposal of the MyFaces group. Not yet ...
RE: [VOTE] Release of Extensions Validator 1.1.1
+0 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerhard Petracek Sent: Thursday, December 04, 2008 12:01 PM To: MyFaces Development Subject: [VOTE] Release of Extensions Validator 1.1.1 Hi, I was running the needed tasks to get the 1.1.1 release of Apache MyFaces Extensions Validator out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.1.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] http://people.apache.org/~gpetracek/myfaces/extval/release_candidate/1_1_1/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
RE: [OT] Babs Books
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Are there also MyFaces diapers available, that would be the perfect present for my newborn child this year ;-) cool. congrats! is is a wernER or wernSIE ? ROFL Werner, whats up? Why haven't you notified us? Congrats! :-) Hope, you still get some sleep. Ciao, Mario
RE: New MyFaces PMC chair
Welcome Mr. President! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manfred Geiler Sent: Thursday, November 20, 2008 10:08 AM To: MyFaces Development Subject: New MyFaces PMC chair Please welcome our new MyFaces PMC chair Matthias Wessendorf! As some of you already might know, I had decided to step down as the chair. The MyFaces PMC members then voted for Matthias Wessendorf as the successor and yesterday the board approved the change. Matthias, thanks for beeing up to that job. I personally have great confidence in you and wish you all the best for guiding us into the JSF 2.0 era. Regards, Manfred Geiler
RE: New MyFaces PMC chair
The old JFK one … ;-) From: Bruno Aranda [mailto:[EMAIL PROTECTED] Sent: Thursday, November 20, 2008 1:21 PM To: MyFaces Development Subject: Re: New MyFaces PMC chair Congratulations!! Is it a wood chair or a metal chair? Bruno 2008/11/20 Hazem Saleh [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Congratulations! On Thu, Nov 20, 2008 at 11:42 AM, Mario Ivankovits [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Welcome Mr. President! -Original Message- From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Manfred Geiler Sent: Thursday, November 20, 2008 10:08 AM To: MyFaces Development Subject: New MyFaces PMC chair Please welcome our new MyFaces PMC chair Matthias Wessendorf! As some of you already might know, I had decided to step down as the chair. The MyFaces PMC members then voted for Matthias Wessendorf as the successor and yesterday the board approved the change. Matthias, thanks for beeing up to that job. I personally have great confidence in you and wish you all the best for guiding us into the JSF 2.0 era. Regards, Manfred Geiler -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250
RE: [Continuum] up? or down?
At least, I can't access it either. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Thursday, November 20, 2008 1:33 PM To: MyFaces Development Subject: Re: [Continuum] up? or down? http://myfaces.zones.apache.org:8080/ is that only down behind my firewall ? -M On Tue, Nov 18, 2008 at 10:26 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: hrm looks like the project builds is fine... just some (maven|minor|random) issue on the (trinidad) site... -M On Tue, Nov 18, 2008 at 10:07 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I don't see mails from the continuum server recently. In the past we saw them once in a while. The server is up, but looks like the old password (for me) doesn't work. Was there an update on the machine ? Looks like the site build isn't working as well. Does one know more? Thanks! Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
RE: SVN question
Probably something went wrong during the copy process and you have old .svn directories in the structure. Check the content of the files in the .svn directory in trinidad-1.0.10/trinidad-api and check if the url points to the correct svn path and not to the trunk or any other tag path. Ciao, Mario -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Tuesday, November 11, 2008 11:28 AM To: MyFaces Development Subject: SVN question Hi, a little quiz. I got this output, from my lovely svn tool... svn: Commit failed (details follow): svn: File '/repos/asf/myfaces/trinidad/tags/trinidad-1.0.10/trinidad- api/pom.xml' already exists However, as a matter of fact, there is nothing like this: http://svn.apache.org/viewvc/myfaces/trinidad/tags/ So, I am really really wondering, what is wrong here... Any hint is totally appreciated! -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
RE: [orchestra flow] support JSF1.2 only?
+1 -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 04, 2008 12:15 PM To: MyFaces Development Subject: [orchestra flow] support JSF1.2 only? Hi, Currently orchestra-flow 0.0.1 supports JSF1.1. However in order to allow pages that declare orchestra flows to be *included* in other pages, eg ui:include src=somePageThatCallsAFlow ui:param name=vname value=value/ /ui:include the EL expressions in the included page need to be build using the correct ELContext object (otherwise they cannot see the params). Rather than build some kind of reflection-based solution, it would be simpler to just ditch JSF1.1 support for orchestra-flow. Note that there are no plans to ditch JSF1.1 support for orchestra-core .. Any objections? Regards, Simon. -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
RE: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi! The problem is, that it is hard to ensure having a stopConversation for each startConversation, and what about reloading the page where possibly the startConversation gets called twice. Well, if I'm not completely mistaken, you also have to invalidate all Orchestra conversations manually by now. Well, for conversation.access this is no problem, they die with any request not accessing any bean in the conversation. For manual-scoped conversations, this is true. However due to the map based approach, the impact of not having a converation closed is much less, and if the user navigates back it can resume the work automagically. Manual conversations also have a timeout; when not used for a while they are garbage-collected. Will this work as well in your approach? The not used thing won't work so well, yes? I don't see the point, why forcing the user to stop the conversation manually is a problem. Normally the user wont play nicely - and a web application should not force the user to do so. But, to say the truth, we often use the conversation.access for the persistence stuff and conversation.manual for storing non-persistence state of the conversation which allows to restart easily. This gives the user a great application experience I think. Reloading the page, however, doesn't matter. Well, of course, it creates another conversation but sooner a later a timeout will invalidate the one that has been created first. But then you can not talk about nested conversations, then you too have the same flat structure as Orchestra has by today. When you talk about nested conversation you normally also mean to invalidate all child conversations once the parent timeout. This clearly can not work for your scenario. So you too have to distinguish between nested conversations and start a new conversation. Currently nested conversations are supported through Orchestra Flow ... which also requires some sort of configuration/convention for the flow demarcation. Another problem ist that not each and every page-flow is triggered by a navigation-handler event, what about get requests - e.g. from the main menu. The NavigationHandler was just supposed to be an example. However, somewhere, of course, you have to implement that logic, i.e. some callback method is needed in order to handle the conversation selection, for example, you could use a ViewController for GET Requests. But then again you do not know if you'd like to start or end a conversation without specific external configuration. You can not state this as implementation detail. Starting and ending a conversation in a reasonable and controlled way is what it is all about. Orchestra just allowes to handle it in a less hot way. Of course, it's best practice not to pass any entities between Orchestra conversations, but that's just true because each Orchestra conversation has got its own persistence context. Seperating conversations and persistence contexts allows you to use the conversation scope in a more fine-grained way (for example, I'd like to reset filter criteria of a search conversation without closing the persistence context). How many levels do you want the developer to keep in mind? If you separate the conversation from the persistence scope you also have to be aware that, once the persistence context dies all the conversation cached in a conversation bean is detached. Creating a new persistence scope and pulling in conversation beans with entites loaded using another persistence scope will not work. The only workaround is to NOT cache any entity in the conversation bean and look it up from the persistence context each and every time. Which is doable, for clustering probably needed, but hard to code. And yes, the reset filter criteria is just what is easily possible (and used) with orchestra. Simply invalidate the conversation which holds the criteria. BTW: This conversation lives in a scope which does not use any persistence context at all here. This is just a matter of scope configuration. You could count it as example 3 of things I don't like in Orchestra. I have to use a single persistence context for a certain dialog (I'm calling it dialog now so that you don't mix it up with Orchestra conversations). Now I'd like to split this dialog into seperate conversations, but I can't because I have to reuse the persistence context so I'm actually reseting some values manually. :-f This is just not true, you can use as many persistence contexts as you would like to. You just have to be aware how to pass information from one conversation to another one. That you should not pass entities between persistence contexts is a limitation of the persistence framework - and nothing which is a real problem in any application, is it? I don't know what you mean by split this dialog as no persistence framework allows you to split its session, but if you'd like to push the data to other
RE: [orchestra] [VOTE] Orchestra Core 1.3 Release
+1 -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2008 11:27 AM To: MyFaces Development Cc: MyFaces Discussion Subject: [orchestra] [VOTE] Orchestra Core 1.3 Release Hi All, A release-candidate has been prepared for Orchestra Core 1.3. The release-candidate source is currently at: http://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-1_3- prepare and will be moved to tags dir when/if the release vote passes. The artifacts have been deployed to the staging repository here: http://people.apache.org/builds/myfaces/m2-staging- repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3/ Sorry about the .asc.asc.* files; please ignore those and I will remove them before deploying the final artifacts to the central repo. The latest maven-clirr-report plugin unfortunately crashes on orchestra, but I have created a report using clirr trunk; please see here: http://people.apache.org/~skitching/orchestra-core-1.3/clirr- orchestra-1.2-to-1.3.txt Javadocs etc for this release can be found here: http://people.apache.org/~skitching/orchestra-core-1.3/myfaces- orchestra-core-1.3/site/ The release notes from this version can be found at: http://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-1_3- prepare/RELEASE-NOTES.txt Please have a look at these artifacts and vote: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
AW: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi! Example 1) I've developed some views for a search dialog that I wanted to use in at least two different conversations. Everything worked fine for the first conversation. The following code listing should give you an idea of the problem. Simon developed Orchestra Flow which might solve this problem as it creates an all new conversation context for this flow and thus can reuse the conversation setup. Simon is still working on it to make it work with our latest requirements, but it should work for many use-cases already. I am not sure if there is a detailed documentation already. Example 2) In a different part of the same application I've created a view that should serve for three different usecases. Basically the view doesn't change for these usecases at all, but the logic of the backing bean does. My first approach was to determine the specific page bean at runtime in the action method that navigates to this view. This action method was supposed to register the specific page bean under a common name. So somehow it can be said that I wanted to use polymorphic beans. You might treat it as workaround (which you don't want to hear), but the latest Orchestra provides the method convObject = ConversationUtils.bindToCurrent(object) which allows you to attach all the aspects to any bean you'd like to. Allowing to use that from within the spring configuration is on our todo list. I don't want to hear anything about certain workarounds that I could have used in these cases as I think that these usecases aren't exceptional enough to justify workarounds. It is hard to know what you treat as workaround and what we treat as by design ;-) However, the missing flow part is nearly there and already usable. Summarizing it can be stated that I'd propose you to rewrite conversation handling for the next major release and I'd be willing to contribute. Note that I don't want to drop support for these named conversations, but I think that this usecase is not the default one for conversations. I know from the past that you would like to rewrite this stuff, but I've never seen a proposal what exactly and how. Don't get me wrong, but if you'd like to make the naming-conversation-way optional you need another way how to deal with the persistence context. Orchestra IS different to Seam here and probably different to Webflow. If the naming-conversations are exceptional ... I don't know, we use it heavily, and now with Orchestra Flow the last missing bit has been developed and Orchestra fits VERY nicely within our application. Probably how we built our application is exceptional (for the good and the bad ;-) ) Well, now with Orchestra Flow it might be possible to reach what you want. If I understood that right. You'd like to have a single conversation active for the request instead for a bean. So, creating a SingleConversationScope, this scope then should hold the persistence context in the conversationContext and bind/unbind it on request start/end. Different conversations then are only possible by utilizing Orchestra Flow. How parallel running conversations should work in such a setup, I don't know yet ... Ciao, Mario
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi!
Example 1)
I've developed some views for a search dialog that I wanted to use in at
least two different conversations. Everything worked fine for the first
conversation. The following code listing should give you an idea of the
problem.
However (as noted in my other email) flow won't solve this issue. In
fact it sets up even more strict isolation between caller and called
views - deliberately. The called view cannot access any
conversation-scoped data except its own - and whatever parameters it
gets explicitly passed.
I thought Bernhard is searching a way how to do solve this problem, and
Orchestra Flow clearly shows how to solve the search-flow-use-case without
having to build your own parameter passing framework.
For me it was clear that passing entities between conversations is a no-go; as
with any framework which allows multiple persistence context.
Example 2)
In a different part of the same application I've created a view that
should serve for three different usecases. Basically the view
doesn't
You might treat it as workaround (which you don't want to hear),
but the latest Orchestra provides the method
convObject = ConversationUtils.bindToCurrent(object)
which allows you to attach all the aspects to any bean you'd like to.
Allowing to use that from within the spring configuration is on our
todo list.
I'm not sure how the new Conversationutils.bindToCurrent would help
here..
In your main bean you can have this switch/case to create the bean and put it
into a specific conversation, your main bean then provides a method like
getImplementation.
In your view then you write #{mainBean.implementation.xyz}.
The SingleConversationScope class was recently deleted from Orchestra -
as discussed on the list. Partly because there did not seem to be any
use-case that it was useful for.
We can resurrect it if such a use-case is found. But I don't understand
the above description...how exactly does it solve the two issues that
Bernhard had?
From discussions in the past with Bernhard I got the feeling that he don't
like the multiple-conversations per request approach. Which forced us to
create something like the view-controller scope, however, I still see no way
around that. Having the request conversation defined by the view controller
is the best we can do I think.
Ciao,
Mario
RE: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi! Well, basically I'd refactor the ConversationContext so that it's actually the main conversation of Orchestra. The conversation itself is almost independent of Spring (of course, there's still an according implementation of the Scope interface, but it will be implemented way easier). It's possible to nest conversations, i.e. a there's a certain hierarchy of conversations. The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. In a web-application, where you have global menues where the user is able to suspend the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this free-floating-named-conversations in our application. As far as I know Spring WebFlow is such a system and is able to deal with persistence contexts already. Each conversation has got it's own lifecycle and therefore it's possible to register so-called conversation listeners in order to hook logic into such lifecycle phases. Some of the events you outlined are already there in Orchestra. Also using Orchestra without persistence at all works great, on a per-scope-configuration basis! Still, the beauty of Orchestra is that it supports use-cases like: 1) Doing Order-Processing 2) Suspend task 1 and do some different things like, update customers master-data 3) Go back to Order-Processing and continue All this works without a single line of flow-description and by nicely separate the persistence contexts, so the memory of task 2 has been freed while task 1 is stil there. Also no user-interaction is required (pause, restart, etc) and no other sort of convention. On top of THAT we built the flow, so each flow separates even more by still keeping the easy-to-use multiple conversation feature. Where a flow is required (e.g. search-pages) you can use them now. So, it is not only using two conversations during the same render-request, no, it is about using different parallel conversations for different tasks without additional configuration on view level. In fact, if one finds a method how Orchestra can determin what is the CURRENT conversation we could get rid of the viewController-scope, but since Orchestra talks about beans and not about views in its innerst, that is hard to find. For me the single-conversation approach looks like a limitation, which to break out requires a flow-description. Sorry, at all it is hard for me to see what is better to do it like Spring WebFlow. Ciao, Mario
Re: [orchestra] release orchestra-core version 1.3?
Hi! Great! I think it is a good time to make another Orchestra Core release. There is nothing radical in this new version, Yep, the radical stuff is kept for the next version ;-) Ciao, Mario
Re: tomahawk examples design proposal
Hi! +1 to number one. Ciao, Mario
RE: [Orchestra] SpringSingleConversationScope
Hi! A while ago you added class SpringSingleConversationScope to orchestra with the comment Mostly useful for dialog/flow frameworks. The idea was that a dialog can have only one conversation. I can't remember why we/I thought that we require that. Now that it works without this limitation I am fine if you remove that class. Ciao, Mario
Re: Bug in ApplicationImpl
Hi! This used to work in MyFaces 1.1, but in 1.2 it looks like the fact that my type is an enum takes precedence over the fact that it implements EnumCoded interface, so I end up with the built-in EnumConverter instead of my GenericEnumTypeConverter. Of course this issue was not relevant in JSF1.1, as java1.5 native enums were not supported (JSF1.1 is java1.4-compatible). But for JSF1.2, it makes a lot of sense to check for an optional interface first. Shouldn't that be specified by the spec? Is this a spec bug? I mean, things like that are very important for a JSF application to rely on to work correctly between various JSF implementations. Ciao, Mario
Re: Tomahawk sandbox release (was Re: [ANNOUNCE] Release of Tomahawk 1.1.7)
Hi! If people are happy with adding a note to the tomahawk sandbox page as described above then I'll do it. I'd prefer this mark buoy. Ciao, Mario
Re: [VOTE] Orchestra core 1.2 release candidate 1 available
+0 No chance to look at it for me now, but I trust that you did a good job again :-) Ciao, Mario On Tue, 2008-07-15 at 23:03 +0200, simon wrote: Hi All, The release candidate for MyFaces Orchestra Core 1.2 can be found in the following places: Download bundles: http://people.apache.org/~skitching/orchestra-core-1.2/ Maven staging repository: http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.2/ Please have a look at these artifacts and vote: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released (and reason why) Note that I will be on holiday until Monday 15 July, so there is no hurry :-) I hope it was just the fact that I forgot to put [VOTE] in the subject line which lead to the lack of response...(now fixed). The release candidate is still out there waiting for a few kind souls to review BTW, the release notes can be found here: http://svn.apache.org/repos/asf/myfaces/orchestra/branches/prepare_core12/RELEASE-NOTES.txt Regards, Simon
Re: Orchestra core 1.2 release candidate 1 available
Hi! Note that I will be on holiday until Monday 15 July, so there is no hurry :-) Monday OR 15 July, both together will not be possible ;-) Well, and even 15 July might be a VERY short vacation. *hehe* Thanks or the work, I'll look at the artifacts in the next few days, before my vacation :-D *yes* Ciao, Mario
Re: [VOTE] release orchestra parent pom version 1.2
+1 simon schrieb: Hi All, I'd like to release a new parent pom for the Orchestra project. You can find the artifact here: http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-maven/1.2/ and the svn tag here: http://svn.apache.org/repos/asf/myfaces/orchestra/branches/prepare-maven-1_2/ The major differences are: * some website updates * use version 6 of parent pom rather than version 5 * enable checkstyle rules As with all parent-pom releases, this of course does not affect any existing software; things need to explicitly point at the new version before they pick up any of these changes. +1 from me of course Regards, Simon -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: Dojo discussion - opensourcing the jsf dojo components project
Hi! Werner Punz schrieb: Martin Marinschek schrieb: In any case, I remain -1 to add a new component library - I am sorry. Ok I am going to postpone this discussion until I can showcase something then we can start it over... Hmm ... was Martin's -1 a veto or did he just express his opinion. Martin, how do we have to count your -1? Ciao, Mario
Re: [tomahawk] Is there any task left to make a release of tomahawk?
Hi! Mario, Could you please open jira issues on the defects you found during your work with s:pprPanelGroup. The problems I had previously were: 1) Sometimes ppr simply stopps working, a full page refresh will happen. Don't know how to reproduce it. Probably you could simply ignore that issue. 2) You need a way how to send the component h:messages together with the ppr response. In a4j you could wrap any component. These component are then fetched with ANY ajax request. This makes it VERY easy to have ajax submit by still being able to show the messages, even if a custom messagesRenderer is used (like we have here). 3) Support setting a new ViewRoot from within an ajax request. a4j also supports that. The ajax response will then be (I think aborted) and a full page refresh will happen. But hey, it was really cool once I discovered that this works at all. More generally I have to say I find it way more harder to define all the client-side id's where the ppr should trigger than to simply setup a reRender attribute on any commandLink/commandButton. We found it much more natural to work that way then to configure triggerPatterns. a4j also provides an easy way to have a status icon somewhere on the page which will appear on ajax-req-start and disappear (or whatever, just configure the facets) on ajax-req-stop. The main question is, what is the target of our pprPanelGroup. If it is to be as comfortable as the other ppr implementations I think it needs much more work. Ciao, Mario Thank you. On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi! s:xmlTemplate Dont know much, not to say nothing, about that. s:pprPanelGroup (is this component ready? it could be good but I don't know if there is any objection). I do not think that pprPanelGroup is ready for a release, there are some things still missing and sometimes it stopps working. Unfortunately, I have to say I am switching away from pprPanelGroup to a4j with richfaces. I just have no time to look into pprPanelGroup ... Ciao, Mario -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: proposal: new Orchestra Flow subproject
Hi! (a) create a sub-project myfaces/orchestra/trunk/flow, publish to snapshot-repo and main myfaces website as normel, but make sure that the welcome page for the website says SANDBOX in big letters and the version number is something like 0.0.1 +1 Often even the sandbox will be used also in production. Which is peoples own fault, but it is as it is. Given automatic installation of NavigationHandler and ViewHandler I'll second that it is a good idea to have it as sub-project even when it will be released. Also it clearly shows Orchestra's openess for anything else, even another flow implementation. Ciao, Mario
Re: [tomahawk] Is there any task left to make a release of tomahawk?
Hi! s:xmlTemplate Dont know much, not to say nothing, about that. s:pprPanelGroup (is this component ready? it could be good but I don't know if there is any objection). I do not think that pprPanelGroup is ready for a release, there are some things still missing and sometimes it stopps working. Unfortunately, I have to say I am switching away from pprPanelGroup to a4j with richfaces. I just have no time to look into pprPanelGroup ... Ciao, Mario
Re: current state of MYFACES-434
Hi Leonardo, I tried to upgrade to the latest Tomahawk+Sandbox and now the application fails to run properly as the TomahawkFacesContextWrapper does the AddResource processing AND the ExtensionsFilter does the AddResource processing. The code in extension filter that do AddResource processing should be commented (this was added to disable this feature before). But before do that, we need to test several configurations of this feature (DefaultAddResource, NonBufferingAddResource, if servlet or portlet environment and other variations), because it could break old code. Ok, but it seems that Tomahawk head breaks every installation using DefaultAddResource which makes it impossible to test new things. My workaround is to use DojoAddResource, but that is far from being nice. If you would like us to test this thing it would be great if you could finish the work in ExtensionsFilter so that it really works as drop in replacement. Thanks! Ciao, Mario
Re: [myfaces core] Redirect to a JSF page when Throwable exception or error occur
Hi! the use-case is that people want the same type of functionality they have in their web.xml (specifying an error-page per exception) in the JSF-world as well. Just doing it in the web.xml is not sufficient, as then the faces-context is already closed and not available anymore, so important context-information for the error would be missing. I wonder why people always want a full running JSF environment for each and every page. If there is an exception it might be due to a problem in JSF itself which might make it impossible to show any error page at all. Not that you can not handle such situations (revert to default error handling), but it makes things complicated. As long as it does not break other things and is fully optional with non-intrusive by default I am -0 adding such a feature. Ciao, Mario
Re: Dojo discussion - opensourcing the jsf dojo components project
Hi! Ok then those things are cleared up, now back to the original question sandbox or own subproject? +1 for own subproject. Any further influence with tomahawk/sandbox needs to be avoided. These two projects are still waiting for a overhaul themself. Ciao, Mario
current state of MYFACES-434
Hi! What is the current state of MYFACES-434? I tried to upgrade to the latest Tomahawk+Sandbox and now the application fails to run properly as the TomahawkFacesContextWrapper does the AddResource processing AND the ExtensionsFilter does the AddResource processing. This results in having the scripts added twice to the header which will result in non working dojo components. Configuring the ExtensionsFilter to not cover the jsf requests will result in the well known ExtensionsFilter not correctly configured. JSF mapping missing. JSF pages not covered. Please see: http://myfaces.apache.org/tomahawk/extensionsFilter.html (java.lang.IllegalStateException) message. So it seems we are half way, aren't we? Did I do something wrong? If not, can we fix this? Notice: I built Tomahawk MyFaces from a fresh checkout (which was a story itself as the 6-SNAPSHOT master pom couldn't be found). Ciao, Mario
Re: [myfaces core] Redirect to a JSF page when Throwable exception or error occur
Hi! One possible enhancement to the error handling feature of myfaces could be the capability of redirect to a jsf page. Any concrete use-case for this, or just yet another cool-we-can-make-it thingy? ;-) Seriously, what's wrong with the error page capabilities of the webapp container? Instead of error-code you can have error-type. Never used, tough. Probably it would be enough to learn the Faces-Servlet to unwrap the real exception instead of introduce another error handling stuff. Even this I'd do with a Faces-Servlet wrapper, more like a general purpose exception-unwrapper-servlet so that this can work with Mojarra and whatever. Ciao, Mario
Re: t:graphicImage doesnot generate XHTML complaint code
Hi! Ok, just to say something here too. If you are going to create an accessibility application you have to put more work into it than just adding an ALT text to your images. Since a meaningful default text is not easy to find, if not impossible, my vote is: that means: - log a nag warning +1 probably configurable. something like org.apache.myfaces.ACCESSIBILITY_WARNINGS=true|false with default to true. - render a non-empty alt attribute with a meaningful default text if the developer omits the attribute (or provides an empty one) -1 (a) don't output ALT. This screws all blind users, but in an obvious way so that QA departments can easily detect it and tell their developers to add the needed alt attributes. And it is not our code that is at fault. +1 (b) output empty ALT. This screws all blind users, but it cannot be detected by validation. And it is our code that is at fault as well as the user code. -1 (c) output ALT with ha ha no description. See (b). -1 Probably we can use the title text as default for the alt if there is one. For sure, the Tomahawk components (e.g. tree2) need to be fixed to properly render an ALT attrbute. Ciao, Mario
Re: svn commit: r671015 - in /myfaces/tomahawk/trunk: core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java examples/simple/src/main/webapp/aliasBean.jsp
Hi!
Doesn't this change break backward compatibility completley?
The value of the alias= attribute now has to be defined differently,
instead of the el-expressesion just the name needs to be set.
Even if this change is logical to me, a new tomahawk release will break
any existing application using the aliasBean, no?
If so, I think this patch needs to be reverted unless we are going to
release a new major version of tomahawk.
Ciao,
Mario
[EMAIL PROTECTED] schrieb:
Author: lu4242
Date: Mon Jun 23 21:22:49 2008
New Revision: 671015
URL: http://svn.apache.org/viewvc?rev=671015view=rev
Log:
TOMAHAWK-790 Aliasbean warning/error when no EL expression in the alias property
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java?rev=671015r1=671014r2=671015view=diff
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
Mon Jun 23 21:22:49 2008
@@ -47,7 +47,7 @@
protected void setProperties(UIComponent component) {
super.setProperties(component);
-setStringProperty(component, alias, _alias);
+setValueBinding(component, alias, _alias);
setStringProperty(component, value, _valueExpression);
}
Modified: myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp?rev=671015r1=671014r2=671015view=diff
==
--- myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
(original)
+++ myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp Mon
Jun 23 21:22:49 2008
@@ -45,7 +45,7 @@
h:form
h2aliasTest1/h2
-t:aliasBean alias=#{holder} value=#{aliasTest1}
+t:aliasBean alias=holder value=#{aliasTest1}
f:subview id=simulatedIncludedSubform1
%-- The next tags could be inserted by an %@ include or
jsp:include --%
h:outputLabel for=name value=Name :/
[jira] Commented: (TOMAHAWK-1014) HTMLInputDate ignores custom converters
[ https://issues.apache.org/jira/browse/TOMAHAWK-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607465#action_12607465 ] Mario Ivankovits commented on TOMAHAWK-1014: at least t:inputCalendar allows to use the converter= property (we use it here), and so should inputDate too no? The custom converter just inherits from the special inputCalendar converter. This is required to e.g. allow to plug in any other date library like Joda-DateTime. I'll reopen this bug, please close it again if I got things wrong. Ciao, Mario HTMLInputDate ignores custom converters --- Key: TOMAHAWK-1014 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1014 Project: MyFaces Tomahawk Issue Type: Bug Components: Date Affects Versions: 1.1.5 Reporter: Steven Gollery Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT Setting a custom converter on HTMLInputDate fails. HTMLDateRenderer.getConvertedValue does not use the converter from the component, but instead uses UserData.parse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TOMAHAWK-1014) HTMLInputDate ignores custom converters
[ https://issues.apache.org/jira/browse/TOMAHAWK-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits reopened TOMAHAWK-1014: HTMLInputDate ignores custom converters --- Key: TOMAHAWK-1014 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1014 Project: MyFaces Tomahawk Issue Type: Bug Components: Date Affects Versions: 1.1.5 Reporter: Steven Gollery Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT Setting a custom converter on HTMLInputDate fails. HTMLDateRenderer.getConvertedValue does not use the converter from the component, but instead uses UserData.parse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] layout for myfaces-commons project
simon schrieb: In other words, keeping one line of code makes sense (less maintenance) even if we lose some JSF1.2/JSF2.0-specific features or performance boosts. While I second the rest of your mail, I wont do so with the sentence above. We are developers, and, at least in your younger years ;-), you'd like to keep up with technology and use the newest things. And JSF 1.2 is anything else then new today, not to speak about JSF 1.1. In contrast, we spent alot of time to make our JSF 1.1 development upward compatible. I don't think that we are responsible to provide a vital community around a library which itself depends on a stone old architecture. So, yes to one line of code, but I'd like to see the bundle Tomahawk+JSF1.1 frozen. Anything new should go to a JSF 1.2 native Tomahawk. And JSF 2.0 release date + (lets say) half year the same should count for Tomhawk JSF 1.2 then. Ciao, Mario
Re: [trinidad] Why input type=hidden name=javax.faces.ViewState ... does not render its id?
Hi! why not getElementsByName[0] ? Well, in general document.getElementById is both faster and more elegant. So in this case, rendering this component with id=clientId seems reasonable. Hmm..but it is possible that there are multiple view state fields in the page, one per form. So perhaps using getElementsByName is a good idea in this specific case. And also ensure that every ViewState will be replaced and not only the first [0] one. When you do have multiple JSF forms (which is valid) each ViewState needs to be replaced. Ciao, Mario
Re: [trinidad] Why input type=hidden name=javax.faces.ViewState ... does not render its id?
Hi!
And also ensure that every ViewState will be replaced and not only the
first [0] one.
When you do have multiple JSF forms (which is valid) each ViewState
needs to be replaced.
Yes, but only when they came from the same view!
I don't know much about JSF portal bridge stuff. Can this result in a
page contains a form that was rendered via JSF from host A, and a
different form that was rendered via JSF from host B?
I'd say yes. You might be right.
Don't know much about protlets either, but, I guess one solution can be
to replace only those ViewState fields with the same value as the one
associated with the form the component is embedded in.
Lets speak code:
var enclosingForm = findEnclosingForm(theComponent);
var oldViewState = enclosingForm[ViewState].value;
for (form : forms)
{
if (form[ViewState].value == oldViewState)
{
form[ViewState].value = newViewState;
}
}
Or do any portlet have its own namespace reflected into the element id?
Then this could be checked too, though, this will be a portlet specific
solution then.
Ciao,
Mario
Re: [trinidad] Why input type=hidden name=javax.faces.ViewState ... does not render its id?
Hi! I ignore what happens when use multiple jsf portlets in the same page, or when the page is using multiple forms on the same page (normal submits should work on both environmets, but ajaxified components?). With I ignore you mean you will not replace the ViewState for each form having a ViewState hidden field? If so, this is bad I think, as having multiple forms is a perfect possible scenario, subForm is not always the best answer. Ciao, Mario
Re: [VOTE] Orchestra core15 version 1.0 release
Hi! [X] +1 for community members who have reviewed the bits Thanks for being the release-manager again! Ciao, Mario
Re: svn commit: r656086 [2/2] - in /myfaces/tomahawk/trunk/core: ./ src/main/java/org/apache/myfaces/component/html/util/ src/main/java/org/apache/myfaces/custom/jslistener/ src/main/java/org/apache/m
Hi!
Simon and me had to spend 5 hours today to track down a problem which in
the end uncovered a nasty bug in TomahawkFacesContextWrapper. In
.release() the delegation was broken (due to a return in the try block).
Bad stuff :-(
Also I found some questionable stuff:
* Some important todos like the arguments for the MultipartRequestWrapper
* A lot of e.printStackTrace()
Is this work in progress? Or is the module already in
if-one-finds-a-problem-fix-it-yourself-mode ;-)
Ciao,
Mario
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/webapp/filter/TomahawkFacesContextWrapper.java?rev=656086view=auto
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/webapp/filter/TomahawkFacesContextWrapper.java
(added)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/webapp/filter/TomahawkFacesContextWrapper.java
Tue May 13 19:00:38 2008
@@ -0,0 +1,292 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.myfaces.webapp.filter;
+
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.util.Iterator;
+
+import javax.faces.FacesException;
+import javax.faces.application.Application;
+import javax.faces.application.FacesMessage;
+import javax.faces.component.UIViewRoot;
+import javax.faces.context.ExternalContext;
+import javax.faces.context.FacesContext;
+import javax.faces.context.ResponseStream;
+import javax.faces.context.ResponseWriter;
+import javax.faces.render.RenderKit;
+import javax.portlet.PortletResponse;
+import javax.servlet.http.HttpServletRequest;
+import javax.servlet.http.HttpServletResponse;
+
+import org.apache.commons.fileupload.FileUpload;
+import org.apache.myfaces.renderkit.html.util.AddResource;
+import org.apache.myfaces.renderkit.html.util.AddResourceFactory;
+import org.apache.myfaces.tomahawk.util.ExternalContextUtils;
+
+/**
+ * @author Martin Marinschek
+ */
+public class TomahawkFacesContextWrapper extends FacesContext {
+
+private FacesContext delegate=null;
+private ExternalContext externalContextDelegate=null;
+private ExtensionsResponseWrapper extensionsResponseWrapper = null;
+
+public TomahawkFacesContextWrapper(FacesContext delegate) {
+
+this.delegate = delegate;
+
+//if(delegate.getExternalContext().getResponse() instanceof
PortletResponse) {
+
if(ExternalContextUtils.getRequestType(delegate.getExternalContext()).isPortlet())
{
+//todo do something here - with the multipart-wrapper. rest
should be fine
+AddResource addResource= AddResourceFactory.getInstance(this);
+addResource.responseStarted();
+
+ if (addResource.requiresBuffer())
+ {
+throw new IllegalStateException(buffering not supported in
the portal environment.);
+}
+}
+else {
+HttpServletResponse httpResponse = (HttpServletResponse)
delegate.getExternalContext().getResponse();
+HttpServletRequest httpRequest = (HttpServletRequest)
delegate.getExternalContext().getRequest();
+
+HttpServletRequest extendedRequest = httpRequest;
+HttpServletResponse extendedResponse = httpResponse;
+
+// For multipart/form-data requests
+if (FileUpload.isMultipartContent(httpRequest)) {
+extendedRequest = new MultipartRequestWrapper(httpRequest,
/*todo _uploadMaxFileSize*/-1,
+/*todo _uploadThresholdSize*/-1, /*todo
_uploadRepositoryPath*/null);
+}
+
+AddResource addResource= AddResourceFactory.getInstance(this);
+addResource.responseStarted();
+
+ if (addResource.requiresBuffer())
+ {
+extensionsResponseWrapper = new
ExtensionsResponseWrapper(httpResponse);
+ extendedResponse = extensionsResponseWrapper;
+}
+
+externalContextDelegate = new ExternalContextWrapper(
+
Re: [VOTE] To create a subproject alchemy under MyFaces for the contribution that integrates Adobe Flex components as MyFaces JSF components
Hi! Reason #3: The development community is not (so far) very large. Jihoon Kim's initial code looks nicely written, but it was written as a hobby project rather than being driven by any long-term goal. Shouldn't the project go through the incubator for this reason? MyFaces can be the sponsor (or however this is called in incubator land ;-) ) It also gives Apache the chance to sort out the legal issues. Ciao, Mario
Re: [Orchestra] Disabling Persistence Conversation Feature
Hi! I tried deleting the part regardless to persistence from spring configuration (application-context.xml) but no success. I encountered exceptions thrown by the Orchestra Conversation Interceptor. Not configuring the persistence related advice (e.g the persistentContextConversationInterceptor) with the scope should be sufficient. What exceptions do you encounter? Ciao, Mario
Re: [VOTE] Add MyfacesBuilderPlugin to buildtools branch and use it on myfaces 1.1
Leonardo Uribe schrieb: +0 ... just due to the fact that I don't have time to review these bits, but I trust you guys that *everything* ;-) works as expected. +1 for the architecture and the general approach! Great work! Hi MyfacesBuilderPlugin is now available for use on myfaces 1.1, so we can officially vote about what plugin use on myfaces 1.1, 1.2 and tomahawk for code generation Please note that this work is based on the discussion about code generation long time ago. A vote is necessary since this is a new module and the changes proposed impact several projects. The wiki describing how works this is here: http://wiki.apache.org/myfaces/MyfacesBuilderPlugin The examples are available here: https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/builder_plugin/ You can find a copy of myfaces 1.1 working with this plugin here: https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/builder_plugin/bigtest/core_trunk_11/ So please vote if you want to see this feature included on myfaces 1.x and tomahawk regards Leonardo Uribe -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: possible replacement for our kupu based html editor
No way - http://www.cdolivet.net/editarea/editarea/docs/license.html - its LGPL Probably contacting the author and asking him to change the license or dual license it might be worth a try. Ciao, Mario Hi Werner, It works for me after removing some plug-ins from FF2. I can start working on it when I have sometime. But what is the new name u suggest for the new TextEditor? On 4/22/08, Werner Punz [EMAIL PROTECTED] wrote: Hazem Saleh schrieb: Hi Werner, It doesn't work for me on FF2. On 4/22/08, Werner Punz [EMAIL PROTECTED] wrote: Guys have a look at this amazing editor http://www.cdolivet.net/editarea/editarea/exemples/exemple_full.html the best, the code is under apache license!!! Werner Check your browser settings FF2 is exactly what I am using to view it :-) -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits smime.p7s Description: S/MIME Cryptographic Signature
Re: MyfacesBuilderPlugin work now against myfaces core 1.1
Hi! MyfacesBuilderPlugin is almost complete. Actually works for 1.1 and all interested people could see the example here: Cool work guys. Great job! Thanks for all the hard work! Ciao, Mario
[jira] Commented: (ORCHESTRA-23) Incorrect initialization of OrchestraFacesContextFactory
[ https://issues.apache.org/jira/browse/ORCHESTRA-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590607#action_12590607 ] Mario Ivankovits commented on ORCHESTRA-23: --- *shocked* Really?! All due to this bug or do you refer to some other (hopefully fixed) bugs too ... We use the 1.1 release without the problems you mentioned. Incorrect initialization of OrchestraFacesContextFactory Key: ORCHESTRA-23 URL: https://issues.apache.org/jira/browse/ORCHESTRA-23 Project: MyFaces Orchestra Issue Type: Bug Components: FrameworkAdapter Affects Versions: 1.1 Environment: windows, linux, solaris Reporter: Dan Tran Priority: Blocker Fix For: 2.0 Attachments: diff.txt In org.apache.myfaces.orchestra.lib.jsf. OrchestraFacesContextFactory. getFacesContext(...) The ContextLockRequestHandler is registered BEFORE FrameworkAdapterRequestHandler, For serialization of requests to work properly, the FrameworkAdapter must be initialized BEFORE the ContextLockRequestHandler attempts to use it in ContextLockRequestHandler.init(...) (in fact ,there is even a NOTE in there to that effect). The current order means the FrameworkAdapter is initialized JUST AFTER the ContextLockRequestHandler needs it. The fix is to swap the order of registering these adapters in OrchestraFacesContextFactory. getFacesContext(...). final LinkedList handlers = new LinkedList(); handlers.add(new ContextLockRequestHandler()); handlers.add(new FrameworkAdapterRequestHandler()); handlers.add(new ConversationManagerRequestHandler()); handlers.add(new DataSourceLeakRequestHandler()); should read final LinkedList handlers = new LinkedList(); handlers.add(new FrameworkAdapterRequestHandler()); handlers.add(new ContextLockRequestHandler()); handlers.add(new ConversationManagerRequestHandler()); handlers.add(new DataSourceLeakRequestHandler()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1855) hidden fields created when using h:commandLink and f:param should be created and removed using javascript
[ https://issues.apache.org/jira/browse/MYFACES-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587862#action_12587862 ] Mario Ivankovits commented on MYFACES-1855: --- It would be really great if you could externalize the javascript too. Currently it is simply inlined into the source, which looks not very professional I think. hidden fields created when using h:commandLink and f:param should be created and removed using javascript - Key: MYFACES-1855 URL: https://issues.apache.org/jira/browse/MYFACES-1855 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Myfaces render the hidden fields before the end of the form, which cause compatibility problems when someone does not use h:form to encapsulate a form. Mojarra or jsf ri does not, instead create the hidden fields before submit (including the hidden fields for params), submit the form an then remove the hidden fields to avoid unwanted effects. Myfaces set the hidden fields (if it is not rendered on the form creates it), submit the form and then set the values of the hidden fields to null. I have noted that autoscroll feature available when using tomahawk + myfaces uses oamSetHiddenInput instead render the hidden autoscroll part. After thinking a lot (A LOT!!) about this problem, the best for solve this problem is do not render hidden fields for this case, but let the code for hidden fields (compatibility with tomahawk, since jscookmenu use this feature, this should change in a future release). Instead, for h:commandLink, set and remove the hidden fields using javascript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1214) allow to process form submits in a queue for high-speed input handling
[ https://issues.apache.org/jira/browse/TOMAHAWK-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved TOMAHAWK-1214. Resolution: Later Immediate need for this feature is no longer existent. It would be an interesting feature anyway, so resolved with later to get it out of line, but to keep the idea too. allow to process form submits in a queue for high-speed input handling -- Key: TOMAHAWK-1214 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1214 Project: MyFaces Tomahawk Issue Type: New Feature Components: PPRPanelGroup Reporter: Mario Ivankovits Assignee: Ernst Fastl Enhance the PPR stuff in a way which allows to process form input asynchron in a queue for high-speed input handling. Probably by adding a new attribute to the PPRPanelGroup called queued=true|false. With true the form data should be collected and held in a queue on client side. The client then checks that queue at given intervalls (queueCheckInterval=) if there is data in the queue and transmit that data to the server like a normal ppr request. Between each transmit a queueWaitInterval= should be waited. A status component (queueShowStatus=true|false) should show the success of each transmit. A client side javascript should be used to extract the status text information from the form data (queueShowStatusInfoBuilder=javascript-method-name(formData)) The PprPanelGroup should also be enhanced to being able to point to the messages component (messages=component-id) the queueStatus information should then be able to visualize that text and show e.g. a red-cross if there were errors (=messages) For this first version the status info can be a simple table created client-side using some css to allow to format it according to the application skin. A simple table with two columns status-info|return-visualization status-info is the text returned by the queueShowStatusInfoBuilder javascript method and return-visualization might be an icon. Only waiting requests and those with errors should be shown, correctly finished requests can be removed from the list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [proposal] jsf validation with annotations
Hi! my position on this is we could make sev-en part of orchestra, if the orchestra crew really, really wants it. If not, this should just be a separate sub-module in MyFaces. It is interesting enough to stand on its own. First, Orchestra is part of the MyFaces community, so it really, really should be a decision the MyFaces community felt, and not a Orchestra Team only one. Anyway, I think this is a question on how we position Orchestra. If it is a strong position against JBoss Seam, then it probably might make sense to include everything which makes life easier for the developer into Orchestra - just as Seam tries to do. However, then we loose one of the strongest arguments pro Orchestra: Being a lightweight Conversation-Centric Library. If, we could add it as sub-module to Orchestra, but I think the best place for sev-en (would like to see a new name anyway) is to be a submodule of MyFaces. But first I'd like to see the technical details of how the sev-en core works. e.g. in the examples I've seen a lot of converter wrapper stuff ... Building an official MyFaces Maven Artifact which bootup a development environment (MyFaces Fullstack) with what we think on need for development of any-range-sized applications would be more approriate then. Such a project could include sev-en too. Ciao, Mario
[jira] Commented: (ORCHESTRA-21) URLs are always encoded
[ https://issues.apache.org/jira/browse/ORCHESTRA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587058#action_12587058 ] Mario Ivankovits commented on ORCHESTRA-21: --- Ouch ... good catch. Will do so. URLs are always encoded --- Key: ORCHESTRA-21 URL: https://issues.apache.org/jira/browse/ORCHESTRA-21 Project: MyFaces Orchestra Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Mario Ivankovits Fix For: 2.0 In Trinidad some components creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Fix would be to ignore anything that has a javascript: prefix. Orchestra should only append the conversationContext if the protocol is http or https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-21) URLs are always encoded
[ https://issues.apache.org/jira/browse/ORCHESTRA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587059#action_12587059 ] Mario Ivankovits commented on ORCHESTRA-21: --- done URLs are always encoded --- Key: ORCHESTRA-21 URL: https://issues.apache.org/jira/browse/ORCHESTRA-21 Project: MyFaces Orchestra Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Mario Ivankovits Fix For: 2.0 In Trinidad some components creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Fix would be to ignore anything that has a javascript: prefix. Orchestra should only append the conversationContext if the protocol is http or https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-21) URLs are always encoded
[ https://issues.apache.org/jira/browse/ORCHESTRA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-21. --- Resolution: Fixed Fix Version/s: 2.0 Assignee: Mario Ivankovits We will encode now only if the url starts with http* URLs are always encoded --- Key: ORCHESTRA-21 URL: https://issues.apache.org/jira/browse/ORCHESTRA-21 Project: MyFaces Orchestra Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Mario Ivankovits Fix For: 2.0 In Trinidad some components creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Fix would be to ignore anything that has a javascript: prefix. Orchestra should only append the conversationContext if the protocol is http or https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-20) single conversation
[ https://issues.apache.org/jira/browse/ORCHESTRA-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585939#action_12585939 ] Mario Ivankovits commented on ORCHESTRA-20: --- Currently, the viewController scope does not work with this single conversation scope as the way how the conversation name will be derived from the bean name does not honor the fact into which scope the bean has been put into. This needs to be fixed. single conversation --- Key: ORCHESTRA-20 URL: https://issues.apache.org/jira/browse/ORCHESTRA-20 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits Create an implementation of a single conversation. A dialog/flow framework will create new conversationContexts instead of direct conversations. While you still will be able to use conversation.manual or conversation.access it makes sense to also provide a conversation.single implementation which shares the lifetime of the conversationContext (managed by the dialog framework) and has only one (single) persistence context. Still, mixing the various conversation implementations is possible. Probably Conversation.getCurrentInstance() outside of a conversation will return this single conversation if it exists within the current conversationContext. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-20) single conversation
[ https://issues.apache.org/jira/browse/ORCHESTRA-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585944#action_12585944 ] Mario Ivankovits commented on ORCHESTRA-20: --- Committed a fix for that too. Unfortunately this introduces a small binary incompatibility if one implemented a custom scope. In AbstractSpringOrchestraScope: protected String getConversationNameForBean(String beanName) has been changed to public String getConversationNameForBean(String beanName) single conversation --- Key: ORCHESTRA-20 URL: https://issues.apache.org/jira/browse/ORCHESTRA-20 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits Create an implementation of a single conversation. A dialog/flow framework will create new conversationContexts instead of direct conversations. While you still will be able to use conversation.manual or conversation.access it makes sense to also provide a conversation.single implementation which shares the lifetime of the conversationContext (managed by the dialog framework) and has only one (single) persistence context. Still, mixing the various conversation implementations is possible. Probably Conversation.getCurrentInstance() outside of a conversation will return this single conversation if it exists within the current conversationContext. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext
[ https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586009#action_12586009 ] Mario Ivankovits commented on ORCHESTRA-19: --- First draft committed. Most noteworthy are startConversationContext and activateConversationContext which allows one to start new conversation contexts as child of the current one. One has to take care about to call activateConversationContext() at the right time. Unhappily I had to break binary compatibility of the conversationContext class. This might mean that we are on the way to Orchestra 2. Though, I one did not customize Orchestra in that area (which is highly unlikely that one did) it is still a drop-in upgrade. refactor conversationContext to allow nested conversationContext Key: ORCHESTRA-19 URL: https://issues.apache.org/jira/browse/ORCHESTRA-19 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits The conversationContext should be enhanced to allow nested conversationContext which is a requirement for dialog/flow implementations to separate the conversations for different flows. The new conversationContext should be able to handle: * a conversation context per windows * multiple named conversationContexts * a stack of conversationContexts to fulfill the requirement a dialog framework has with its subflows Technically this might all be the same conversationContext implementation probably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext
[ https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586009#action_12586009 ] imario edited comment on ORCHESTRA-19 at 4/5/08 8:01 AM: --- First draft committed. Most noteworthy are startConversationContext and activateConversationContext which allows one to start new conversation contexts as child of the current one. One has to take care about to call activateConversationContext() at the right time. Unhappily I had to break binary compatibility of the conversationContext class. This might mean that we are on the way to Orchestra 2. Though, if one did not customize Orchestra in that area (which is highly unlikely that one did) it is still a drop-in upgrade. was (Author: imario): First draft committed. Most noteworthy are startConversationContext and activateConversationContext which allows one to start new conversation contexts as child of the current one. One has to take care about to call activateConversationContext() at the right time. Unhappily I had to break binary compatibility of the conversationContext class. This might mean that we are on the way to Orchestra 2. Though, I one did not customize Orchestra in that area (which is highly unlikely that one did) it is still a drop-in upgrade. refactor conversationContext to allow nested conversationContext Key: ORCHESTRA-19 URL: https://issues.apache.org/jira/browse/ORCHESTRA-19 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits The conversationContext should be enhanced to allow nested conversationContext which is a requirement for dialog/flow implementations to separate the conversations for different flows. The new conversationContext should be able to handle: * a conversation context per windows * multiple named conversationContexts * a stack of conversationContexts to fulfill the requirement a dialog framework has with its subflows Technically this might all be the same conversationContext implementation probably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [proposal] jsf validation with annotations
Hi! sev-en is a new jsf-extension. Looks Cool, I love it to see that a long standing idea now seems to be realized. You posted on the dev list .. cool .. you probably know we are developers too ... so .. where do we find the code? Or is it just a too-late April joke ;-) I think that would make a great new module for myfaces, no? Ciao, Mario
[jira] Created: (MYFACES-1850) component attributes problem with server side state saving with serialize in state = false
component attributes problem with server side state saving with serialize in state = false Key: MYFACES-1850 URL: https://issues.apache.org/jira/browse/MYFACES-1850 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.2, 1.1.5 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Priority: Critical When using server side state saving with serialize state in view=false all the saved states for the same view contains a shared reference to the component attribute map. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-20) single conversation
single conversation --- Key: ORCHESTRA-20 URL: https://issues.apache.org/jira/browse/ORCHESTRA-20 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits Create an implementation of a single conversation. A dialog/flow framework will create new conversationContexts instead of direct conversations. While you still will be able to use conversation.manual or conversation.access it makes sense to also provide a conversation.single implementation which shares the lifetime of the conversationContext (managed by the dialog framework) and has only one (single) persistence context. Still, mixing the various conversation implementations is possible. Probably Conversation.getCurrentInstance() outside of a conversation will return this single conversation if it exists within the current conversationContext. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext
[ https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585648#action_12585648 ] Mario Ivankovits commented on ORCHESTRA-19: --- The conversationContext URL parameter might hold the bottom conversationContext id. refactor conversationContext to allow nested conversationContext Key: ORCHESTRA-19 URL: https://issues.apache.org/jira/browse/ORCHESTRA-19 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits The conversationContext should be enhanced to allow nested conversationContext which is a requirement for dialog/flow implementations to separate the conversations for different flows. The new conversationContext should be able to handle: * a conversation context per windows * multiple named conversationContexts * a stack of conversationContexts to fulfill the requirement a dialog framework has with its subflows Technically this might all be the same conversationContext implementation probably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext
[ https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585651#action_12585651 ] Mario Ivankovits commented on ORCHESTRA-19: --- The conversationContext api needs to be enhanced to get access to specific types of conversationContext. * byId (already there) * byName (user definable name) * byType (e.g. find the one responsible for the window data) refactor conversationContext to allow nested conversationContext Key: ORCHESTRA-19 URL: https://issues.apache.org/jira/browse/ORCHESTRA-19 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits The conversationContext should be enhanced to allow nested conversationContext which is a requirement for dialog/flow implementations to separate the conversations for different flows. The new conversationContext should be able to handle: * a conversation context per windows * multiple named conversationContexts * a stack of conversationContexts to fulfill the requirement a dialog framework has with its subflows Technically this might all be the same conversationContext implementation probably. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
nasty problem in server side state saving
... with serialize in state disabled.
I've create a small test case which shows that the attributes map is
just copied over into the state. Which means that each and every
Component shares exactly the same map. Any change to this map will be
reflected in ALL saved states.
Correct would be to clone the map, but this must not work, at least a
shallow copy of the map should be saved (when serialize in
state=false) to avoid this problem.
What do you think?
public void testSaveInSessionWithoutSerialize() throws Exception
{
// create a fake viewRoot
UIViewRoot root = new UIViewRoot();
root.getAttributes().put(key, value);
// simulate server-side-state-saving without serialization
Object state = root.saveState(facesContext);
// restore view
UIViewRoot root1 = new UIViewRoot();
root1.restoreState(facesContext, state);
// restore view .. next request
UIViewRoot root2 = new UIViewRoot();
root2.restoreState(facesContext, state);
// chaange attribute in root1
root1.getAttributes().put(key, borken);
// and see it changed in root2 too
assertEquals(value, root2.getAttributes().get(key));
// and see it changed everywhere
assertEquals(value, root.getAttributes().get(key));
}
Ciao,
Mario
Re: nasty problem in server side state saving
Hi! It's because the wrong constructor in api's _ComponentAttributesMap class, it's assigning the map directly: So we do agree that this needs to be fixed? Then I'll do so ... Ciao, Mario
Re: JspStateManagerImpl into shared?
Ping! It seems that Orchestra has to implement a StateManager which holds the view state in the conversationContext instead of the session. At the moment it seems that large portions of JspStateManagerImpl can be reused, but requires to copy it over into Orchestra. With slight refactoring of JspStateManagerImpl it should be possible to just replace the actual storing/loading stuff. Does this qualify to move JspStateManagerImpl into shared? Or should I better copy the source over? Ciao, Mario
shared discuss again [was Re: JspStateManagerImpl into shared?]
Hi! Mario, you are not alone in hating the shared concept. ;-) Good! 1) has a super stable API That is true, that might be the hardest part. 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces projects Sure! 3) may be used by the experienced JSF app developer who wants to write his own StateManager or ELResolver or some other pluggable/replaceable JSF thingy (ie. all the things you can replace via faces-config.xml) Yepp! Problem here again is the name of such a lib: myfaces-commons-base? myfaces-commons-core? myfaces-commons-super? myfaces-commons-commons? ;-) I'd opt for myfaces-base, but to say the truth, I do not care about the name, whatever name it has will be good for me as long as the goal is the same. It is no place where we swiftly drop some nice and convenient utils stuff and the API is nothing to play around with. +1 I think that if we find a good name and define some strict rules we could move most (or all?) stuff from myfaces-shared to this lib. And perhaps even get rid of shard in the long run! One rule can be to allow only stuff which itself directly implements a JSF API but do not provide any functionality on its own, you see, no enum converter or soo. Probably only abstract classes? Of course, some well-known issues pop up immediately: which JSF-Spec - 1.1 and 1.2 or only 1.2? What about JSF 2.0? I'd like to see one project per version, e.g. myfaces-base11, myfaces-base12, myfaces-base20 (with namespaced package names: org.apache.myfaces.base11, etc) This might lead to code duplication for every new project, but is the only way I can think of making it possible for this project to succeed. It would not be nice if myfaces-base12 has to deal with backward-compatibility. Parts of myfaces-base12 MIGHT be backward-compatible, e.g. like any FacesContextWrapper. But there is no need for that, we can't forsee any future change e.g. in JSF 2.0 Ciao, Mario
Re: JspStateManagerImpl into shared?
Hi! Orchestra having its own JspStateManagerImpl sounds interesting though. Enabling this on Sun Mojarra for example will quite radically change the way that a JSF app on Mojarra performs. That's not really Orchestra's role. I thought about this like an optional feature one has to configure in their own faces-config.xml What is *really* needed is for the StateManager spec to have some mechanism to externalise the state, then have Orchestra override just that. +1 But that is not here yet! Is it not possible to apply the decorator pattern to whatever StateManager implementation the current JSF implementation provides? No, unfortunately, no! On the other hand, if you replace the state manager it should work with any other JSF impl too ... as long as it follows the standard by dispatching anything through the StateManager, no? Ciao, Mario
Re: [Orchestra] Core15 release ?
Hi! are there any plans to release the core15 module ? soon :-) I would like open-source the @ConversationName annotation in core15 and then we should be ready. Volunteering doing the release then? Ciao, Mario
JspStateManagerImpl into shared?
Hi! Just to reiterate: I hate shared! ;-) Seriously, it seems that Orchestra has to implement a StateManager which holds the view state in the conversationContext instead of the session. At the moment it seems that large portions of JspStateManagerImpl can be reused, but requires to copy it over into Orchestra. With slight refactoring of JspStateManagerImpl it should be possible to just replace the actual storing/loading stuff. Does this qualify to move JspStateManagerImpl into shared? Or should I better copy the source over? Ciao, Mario
country/zip show city problem [was: partial model update on ppr request]
Hi!
Sorry for the lengthy mail ... Solving this problem just made me crazy
so easy problem, and so complicate if not impossible solution with JSF.
Everything I toucht in the last couple of days had some
side-effect/influence on something else.
My simple country/zip immediate show city ppr problem drives me crazy.
I wonder why no one else wanted to solve that the nice way.
To sum up: You have a form with a couple of input fields, some of them
required. The field triple country/zip/city (within the form) should
behave as follows:
*) after country change - lookup and show city
*) after zip change - lookup and show city
*) allow to manually override the city
*) reset manually override city to automatich mode (using a special
commandLink)
After my latest changes to the ppr stuff I made things work, but not as
nicely as I wanted it to be - depending on the concrete view layout.
The most annoying things I experienced lately are:
1) the inlineMessage make the form not work correctly if the message is
going to replace one of the input controls ... means the value of
this field will not be transmitted (I can live without inlineMessage ...)
2) without inlineMessage, if the focus is within the city field, after
ppr the focus is lost (the input field has been readded to the form) and
you have to use the mouse to reset it.
3) The view (follows later) just looks ugly with some hacks (hidden
command buttons to make submitOnEvent happy)
The problem 2 is the one currently struggling me. As far as I know it is
not possible to get the element with the current focus.
If I would like to solve this problem, it seems if have to
a) attach an onfocus()/onblur() handler to each and every input element
and track the focus that way. You probably know how bad such things
interact with user supplied javascript (-1)
b) probably make the ajax call synchron which should hopefully avoid the
focus problem (+0)
c) get rid of this way at all (personally I don't like it to transfer
the whole component just to update the value) and introduce something
different at all (+1 I think)
Long story
Don't you think too that something like Shale Remoting (with a nicer
javascript client API) would be more helpful here?
You can solve that problem then easily and it should do the trick too.
What do you think?
Do you know any nice looking implementation of such a thing?
On java.net there is one (mabon), but it looks like it uses dojo which
then again will introduce some conflicts with the tomahawk-sandbox dojo.
Some javascript which again updates only the specific model fields and
executed a method then where you can use the return value in javascript
then again.
Something like:
// invoke(method, form-to-use, fields-to-send-and-process,
return-values-to-gather-from)
var returnArray[] =
BackingBeanExecutor.invoke(#{backingBeanName.method}, form,
{country, zip}, {city})
formField.value=returnArray[0];
In contrast to other remoting implementations this will really update
the model data and gather the value again from the components. Thus, the
converter/validation stuff will happen here too.
Ideas?
Ciao,
Mario
For those interested - the current view snipped:
h:outputLabel for=land value=Land/
h:selectOneMenu id=land value=#{prCustomerRegistration.land}
required=true
f:selectItems value=#{prCustomerRegistration.laender}/
s:submitOnEvent event=change for=searchCity/
/h:selectOneMenu
h:outputLabel for=plz value=Plz/
h:panelGroup
h:inputText id=plz value=#{prCustomerRegistration.plz} size=5
maxlength=5 required=true
s:submitOnEvent event=change for=searchCity/
/h:inputText
h:outputText value= Ort /
s:pprPanelGroup
partialTriggers=searchCity,searchCityOverride,searchCityReset
h:inputText id=ort value=#{prCustomerRegistration.ort}
size=30
maxlength=40
s:submitOnEvent event=change for=searchCityOverride/
/h:inputText
s:pprSubmit processComponentIds=land,plz,ort
h:commandLink id=searchCityReset
action=#{prCustomerRegistration.searchCityResetAction}
rendered=#{!prCustomerRegistration.useOrtAutomatic and not empty
prCustomerRegistration.ortAutomatic and prCustomerRegistration.ort ne
prCustomerRegistration.ortAutomatic}
h:outputText value=Ort
'#{prCustomerRegistration.ortAutomatic}' übernehmen./
/h:commandLink
/s:pprSubmit
/s:pprPanelGroup
s:pprSubmit processComponentIds=land,plz,ort
h:commandButton id=searchCityOverride
value=searchCityOverride
action=#{prCustomerRegistration.searchCityOverrideAction}
style=display:none;/
h:commandButton id=searchCity value=searchCity
ppr component update funcation hook [was: Re: country/zip show city problem]
Hi! What do you think about an enhancement for ppr which allows to customize the DOM update of the response? So, instead of the simple domElement.innerHtml=xx stuff, one is able to hook into that and provide his/hers own dom update. s:pprPanelGroup componentUpdateFunction=javascript-function-name/ where javascript-function-name points to a function with the signature of function(componentDataInResponse, targetDomElement) All the script handling will stay the same with this solution: If there is a script tag in the resulting innerHTML it will be executed. That way I'll be able to have a function like pprResponseCopyValuesOnly() which will not replace the whole DOM but just the wanted attributes of a given element. Later on we can also add a domUpdateFunction which will replace most of the ppr.handleCallback logic ... but that is another story. Thoughts? Ciao, Mario
