[jira] [Commented] (MYFACES-3168) Bound attribute values resolve to NULL during PreRenderViewEvent for nested composite components
[
https://issues.apache.org/jira/browse/MYFACES-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132353#comment-13132353
]
Kennard Consulting commented on MYFACES-3168:
-
Hi guys,
Another one of my users has encountered this same bug. See:
https://sourceforge.net/projects/metawidget/forums/forum/747623/topic/4765688
It is the same problem I described above: if the 'outer' component is an
h:column, you cannot make it call pushComponentToEL. So any inner components
that are working off PreRenderViewEvent will fail.
Can you please reopen this bug?
Regards,
Richard.
Bound attribute values resolve to NULL during PreRenderViewEvent for nested
composite components
Key: MYFACES-3168
URL: https://issues.apache.org/jira/browse/MYFACES-3168
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.6, 2.1.0
Environment: Windows 7 x64 Enterprise.
JDK 1.6.0_25.
Eclipse Version: Helios Service Release 2
Build id: 20110218-0911
Reporter: MAtthew Sweeney
Assignee: Leonardo Uribe
Attachments: jsf-testing-2.zip, jsf-testing-myfaces.zip,
screenshot-1.jpg
When nesting custom composite components, any data bound attributes (eg
#{someValueExpression} ) will resolve to null during the PreRenderViewEvent.
This only occurs on the second level or deeper nested component (the
top-level component in the page works fine).
This same issue occurs on JSF RI 2.0.4, 2.1.x, 2.2.x
I have an eclipse project for upload that reproduces the problem.
I have no cause for the issue at this time.
Cheers,
Matt
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MFCOMMONS-40) enable checkstyle checks for MyFaces commons
[ https://issues.apache.org/jira/browse/MFCOMMONS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MFCOMMONS-40. Resolution: Fixed Fix Version/s: 1.0.3-SNAPSHOT fixed in trunk (which is now commons20) enable checkstyle checks for MyFaces commons Key: MFCOMMONS-40 URL: https://issues.apache.org/jira/browse/MFCOMMONS-40 Project: MyFaces Commons Issue Type: Bug Affects Versions: 1.0.2 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Critical Fix For: 1.0.3-SNAPSHOT Currently there are no checkstyle rules at all enabled in MyFaces-Commons. I will upgrade to myfaces-parent-11-SNAPSHOT which will in turn automatically enable the standard checkstyle rules. Afterwards we need to fix all outstanding checkstyle issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MFCOMMONS-39) semicolon typo in ExtendedDefaultResourceHandlerSupport
[ https://issues.apache.org/jira/browse/MFCOMMONS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated MFCOMMONS-39: --- Resolution: Fixed Fix Version/s: 1.0.3-SNAPSHOT Status: Resolved (was: Patch Available) txs Bütt, fixed while cleaning up myfaces-commons and force checkstyle rules ;) semicolon typo in ExtendedDefaultResourceHandlerSupport --- Key: MFCOMMONS-39 URL: https://issues.apache.org/jira/browse/MFCOMMONS-39 Project: MyFaces Commons Issue Type: Bug Components: myfaces-commons-resourcehandler Affects Versions: 1.0.3-SNAPSHOT Reporter: Marcus Büttner Assignee: Mark Struberg Fix For: 1.0.3-SNAPSHOT Attachments: MFCOMMONS-39.patch Wrong semicolon in ExtendedDefaultResourceHandlerSupport -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3364) UIComponent.findComponent ignored overridden method findComponent of a NamingContainer
UIComponent.findComponent ignored overridden method findComponent of a NamingContainer -- Key: MYFACES-3364 URL: https://issues.apache.org/jira/browse/MYFACES-3364 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.9 Reporter: Bernd Bohmann Priority: Critical Regression from 1.2 to 2.0 See: javax.faces.component.UIComponentFindComponentTest.testOverriddenFindComponent() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (MYFACES-3268) UIComponentBase.findComponent does not allow use the same id for a child component.
[ https://issues.apache.org/jira/browse/MYFACES-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann reopened MYFACES-3268: caused a regression see MYFACES-3364 UIComponentBase.findComponent does not allow use the same id for a child component. --- Key: MYFACES-3268 URL: https://issues.apache.org/jira/browse/MYFACES-3268 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.8, 2.1.2 Suppose the following tree x |-x and the following search expression: x:x The current algorithm has at the end this line: return findBase.findComponent(expr.substring(separator + 1)); The effect of this call is the component is not found, because the first x is swallowed, but the recursive call over the same component return the parent again, so the expected component is not returned, instead the parent. It is rare to use this kind of code, but with composite components, there are NamingContainer instances everywhere, which makes this issue more probable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3268) UIComponentBase.findComponent does not allow use the same id for a child component.
[ https://issues.apache.org/jira/browse/MYFACES-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132514#comment-13132514 ] Bernd Bohmann commented on MYFACES-3268: I did not find any unit test about this? UIComponentBase.findComponent does not allow use the same id for a child component. --- Key: MYFACES-3268 URL: https://issues.apache.org/jira/browse/MYFACES-3268 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.8, 2.1.2 Suppose the following tree x |-x and the following search expression: x:x The current algorithm has at the end this line: return findBase.findComponent(expr.substring(separator + 1)); The effect of this call is the component is not found, because the first x is swallowed, but the recursive call over the same component return the parent again, so the expected component is not returned, instead the parent. It is rare to use this kind of code, but with composite components, there are NamingContainer instances everywhere, which makes this issue more probable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3365) jsf.js: getProjectStage speed improvement
jsf.js: getProjectStage speed improvement - Key: MYFACES-3365 URL: https://issues.apache.org/jira/browse/MYFACES-3365 Project: MyFaces Core Issue Type: Improvement Reporter: Werner Punz Priority: Minor The getProjectStage in our impl is suboptimal performancewise because it is implemented purely functional. But our implementation is an imperative singleton, so we can apply the singleton pattern to the method as well and safe the state after the first determination for future access. This should save us a little bit of time because we do not have to parse the script tags every time. Also the 4 == in the if are slower than a direct map lookup. The code becomes tighter that way as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3268) UIComponentBase.findComponent does not allow use the same id for a child component.
[ https://issues.apache.org/jira/browse/MYFACES-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132548#comment-13132548 ] Bernd Bohmann commented on MYFACES-3268: added Test for this case please take a look at the fix in the 1.2.x branch if you like i would commit the same in 2.x UIComponentBase.findComponent does not allow use the same id for a child component. --- Key: MYFACES-3268 URL: https://issues.apache.org/jira/browse/MYFACES-3268 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Leonardo Uribe Assignee: Bernd Bohmann Fix For: 1.2.10, 2.0.8, 2.1.2 Suppose the following tree x |-x and the following search expression: x:x The current algorithm has at the end this line: return findBase.findComponent(expr.substring(separator + 1)); The effect of this call is the component is not found, because the first x is swallowed, but the recursive call over the same component return the parent again, so the expected component is not returned, instead the parent. It is rare to use this kind of code, but with composite components, there are NamingContainer instances everywhere, which makes this issue more probable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3365) jsf.js: getProjectStage speed improvement
[ https://issues.apache.org/jira/browse/MYFACES-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3365. -- Resolution: Fixed jsf.js: getProjectStage speed improvement - Key: MYFACES-3365 URL: https://issues.apache.org/jira/browse/MYFACES-3365 Project: MyFaces Core Issue Type: Improvement Reporter: Werner Punz Priority: Minor The getProjectStage in our impl is suboptimal performancewise because it is implemented purely functional. But our implementation is an imperative singleton, so we can apply the singleton pattern to the method as well and safe the state after the first determination for future access. This should save us a little bit of time because we do not have to parse the script tags every time. Also the 4 == in the if are slower than a direct map lookup. The code becomes tighter that way as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Failed Tests in 2.0.x and 2.1.x and UIComponent.findComponent contract is not correctly implemented
Hello, just commited a Test that shows the wrong behavior of UIComponent.findComponent since 2.0.8 and 2.1.2. I would like to discuss this with leonardo. Sorry for any inconvenience. Regards Bernd
[jira] [Created] (TRINIDAD-2152) token cache pinning session attribute map
token cache pinning session attribute map -- Key: TRINIDAD-2152 URL: https://issues.apache.org/jira/browse/TRINIDAD-2152 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Gary VanMatre Stevan Malesevic found that the token cache is pinning the session map. com.sun.faces.context.ExternalContextImpl will create a instance of com.sun.faces.context.SessionMap on every request. SessionMap points to Request object. However this is per request so it is not carried over between requests. Now, the reason why we always have request object pined between requests is Trinidad code TokenCache which pins the owner (SessionMap) which would otherwise be gc-ed. From what I can see Trinidad code can be changed to always get extContext.getSessionMap() instead pinning it permanently. This will make sure we are not pinning Request object and all its attributes in between requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2152) token cache pinning session attribute map
[ https://issues.apache.org/jira/browse/TRINIDAD-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary VanMatre updated TRINIDAD-2152: Status: Patch Available (was: Open) token cache pinning session attribute map -- Key: TRINIDAD-2152 URL: https://issues.apache.org/jira/browse/TRINIDAD-2152 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Gary VanMatre Stevan Malesevic found that the token cache is pinning the session map. com.sun.faces.context.ExternalContextImpl will create a instance of com.sun.faces.context.SessionMap on every request. SessionMap points to Request object. However this is per request so it is not carried over between requests. Now, the reason why we always have request object pined between requests is Trinidad code TokenCache which pins the owner (SessionMap) which would otherwise be gc-ed. From what I can see Trinidad code can be changed to always get extContext.getSessionMap() instead pinning it permanently. This will make sure we are not pinning Request object and all its attributes in between requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: gsoc/webtest vs gsoc/manila?
Hi,
Mhh why is the project not hosted on apache extras which would be the
perfect place for now?
Since there is no restriction for source code repositories from
Google, I left this choice to the student (Jan), and he preferred
assembla.com.
However, it would totally be fine to move it to myfaces/gsoc in the near future.
Regards,
Jakob
2011/10/20 Werner Punz werner.p...@gmail.com:
Mhh why is the project not hosted on apache extras which would be the
perfect place for now?
Werner
Am 10/20/11 9:41 AM, schrieb Gerhard Petracek:
hi mark,
manila is the next generation of myfaces webapp-test.
you already mentioned one of the restrictions/issues of myfaces
webapp-test and that's the reason why we don't have a release (with
manila everything would change in the release afterwards).
manila solves most of the known issues and should replace webapp-test
v1 as soon as we know that the approach of manila works in ci-servers.
imo we should test it before we move the code to apache, because it's
useless for us if there are basic issues (esp. in combination with
jenkins).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/20 Mark Struberg strub...@yahoo.de mailto:strub...@yahoo.de
Hi folks!
We now have 2 GSOC test projects which are based on Arquillian:
a.) gsoc/webtest [1] which got implemented last year and is already
in our SVN (but not yet released) and
b.) gsoc/manila [2] which is not yet granted to the ASF (or is it?)
What is the state of both projects?
If I understood them correctly both cover the same areas (at least
partly).
Oh yes, and having to write something like:
@WebappDependency.List
({
@WebappDependency(org.apache.myfaces.extensions.cdi.core:myfaces-extcdi-core-api:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.core:myfaces-extcdi-core-impl:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-jsf20-module-api:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-jsf20-module-impl:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-message-module-api:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-message-module-impl:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.openwebbeans:openwebbeans-impl:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-spi:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-jsf:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-resource:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-web:jar:1.1.0),
@WebappDependency(javassist:javassist:jar:3.12.0.GA
http://3.12.0.ga/),
@WebappDependency(net.sf.scannotation:scannotation:jar:1.0.2)
})
in a test Java class is an absolute no-go for me! This is terribly
to maintain and will way too often be broken...
Such things must NOT be part of any test class!
LieGrue,
strub
[1] https://svn.apache.org/repos/asf/myfaces/gsoc/webapptest
[2]http://subversion.assembla.com/svn/manila/trunk
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: gsoc/webtest vs gsoc/manila?
Hi Mark,
Manila allows you to specify the test dependencies in several ways,
you can have a look at the examples.
@Manila hosting:
I decided to use assembla SVN hosting because I already had several
other private projects there. I don't mind moving it to Apache Extras.
Jan
On Thu, Oct 20, 2011 at 8:58 AM, Mark Struberg strub...@yahoo.de wrote:
Hi folks!
We now have 2 GSOC test projects which are based on Arquillian:
a.) gsoc/webtest [1] which got implemented last year and is already in our
SVN (but not yet released) and
b.) gsoc/manila [2] which is not yet granted to the ASF (or is it?)
What is the state of both projects?
If I understood them correctly both cover the same areas (at least partly).
Oh yes, and having to write something like:
@WebappDependency.List
({
@WebappDependency(org.apache.myfaces.extensions.cdi.core:myfaces-extcdi-core-api:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.core:myfaces-extcdi-core-impl:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-jsf20-module-api:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-jsf20-module-impl:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-message-module-api:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-message-module-impl:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.openwebbeans:openwebbeans-impl:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-spi:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-jsf:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-resource:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-web:jar:1.1.0),
@WebappDependency(javassist:javassist:jar:3.12.0.GA),
@WebappDependency(net.sf.scannotation:scannotation:jar:1.0.2)
})
in a test Java class is an absolute no-go for me! This is terribly to
maintain and will way too often be broken...
Such things must NOT be part of any test class!
LieGrue,
strub
[1] https://svn.apache.org/repos/asf/myfaces/gsoc/webapptest
[2]http://subversion.assembla.com/svn/manila/trunk
Re: Failed Tests in 2.0.x and 2.1.x and UIComponent.findComponent contract is not correctly implemented
Hi Bernd I have checked the problem against the algorithm implemented in 2.0.x and I see the problem. The spec does not define if this method can be overriden, so that details was ignored on MYFACES-3268, and all known tests doesn't check that part. It seems we need to sync the algorithm in 1.2.x with the code in 2.0.x, which was enhanced. What I see is the case that fails is: :data:1:command The base when a findComponent expression starts with ':' is UIViewRoot, the algorithm found it, then it found data, but the code does not delegate to data, instead start looking from data. This is the patch agains 2.0.x branch: https://issues.apache.org/jira/secure/attachment/12500202/MYFACES-3268-3-fix-delegation.patch Note the overriden method on the test case has a problem, because the call for findComponent does not assume the id of the map should be attached. I have seen other changes on 1.2.x, but I think we should copy the code on 2.0.x/2.1.x to 1.2.x (changing the separator stuff). Do you agree with this fix? regards, Leonardo Uribe 2011/10/21 Bernd Bohmann bernd.bohm...@atanion.com: Hello, just commited a Test that shows the wrong behavior of UIComponent.findComponent since 2.0.8 and 2.1.2. I would like to discuss this with leonardo. Sorry for any inconvenience. Regards Bernd
[jira] [Created] (MFHTML5-18) Use myfaces commons utils 1.0.2 to prevent duplicated code
Use myfaces commons utils 1.0.2 to prevent duplicated code -- Key: MFHTML5-18 URL: https://issues.apache.org/jira/browse/MFHTML5-18 Project: MyFaces HTML5 Component Library Issue Type: Improvement Components: Component Library Reporter: Leonardo Uribe Assignee: Leonardo Uribe This library should use the api from commons and prevent duplicate code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[html5] alpha release for myfaces html5
Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe
[jira] [Resolved] (MFHTML5-18) Use myfaces commons utils 1.0.2 to prevent duplicated code
[ https://issues.apache.org/jira/browse/MFHTML5-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MFHTML5-18. --- Resolution: Fixed Fix Version/s: 1.0.0-alpha-SNAPSHOT Use myfaces commons utils 1.0.2 to prevent duplicated code -- Key: MFHTML5-18 URL: https://issues.apache.org/jira/browse/MFHTML5-18 Project: MyFaces HTML5 Component Library Issue Type: Improvement Components: Component Library Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 1.0.0-alpha-SNAPSHOT This library should use the api from commons and prevent duplicate code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2153) clear needs to be overridden in ChildArrayList
clear needs to be overridden in ChildArrayList -- Key: TRINIDAD-2153 URL: https://issues.apache.org/jira/browse/TRINIDAD-2153 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gabrielle Crawford ChildArrayList overrides remove, removeAll etc, but not clear. This needs to be overridden to call remove on each item, otherwise reordering with the change manager doesn't work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [html5] alpha release for myfaces html5
before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribe lu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe
Re: [Trinidad] - Internationalization, file upload
Trinidad just uses input type=file, the browser is rendering the browse button, we don't control the text of the button. If you google something like localize browse button this you'll see some answers. On 10/20/2011 6:34 AM, Pedro Dionizio Filho wrote: Hi, I've a web app developed used JBoss Seam, JSF, RichFaces and Trinidad and I've worked with internationalization in my application, however I'm facing a very small issue about Trinidad and File Upload component. When using the tr:inputFile component, automaticaly is added the Search button so the user can find where the files are. But the label of this Search button doesn't change. When my app is using the pt_br locale, the label of button shows Procurar, but when my app is using the en_US locale, the label of the button still shows Procurar . I've looked for a solution in the web but I'm not able to find how to customize it. Trinidad and internationalization is a very specific subject, I can rarely find something about it. I know that in the trinidad-config.xml we have a tag called formatting-locale. I already tried to use it with en_US locale, but the label Procurar is still there! I already tried to change the O.S. language, but nothing happens. Hope you guys can help me, Thanks in advance, Pedro
Re: [html5] alpha release for myfaces html5
Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com: before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribe lu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe
[jira] [Updated] (MYFACES-3309) Throw correct exception while using FactoryFinderProvider SPI
[ https://issues.apache.org/jira/browse/MYFACES-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3309: Resolution: Fixed Fix Version/s: 2.1.4 2.0.10 Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) I checked the patch and the changes proposed are reasonable. Thanks to Ivan for provide this patch. Throw correct exception while using FactoryFinderProvider SPI - Key: MYFACES-3309 URL: https://issues.apache.org/jira/browse/MYFACES-3309 Project: MyFaces Core Issue Type: Bug Components: SPI Affects Versions: 2.0.9, 2.1.3 Reporter: Ivan Assignee: Leonardo Uribe Fix For: 2.0.10, 2.1.4 Attachments: MYFACES-3309.patch While using FactoryFinderProvider SPI, it is required to check the real exception from InvocationTargetException, and throw some exceptions directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [html5] alpha release for myfaces html5
+1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com: before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe
Re: Several main links on the Trinidad home page are broken
Upps sorry Scott I overlooked your mail, I didn´t find the time to do it myself anyway. Scott, thanks for doing it. werner Am 10/20/11 9:14 PM, schrieb Scott O'Bryan: Yes, I'll get right on it.. On 10/20/2011 01:12 PM, Jan Zarnikov wrote: Hi Victor, thanks for the report. Irian has completely redesigned the homepage and the links to www.irian.at/trinidad-examples are no longer valid. You can use http://example.irian.at/trinidad-demo/ and the component showcase at http://example.irian.at/trinidad-components-showcase/ @MyFaces Devs: Can somebody with access to the MyFaces page change the links? Please make sure that the links go to example.irian.com and not www.irian.at/something or irian.at/something Regards, Jan On Thu, Oct 20, 2011 at 5:06 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi victor, the live-demos should be back online within the next days. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/20 Victor Gradinescuvictor.gradine...@gmail.com Hi, I've heard of the trinidad project and wanted to check it out but most of the links on the home page (left menu) are broken (Live Demos, for example). What's the status of this project? Thank you, Victor
[jira] [Reopened] (MYFACES-3361) jsf.js: code restructuration for size and speed improvlements
[ https://issues.apache.org/jira/browse/MYFACES-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz reopened MYFACES-3361: -- Assignee: Werner Punz (was: Leonardo Uribe) I also want to split the RT into a Core RT and a quirks RT so that we can isolate legacy browser specific code from the RT and remove it for our minimal-modern build. jsf.js: code restructuration for size and speed improvlements - Key: MYFACES-3361 URL: https://issues.apache.org/jira/browse/MYFACES-3361 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.10-SNAPSHOT, 2.1.4-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz Fix For: 2.0.10, 2.1.4 Attachments: Adding_modular_jsf_js_support_.patch h2. Currently we have one big jsf.js file with all code in * *core* which implements all of the spec * *i18n* which implements the language messages for currently 7 languages * *experimental* which implements features targetted for jsf 2.2 onwards * *quirksmode* code which supports non standard compliant browsers The idea is to still keep one big file, but also provide several files which partially can be mixed to achieve the functionality needed h2. We are going to allow * one big file which resembles our current jsf.js * a base file which resembles the core + quirksmode * a modern browser file which resembles the core only without quirksmode code * a separate i18n file for the i18n messages * a legacy file for quirksmode browsers * an experimental file with all non standard features combined In the end the plan is to allow the users to mix those feature sets to reduce the import size while still retaining all the existing functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3168) Bound attribute values resolve to NULL during PreRenderViewEvent for nested composite components
[
https://issues.apache.org/jira/browse/MYFACES-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132926#comment-13132926
]
Leonardo Uribe commented on MYFACES-3168:
-
Hi Richard
I checked the comment on metawidget forum and it seems like a typo error. The
datatable definition is:
h:dataTable id=communications value=#{contact.currentCommunications}
var=_communication
but the metawidget usage is this:
m:metawidget value=#{communication.current.value} rendererType=simple
rendered=#{!contact.readOnly}/
It should be
m:metawidget value=#{_communication.current.value} rendererType=simple
rendered=#{!contact.readOnly}/
Now about this bug: I think we have done everything we can. I have discussed
earlier this problem with other people. The last thing done was on
MYFACES-3289. Here are some comments discussed earlier:
?? Also your workarounds of finding the components by executing
findComponent
?? are not really safe: findComponent does not setup the context of the
component
?? which you would need to have. Only invokeOnComponent or a treevisit can
do
?? this for you!
LU Yes, I know, but note both invokeOnComponent and visitTree requires a
clientId.
LU The problem is for example when the component is inside a datatable.
There is
LU only one real UIComponent instance, but it could be many virtual
instances
LU per row. Since PreRenderViewEvent is propagated to UIViewRoot, there is
no
LU associate context, so the only way to do it is create a findComponent
expression
LU to locate the real component instance.
LU I know in this case a invokeOnComponent or visitTree with a
findComponent
LU expression sounds better, but there is nothing on the spec that helps.
Usually
LU the tasks done in that location does not require the context, so it is
valid to
LU simplify this case and expect only one call per real component. In
conclusion,
LU I agree with the solution done in mojarra for this one, even if it is not
the
LU best we can do in this case.
LU Anyway, there is something missing on the spec. Some weeks ago, I sent a
mail
LU to the EG list under the name:
LU [jsr344-experts] Referencing composite component attributes in child
components
LU outside of a tree traversal
LU I think at the end there is something related to this one.
It would be great to have a way to call a visitTree or invokeOnComponent using
a find component expression. In that way, from PreRenderViewEvent the
developer can set up the context using such call. For now all that should be
done outside the spec.
Bound attribute values resolve to NULL during PreRenderViewEvent for nested
composite components
Key: MYFACES-3168
URL: https://issues.apache.org/jira/browse/MYFACES-3168
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.6, 2.1.0
Environment: Windows 7 x64 Enterprise.
JDK 1.6.0_25.
Eclipse Version: Helios Service Release 2
Build id: 20110218-0911
Reporter: MAtthew Sweeney
Assignee: Leonardo Uribe
Attachments: jsf-testing-2.zip, jsf-testing-myfaces.zip,
screenshot-1.jpg
When nesting custom composite components, any data bound attributes (eg
#{someValueExpression} ) will resolve to null during the PreRenderViewEvent.
This only occurs on the second level or deeper nested component (the
top-level component in the page works fine).
This same issue occurs on JSF RI 2.0.4, 2.1.x, 2.2.x
I have an eclipse project for upload that reproduces the problem.
I have no cause for the issue at this time.
Cheers,
Matt
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Failed Tests in 2.0.x and 2.1.x and UIComponent.findComponent contract is not correctly implemented
Hello Leonardo, I think we should fix it like my suggestion in 1.2.x. Your suggestion didn't work with the data:1:command expression. You can see it with my last commit on the trunk. Regards Bernd On Fri, Oct 21, 2011 at 6:35 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Bernd I have checked the problem against the algorithm implemented in 2.0.x and I see the problem. The spec does not define if this method can be overriden, so that details was ignored on MYFACES-3268, and all known tests doesn't check that part. It seems we need to sync the algorithm in 1.2.x with the code in 2.0.x, which was enhanced. What I see is the case that fails is: :data:1:command The base when a findComponent expression starts with ':' is UIViewRoot, the algorithm found it, then it found data, but the code does not delegate to data, instead start looking from data. This is the patch agains 2.0.x branch: https://issues.apache.org/jira/secure/attachment/12500202/MYFACES-3268-3-fix-delegation.patch Note the overriden method on the test case has a problem, because the call for findComponent does not assume the id of the map should be attached. I have seen other changes on 1.2.x, but I think we should copy the code on 2.0.x/2.1.x to 1.2.x (changing the separator stuff). Do you agree with this fix? regards, Leonardo Uribe 2011/10/21 Bernd Bohmann bernd.bohm...@atanion.com: Hello, just commited a Test that shows the wrong behavior of UIComponent.findComponent since 2.0.8 and 2.1.2. I would like to discuss this with leonardo. Sorry for any inconvenience. Regards Bernd
[jira] [Resolved] (MYFACES-3361) jsf.js: code restructuration for size and speed improvlements
[ https://issues.apache.org/jira/browse/MYFACES-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3361. -- Resolution: Fixed jsf.js: code restructuration for size and speed improvlements - Key: MYFACES-3361 URL: https://issues.apache.org/jira/browse/MYFACES-3361 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.10-SNAPSHOT, 2.1.4-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz Fix For: 2.0.10, 2.1.4 Attachments: Adding_modular_jsf_js_support_.patch h2. Currently we have one big jsf.js file with all code in * *core* which implements all of the spec * *i18n* which implements the language messages for currently 7 languages * *experimental* which implements features targetted for jsf 2.2 onwards * *quirksmode* code which supports non standard compliant browsers The idea is to still keep one big file, but also provide several files which partially can be mixed to achieve the functionality needed h2. We are going to allow * one big file which resembles our current jsf.js * a base file which resembles the core + quirksmode * a modern browser file which resembles the core only without quirksmode code * a separate i18n file for the i18n messages * a legacy file for quirksmode browsers * an experimental file with all non standard features combined In the end the plan is to allow the users to mix those feature sets to reduce the import size while still retaining all the existing functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [html5] alpha release for myfaces html5
Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petracek@**gmail.comgerhard.petra...@gmail.com : before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/**html5/ http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [html5] alpha release for myfaces html5
hi ali, most commits happened directly after the initial import. that didn't look very promising. it's great to hear that you plan to continue. however, since we haven't seen a lot of activity, we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Ali Ok al...@aliok.com.tr Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.comwrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petracek@**gmail.comgerhard.petra...@gmail.com : before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/**html5/ http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Failed Tests in 2.0.x and 2.1.x and UIComponent.findComponent contract is not correctly implemented
Hello Bernd I see. Could you commit the solution for 2.0.x/2.1.x branch? regards, Leonardo Uribe 2011/10/21 Bernd Bohmann bernd.bohm...@atanion.com: Hello Leonardo, I think we should fix it like my suggestion in 1.2.x. Your suggestion didn't work with the data:1:command expression. You can see it with my last commit on the trunk. Regards Bernd On Fri, Oct 21, 2011 at 6:35 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Bernd I have checked the problem against the algorithm implemented in 2.0.x and I see the problem. The spec does not define if this method can be overriden, so that details was ignored on MYFACES-3268, and all known tests doesn't check that part. It seems we need to sync the algorithm in 1.2.x with the code in 2.0.x, which was enhanced. What I see is the case that fails is: :data:1:command The base when a findComponent expression starts with ':' is UIViewRoot, the algorithm found it, then it found data, but the code does not delegate to data, instead start looking from data. This is the patch agains 2.0.x branch: https://issues.apache.org/jira/secure/attachment/12500202/MYFACES-3268-3-fix-delegation.patch Note the overriden method on the test case has a problem, because the call for findComponent does not assume the id of the map should be attached. I have seen other changes on 1.2.x, but I think we should copy the code on 2.0.x/2.1.x to 1.2.x (changing the separator stuff). Do you agree with this fix? regards, Leonardo Uribe 2011/10/21 Bernd Bohmann bernd.bohm...@atanion.com: Hello, just commited a Test that shows the wrong behavior of UIComponent.findComponent since 2.0.8 and 2.1.2. I would like to discuss this with leonardo. Sorry for any inconvenience. Regards Bernd
Re: [html5] alpha release for myfaces html5
Hi The problem with move to tomahawk sandbox is those artifact can't never be released. Do an alpha release give us the chance to know if the bits are good enough, get more feedback, and later decide what to do. The truth is some people only test some artifacts after a release. Do it as an alpha release means ... software that has just been compiled and ready for its initial test inhouse. I think that is enough clear. regards, Leonardo Uribe 2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com: hi ali, most commits happened directly after the initial import. that didn't look very promising. it's great to hear that you plan to continue. however, since we haven't seen a lot of activity, we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Ali Ok al...@aliok.com.tr Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com: before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Failed Tests in 2.0.x and 2.1.x and UIComponent.findComponent contract is not correctly implemented
Hello Leonardo, can you review my commit, please. Thanks Bernd On Fri, Oct 21, 2011 at 9:36 PM, Leonardo Uribe lu4...@gmail.com wrote: Hello Bernd I see. Could you commit the solution for 2.0.x/2.1.x branch? regards, Leonardo Uribe 2011/10/21 Bernd Bohmann bernd.bohm...@atanion.com: Hello Leonardo, I think we should fix it like my suggestion in 1.2.x. Your suggestion didn't work with the data:1:command expression. You can see it with my last commit on the trunk. Regards Bernd On Fri, Oct 21, 2011 at 6:35 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Bernd I have checked the problem against the algorithm implemented in 2.0.x and I see the problem. The spec does not define if this method can be overriden, so that details was ignored on MYFACES-3268, and all known tests doesn't check that part. It seems we need to sync the algorithm in 1.2.x with the code in 2.0.x, which was enhanced. What I see is the case that fails is: :data:1:command The base when a findComponent expression starts with ':' is UIViewRoot, the algorithm found it, then it found data, but the code does not delegate to data, instead start looking from data. This is the patch agains 2.0.x branch: https://issues.apache.org/jira/secure/attachment/12500202/MYFACES-3268-3-fix-delegation.patch Note the overriden method on the test case has a problem, because the call for findComponent does not assume the id of the map should be attached. I have seen other changes on 1.2.x, but I think we should copy the code on 2.0.x/2.1.x to 1.2.x (changing the separator stuff). Do you agree with this fix? regards, Leonardo Uribe 2011/10/21 Bernd Bohmann bernd.bohm...@atanion.com: Hello, just commited a Test that shows the wrong behavior of UIComponent.findComponent since 2.0.8 and 2.1.2. I would like to discuss this with leonardo. Sorry for any inconvenience. Regards Bernd
Re: [html5] alpha release for myfaces html5
hi leo, imo such an argument doesn't justify an own sub-project. i don't say -1. my point is that we should discuss it (esp. because the situation changed). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribe lu4...@gmail.com Hi The problem with move to tomahawk sandbox is those artifact can't never be released. Do an alpha release give us the chance to know if the bits are good enough, get more feedback, and later decide what to do. The truth is some people only test some artifacts after a release. Do it as an alpha release means ... software that has just been compiled and ready for its initial test inhouse. I think that is enough clear. regards, Leonardo Uribe 2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com: hi ali, most commits happened directly after the initial import. that didn't look very promising. it's great to hear that you plan to continue. however, since we haven't seen a lot of activity, we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Ali Ok al...@aliok.com.tr Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com: before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: [html5] alpha release for myfaces html5
I must agree with Gerhard. The whole point of the sandbox is for this very purpose. However, perhaps we should look at the sandbox more often and vote on components that are ready to graduate. On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi leo, imo such an argument doesn't justify an own sub-project. i don't say -1. my point is that we should discuss it (esp. because the situation changed). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribe lu4...@gmail.com Hi The problem with move to tomahawk sandbox is those artifact can't never be released. Do an alpha release give us the chance to know if the bits are good enough, get more feedback, and later decide what to do. The truth is some people only test some artifacts after a release. Do it as an alpha release means ... software that has just been compiled and ready for its initial test inhouse. I think that is enough clear. regards, Leonardo Uribe 2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com: hi ali, most commits happened directly after the initial import. that didn't look very promising. it's great to hear that you plan to continue. however, since we haven't seen a lot of activity, we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Ali Ok al...@aliok.com.tr Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com: before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: [html5] alpha release for myfaces html5
@grant: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Grant Smith work.gr...@gmail.com I must agree with Gerhard. The whole point of the sandbox is for this very purpose. However, perhaps we should look at the sandbox more often and vote on components that are ready to graduate. On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi leo, imo such an argument doesn't justify an own sub-project. i don't say -1. my point is that we should discuss it (esp. because the situation changed). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribe lu4...@gmail.com Hi The problem with move to tomahawk sandbox is those artifact can't never be released. Do an alpha release give us the chance to know if the bits are good enough, get more feedback, and later decide what to do. The truth is some people only test some artifacts after a release. Do it as an alpha release means ... software that has just been compiled and ready for its initial test inhouse. I think that is enough clear. regards, Leonardo Uribe 2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com: hi ali, most commits happened directly after the initial import. that didn't look very promising. it's great to hear that you plan to continue. however, since we haven't seen a lot of activity, we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Ali Ok al...@aliok.com.tr Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com: before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do the necessary steps. regards, Leonardo Uribe -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: Failed Tests in 2.0.x and 2.1.x and UIComponent.findComponent contract is not correctly implemented
Hi Bernd It looks good. regards, Leonardo 2011/10/21 Bernd Bohmann bernd.bohm...@atanion.com: Hello Leonardo, can you review my commit, please. Thanks Bernd On Fri, Oct 21, 2011 at 9:36 PM, Leonardo Uribe lu4...@gmail.com wrote: Hello Bernd I see. Could you commit the solution for 2.0.x/2.1.x branch? regards, Leonardo Uribe 2011/10/21 Bernd Bohmann bernd.bohm...@atanion.com: Hello Leonardo, I think we should fix it like my suggestion in 1.2.x. Your suggestion didn't work with the data:1:command expression. You can see it with my last commit on the trunk. Regards Bernd On Fri, Oct 21, 2011 at 6:35 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Bernd I have checked the problem against the algorithm implemented in 2.0.x and I see the problem. The spec does not define if this method can be overriden, so that details was ignored on MYFACES-3268, and all known tests doesn't check that part. It seems we need to sync the algorithm in 1.2.x with the code in 2.0.x, which was enhanced. What I see is the case that fails is: :data:1:command The base when a findComponent expression starts with ':' is UIViewRoot, the algorithm found it, then it found data, but the code does not delegate to data, instead start looking from data. This is the patch agains 2.0.x branch: https://issues.apache.org/jira/secure/attachment/12500202/MYFACES-3268-3-fix-delegation.patch Note the overriden method on the test case has a problem, because the call for findComponent does not assume the id of the map should be attached. I have seen other changes on 1.2.x, but I think we should copy the code on 2.0.x/2.1.x to 1.2.x (changing the separator stuff). Do you agree with this fix? regards, Leonardo Uribe 2011/10/21 Bernd Bohmann bernd.bohm...@atanion.com: Hello, just commited a Test that shows the wrong behavior of UIComponent.findComponent since 2.0.8 and 2.1.2. I would like to discuss this with leonardo. Sorry for any inconvenience. Regards Bernd
[jira] [Resolved] (MYFACES-3364) UIComponent.findComponent ignored overridden method findComponent of a NamingContainer
[ https://issues.apache.org/jira/browse/MYFACES-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved MYFACES-3364. Resolution: Fixed Fix Version/s: 2.1.4 2.0.10 Assignee: Bernd Bohmann UIComponent.findComponent ignored overridden method findComponent of a NamingContainer -- Key: MYFACES-3364 URL: https://issues.apache.org/jira/browse/MYFACES-3364 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.9, 2.1.3 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Critical Fix For: 2.0.10, 2.1.4 Regression from 1.2 to 2.x See: javax.faces.component.UIComponentFindComponentTest.testOverriddenFindComponent() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [html5] alpha release for myfaces html5
Hi, The truth is some people only test some artifacts after a release. Do it as an alpha release means ... software that has just been compiled and ready for its initial test inhouse. Yes, exactly. Everyone is using maven, and even I am annoyed when I try to use this library in another machine for the first time, since there is no repo for maven to download it. IMHO, having release cycles for the project would be really great. I also know the project needs more effort, but first thing we need is feedback. we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). If you think this way is better for the project, then IMHO it is also OK. I think this would be an advantage for the project if more people are going to participate. But what are the advantages of moving into sandbox? Or, I should ask, what are the concerns with the current way? If we clear this, we can easily decide :) Cheers, Ali On Fri, Oct 21, 2011 at 10:22 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: @grant: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Grant Smith work.gr...@gmail.com I must agree with Gerhard. The whole point of the sandbox is for this very purpose. However, perhaps we should look at the sandbox more often and vote on components that are ready to graduate. On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi leo, imo such an argument doesn't justify an own sub-project. i don't say -1. my point is that we should discuss it (esp. because the situation changed). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribe lu4...@gmail.com Hi The problem with move to tomahawk sandbox is those artifact can't never be released. Do an alpha release give us the chance to know if the bits are good enough, get more feedback, and later decide what to do. The truth is some people only test some artifacts after a release. Do it as an alpha release means ... software that has just been compiled and ready for its initial test inhouse. I think that is enough clear. regards, Leonardo Uribe 2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com: hi ali, most commits happened directly after the initial import. that didn't look very promising. it's great to hear that you plan to continue. however, since we haven't seen a lot of activity, we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Ali Ok al...@aliok.com.tr Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com: before we release it, we should (imo) discuss the future of this module. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribelu4...@gmail.com Hi It could be good to do an alpha release of myfaces html5 next week. The site for this project is: http://myfaces.apache.org/html5/ If no objections I'll do the
[jira] [Resolved] (TRINIDAD-2153) clear needs to be overridden in ChildArrayList
[ https://issues.apache.org/jira/browse/TRINIDAD-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabrielle Crawford resolved TRINIDAD-2153. -- Resolution: Fixed Assignee: Gabrielle Crawford clear needs to be overridden in ChildArrayList -- Key: TRINIDAD-2153 URL: https://issues.apache.org/jira/browse/TRINIDAD-2153 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gabrielle Crawford Assignee: Gabrielle Crawford ChildArrayList overrides remove, removeAll etc, but not clear. This needs to be overridden to call remove on each item, otherwise reordering with the change manager doesn't work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2152) token cache pinning session attribute map
[ https://issues.apache.org/jira/browse/TRINIDAD-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabrielle Crawford updated TRINIDAD-2152: - Resolution: Fixed Assignee: Gabrielle Crawford Status: Resolved (was: Patch Available) token cache pinning session attribute map -- Key: TRINIDAD-2152 URL: https://issues.apache.org/jira/browse/TRINIDAD-2152 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Gary VanMatre Assignee: Gabrielle Crawford Attachments: TokenCache-trunk.patch, TokenCache-trunk.patch Stevan Malesevic found that the token cache is pinning the session map. com.sun.faces.context.ExternalContextImpl will create a instance of com.sun.faces.context.SessionMap on every request. SessionMap points to Request object. However this is per request so it is not carried over between requests. Now, the reason why we always have request object pined between requests is Trinidad code TokenCache which pins the owner (SessionMap) which would otherwise be gc-ed. From what I can see Trinidad code can be changed to always get extContext.getSessionMap() instead pinning it permanently. This will make sure we are not pinning Request object and all its attributes in between requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [html5] alpha release for myfaces html5
hi ali, @maven dependency: we can deploy a snapshot to the (maven) snapshot-repository at any time. @release cycle: that won't change with tomahawk. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/22 Ali Ok al...@aliok.com.tr Hi, The truth is some people only test some artifacts after a release. Do it as an alpha release means ... software that has just been compiled and ready for its initial test inhouse. Yes, exactly. Everyone is using maven, and even I am annoyed when I try to use this library in another machine for the first time, since there is no repo for maven to download it. IMHO, having release cycles for the project would be really great. I also know the project needs more effort, but first thing we need is feedback. we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). If you think this way is better for the project, then IMHO it is also OK. I think this would be an advantage for the project if more people are going to participate. But what are the advantages of moving into sandbox? Or, I should ask, what are the concerns with the current way? If we clear this, we can easily decide :) Cheers, Ali On Fri, Oct 21, 2011 at 10:22 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: @grant: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Grant Smith work.gr...@gmail.com I must agree with Gerhard. The whole point of the sandbox is for this very purpose. However, perhaps we should look at the sandbox more often and vote on components that are ready to graduate. On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi leo, imo such an argument doesn't justify an own sub-project. i don't say -1. my point is that we should discuss it (esp. because the situation changed). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Leonardo Uribe lu4...@gmail.com Hi The problem with move to tomahawk sandbox is those artifact can't never be released. Do an alpha release give us the chance to know if the bits are good enough, get more feedback, and later decide what to do. The truth is some people only test some artifacts after a release. Do it as an alpha release means ... software that has just been compiled and ready for its initial test inhouse. I think that is enough clear. regards, Leonardo Uribe 2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com: hi ali, most commits happened directly after the initial import. that didn't look very promising. it's great to hear that you plan to continue. however, since we haven't seen a lot of activity, we should re-visit the option to move the components to tomahawk (btw. tomahawk-sandbox). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/21 Ali Ok al...@aliok.com.tr Hi, Thank you Leonardo for volunteering in the release. Yes, it would be good discussing the future. I am still working on the project. Leonardo and I am the only ones at the moment. I am trying to work on the project 1 night a week, so the progress is slow. I think it will be like this for a while. We have a few issues to fix / features to implement already in the issue tracker, and I am going to add more. There isn't enough feedback, since I guess Html5 stuff is still not supported by every browser and not everyone can use them. So the user profile is more like enthusiasts who are experimenting with Html5. What we could do is providing fallback for old browsers out of the box, but it is really hard to implement. About the future: there is a lot to do in this area and I am willing to work, but I can say I can spare limited time. That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. I agree. I am pretty sure a release is good for the project, more people will hear about it; and hopefully we can get some feedback. Cheers, Ali On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 10/21/11 7:56 PM, schrieb Leonardo Uribe: Hi That's the intention of this mail. I think we should do an alpha release. I don't see reasons to block a release. regards, Leonardo Uribe 2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com: before we release it, we should (imo) discuss the future of this module. regards, gerhard
[jira] [Commented] (TRINIDAD-2115) replace javax.faces.IS_SAVING_STATE with StateManager.IS_SAVING_STATE once we upgrade our JSF verstion to 2.1 or higher
[ https://issues.apache.org/jira/browse/TRINIDAD-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133210#comment-13133210 ] Gabrielle Crawford commented on TRINIDAD-2115: -- adf rich client depends on trinidad, if you are closing this issue please send a mail to the dev mailing list to let someone with access to the adf code know so they can fix the adf code. They can search for the term TRINIDAD-2115 in the adf code. replace javax.faces.IS_SAVING_STATE with StateManager.IS_SAVING_STATE once we upgrade our JSF verstion to 2.1 or higher -- Key: TRINIDAD-2115 URL: https://issues.apache.org/jira/browse/TRINIDAD-2115 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gabrielle Crawford In JSF 2.1 in com.sun.faces.application.StateManagerImpl.saveView StateManager.IS_SAVING_STATE is put in the contextAttributes before saving the view. We are not yet relying on JSF 2.1, so for now we will use the string value javax.faces.IS_SAVING_STATE. This was done in issue 2114 https://issues.apache.org/jira/browse/TRINIDAD-2114 Once we are dependendent on JSF 2.1 we should search for the string javax.faces.IS_SAVING_STATE and replace it with StateManager.IS_SAVING_STATE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
