[jira] [Updated] (JSPWIKI-1032) layout and img src fixes
[ https://issues.apache.org/jira/browse/JSPWIKI-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits updated JSPWIKI-1032: -- Attachment: fixed_image_src_link_fixed_layout_in_ie_11.patch > layout and img src fixes > > > Key: JSPWIKI-1032 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1032 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.10.3 >Reporter: Mario Ivankovits >Priority: Trivial > Attachments: fixed_image_src_link_fixed_layout_in_ie_11.patch > > > The attaches patch will fix: > * Use image "src" attribute instead of "href" > * Rendering glitches in IE 11 due to different interpretation of flex > http://stackoverflow.com/questions/21600345/flexbox-and-internet-explorer-11-displayflex-in-html > > "IE10 and IE11 default values for flex are 0 0 auto rather than 0 1 auto, > > as per the draft spec, as of September 2013" > > So in plain words, if somewhere in your CSS you have something like this: > > flex:1 , that is not translated the same way in all browsers. Try changing > > it > > to 1 0 0 and I believe you will immediately see that it -kinda- works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JSPWIKI-1032) layout and img src fixes
Mario Ivankovits created JSPWIKI-1032: - Summary: layout and img src fixes Key: JSPWIKI-1032 URL: https://issues.apache.org/jira/browse/JSPWIKI-1032 Project: JSPWiki Issue Type: Bug Components: Templates and UI Affects Versions: 2.10.3 Reporter: Mario Ivankovits Priority: Trivial Attachments: fixed_image_src_link_fixed_layout_in_ie_11.patch The attaches patch will fix: * Use image "src" attribute instead of "href" * Rendering glitches in IE 11 due to different interpretation of flex http://stackoverflow.com/questions/21600345/flexbox-and-internet-explorer-11-displayflex-in-html > "IE10 and IE11 default values for flex are 0 0 auto rather than 0 1 auto, > as per the draft spec, as of September 2013" > So in plain words, if somewhere in your CSS you have something like this: > flex:1 , that is not translated the same way in all browsers. Try changing it > to 1 0 0 and I believe you will immediately see that it -kinda- works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-928) Array out of bounds in IgniteUtils.filterReachable
Mario Ivankovits created IGNITE-928:
---
Summary: Array out of bounds in IgniteUtils.filterReachable
Key: IGNITE-928
URL: https://issues.apache.org/jira/browse/IGNITE-928
Project: Ignite
Issue Type: Bug
Components: general
Environment: Ignite 1.0.5
Reporter: Mario Ivankovits
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)
public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;
if (addrs.isEmpty())
return Collections.emptyList();
if (addrs.size() == 1) {
if (reachable(addrs.get(1), reachTimeout))
return Collections.singletonList(addrs.get(1));
return Collections.emptyList();
}
Regards,
Mario
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-928) Array out of bounds in IgniteUtils.filterReachable
[
https://issues.apache.org/jira/browse/IGNITE-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits updated IGNITE-928:
Description:
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)
{noformat}
public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;
if (addrs.isEmpty())
return Collections.emptyList();
if (addrs.size() == 1) {
if (reachable(addrs.get(1), reachTimeout))
return Collections.singletonList(addrs.get(1));
return Collections.emptyList();
}
{noformat}
Regards,
Mario
was:
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)
public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;
if (addrs.isEmpty())
return Collections.emptyList();
if (addrs.size() == 1) {
if (reachable(addrs.get(1), reachTimeout))
return Collections.singletonList(addrs.get(1));
return Collections.emptyList();
}
Regards,
Mario
Array out of bounds in IgniteUtils.filterReachable
--
Key: IGNITE-928
URL: https://issues.apache.org/jira/browse/IGNITE-928
Project: Ignite
Issue Type: Bug
Components: general
Environment: Ignite 1.0.5
Reporter: Mario Ivankovits
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)
{noformat}
public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;
if (addrs.isEmpty())
return Collections.emptyList();
if (addrs.size() == 1) {
if (reachable(addrs.get(1), reachTimeout))
return Collections.singletonList(addrs.get(1));
return Collections.emptyList();
}
{noformat}
Regards,
Mario
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-928) Array out of bounds in IgniteUtils.filterReachable
[
https://issues.apache.org/jira/browse/IGNITE-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits updated IGNITE-928:
Description:
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)
public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;
if (addrs.isEmpty())
return Collections.emptyList();
if (addrs.size() == 1) {
if (reachable(addrs.get(1), reachTimeout))
return Collections.singletonList(addrs.get(1));
return Collections.emptyList();
}
Regards,
Mario
was:
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)
public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;
if (addrs.isEmpty())
return Collections.emptyList();
if (addrs.size() == 1) {
if (reachable(addrs.get(1), reachTimeout))
return Collections.singletonList(addrs.get(1));
return Collections.emptyList();
}
Regards,
Mario
Array out of bounds in IgniteUtils.filterReachable
--
Key: IGNITE-928
URL: https://issues.apache.org/jira/browse/IGNITE-928
Project: Ignite
Issue Type: Bug
Components: general
Environment: Ignite 1.0.5
Reporter: Mario Ivankovits
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)
public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;
if (addrs.isEmpty())
return Collections.emptyList();
if (addrs.size() == 1) {
if (reachable(addrs.get(1), reachTimeout))
return Collections.singletonList(addrs.get(1));
return Collections.emptyList();
}
Regards,
Mario
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (VFS-210) Wrapper-Mode VFS
[ https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999688#comment-13999688 ] Mario Ivankovits commented on VFS-210: -- Hi Bernd! Sorry for my late response. Sure, you can do whatever it requires to keep the project running! Thanks for that! Best regards, Mario Wrapper-Mode VFS Key: VFS-210 URL: https://issues.apache.org/jira/browse/VFS-210 Project: Commons VFS Issue Type: Improvement Affects Versions: 1.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 2.1 VFS should behave more like a wrapper to the underlaying library than a full blown filesystem. This should solve the following problems: * access of hidden files/directories * access to special folders * speed up FTP access -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] Created: (VFS-307) VFS issues a lot of FTP commands when listing a directory
VFS issues a lot of FTP commands when listing a directory - Key: VFS-307 URL: https://issues.apache.org/jira/browse/VFS-307 Project: Commons VFS Issue Type: Improvement Reporter: Mario Ivankovits Hello Mario, We at JetBrains are implementing support for (S)FTP sync in our IDEs using Commons VFS. When looking at the performance, we noticed that FTP provider is somewhat not perfect: see my discussion with Ralph. So the question is: why FtpClientWrapper changes the current directory to issue 'LIST' command and restoring it back afterwards instead of issuing single 'LIST relpath'? Subversion says it was you who introduced this behavior far back in 2008. Hope you remember those times and reason why you did this. Thanks a lot in advance, Kirill Safonov JetBrains, Inc http://www.jetbrains.com Develop with pleasure! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-307) VFS issues a lot of FTP commands when listing a directory
[ https://issues.apache.org/jira/browse/VFS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863727#action_12863727 ] Mario Ivankovits commented on VFS-307: -- The change happened when implementing the umbrella issue [1] more concret it was the issue [2] for which we did this. Hmmm ... So, I see three ways to move on: 1) leave as is, which surely is a performance penalty and not good for any DIE 2) change to try first LIST path and fallback to the current way if directory is not found 3) change to LIST path and try to escape the path in a way which makes it work with spaces in it I'll try to see if I can make 3 work and go up the list then :-) VFS issues a lot of FTP commands when listing a directory - Key: VFS-307 URL: https://issues.apache.org/jira/browse/VFS-307 Project: Commons VFS Issue Type: Improvement Reporter: Mario Ivankovits Hello Mario, We at JetBrains are implementing support for (S)FTP sync in our IDEs using Commons VFS. When looking at the performance, we noticed that FTP provider is somewhat not perfect: see my discussion with Ralph. So the question is: why FtpClientWrapper changes the current directory to issue 'LIST' command and restoring it back afterwards instead of issuing single 'LIST relpath'? Subversion says it was you who introduced this behavior far back in 2008. Hope you remember those times and reason why you did this. Thanks a lot in advance, Kirill Safonov JetBrains, Inc http://www.jetbrains.com Develop with pleasure! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-307) VFS issues a lot of FTP commands when listing a directory
[ https://issues.apache.org/jira/browse/VFS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved VFS-307. -- Fix Version/s: Nightly Builds Resolution: Fixed Please give it a try VFS issues a lot of FTP commands when listing a directory - Key: VFS-307 URL: https://issues.apache.org/jira/browse/VFS-307 Project: Commons VFS Issue Type: Improvement Reporter: Mario Ivankovits Fix For: Nightly Builds Hello Mario, We at JetBrains are implementing support for (S)FTP sync in our IDEs using Commons VFS. When looking at the performance, we noticed that FTP provider is somewhat not perfect: see my discussion with Ralph. So the question is: why FtpClientWrapper changes the current directory to issue 'LIST' command and restoring it back afterwards instead of issuing single 'LIST relpath'? Subversion says it was you who introduced this behavior far back in 2008. Hope you remember those times and reason why you did this. Thanks a lot in advance, Kirill Safonov JetBrains, Inc http://www.jetbrains.com Develop with pleasure! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-307) VFS issues a lot of FTP commands when listing a directory
[ https://issues.apache.org/jira/browse/VFS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863765#action_12863765 ] Mario Ivankovits commented on VFS-307: -- It seems there is no FTP spec which allows to escape/quote a path so that it works on each and every ftp server. So I landed at solution 2 similar to what the patch in VFS-123 proposed. It seems to work with my ftp server. VFS issues a lot of FTP commands when listing a directory - Key: VFS-307 URL: https://issues.apache.org/jira/browse/VFS-307 Project: Commons VFS Issue Type: Improvement Reporter: Mario Ivankovits Fix For: Nightly Builds Hello Mario, We at JetBrains are implementing support for (S)FTP sync in our IDEs using Commons VFS. When looking at the performance, we noticed that FTP provider is somewhat not perfect: see my discussion with Ralph. So the question is: why FtpClientWrapper changes the current directory to issue 'LIST' command and restoring it back afterwards instead of issuing single 'LIST relpath'? Subversion says it was you who introduced this behavior far back in 2008. Hope you remember those times and reason why you did this. Thanks a lot in advance, Kirill Safonov JetBrains, Inc http://www.jetbrains.com Develop with pleasure! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-349) ignore exception during type hierarchy scan
ignore exception during type hierarchy scan --- Key: OWB-349 URL: https://issues.apache.org/jira/browse/OWB-349 Project: OpenWebBeans Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Environment: JDK 1.6.0_17 Reporter: Mario Ivankovits Assignee: Gurkan Erdogdu Attachments: invalid_superclass_type.patch During classpath scan OWB crashes with an MalformedParameterizedTypeException exception. This exception happens in ClassUtils.setTypeHierarchy when trying to get the GenericSuperclass. It seems I can not fix this exception on my side as the code compiles and works fine and the class I inherit from is a class of a used library. I think the system should not fail anyway. A warning that a type needs to be ignored should be enough ... Attached is a patch which makes OWB correctly startup here by doing so. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[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) at
[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) at
[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.
[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.
[jira] Commented: (VFS-203) FileObject..getName().getURI() returns URIs with spaces
[ https://issues.apache.org/jira/browse/VFS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675791#action_12675791 ] Mario Ivankovits commented on VFS-203: -- Hmmm normally escaping these special charachters should do the trick, e.g. %20 instead of space. It might not look nice, but this is how URIs work (IMHO) FileObject..getName().getURI() returns URIs with spaces --- Key: VFS-203 URL: https://issues.apache.org/jira/browse/VFS-203 Project: Commons VFS Issue Type: Bug Affects Versions: 1.0 Reporter: Tim Lebedkov Windows supports file names with spaces and '#'. AFAIK spaces are not allowed in URIs and # will be interpreted as an URI fragment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-106) VFS Truezip provider
[ https://issues.apache.org/jira/browse/VFS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12661856#action_12661856 ] Mario Ivankovits commented on VFS-106: -- commons-compress is on the way of providing writable zip support (and probably others), no need to get truezip into play here. Would be great if someone could have a at integrating commons-compress trunk into a new filesystem in vfs-sandbox. VFS Truezip provider - Key: VFS-106 URL: https://issues.apache.org/jira/browse/VFS-106 Project: Commons VFS Issue Type: New Feature Reporter: Filip Defoort Attachments: TzFileObject.java, TzFileProvider.java, TzFileSystem.java, vfs-tz.patch Attached is a quicky truezip provider to allow for read/write access to zip/tar/... archives. See https://truezip.dev.java.net/ for details on truezip. Let me know how you want to proceed with something like this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-218) .skip() always returns the same number as given as parameter while the stream itself may or may not skip to given position
[
https://issues.apache.org/jira/browse/VFS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved VFS-218.
--
Resolution: Invalid
Hi!
... and so does this code snippet
{code}
FileInputStream fis = new FileInputStream(C:/temp/bla.txt);
long skipped = fis.skip(9L);
System.out.println(skipped+ = prints 9, this should be 6 as
per javadoc's specification; +
http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#skip(long));
{code}
And this is due to a bug/feature in java [1] which has already been added to
the documentation of FileInputStream [2].
Clearly, FileInputStream breaks the contract of its interface.
Seems like you are out of luck.
Ciao,
Mario
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6294974
[2] http://java.sun.com/javase/6/docs/api/java/io/FileInputStream.html
.skip() always returns the same number as given as parameter while the stream
itself may or may not skip to given position
--
Key: VFS-218
URL: https://issues.apache.org/jira/browse/VFS-218
Project: Commons VFS
Issue Type: Bug
Affects Versions: 1.0
Environment: Java 5, using jdk1.6.0_06 on Windows XP SP3
Reporter: Not Telling
The code below should reproduce the bug, so far I've tested this with file:
and res: file systems and at least those two expose this bug. As you may
notice from the source, you should have file called bla.txt containing
blabla (6 characters) in your C:\temp\ folder for this.
{code:title=VFSStreamSkipping.java}
import java.io.IOException;
import java.io.InputStream;
import org.apache.commons.vfs.FileObject;
import org.apache.commons.vfs.FileSystemException;
import org.apache.commons.vfs.FileSystemManager;
import org.apache.commons.vfs.VFS;
/**
* This class demonstrates buggy behaviour of .skip() when using VFS.
* The bug is that no matter how many bytes were actually skipped, .skip()
* always returns the same number as the user tried to skip. The stream itself
* may get skipped though, if one tries to read the stream in this example
* after .skip(), it will return -1 indicating that .skip() was executed
* properly.
*/
public class VFSStreamSkipping {
public static void main(String[] args) {
FileObject file;
FileSystemManager fsm;
try {
fsm = VFS.getManager();
} catch (FileSystemException e) {
fsm = null;
}
InputStream is = null;
try {
file = fsm.resolveFile(file:C:/temp/bla.txt);
// file content is simply blabla with no \n or \r
is = file.getContent().getInputStream();
} catch (FileSystemException e) {}
try {
long skipped = is.skip(9L);
System.out.println(skipped+ = prints 9, this should
be 6 as per javadoc's specification; +
http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#skip(long));
System.out.println(is.read());
} catch (IOException e) {}
}
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[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.
[jira] Commented: (VFS-210) Wrapper-Mode VFS
[
https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599578#action_12599578
]
Mario Ivankovits commented on VFS-210:
--
Yes!
I haven't changed the API so far and I do not plan to do so. There are just a
few changes in the contract VFS had with some of it's abstract methods in
AbstractFileObject. Nothing too serious so far.
If your code does something like this ...
FileObject fo = VFS.getManager().resolveFile(ftp://xyz/;);
if (fo.getType().hasChildren())
{
// traverse fo
fo.getChildren();
}
... you should not see any changes. But you could also not expect any
performance increase as you called getType().
With the commits today you will be able to:
FileObject fo = VFS.getManager().resolveFile(ftp://xyz/;);
// traverse fo
fo.getChildren();
This will no longer call getType(), not in your code nor within VFS. Thus, it
is no longer required to list the parent directory which was a real pain.
You will get a FileNotFolderException from getChildren() if the file wasn't a
directory instead.
Both modes work in parallel. It just depends on the way how you use the VFS API.
Wrapper-Mode VFS
Key: VFS-210
URL: https://issues.apache.org/jira/browse/VFS-210
Project: Commons VFS
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
Fix For: 2.0
VFS should behave more like a wrapper to the underlaying library than a full
blown filesystem.
This should solve the following problems:
* access of hidden files/directories
* access to special folders
* speed up FTP access
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599580#action_12599580 ] Mario Ivankovits commented on VFS-196: -- Go on an commit it please! Thanks! FTP Provider Does Not Support Symbolic Links Correctly -- Key: VFS-196 URL: https://issues.apache.org/jira/browse/VFS-196 Project: Commons VFS Issue Type: Bug Affects Versions: 1.1 Reporter: James Carman Assignee: James Carman Fix For: 1.1 Attachments: symbolic_links.patch If a directory is a symbolic link, it shows up as file type imaginary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599589#action_12599589 ] Mario Ivankovits commented on VFS-196: -- In VFS 2 we need the first version where nul will be returned in case of listFiles didn't return something which indicates that this was a file and not a directory and thus this file had null children. FTP Provider Does Not Support Symbolic Links Correctly -- Key: VFS-196 URL: https://issues.apache.org/jira/browse/VFS-196 Project: Commons VFS Issue Type: Bug Affects Versions: 1.1 Reporter: James Carman Assignee: James Carman Fix For: 1.1, 2.0 Attachments: symbolic_links.patch If a directory is a symbolic link, it shows up as file type imaginary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599590#action_12599590 ] Mario Ivankovits commented on VFS-196: -- Just in case it is not clear, with first version I mean the null check. The symbolic check stuff should be fine. BTW. In case of isSymbolicLink, you can also use this.getLinkDestination().getName() instead of doing the name-resolve yourself. FTP Provider Does Not Support Symbolic Links Correctly -- Key: VFS-196 URL: https://issues.apache.org/jira/browse/VFS-196 Project: Commons VFS Issue Type: Bug Affects Versions: 1.1 Reporter: James Carman Assignee: James Carman Fix For: 1.1, 2.0 Attachments: symbolic_links.patch If a directory is a symbolic link, it shows up as file type imaginary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (VFS-210) Wrapper-Mode VFS
Wrapper-Mode VFS Key: VFS-210 URL: https://issues.apache.org/jira/browse/VFS-210 Project: Commons VFS Issue Type: Improvement Affects Versions: 1.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 2.0 VFS should behave more like a wrapper to the underlaying library than a full blown filesystem. This should solve the following problems: * access of hidden files/directories * access to special folders * speed up FTP access -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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.
[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.
[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.
[jira] Commented: (TOMAHAWK-1215) Add a communication channel for FacesMessages to the PPRPanelGroup
[ https://issues.apache.org/jira/browse/TOMAHAWK-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583297#action_12583297 ] Mario Ivankovits commented on TOMAHAWK-1215: Why do you transfer the message and not simply the output of the messages component(s)? The problem I see with the current solution is that it do not honor any applied stylesheet/class configuration or a custom messages renderer. Instead you render on client-side - which seems too limiting to me. I see the use case of this solution when I think about the queueing stuff we talked about, but for the common use case of PPR (simple form transmissal) you do not need the messages machine readable. At least having an attribute messages=id,id,id which simply transfers the server side rendered output of those components would be great. Instead of naming it messages= you could also name it more general externalComponents= (or something like that) - Then it will be possible to configure components outside of the current pprPanelGroup - most likely the messages component. Add a communication channel for FacesMessages to the PPRPanelGroup -- Key: TOMAHAWK-1215 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1215 Project: MyFaces Tomahawk Issue Type: New Feature Components: PPRPanelGroup Reporter: Ernst Fastl Assignee: Ernst Fastl Fix For: 1.1.7-SNAPSHOT As any conventional JSF request PPR requests can lead to conversion and validation errors or other events which produce FacesMessages. The PPRPanelGroup should be enhanced to transport these messages in a separate channel (meaning a different type of child element in the xml-response). Optionally a messages-component could be build to which these messages can subsequently be added. Since this component might collect a lot of messages over various PPR requests it could have a clear button or something similar which enables the user to clear the messages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1215) Add a communication channel for FacesMessages to the PPRPanelGroup
[ https://issues.apache.org/jira/browse/TOMAHAWK-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583298#action_12583298 ] Mario Ivankovits commented on TOMAHAWK-1215: Is it true that you collect the messages of all configured components and then add/replace them on all the components on the client side? If you have multiple message components on the page this would mean that each component will receive ALL collected messages, no? Add a communication channel for FacesMessages to the PPRPanelGroup -- Key: TOMAHAWK-1215 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1215 Project: MyFaces Tomahawk Issue Type: New Feature Components: PPRPanelGroup Reporter: Ernst Fastl Assignee: Ernst Fastl Fix For: 1.1.7-SNAPSHOT As any conventional JSF request PPR requests can lead to conversion and validation errors or other events which produce FacesMessages. The PPRPanelGroup should be enhanced to transport these messages in a separate channel (meaning a different type of child element in the xml-response). Optionally a messages-component could be build to which these messages can subsequently be added. Since this component might collect a lot of messages over various PPR requests it could have a clear button or something similar which enables the user to clear the messages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12580264#action_12580264 ] Mario Ivankovits commented on TOMAHAWK-1214: re 1: I'd say we do it like the standard PPR. Using submitOnEvent a button can be clicked. PPR then has that button as partialTrigger configured and intercept the form submission. Now, instead of submitting the form its data will be put into the queue. The tricky thing here is, that on the response the viewState has to be taken and on next request the captured viewState needs to be replaced by the new one. re 2: Since it is a normal request, the normal JSF lifecycle will be executed. Another open question is, what about the response? I'd like to see yet another ppr option (queueResponseUpdate=lazy|eager) with default to eager. On eager, each response will be used to update the browser dom, on lazy, only the last response of a queue will be used. So, if the user executes many successive requests (e.g. through a barcode scanner), there is no need to refresh the user interface all the time. 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.
[jira] Created: (TOMAHAWK-1214) allow to process form submits in a queue for high-speed input handling
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.
[jira] Commented: (ORCHESTRA-17) RequestParameterFacesContextFactory only works with HttpServletResponse
[
https://issues.apache.org/jira/browse/ORCHESTRA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577464#action_12577464
]
Mario Ivankovits commented on ORCHESTRA-17:
---
If I understand your patch correctly this thing will no longer work with plain
jsp, will it?
Some applications mix jsp and jsf pages, even if the jsp page is just a
bridge or something like that. I (we) wanted to support such setup.
But probably I missed some things ;-)
RequestParameterFacesContextFactory only works with HttpServletResponse
---
Key: ORCHESTRA-17
URL: https://issues.apache.org/jira/browse/ORCHESTRA-17
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0, 1.1
Environment: Liferay Portlet Container
Reporter: Martin Marinschek
Assignee: Martin Marinschek
The following snippet wrongly casts to HttpServletResponse, therefore
portlet-environments will not work:
if (response instanceof HttpServletResponse)
{
HttpServletRequest httpServletRequest = (HttpServletRequest)
request;
// Wrap this request only if something else (eg a
RequestParameterServletFilter) has not already wrapped it.
if
(!Boolean.TRUE.equals(httpServletRequest.getAttribute(RequestParameterServletFilter.REQUEST_PARAM_FILTER_CALLED)))
{
I will commit a solution very soon.
regards,
Martin
--
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: (MYFACES-1831) JSF12 UIComponentClassicTagBase.getCreated is broken, breaking t:updateActionListener
[ https://issues.apache.org/jira/browse/MYFACES-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574694#action_12574694 ] imario edited comment on MYFACES-1831 at 3/3/08 11:31 AM: Hmmm ... for what I have seen in my special case the UIComponentClassicTagBase.getCreated returned false and that's why the UpdateActionListenerTag did not configure the parent accordingly. If getCreated would have returned true, it would have worked. Anyway, if there is a bug in the Tag base-class it is worth fixing it, but please do not spend a single hour in fixing the updateActionListener as there is a working JSF standard replacement. Ok, I can't influence what you do in your spare free time ;-) was (Author: imario): Hmmm ... for what I have seen in my special case the UIComponentClassicTagBase.getCreated returned false and that's why the UpdateActionListenerTag did not configure the parent accordingly. If it would have returned getCreated it would have worked. Anyway, if there is a bug in the Tag base-class it is worth fixing it, but please do not spend a single hour in fixing the updateActionListener as there is a working JSF standard replacement. Ok, I can't influence what you do in your spare free time ;-) JSF12 UIComponentClassicTagBase.getCreated is broken, breaking t:updateActionListener - Key: MYFACES-1831 URL: https://issues.apache.org/jira/browse/MYFACES-1831 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Simon Kitching In testing I have found that t:updateActionListener works fine with MyFaces 1.1.x but is ignored with MyFaces 1.2.3-SNAPSHOT After debugging, I found that UIComponentClassicTagBase.getCreated is always returning true. This means that UpdateActionListenerTag always thinks its parent component is already configured, so does not attach an UpdateActionListener instance to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1831) JSF12 UIComponentClassicTagBase.getCreated is broken, breaking t:updateActionListener
[ https://issues.apache.org/jira/browse/MYFACES-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574694#action_12574694 ] Mario Ivankovits commented on MYFACES-1831: --- Hmmm ... for what I have seen in my special case the UIComponentClassicTagBase.getCreated returned false and that's why the UpdateActionListenerTag did not configure the parent accordingly. If it would have returned getCreated it would have worked. Anyway, if there is a bug in the Tag base-class it is worth fixing it, but please do not spend a single hour in fixing the updateActionListener as there is a working JSF standard replacement. Ok, I can't influence what you do in your spare free time ;-) JSF12 UIComponentClassicTagBase.getCreated is broken, breaking t:updateActionListener - Key: MYFACES-1831 URL: https://issues.apache.org/jira/browse/MYFACES-1831 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Simon Kitching In testing I have found that t:updateActionListener works fine with MyFaces 1.1.x but is ignored with MyFaces 1.2.3-SNAPSHOT After debugging, I found that UIComponentClassicTagBase.getCreated is always returning true. This means that UpdateActionListenerTag always thinks its parent component is already configured, so does not attach an UpdateActionListener instance to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-16) Rendering Problem
[ https://issues.apache.org/jira/browse/ORCHESTRA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574249#action_12574249 ] Mario Ivankovits commented on ORCHESTRA-16: --- What I said ... You should see it only on the first response which happens after the session has been created. Tomcat then encodes the URL _and_ sets the cookie. With the next request both will be sent back to tomcat (given cookies are enabled with the broswer) and the ;jsessionid will no longer be added to the link. Given the bug reporter didn't provide any new information I am going to close this bug. Rendering Problem - Key: ORCHESTRA-16 URL: https://issues.apache.org/jira/browse/ORCHESTRA-16 Project: MyFaces Orchestra Issue Type: Bug Environment: Spring, Apache Orchestra, JSF RI 1.2, Custom Components Reporter: Miroslav Genov It seems that there is a problem when any control is trying to access servlet for rendering of an image. I have an image verification component which is rendered as: img id=loginForm:verification_image src=/jadm-web/resourceServlet;jsessionid=CB3A2751A2FEF9823DE59A281AFA1BF0?imgId=14590567251000conversationContext=1 alt= height=40 width=100 / Any idea why orchestra places ; after servlet name.? This is the code which I'm using to render the image element. String src = / + ResourceServlet.RESOURCE_SERVLET_MAPPING + ?imgId= + id; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-16) Rendering Problem
[ https://issues.apache.org/jira/browse/ORCHESTRA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573021#action_12573021 ] Mario Ivankovits commented on ORCHESTRA-16: --- This has nothing to do with orchestra. The ;jsessionid will be added by the servlet container (tomcat) on the first response or always if cookies are disabled (either server side or client side). HttpServletResponse.encodeUrl [1] is responsible for this. Ciao, Mario [1] http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpServletResponse.html#encodeURL(java.lang.String) Rendering Problem - Key: ORCHESTRA-16 URL: https://issues.apache.org/jira/browse/ORCHESTRA-16 Project: MyFaces Orchestra Issue Type: Bug Environment: Spring, Apache Orchestra, JSF RI 1.2, Custom Components Reporter: Miroslav Genov It seems that there is a problem when any control is trying to access servlet for rendering of an image. I have an image verification component which is rendered as: img id=loginForm:verification_image src=/jadm-web/resourceServlet;jsessionid=CB3A2751A2FEF9823DE59A281AFA1BF0?imgId=14590567251000conversationContext=1 alt= height=40 width=100 / Any idea why orchestra places ; after servlet name.? This is the code which I'm using to render the image element. String src = / + ResourceServlet.RESOURCE_SERVLET_MAPPING + ?imgId= + id; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1193) add columnId to t:column
[ https://issues.apache.org/jira/browse/TOMAHAWK-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved TOMAHAWK-1193. Resolution: Fixed add columnId to t:column Key: TOMAHAWK-1193 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1193 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT Add a columnId to t:column similar to the rowId on t:datatable the provided id should not render any namespace. Just take the provided user value as is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1193) add columnId to t:column
add columnId to t:column Key: TOMAHAWK-1193 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1193 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT Add a columnId to t:column similar to the rowId on t:datatable the provided id should not render any namespace. Just take the provided user value as is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1193) add columnId to t:column
[ https://issues.apache.org/jira/browse/TOMAHAWK-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566953#action_12566953 ] Mario Ivankovits commented on TOMAHAWK-1193: Together wit this bug the rowId on t:datatable has been fixed to be facelets compatible add columnId to t:column Key: TOMAHAWK-1193 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1193 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT Add a columnId to t:column similar to the rowId on t:datatable the provided id should not render any namespace. Just take the provided user value as is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-15) Orchestra in Portal Environment
[ https://issues.apache.org/jira/browse/ORCHESTRA-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566531#action_12566531 ] Mario Ivankovits commented on ORCHESTRA-15: --- I've commited a try to fix this issue. By checking out Orchestra from svn using [1] you should be able to mvn install your own version. Afterwards you can copy the resulting jar to your project and give it a try. Or wait for the next nightly. I am not sure if there is any side effect I've overlooked, but a quick test showed me that the Orchestra at least started up again ;-) Ciao, Mario [1] http://svn.apache.org/repos/asf/myfaces/orchestra/trunk Orchestra in Portal Environment --- Key: ORCHESTRA-15 URL: https://issues.apache.org/jira/browse/ORCHESTRA-15 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.0 Environment: myfaces1.1.5, liferay portal4.3.3, orchestra-core1.0, tomcat 5.5 Reporter: Rashmi Priority: Blocker In the portlet environment ConversationManager is not getting initialized. The FrameworkAdapter.getCurrentInstance() is as well NULL. The part of the exception is as follows: Caused by: java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:90) at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:76) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.getBean(AbstractSpringOrchestraScope.java:125) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.get(AbstractSpringOrchestraScope.java:117) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:661) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:611) at de.seat.mitarbeiterinfo.view.mitarbeiterlist$$EnhancerByCGLIB$$4f90561b.getMitarbeiterListModel(generated) ... 125 more The filter is not working as expected in Portlet environment but works perfetly well in norman Servlet container. Can myfaces-portlet-bridge be used in someway to configure the filter to run in portlet environment? Thanks and Regards, Rashmi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1181) allow to embed a datatable within the parent
[ https://issues.apache.org/jira/browse/TOMAHAWK-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566287#action_12566287 ] Mario Ivankovits commented on TOMAHAWK-1181: Three new attribute on the datatable have been added: embedded true|false Render the table in the embedded mode (no table/thead/tfoot/th tags will be used) detailStampLocation after|before Render the detailStamp after of before the row of the master table. before allow you to treat the master table as a list of summs of the child tables data. detailStampExpandedDefault true|false Render all the details by default. No further special header handling for now, lets have a look if this is enough for now. allow to embed a datatable within the parent Key: TOMAHAWK-1181 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1181 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT As discussed in this thread http://marc.info/?l=myfaces-devm=120118289000330w=2 add a new attribute to the datatable which allows to reuse the layout of the parent table. The attribute name so far is embed=true|false where false is the default. When embed=true: * avoid rendering the table start/end tag * do not add the thead/tfoot tags around the header or footer - instead simply render them at the start/end of the embedded table * do not render the header cells using the th tag Probably we have to think about another way how to define the header on the parent datatable. Not sure about that yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1181) allow to embed a datatable within the parent
[ https://issues.apache.org/jira/browse/TOMAHAWK-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved TOMAHAWK-1181. Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Assignee: Mario Ivankovits allow to embed a datatable within the parent Key: TOMAHAWK-1181 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1181 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.1.7-SNAPSHOT As discussed in this thread http://marc.info/?l=myfaces-devm=120118289000330w=2 add a new attribute to the datatable which allows to reuse the layout of the parent table. The attribute name so far is embed=true|false where false is the default. When embed=true: * avoid rendering the table start/end tag * do not add the thead/tfoot tags around the header or footer - instead simply render them at the start/end of the embedded table * do not render the header cells using the th tag Probably we have to think about another way how to define the header on the parent datatable. Not sure about that yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-195) Unable to get Zip file URL working on Windows machine
[ https://issues.apache.org/jira/browse/VFS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563142#action_12563142 ] Mario Ivankovits commented on VFS-195: -- Hmmm I think the examples on our web-page [1] are rather self-explaining, aren't they? I had no chance to test this on a windows machine yet, but my try on linux with the latest VFS snapshot the following worked: FileObject fo = VFS.getManager().resolveFile(zip:file:///home/im/Downloads/commons-compress-draft.zip); or FileObject fo = VFS.getManager().resolveFile(zip:file:///home/im/Downloads/commons-compress-draft.zip!/); If you do not use VFS.getManager() you have to ensure you setup VFS correctly e.g. by adding all wanted providers. As always, please try the latest nightly build too. BTW: Please do not use JIRA as disuccsion platform. I am going to close this bug again and looking forward that we help you on the user list until we all conclude that this is a bug. Ciao, Mario [1] http://commons.apache.org/vfs/filesystems.html#Zip__Jar_and_Tar Unable to get Zip file URL working on Windows machine - Key: VFS-195 URL: https://issues.apache.org/jira/browse/VFS-195 Project: Commons VFS Issue Type: Bug Affects Versions: 1.0 Reporter: Rajiv Kumar Could not get the Zip file URL working on Windows machine? Tried following formats. zip:file:/C:/Temp/source/test.zip --- Invalid Absolute URI zip:file:/C:/Temp/source/test.zip! --- Invalid Absolute URI zip:file://C:/Temp/source/test.zip --- Invalid Absolute URI zip:file:/C:/Temp/source/test.zip! -- Invalid Absolute URI zip://file:/C:/Temp/source/test.zip -- org.apache.commons.vfs.FileSystemException: Could not copy because it does not exist. zip:///C:/Temp/source/test.zip! - Could not copy because it does not exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1181) allow to embed a datatable within the parent
allow to embed a datatable within the parent Key: TOMAHAWK-1181 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1181 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits As discussed in this thread http://marc.info/?l=myfaces-devm=120118289000330w=2 add a new attribute to the datatable which allows to reuse the layout of the parent table. The attribute name so far is embed=true|false where false is the default. When embed=true: * avoid rendering the table start/end tag * do not add the thead/tfoot tags around the header or footer - instead simply render them at the start/end of the embedded table * do not render the header cells using the th tag Probably we have to think about another way how to define the header on the parent datatable. Not sure about that yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1804) Pressing a download button corrupts other button actions in Internet Explorer
[
https://issues.apache.org/jira/browse/MYFACES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits updated MYFACES-1804:
--
Resolution: Duplicate
Status: Resolved (was: Patch Available)
It is so strange.
Two bugs uncovered by different people and filed in sequence. I can't belive it
:-) Way too cool.
MYFACES-1805 fixed it.
Pressing a download button corrupts other button actions in Internet Explorer
-
Key: MYFACES-1804
URL: https://issues.apache.org/jira/browse/MYFACES-1804
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Microsoft internet Explorer 6.0 (not tested for other
versions)
Reporter: Thomas Fischer
Attachments: myfaces-1804.patch, testHiddenInputJavascript.html,
testie.jsp, TestieController.java
Situation: The user accesses a jsf page where a commandlink or commandButton
starts a download, and other commandLinks or CommandButtons are present in
the same form, using the internet explorer as a browser. The user e clicks on
the download Button. Afterwards, the user clicks on any other button in the
same form.
Observed behaviour: The previous download is started again, regardless of the
action associated with the button
Expected behaviour: The action associated with the button should be executed
Analysis: The error originates in the generated javascript function
oamSetHiddenInput(formname, name, value). In this function, it is checked
whether the hidden input already exists, using the javascript code
if(typeof form.elements[name]=='undefined')
This works fine in the Internet explorer as long as the hidden input was
created in html. If the hidden input was created using javascript, e.g. by
the code in the same function, the above condition returns true although the
hidden input already exists. This results in creating a second hidden input
field instead of replacing the value in the existing one. If the server only
uses the value of the first(i.e. already existing) hidden input field, it
gets the old value instead of the new one. In the end, myfaces reads the old
value of the html parameter ${formName}:_idcl, and so the old action is
executed instead of the new one.
Resolution: Accessing the hidden input via indices (form.elements[0],
form.elements[1] ...) also works if the hidden input is created dynamically.
Note that the error does only occur if the page is not reloaded when the
first button is pressed, so a special action as e.g. a download is needed to
trigger the behaviour.
I'd consider this to be a bug in IE, but as we cannot persuade all users to
use a browser which is less buggy, a workaround should be implemented in
myfaces. The error does not occur in Firefox.
As the implementation is in the myfaces_shared project, this affects both
core and tomahawk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-194) Redirect of HTTP url using the header location
[
https://issues.apache.org/jira/browse/VFS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561011#action_12561011
]
Mario Ivankovits commented on VFS-194:
--
could you attach a svn diff with the whole patch please.
Thanks!
Mario
Redirect of HTTP url using the header location
--
Key: VFS-194
URL: https://issues.apache.org/jira/browse/VFS-194
Project: Commons VFS
Issue Type: Wish
Environment: Windows XP/Linux/FreeBSD
Reporter: Yves Zoundi
The http provider classes don't test the header location before resolving a
file. If the redirection is reported as invalid by commons-httpclient, then
the HttpFileObject is not resolved. Here is how to fix it in all the http
provider implementation classes.
int status = 0;//client.executeMethod(method);
try{
status = client.executeMethod(method);
System.out.println(method executed);
}
catch(Exception e){
System.out.println(Exception co);
try{
HostConfiguration config =
client.getHostConfiguration();
Header header =
method.getResponseHeader(Location);
System.out.println(Checking header);
if (header != null) {
String redirectUrl = header.getValue();
config.setHost(new
java.net.URL(redirectUrl).getHost(), config.getPort(), config.getProtocol());
client.setHostConfiguration(config);
status = client.executeMethod(method);
}
}
catch(Exception err){
throw new Exception(err);
}
}
if ((status = 300) (status 400)) {
try{
HostConfiguration config =
client.getHostConfiguration();
Header header =
method.getResponseHeader(Location);
if (header != null) {
String redirectUrl = header.getValue();
method = new HeadMethod();
setupMethod(method);
config.setHost(new
java.net.URL(redirectUrl).getHost(), config.getPort(), config.getProtocol());
client.setHostConfiguration(config);
status = client.executeMethod(method);
}
}
catch(Exception err){
throw new Exception(err);
}
}
method.releaseConnection();
if (status == HttpURLConnection.HTTP_OK)
{
return FileType.FILE;
}
else if (status == HttpURLConnection.HTTP_NOT_FOUND
|| status == HttpURLConnection.HTTP_GONE)
{
return FileType.IMAGINARY;
}
else
{
throw new FileSystemException(vfs.provider.http/head.error,
getName());
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1805) form stopped working after ajax request
form stopped working after ajax request --- Key: MYFACES-1805 URL: https://issues.apache.org/jira/browse/MYFACES-1805 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.1.5 Reporter: Mario Ivankovits In a little bit complicated form using multiple PPR areas the datascroller attached to a datatable stopped working with InternetExplorer after the first ajax request. MyFaces always sent the current page again. It turned out that the code in oamSetHiddenInput is not fully compatible with InternetExplorer. The problem is that even after adding the element to the form using javascript the check for it (typeof form.elements[name]=='undefined') still returns undefined. After setting the id of the created element (beside of it's name) fixed this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1805) form stopped working after ajax request
[ https://issues.apache.org/jira/browse/MYFACES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved MYFACES-1805. --- Resolution: Fixed Fix Version/s: 1.2.2-SNAPSHOT 1.1.6-SNAPSHOT committed to both myfaces version (1.1, 1.2) form stopped working after ajax request --- Key: MYFACES-1805 URL: https://issues.apache.org/jira/browse/MYFACES-1805 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5, 1.2.0 Reporter: Mario Ivankovits Fix For: 1.1.6-SNAPSHOT, 1.2.2-SNAPSHOT In a little bit complicated form using multiple PPR areas the datascroller attached to a datatable stopped working with InternetExplorer after the first ajax request. MyFaces always sent the current page again. It turned out that the code in oamSetHiddenInput is not fully compatible with InternetExplorer. The problem is that even after adding the element to the form using javascript the check for it (typeof form.elements[name]=='undefined') still returns undefined. After setting the id of the created element (beside of it's name) fixed this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1802) FacesException and nested exceptions
[ https://issues.apache.org/jira/browse/MYFACES-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558369#action_12558369 ] Mario Ivankovits commented on MYFACES-1802: --- I'd check the existence of getCause() using reflection as then it will also work with pre Java 1.4 Exceptions implementing getCause() - for example those Exceptions prepared to be backward compatible. FacesException and nested exceptions Key: MYFACES-1802 URL: https://issues.apache.org/jira/browse/MYFACES-1802 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.5 Reporter: Bernhard Huemer Attachments: MyFaces-1802.patch The JSF 1.1 specification requires any implementation to support Java 1.3 and that's why the FacesException isn't allowed to utilize builtin exception chaining mechanisms (i.e. initCause(), etc..) as they have been introduced in Java 1.4. However, the FacesException retains it's cause by delegating to the parent's constructor (for example, super(cause); or super(message, cause);). Although this bug is rather easy to fix, I've assigned the priority level 'Major' as it breaks the specification. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1798) DefaultViewHandlerSupports fails detecting extension if there are dots in the path
DefaultViewHandlerSupports fails detecting extension if there are dots in the
path
--
Key: MYFACES-1798
URL: https://issues.apache.org/jira/browse/MYFACES-1798
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
For example: With /myStrange.path/view.jsp the extension .path/view.jsp
will be derived.
In DefaultViewHandlerSupport a wrong regular expression is used to extract the
extension.
I'll try to change this to a simple string.lastIndexOf('.') as this should do
exactly what we want.
--
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: (MYFACES-1790) HtmlColumnTag.getComponentType returns the wrong value
[ https://issues.apache.org/jira/browse/MYFACES-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1225#action_1225 ] imario edited comment on MYFACES-1790 at 1/3/08 2:19 AM: --- This fixed broke the HtmlColumn component as now is tag (HtmlColumnTag) creates a UIColumn component instead of a HtmlColumn. was (Author: imario): This fixed broke the HtmlColumn component as now it tag creates a UIColumn component instead of a HtmlColumn HtmlColumnTag.getComponentType returns the wrong value -- Key: MYFACES-1790 URL: https://issues.apache.org/jira/browse/MYFACES-1790 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Reporter: Cameron Bateman Assignee: Matthias Weßendorf Fix For: 1.2.1 According to the spec, the component type of the default h:column tag is supposed to be javax.faces.Column, however HtmlColumnTag returns javax.faces.HtmlColumn. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-1790) HtmlColumnTag.getComponentType returns the wrong value
[ https://issues.apache.org/jira/browse/MYFACES-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits reopened MYFACES-1790: --- This fixed broke the HtmlColumn component as now it tag creates a UIColumn component instead of a HtmlColumn HtmlColumnTag.getComponentType returns the wrong value -- Key: MYFACES-1790 URL: https://issues.apache.org/jira/browse/MYFACES-1790 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Reporter: Cameron Bateman Assignee: Matthias Weßendorf Fix For: 1.2.1 According to the spec, the component type of the default h:column tag is supposed to be javax.faces.Column, however HtmlColumnTag returns javax.faces.HtmlColumn. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1798) DefaultViewHandlerSupports fails detecting extension if there are dots in the path
[
https://issues.apache.org/jira/browse/MYFACES-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved MYFACES-1798.
---
Resolution: Fixed
Fix Version/s: 1.2.2-SNAPSHOT
DefaultViewHandlerSupports fails detecting extension if there are dots in the
path
--
Key: MYFACES-1798
URL: https://issues.apache.org/jira/browse/MYFACES-1798
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
Fix For: 1.2.2-SNAPSHOT
For example: With /myStrange.path/view.jsp the extension .path/view.jsp
will be derived.
In DefaultViewHandlerSupport a wrong regular expression is used to extract
the extension.
I'll try to change this to a simple string.lastIndexOf('.') as this should do
exactly what we want.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1798) DefaultViewHandlerSupports fails detecting extension if there are dots in the path
[
https://issues.apache.org/jira/browse/MYFACES-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1267#action_1267
]
Mario Ivankovits commented on MYFACES-1798:
---
I think I fixed the last-dot-after-last-slash issue by searching and comparing
both character positions requiring the last dot after the last slash.
Regarding the double-extension issue. I'll leave this as room for improvements
by the community once required.
DefaultViewHandlerSupports fails detecting extension if there are dots in the
path
--
Key: MYFACES-1798
URL: https://issues.apache.org/jira/browse/MYFACES-1798
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
Fix For: 1.2.2-SNAPSHOT
For example: With /myStrange.path/view.jsp the extension .path/view.jsp
will be derived.
In DefaultViewHandlerSupport a wrong regular expression is used to extract
the extension.
I'll try to change this to a simple string.lastIndexOf('.') as this should do
exactly what we want.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1789) UIData do not honor first and row value binding in decode
UIData do not honor first and row value binding in decode - Key: MYFACES-1789 URL: https://issues.apache.org/jira/browse/MYFACES-1789 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits UIData do not honor first and row value binding in decode. If rows= and first= points to a valueBinding during decode these values will not correctly taken by evaluating the valuebinding but the local literal values will be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1789) UIData do not honor first and row value binding in decode
[ https://issues.apache.org/jira/browse/MYFACES-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved MYFACES-1789. --- Resolution: Fixed Don't know the current release status, so leaving Unknown as Fix Version for now. UIData do not honor first and row value binding in decode - Key: MYFACES-1789 URL: https://issues.apache.org/jira/browse/MYFACES-1789 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits UIData do not honor first and row value binding in decode. If rows= and first= points to a valueBinding during decode these values will not correctly taken by evaluating the valuebinding but the local literal values will be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-13) RequestParameterProviderManager fails when template URL includes EL expressions
[
https://issues.apache.org/jira/browse/ORCHESTRA-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548721
]
Mario Ivankovits commented on ORCHESTRA-13:
---
But the RequestParameterProvidedManager should not see any url with
el-expressions in it.
The UrlParameterNavigationHandler should have replaced them all.
If this didn't work I see two possible problems:
1) UrlParameterNavigationHandler is not configured correctly (needs to be done
manually, is not setup by orchestra)
2) The UrlParameterNavigationHandler is broken :-(
RequestParameterProviderManager fails when template URL includes EL
expressions
---
Key: ORCHESTRA-13
URL: https://issues.apache.org/jira/browse/ORCHESTRA-13
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0
Reporter: Simon Kitching
As reported by Jonas Esser on the mailing list, a url of form
http://foo.example?productId=#{var}
fails badly; the final url is:
http://foo.example?productId=contextId=1val
This occurs in the petstore orchestra example, when viewing a product's
details.
The problem is that RequestParameterProvidedManager thinks the # is a url
fragment marker. Query params go before fragment markers, eg
http://foo.example?productId=5#anchor
does correctly become
http://foo.example?productId=5contextId=1#anchor
But #{...} is NOT an anchor. In the petstore example, the url can be found in
faces-config.xml:
navigation-case
from-outcomeProductDetails/from-outcome
to-view-id/mops/ProductDetail.jsp?productId=#{param.productId}/to-view-id
redirect/
/navigation-case
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1755) create converter with unknown id fails with NPE
create converter with unknown id fails with NPE --- Key: MYFACES-1755 URL: https://issues.apache.org/jira/browse/MYFACES-1755 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.2.1-SNAPSHOT see summary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1755) create converter with unknown id fails with NPE
[ https://issues.apache.org/jira/browse/MYFACES-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved MYFACES-1755. --- Resolution: Fixed create converter with unknown id fails with NPE --- Key: MYFACES-1755 URL: https://issues.apache.org/jira/browse/MYFACES-1755 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.2.1-SNAPSHOT see summary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1752) old tags like htmlTag throws NPE
[ https://issues.apache.org/jira/browse/MYFACES-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved MYFACES-1752. --- Resolution: Duplicate MYFACES-1746 Wasn't aware that this has been uncovered already ... old tags like htmlTag throws NPE -- Key: MYFACES-1752 URL: https://issues.apache.org/jira/browse/MYFACES-1752 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.2.1-SNAPSHOT Tags like the t:htmlTag fail with this NPE Caused by: java.lang.NullPointerException at org.apache.myfaces.custom.htmlTag.HtmlTagRenderer.encodeBegin(HtmlTagRenderer.java:50) at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:528) ... 83 more when running with MyFaces 1.2 After applying this patch Index: api/src/main/java/javax/faces/webapp/UIComponentTag.java === --- api/src/main/java/javax/faces/webapp/UIComponentTag.java(Revision 588035) +++ api/src/main/java/javax/faces/webapp/UIComponentTag.java(Arbeitskopie) @@ -143,6 +143,7 @@ UIComponent component = context.getApplication().createComponent(componentType); component.setId(id); +setProperties(component); return component; things started working for me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1753) Do not require to buffer the output with server-side-state-saving
Do not require to buffer the output with server-side-state-saving
-
Key: MYFACES-1753
URL: https://issues.apache.org/jira/browse/MYFACES-1753
Project: MyFaces Core
Issue Type: Improvement
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
Attachments: no_buffer.diff
Attached you will find a patch against MyFaces 1.2.1 head which will eliminate
the need to buffer the output to write in the ViewState hidden field when using
Server-Side-State-Saving.
With just a sequence number (previously jsf_sequence) will be written into
the ViewState hidden field.
This patch changes just this, and avoid the use of the StateAwareWriter. The
restore process based on the jsf_sequence already worked, just minor
restructuring to get the next sequence number early.
When using Facelets, you'll also need a ViewHandler with the following content:
public void renderView(FacesContext context, UIViewRoot uiRoot) throws
IOException, FacesException
{
StateManager stateManager =
context.getApplication().getStateManager();
original.renderView(context, uiRoot);
stateManager.saveView(context);
}
public void writeState(FacesContext context) throws IOException
{
StateManager stateManager =
context.getApplication().getStateManager();
if (stateManager.isSavingStateInClient(context))
{
original.writeState(context);
}
else
{
stateManager.writeState(context, new Object[2]);
}
}
This disables the Facelets own state handling and ensures we save the view
after rendering.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1752) old tags like htmlTag throws NPE
old tags like htmlTag throws NPE -- Key: MYFACES-1752 URL: https://issues.apache.org/jira/browse/MYFACES-1752 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.2.1-SNAPSHOT Tags like the t:htmlTag fail with this NPE Caused by: java.lang.NullPointerException at org.apache.myfaces.custom.htmlTag.HtmlTagRenderer.encodeBegin(HtmlTagRenderer.java:50) at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:528) ... 83 more when running with MyFaces 1.2 After applying this patch Index: api/src/main/java/javax/faces/webapp/UIComponentTag.java === --- api/src/main/java/javax/faces/webapp/UIComponentTag.java(Revision 588035) +++ api/src/main/java/javax/faces/webapp/UIComponentTag.java(Arbeitskopie) @@ -143,6 +143,7 @@ UIComponent component = context.getApplication().createComponent(componentType); component.setId(id); +setProperties(component); return component; things started working for me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-178) Indicate that passive FTP (and other options) should be used when writing to a FTP location
[ https://issues.apache.org/jira/browse/VFS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537229 ] Mario Ivankovits commented on VFS-178: -- Sorry for being so busy lately with other things This patch is just for vfs.passive and just for ftp, but we need a more general solution for this by using the DelegatingFileSystemOptionsBuilder.setConfigString() method. Done right it will immediately allow to set any configuration exposed through the various FileSystemOptionBuilders ... and any future addition too - as long as it is possible to create the required value-type out of a simple string. Indicate that passive FTP (and other options) should be used when writing to a FTP location --- Key: VFS-178 URL: https://issues.apache.org/jira/browse/VFS-178 Project: Commons VFS Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Asankha C. Perera Attachments: vfs-ftp.patch I am trying to use VFS to connect to a FTP file, but the problem is that I cannot specify that PASSIVE mode should be used. I think we could use the format below to specify for example: ?passive=true etc. ftp://myusername:[EMAIL PROTECTED]/pub/downloads/somefile.tgz?option=value Referece thread http://mail-archives.apache.org/mod_mbox/commons-dev/200709.mbox/[EMAIL PROTECTED] I think the use of the ?? would not be a good URI scheme. However, maybe we could simply make the VFS parameters unique. For example add vfs. in front of them. For example, http://www/path/cgi-bin/send.pl?FILE=ABCTYPE=PDFvfs.proxyHost=proxy.hostvfs.proxyPort=8080 Yes, for sure, this could make it too - I thought about it too. Even if I am still not that happy with this query-string parsing/repacking stuff I'd commit it if someone contributes a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-5) Unable to load orchestra into eclipse
[ https://issues.apache.org/jira/browse/ORCHESTRA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-5. -- Resolution: Won't Fix Assignee: Mario Ivankovits Looks like we wont fix this just for eclipse. Sorry! Unable to load orchestra into eclipse - Key: ORCHESTRA-5 URL: https://issues.apache.org/jira/browse/ORCHESTRA-5 Project: MyFaces Orchestra Issue Type: Wish Environment: xp, eclipse 3.3 Reporter: Dan Tran Assignee: Mario Ivankovits this problem is related to http://jira.codehaus.org/browse/MECLIPSE-317 where one can generate eclipse project files using mvn eclipse:eclipse. However after loading the project into eclipse, core15 and examples are not buildable However, rather waiting for this fix, I would suggest we rename all module directory names to match with corresponding artifactIds - svn move core myfaces-orchestra-core - svn move core15 myfaces-orchestra-core15 - svn move examples myfaces-orchestra-examples - remove SCM elements in all sub module, we dont need them any more - rename artifactId of the example from myface-orchestra-examples-project to myfaces-orchestra-examples This will make the Orchestra adoption a bit easier for new developer who main IDE is eclipse. I just did it in my local disk, It works great. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-7) Deal with # urls
Deal with # urls -- Key: ORCHESTRA-7 URL: https://issues.apache.org/jira/browse/ORCHESTRA-7 Project: MyFaces Orchestra Issue Type: Improvement Components: RequestParameterProvider Reporter: Mario Ivankovits Assignee: Mario Ivankovits Orchestra do not correctly add the fields to # urls -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-7) Deal with # urls
[ https://issues.apache.org/jira/browse/ORCHESTRA-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-7. -- Resolution: Fixed Fix Version/s: 1.1 Deal with # urls -- Key: ORCHESTRA-7 URL: https://issues.apache.org/jira/browse/ORCHESTRA-7 Project: MyFaces Orchestra Issue Type: Improvement Components: RequestParameterProvider Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.1 Orchestra do not correctly add the fields to # urls -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-8) Orchestra do not send an @InitView notification to the ViewController during a non redirect navigation
Orchestra do not send an @InitView notification to the ViewController during a non redirect navigation -- Key: ORCHESTRA-8 URL: https://issues.apache.org/jira/browse/ORCHESTRA-8 Project: MyFaces Orchestra Issue Type: Bug Components: ViewController Affects Versions: 1.0 Environment: JSF 1.1 Facelets Reporter: Mario Ivankovits Assignee: Mario Ivankovits The lifecycle is as follows: BEFORE RESTORE_VIEW(1): null AFTER RESTORE_VIEW(1): /all.xhtml BEFORE APPLY_REQUEST_VALUES(2): /all.xhtml AFTER APPLY_REQUEST_VALUES(2): /all.xhtml BEFORE PROCESS_VALIDATIONS(3): /all.xhtml AFTER PROCESS_VALIDATIONS(3): /all.xhtml BEFORE UPDATE_MODEL_VALUES(4): /all.xhtml AFTER UPDATE_MODEL_VALUES(4): /all.xhtml BEFORE INVOKE_APPLICATION(5): /all.xhtml AFTER INVOKE_APPLICATION(5): /edit1.xhtml as you can see, the viewId changes during INVOKE_APPLICATION. Now, that we do not see a RESTORE_VIEW no InitView will be sent. InitView was meant to be sent after the view has been created, regardless if this is a restoreView or createView. Since we sit in the PhaseListener we do not see the ViewHandler invokes but just those from the PhaseListener where the RESTORE_VIEW is missing then. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-8) Orchestra do not send an @InitView notification to the ViewController during a non redirect navigation
[
https://issues.apache.org/jira/browse/ORCHESTRA-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536457
]
Mario Ivankovits commented on ORCHESTRA-8:
--
committed a proposal to fix this. Please review r586774
Author: imario
Date: Sat Oct 20 11:51:10 2007
New Revision: 586774
URL: http://svn.apache.org/viewvc?rev=586774view=rev
Log:
ORCHESTRA-8: a proposal for this initView problem
Modified:
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/viewController/jsf/ViewControllerPhaseListener.java
Modified:
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/viewController/jsf/ViewControllerPhaseListener.java
URL:
http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/viewController/jsf/ViewControllerPhaseListener.java?rev=586774r1=586773r2=586774view=diff
==
---
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/viewController/jsf/ViewControllerPhaseListener.java
(original)
+++
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/viewController/jsf/ViewControllerPhaseListener.java
Sat Oct 20 11:51:10 2007
@@ -28,6 +28,8 @@
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
+import java.util.Set;
+import java.util.TreeSet;
/**
* Causes lifecycle methods to be invoked on backing beans that are associated
with
@@ -39,6 +41,15 @@
{
private static final long serialVersionUID = -3975277433747722402L;
+ public static class ViewControllerPhaseListenerState
+ {
+ private Set initedViews = new TreeSet();
+
+ protected ViewControllerPhaseListenerState()
+ {
+ }
+ }
+
public void beforePhase(PhaseEvent event)
{
if (PhaseId.RESTORE_VIEW.equals(event.getPhaseId()) ||
@@ -52,6 +63,8 @@
}
}
+ executeInitView(event.getFacesContext());
+
if (PhaseId.RENDER_RESPONSE.equals(event.getPhaseId()))
{
preRenderResponse(event.getFacesContext());
@@ -73,9 +86,9 @@
// we have a redirect ... stop now
return;
}
-
- postRestoreView(event.getFacesContext());
}
+
+ executeInitView(event.getFacesContext());
}
public PhaseId getPhaseId()
@@ -139,6 +152,14 @@
/**
* invokes the initView method on your view controller
*/
+ protected void executeInitView(FacesContext facesContext)
+ {
+ postRestoreView(facesContext);
+ }
+
+ /**
+* @deprecated overload/use [EMAIL PROTECTED]
#executeInitView(javax.faces.context.FacesContext)} instead
+*/
protected void postRestoreView(FacesContext facesContext)
{
ViewControllerManager manager =
_ViewControllerUtils.getViewControllerManager(facesContext);
@@ -153,7 +174,27 @@
return;
}
+ ViewControllerPhaseListenerState state = getState(facesContext);
+
+ if (state.initedViews.contains(viewId))
+ {
+ // already inited
+ return;
+ }
+ state.initedViews.add(viewId);
+
manager.executeInitView(viewId);
+ }
+
+ protected ViewControllerPhaseListenerState getState(FacesContext
facesContext)
+ {
+ ViewControllerPhaseListenerState state =
(ViewControllerPhaseListenerState)
facesContext.getExternalContext().getRequestMap().get(ViewControllerPhaseListenerState.class.getName());
+ if (state == null)
+ {
+ state = new ViewControllerPhaseListenerState();
+
facesContext.getExternalContext().getRequestMap().put(ViewControllerPhaseListenerState.class.getName(),
state);
+ }
+ return state;
}
/**
Orchestra do not send an @InitView notification to the ViewController during
a non redirect navigation
--
Key: ORCHESTRA-8
URL: https://issues.apache.org/jira/browse/ORCHESTRA-8
Project: MyFaces Orchestra
Issue Type: Bug
Components: ViewController
Affects Versions: 1.0
Environment: JSF 1.1 Facelets
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
The lifecycle is as follows:
BEFORE RESTORE_VIEW(1): null
AFTER RESTORE_VIEW(1): /all.xhtml
[jira] Commented: (MYFACES-1733) [Seam] Server-side state saving not working correctly
[ https://issues.apache.org/jira/browse/MYFACES-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533421 ] Mario Ivankovits commented on MYFACES-1733: --- I don't see how this patch will fix this issue. Did you try it? facesContext.getExternalContext().getRequestParameterMap().isEmpty() retruns true only if there is no GET NOR a POST parameter. So in case of a postback you'll have at least the minimum view state required to lookup the view state on the server - you'll always have at least one POST parameter, except if you access a view directly, but then there is also no STANDARD_STATE_SAVING_PARAM. But maybe I miss something here? Sorry then ;-) [Seam] Server-side state saving not working correctly - Key: MYFACES-1733 URL: https://issues.apache.org/jira/browse/MYFACES-1733 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6-SNAPSHOT Reporter: Stephen Friedrich Priority: Critical Attachments: jira1733-patch.zip Sometimes when using server-side state-saving some state is fixed and won't ever update. I don't know how exactly this is caused, but it occurs a lot when using JBoss Seam. It is consensus in the Seam community not to ever use myfaces with server-side state saving or even better not to use myfaces, but the RI instead. Here is how to reproduce reliably with one of the Seam example applications: - download and unzip tomcat 5.5. - download and unzip JBoss Seam 1.2.1. - edit seam-install-folder/build.properties and specify the path to tomcat - edit seam-install-folder/examples/seampay/resources/WEB-INF/web.xml and change state saving method to server. - run ant deploy.tomcat from seam-install-folder/examples/seampay/ - open http://localhost:8080/jboss-seam-pay - try to click on different accounts. = Only the first selection ever will make it. All others are ignored. Change back to client side state saving and everything works ok. I tried to look into this, but I am way over my head here with the internals of JSF and MyFaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1733) [Seam] Server-side state saving not working correctly
[ https://issues.apache.org/jira/browse/MYFACES-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533452 ] Mario Ivankovits commented on MYFACES-1733: --- Ah - ok - now I get it - Thanks! Yep, then this could work. Need to wait for someone else to comment here, but I think the patch should make it. [Seam] Server-side state saving not working correctly - Key: MYFACES-1733 URL: https://issues.apache.org/jira/browse/MYFACES-1733 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6-SNAPSHOT Reporter: Stephen Friedrich Priority: Critical Attachments: jira1733-patch.zip Sometimes when using server-side state-saving some state is fixed and won't ever update. I don't know how exactly this is caused, but it occurs a lot when using JBoss Seam. It is consensus in the Seam community not to ever use myfaces with server-side state saving or even better not to use myfaces, but the RI instead. Here is how to reproduce reliably with one of the Seam example applications: - download and unzip tomcat 5.5. - download and unzip JBoss Seam 1.2.1. - edit seam-install-folder/build.properties and specify the path to tomcat - edit seam-install-folder/examples/seampay/resources/WEB-INF/web.xml and change state saving method to server. - run ant deploy.tomcat from seam-install-folder/examples/seampay/ - open http://localhost:8080/jboss-seam-pay - try to click on different accounts. = Only the first selection ever will make it. All others are ignored. Change back to client side state saving and everything works ok. I tried to look into this, but I am way over my head here with the internals of JSF and MyFaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-6) Latest Orchestra fails on JSF RI 1.2_04 and JSF RI 1.2_05
[ https://issues.apache.org/jira/browse/ORCHESTRA-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532232 ] Mario Ivankovits commented on ORCHESTRA-6: -- Which SNAPSHOT do you use? Where do you get it from? I think the snapshot build is still b0rken and so you use an old version instead. The bug throwing the exception above is already been fixed. Please try downloading from SVN [1] and build Orchestra using maven ... should be pretty straight forward. Ciao, Mario [1] https://svn.apache.org/repos/asf/myfaces/orchestra/trunk BTW: I plan to build the release artifacts by tomorrow ... so if you do not want to build on your own give them a try then. Latest Orchestra fails on JSF RI 1.2_04 and JSF RI 1.2_05 - Key: ORCHESTRA-6 URL: https://issues.apache.org/jira/browse/ORCHESTRA-6 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.0-SNAPSHOT Environment: JSF RI 1.2_04 and JSF RI 1.2_05 + tomcat 6 + facelets 1.1.12 Reporter: Alberto Gori Using the Orchestra bundled with the example (built on august) it works with RI implementation. Instead when I tried with latest SNAPSHOT it fails at start up and this is the stack trace: 3-ott-2007 21.44.13 org.apache.catalina.core.StandardContext listenerStart GRAVE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener javax.faces.FacesException: org.apache.myfaces.orchestra.lib.jsf.OrchestraApplicationFactory at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:556) at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:448) at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:249) at com.sun.faces.config.ConfigureListener.application(ConfigureListener.java:465) at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:513) at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:487) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:381) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3830) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4337) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) 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:566) 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:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:549) ... 30 more Caused by: org.springframework.aop.framework.AopConfigException: Couldn't generate CGLIB subclass of class [class com.sun.faces.application.ApplicationImpl]: Common causes of
[jira] Resolved: (ORCHESTRA-6) Latest Orchestra fails on JSF RI 1.2_04 and JSF RI 1.2_05
[ https://issues.apache.org/jira/browse/ORCHESTRA-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-6. -- Resolution: Invalid Assignee: Mario Ivankovits already fixed previously Latest Orchestra fails on JSF RI 1.2_04 and JSF RI 1.2_05 - Key: ORCHESTRA-6 URL: https://issues.apache.org/jira/browse/ORCHESTRA-6 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.0-SNAPSHOT Environment: JSF RI 1.2_04 and JSF RI 1.2_05 + tomcat 6 + facelets 1.1.12 Reporter: Alberto Gori Assignee: Mario Ivankovits Using the Orchestra bundled with the example (built on august) it works with RI implementation. Instead when I tried with latest SNAPSHOT it fails at start up and this is the stack trace: 3-ott-2007 21.44.13 org.apache.catalina.core.StandardContext listenerStart GRAVE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener javax.faces.FacesException: org.apache.myfaces.orchestra.lib.jsf.OrchestraApplicationFactory at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:556) at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:448) at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:249) at com.sun.faces.config.ConfigureListener.application(ConfigureListener.java:465) at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:513) at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:487) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:381) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3830) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4337) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) 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:566) 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:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:549) ... 30 more Caused by: org.springframework.aop.framework.AopConfigException: Couldn't generate CGLIB subclass of class [class com.sun.faces.application.ApplicationImpl]: Common causes of this problem include using a final class or a non-visible class; nested exception is net.sf.cglib.core.CodeGenerationException: java.lang.IllegalStateException--Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory at org.springframework.aop.framework.Cglib2AopProxy.getProxy(Cglib2AopProxy.java:202) at
[jira] Created: (TOMAHAWK-1119) add autocomplete attribute to InputTextHelp
add autocomplete attribute to InputTextHelp --- Key: TOMAHAWK-1119 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1119 Project: MyFaces Tomahawk Issue Type: Improvement Reporter: Mario Ivankovits Assignee: Mario Ivankovits Priority: Minor Fix For: 1.1.7-SNAPSHOT add autocomplete attribute to InputTextHelp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1119) add autocomplete attribute to InputTextHelp
[ https://issues.apache.org/jira/browse/TOMAHAWK-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved TOMAHAWK-1119. Resolution: Fixed add autocomplete attribute to InputTextHelp --- Key: TOMAHAWK-1119 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1119 Project: MyFaces Tomahawk Issue Type: Improvement Reporter: Mario Ivankovits Assignee: Mario Ivankovits Priority: Minor Fix For: 1.1.7-SNAPSHOT add autocomplete attribute to InputTextHelp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-711) -IE7 - AutoComplete Does Not Work When You Use Script to Submit a Form
-IE7 - AutoComplete Does Not Work When You Use Script to Submit a Form -- Key: TRINIDAD-711 URL: https://issues.apache.org/jira/browse/TRINIDAD-711 Project: MyFaces Trinidad Issue Type: Bug Environment: Internet Explorer 7 Reporter: Mario Ivankovits Assignee: Matthias Weßendorf Fix For: 1.0.3-core AutoComplete Does Not Work When You Use Script to Submit a Form see http://support.microsoft.com/kb/329156/en-us Simon said in IE6 this is true as well, at least time by time -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (ORCHESTRA-4) Clean up build files
[ https://issues.apache.org/jira/browse/ORCHESTRA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits reopened ORCHESTRA-4: -- Clean up build files Key: ORCHESTRA-4 URL: https://issues.apache.org/jira/browse/ORCHESTRA-4 Project: MyFaces Orchestra Issue Type: Improvement Affects Versions: 1.0-SNAPSHOT Environment: xp Reporter: Dan Tran Assignee: Mario Ivankovits Attachments: ORCHESTRA-4-2.patch, ORCHESTRA-4.diff the pom files can be cleanup based on the following facts: - core15 depends on core, therefore lots of core15's dependencies can be removed. There is no need to unpack orchestra-share either - Repositories: remove iblio repo can be removed, maven already includes repo1.maven.org/maven2 use faster java.net maven repo. Refactor repository to the root pom - remove unnessesary unpacking of orchestra-share classes in core since we build it from source any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-4) Clean up build files
[ https://issues.apache.org/jira/browse/ORCHESTRA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-4. -- Resolution: Fixed Fixed, thanks! I don't have sufficient permisions - or don't know how - to change jira to allow reopening. Lets see if someone on the ml knows something about it. Clean up build files Key: ORCHESTRA-4 URL: https://issues.apache.org/jira/browse/ORCHESTRA-4 Project: MyFaces Orchestra Issue Type: Improvement Affects Versions: 1.0-SNAPSHOT Environment: xp Reporter: Dan Tran Assignee: Mario Ivankovits Attachments: ORCHESTRA-4-2.patch, ORCHESTRA-4.diff the pom files can be cleanup based on the following facts: - core15 depends on core, therefore lots of core15's dependencies can be removed. There is no need to unpack orchestra-share either - Repositories: remove iblio repo can be removed, maven already includes repo1.maven.org/maven2 use faster java.net maven repo. Refactor repository to the root pom - remove unnessesary unpacking of orchestra-share classes in core since we build it from source any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-4) Clean up build files
[ https://issues.apache.org/jira/browse/ORCHESTRA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-4. -- Resolution: Fixed Assignee: Mario Ivankovits Not, that I really know what I have done, but I've committed your patch. If there is something broken in the maven build - say for the next one and a half light-year - I'll ask you to fix it - I'll promise ;-) Thanks for the patch! Clean up build files Key: ORCHESTRA-4 URL: https://issues.apache.org/jira/browse/ORCHESTRA-4 Project: MyFaces Orchestra Issue Type: Improvement Affects Versions: 1.0-SNAPSHOT Environment: xp Reporter: Dan Tran Assignee: Mario Ivankovits Attachments: ORCHESTRA-4.diff the pom files can be cleanup based on the following facts: - core15 depends on core, therefore lots of core15's dependencies can be removed. There is no need to unpack orchestra-share either - Repositories: remove iblio repo can be removed, maven already includes repo1.maven.org/maven2 use faster java.net maven repo. Refactor repository to the root pom - remove unnessesary unpacking of orchestra-share classes in core since we build it from source any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-1) Use servlet 2.4
[
https://issues.apache.org/jira/browse/ORCHESTRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved ORCHESTRA-1.
--
Resolution: Fixed
Fix Version/s: 1.0-SNAPSHOT
thanks for the patch!
Use servlet 2.4
---
Key: ORCHESTRA-1
URL: https://issues.apache.org/jira/browse/ORCHESTRA-1
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Affects Versions: 1.0-SNAPSHOT
Environment: xp, spring 2.0.6, jsf-1.2 ri
Reporter: Dan Tran
Priority: Blocker
Fix For: 1.0-SNAPSHOT
the current orchestra fails to start my app with 2.4 container.
Please change the poms to use servlet 2.4 and add this changes
---
core/src/main/java/org/apache/myfaces/orchestra/requestParameterProvider/RequestParameterResponseWrapper.java
(revision 562289)
+++
core/src/main/java/org/apache/myfaces/orchestra/requestParameterProvider/RequestParameterResponseWrapper.java
(working copy)
@@ -187,7 +187,7 @@
{
this.original.setContentType(string);
}
-
+
public void setBufferSize(int i)
{
this.original.setBufferSize(i);
@@ -227,4 +227,18 @@
{
return this.original.getLocale();
}
+
+ public String getContentType()
+ {
+ return this.original.getContentType();
+ }
+
+ public void setCharacterEncoding( String encoding )
+ {
+ this.original.setCharacterEncoding(encoding);
+ }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-2) NPE during startup with spring 2.0.6 with orchestra:name configured
[ https://issues.apache.org/jira/browse/ORCHESTRA-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-2. -- Resolution: Fixed Fix Version/s: 1.0-SNAPSHOT thanks for the patch! NPE during startup with spring 2.0.6 with orchestra:name configured --- Key: ORCHESTRA-2 URL: https://issues.apache.org/jira/browse/ORCHESTRA-2 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Environment: xp, jsf 1.2 ri Reporter: Dan Tran Priority: Blocker Fix For: 1.0-SNAPSHOT spring 2.0.6 has some fixed that trigger orchestra to fail at startup. Here is the required change Index: core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/BeanDefinitionConversationNameAttrDecorator.java === --- core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/BeanDefinitionConversationNameAttrDecorator.java (revision 562307) +++ core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/BeanDefinitionConversationNameAttrDecorator.java (working copy) @@ -39,6 +39,6 @@ definition.getBeanDefinition().setAttribute(CONVERSATION_NAME_ATTRIBUTE, conversationName); } - return null; + return definition; } } -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-3) PropertyPlaceholderConfigurer STOPS working after the introduction of orchestra into my configuration
[
https://issues.apache.org/jira/browse/ORCHESTRA-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519214
]
Mario Ivankovits commented on ORCHESTRA-3:
--
This looks like a bug in spring.
The problem is, that
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean implements the
method afterPropertiesSet() which will be called before the
PropertyPlaceholderConfigurer was able to do its job.
I think the AbstractEntityManagerFactoryBean should implement the
BeanFactoryPostProcessor instead so that one can make use of the ordered
attribute.
I'll raise this on the spring ml.
PropertyPlaceholderConfigurer STOPS working after the introduction of
orchestra into my configuration
--
Key: ORCHESTRA-3
URL: https://issues.apache.org/jira/browse/ORCHESTRA-3
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Environment: xp, spring 2.0.6, jsf-1.2 ri
Reporter: Dan Tran
Here is my configuration, any thoughts? or can some one confirm this?
!-- Configurer that replaces ${...} placeholders with values from a
properties file --
!-- (in this case, JDBC-related settings for the dataSource definition
below) --
!-- THIS STOPS WORKING SINCE INTRODUCTION OF ORCHESTRA BEANS --
bean id=propertyConfigurer
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=location value=/WEB-INF/jdbc-hsqldb.properties/
/bean
!-- EL expression is not translated --
bean id=dataSource
class=org.springframework.jdbc.datasource.DriverManagerDataSource
property name=driverClassName value=${jdbc.driverClassName}/
property name=url value=${jdbc.url}/
property name=username value=${jdbc.username}/
property name=password value=${jdbc.password}/
/bean
The error is
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC
driver class '${jdbc.driverClassName}'
It is producable using orchestra example
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-3) PropertyPlaceholderConfigurer STOPS working after the introduction of orchestra into my configuration
[
https://issues.apache.org/jira/browse/ORCHESTRA-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519215
]
Mario Ivankovits commented on ORCHESTRA-3:
--
http://forum.springframework.org/showthread.php?t=42549
PropertyPlaceholderConfigurer STOPS working after the introduction of
orchestra into my configuration
--
Key: ORCHESTRA-3
URL: https://issues.apache.org/jira/browse/ORCHESTRA-3
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Environment: xp, spring 2.0.6, jsf-1.2 ri
Reporter: Dan Tran
Here is my configuration, any thoughts? or can some one confirm this?
!-- Configurer that replaces ${...} placeholders with values from a
properties file --
!-- (in this case, JDBC-related settings for the dataSource definition
below) --
!-- THIS STOPS WORKING SINCE INTRODUCTION OF ORCHESTRA BEANS --
bean id=propertyConfigurer
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=location value=/WEB-INF/jdbc-hsqldb.properties/
/bean
!-- EL expression is not translated --
bean id=dataSource
class=org.springframework.jdbc.datasource.DriverManagerDataSource
property name=driverClassName value=${jdbc.driverClassName}/
property name=url value=${jdbc.url}/
property name=username value=${jdbc.username}/
property name=password value=${jdbc.password}/
/bean
The error is
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC
driver class '${jdbc.driverClassName}'
It is producable using orchestra example
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-3) PropertyPlaceholderConfigurer STOPS working after the introduction of orchestra into my configuration
[
https://issues.apache.org/jira/browse/ORCHESTRA-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519241
]
Mario Ivankovits commented on ORCHESTRA-3:
--
During debugging the situation I found a workaround you can try.
Add the aop:scoped-proxy to the persistentContextConversationInterceptor
bean. It should look like the following then:
bean id=persistentContextConversationInterceptor
class=org.apache.myfaces.orchestra.conversation.spring.PersistenceContextConversationInterceptor
aop:scoped-proxy/
property name=persistenceContextFactory
ref=persistentContextFactory/
/bean
Due to the aop:scoped-proxy configuration the initialization of the dataSource
will happen on the first real request to the scope and thus happens after the
spring property configuration replacement.
PropertyPlaceholderConfigurer STOPS working after the introduction of
orchestra into my configuration
--
Key: ORCHESTRA-3
URL: https://issues.apache.org/jira/browse/ORCHESTRA-3
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Environment: xp, spring 2.0.6, jsf-1.2 ri
Reporter: Dan Tran
Here is my configuration, any thoughts? or can some one confirm this?
!-- Configurer that replaces ${...} placeholders with values from a
properties file --
!-- (in this case, JDBC-related settings for the dataSource definition
below) --
!-- THIS STOPS WORKING SINCE INTRODUCTION OF ORCHESTRA BEANS --
bean id=propertyConfigurer
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=location value=/WEB-INF/jdbc-hsqldb.properties/
/bean
!-- EL expression is not translated --
bean id=dataSource
class=org.springframework.jdbc.datasource.DriverManagerDataSource
property name=driverClassName value=${jdbc.driverClassName}/
property name=url value=${jdbc.url}/
property name=username value=${jdbc.username}/
property name=password value=${jdbc.password}/
/bean
The error is
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC
driver class '${jdbc.driverClassName}'
It is producable using orchestra example
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-3) PropertyPlaceholderConfigurer STOPS working after the introduction of orchestra into my configuration
[
https://issues.apache.org/jira/browse/ORCHESTRA-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved ORCHESTRA-3.
--
Resolution: Fixed
Assignee: Mario Ivankovits
According to the spring forum thread aop:scoped-proxy IS a way to go. So I'll
leave it that way. FAQ needs to be created.
PropertyPlaceholderConfigurer STOPS working after the introduction of
orchestra into my configuration
--
Key: ORCHESTRA-3
URL: https://issues.apache.org/jira/browse/ORCHESTRA-3
Project: MyFaces Orchestra
Issue Type: Bug
Components: Conversation
Environment: xp, spring 2.0.6, jsf-1.2 ri
Reporter: Dan Tran
Assignee: Mario Ivankovits
Here is my configuration, any thoughts? or can some one confirm this?
!-- Configurer that replaces ${...} placeholders with values from a
properties file --
!-- (in this case, JDBC-related settings for the dataSource definition
below) --
!-- THIS STOPS WORKING SINCE INTRODUCTION OF ORCHESTRA BEANS --
bean id=propertyConfigurer
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=location value=/WEB-INF/jdbc-hsqldb.properties/
/bean
!-- EL expression is not translated --
bean id=dataSource
class=org.springframework.jdbc.datasource.DriverManagerDataSource
property name=driverClassName value=${jdbc.driverClassName}/
property name=url value=${jdbc.url}/
property name=username value=${jdbc.username}/
property name=password value=${jdbc.password}/
/bean
The error is
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC
driver class '${jdbc.driverClassName}'
It is producable using orchestra example
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-166) Can't create an SFTP connection to the server
[ https://issues.apache.org/jira/browse/VFS-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510159 ] Mario Ivankovits commented on VFS-166: -- try sftp:// (lower case) Please consult the commons-user mailinglist before writing bugs :-) Thanks! Ciao, Mario Can't create an SFTP connection to the server - Key: VFS-166 URL: https://issues.apache.org/jira/browse/VFS-166 Project: Commons VFS Issue Type: Bug Environment: Windows XP,JAVA 1.6 Reporter: Chris wojdak I'm trying to use the Commons VFS - SFTP component and it's giving me an error. I'm not sure what the problem is because based on the documentation it's correct. This is the error message I get. org.apache.commons.vfs.FileSystemException: Badly formed URI SFTP://user:[EMAIL PROTECTED]. I have no problems logging in using putty and Cygwin. Can anyone help me out? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VFS-166) Can't create an SFTP connection to the server
[ https://issues.apache.org/jira/browse/VFS-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved VFS-166. -- Resolution: Invalid Assignee: Mario Ivankovits Can't create an SFTP connection to the server - Key: VFS-166 URL: https://issues.apache.org/jira/browse/VFS-166 Project: Commons VFS Issue Type: Bug Environment: Windows XP,JAVA 1.6 Reporter: Chris wojdak Assignee: Mario Ivankovits I'm trying to use the Commons VFS - SFTP component and it's giving me an error. I'm not sure what the problem is because based on the documentation it's correct. This is the error message I get. org.apache.commons.vfs.FileSystemException: Badly formed URI SFTP://user:[EMAIL PROTECTED]. I have no problems logging in using putty and Cygwin. Can anyone help me out? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-166) Can't create an SFTP connection to the server
[ https://issues.apache.org/jira/browse/VFS-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510163 ] Mario Ivankovits commented on VFS-166: -- Please post the full stack trace ... and still, whats bad using the commons-user ml until we know that you really catched a bug? Can't create an SFTP connection to the server - Key: VFS-166 URL: https://issues.apache.org/jira/browse/VFS-166 Project: Commons VFS Issue Type: Bug Environment: Windows XP,JAVA 1.6 Reporter: Chris wojdak Assignee: Mario Ivankovits I'm trying to use the Commons VFS - SFTP component and it's giving me an error. I'm not sure what the problem is because based on the documentation it's correct. This is the error message I get. org.apache.commons.vfs.FileSystemException: Badly formed URI SFTP://user:[EMAIL PROTECTED]. I have no problems logging in using putty and Cygwin. Can anyone help me out? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-113) NullPointerException during getting InputStream from SftpFileObject
[ https://issues.apache.org/jira/browse/VFS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510170 ] Mario Ivankovits commented on VFS-113: -- Hi, this is your real exception: Caused by: com.jcraft.jsch.JSchException: Session.connect: java.net.ConnectException: Connection refused: connect at com.jcraft.jsch.Session.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at org.apache.commons.vfs.provider.sftp.SftpClientFactory.createConnection(SftpClientFactory.java:210) It looks like some sort of network configuration problem, could you try to enable debugging of your ssh daemon. In case you use OpenSSH, as far as I know you have to have the configuration option PasswordAuthentication set to yes to make the jsch library work. NullPointerException during getting InputStream from SftpFileObject --- Key: VFS-113 URL: https://issues.apache.org/jira/browse/VFS-113 Project: Commons VFS Issue Type: Bug Reporter: Tim Rademacher Fix For: 1.1 Attachments: SftpFileObject.diff Hi, I experienced unregular NullPointerExceptions while getting an InputStream from an SftpFileObject. It only occures in a multithreading environment. I made a patch. By now it seems to work! Regards, Tim -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
