[jira] Created: (TOBAGO-860) Make Popup work with new LayoutManager
Make Popup work with new LayoutManager -- Key: TOBAGO-860 URL: https://issues.apache.org/jira/browse/TOBAGO-860 Project: MyFaces Tobago Issue Type: Task Components: Core Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 1.5.0-alpha-2, 1.5.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOBAGO-305) Deutsch Umlaut will not be rendered correct for tc:out tag with attribute [escape=false]
[
https://issues.apache.org/jira/browse/TOBAGO-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Schnurpfeil resolved TOBAGO-305.
Resolution: Fixed
Seems to be fixed. If the problem still exists, please report a new bug.
Deutsch Umlaut will not be rendered correct for tc:out tag with attribute
[escape=false]
Key: TOBAGO-305
URL: https://issues.apache.org/jira/browse/TOBAGO-305
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 1.0.9
Environment: winxp prof, tomcat 5.5.20, myfaces 1.1.5 snap
(06.02.2007 04:51), tobago 1.0.10 snap (26.02.2007 5:00)
Reporter: Guido Dubois
The deutsch Umlaut will not be rendered correct.
tc:out value=#{overviewBundle.text}
escape=false /
bundle:
entry key=textBruttobetrag in EUR (abzügl. Sparerfreibetrag und
Werbungskosten)/entry
result looks like this:
Bruttobetrag in EUR (abz�parerfreibetrag und Werbungskosten)
uuml; is not possible and #252; has the same effect
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOBAGO-485) tc:menu and links
[ https://issues.apache.org/jira/browse/TOBAGO-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-485. Resolution: Invalid An other workaround might be using a Toolbar. tc:menu and links Key: TOBAGO-485 URL: https://issues.apache.org/jira/browse/TOBAGO-485 Project: MyFaces Tobago Issue Type: Improvement Components: Core, Themes Reporter: adam Priority: Minor tc:menuBar tc:menu label=Home /tc:menu /tc:menuBar i need to make a link on the menu Home directly with out using tc:menuItem . I need to know the answer plz asap. Thanks Regards M.Adam Junior Developer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1496) HtmlTreeRenderer 'background-image' incorrect html style attribute
[
https://issues.apache.org/jira/browse/TOMAHAWK-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12843989#action_12843989
]
Ronald Müller commented on TOMAHAWK-1496:
-
I just want to confirm this bug and add a patch. This bug is related to two
lines in class HtmlTreeRenderer.
BTW i took *one* day to get the tomahawk-sources compiled in my eclipse-ide and
finally managed it by removing this single class from the tomahawk-binary and
putting the HtmlTreeRenderer.java-sources to my workspace.
in detail:
i checked out the 'current'-folder
(http://svn.apache.org/repos/asf/myfaces/current/)
1) no way to compile tomahawk with maven: maven2 produced constantly build
errors (only at the tomahawk-package, myfaces-core went fine)
2) tried to compile only sources from package org.apache.myfaces.custom.tree2
- there are some sources missing: (HtmlTree.java, TreeTag.java) last seen in
version 1.1.6 !?
(/myfaces/tomahawk/tags/1_1_6/core/src/main/java/org/apache/myfaces/custom/tree2),
searched the whole myfaces-repo - but nothing (automatically generated ?)
i personally think open source is a great idea and i want to support those
projects whenever its possible to me. but in this case it was extremly
complicated.
HtmlTreeRenderer 'background-image' incorrect html style attribute
---
Key: TOMAHAWK-1496
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1496
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Tree2
Affects Versions: 1.1.7, 1.1.8, 1.1.9
Environment: Linux, firefox, ie
Reporter: Daniel del Río
Original Estimate: 0.5h
Remaining Estimate: 0.5h
Currently the td with the line-trunk images have the style to
background-image:/path/to/theImage.gif and should be:
background-image:url('/path/to/theImage') (see line 506). This bug
produces that some trees with big images in the nodes looks bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1496) HtmlTreeRenderer 'background-image' incorrect html style attribute
[
https://issues.apache.org/jira/browse/TOMAHAWK-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ronald Müller updated TOMAHAWK-1496:
Status: Patch Available (was: Open)
HtmlTreeRenderer 'background-image' incorrect html style attribute
---
Key: TOMAHAWK-1496
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1496
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Tree2
Affects Versions: 1.1.7, 1.1.8, 1.1.9
Environment: Linux, firefox, ie
Reporter: Daniel del Río
Original Estimate: 0.5h
Remaining Estimate: 0.5h
Currently the td with the line-trunk images have the style to
background-image:/path/to/theImage.gif and should be:
background-image:url('/path/to/theImage') (see line 506). This bug
produces that some trees with big images in the nodes looks bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2594) Facelets state saving doesn't handle well programmatic component manipulation
[
https://issues.apache.org/jira/browse/MYFACES-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844052#action_12844052
]
Leonardo Uribe commented on MYFACES-2594:
-
After checking this one, the conclusion was this issue should be closed as
won't fix.
Both RI and Myfaces are doing what is expected, or in other words, are doing
everything from the view point of the EG.
The effect demostrated by the example is a side effect of apply the facelet
after before render response. When we have this cases:
- javax.faces.PARTIAL_STATE_SAVING= false
- javax.faces.PARTIAL_STATE_SAVING=true and
org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS=true
- javax.faces.PARTIAL_STATE_SAVING=true and
org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS=auto and there is a c:if,
c:choose, c:forEach, ui:insert with src=valueexpression on the same facelet.
The bad behavior is presented. The reason is in this configurations the current
view is refreshed or updated by facelets algorithm, to allow components to
be added/removed on the tree triggered by a value change on invoke application
phase (c:if, c:forEach, c:when ..). In fact, that algorithm detach and
attach all components from the tree, so in that case, is facelets code that
detach and resort the nodes as originally was on the xml markup. The reason
why myfaces works with PSS enabled is that this specific code does not happen
in this case, but the drawback is we can't use in this case c:if to trigger
tree changes when a value changes on invoke application phase.
In theory, users should not change the components created by facelets or bound
by a facelet tag handler. But you can create components programatically and
add/remove to the tree, so if you create UIColumn instances inside the
h:datatable and try this example, it will work.
I don't think fix facelets algorithm could be possible. Since we cannot advance
more on this issue I'll close it as won't fix.
Facelets state saving doesn't handle well programmatic component manipulation
-
Key: MYFACES-2594
URL: https://issues.apache.org/jira/browse/MYFACES-2594
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.0-beta-3
Environment: myfaces trunk
Reporter: Martin Koci
Priority: Minor
Simple tests (code pasted below) outputs following results:
1) JSP: switchs colums at every click with no problem
2) Facelets with javax.faces.PARTIAL_STATE_SAVING=false - no visual switch
3) Facelets with javax.faces.PARTIAL_STATE_SAVING=true switchs colums at
every click with no problem
Common code from test.jspx and test.xhtml
... jsp: or facelets stuff here ...
h:form id=form
h:commandButton value=Switch columns
f:actionListener binding=#{testBean} /
/h:commandButton
h:dataTable id=table
h:column
f:facet name=header
h:outputText value=firstName /
/f:facet
/h:column
h:column
f:facet name=header
h:outputText value=surname /
/f:facet
/h:column
/h:dataTable
/h:form
@ManagedBean
@RequestScoped
public class TestBean implements ActionListener {
public void processAction(ActionEvent event) throws
AbortProcessingException {
FacesContext context = FacesContext.getCurrentInstance();
UIComponent table =
context.getViewRoot().findComponent(form:table);
UIComponent column1 = table.getChildren().get(0);
UIComponent column2 = table.getChildren().get(1);
table.getChildren().clear();
table.getChildren().add(column2);
table.getChildren().add(column1);
}
}
--
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: (TOBAGO-765) A test web-application for automated tests
[ https://issues.apache.org/jira/browse/TOBAGO-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12720703#action_12720703 ] Udo Schnurpfeil edited comment on TOBAGO-765 at 3/11/10 1:14 PM: - The test are located here: example/test You can run the tests with: mvn -P integration-test Or you may use the webapp for manually testing: mvn jetty:run was (Author: lofwyr): You can run the tests with: mvn -P integration-test A test web-application for automated tests -- Key: TOBAGO-765 URL: https://issues.apache.org/jira/browse/TOBAGO-765 Project: MyFaces Tobago Issue Type: Test Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 1.5.0 The basic idea is, to have a web-appliation with test pages for all functionallity of the tobago framework. This application can be used be a normal web-browser to see if all works fine. On the other side, the application should be tested automatically. Here we can use the selenium framework. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOBAGO-765) A test web-application for automated tests
[ https://issues.apache.org/jira/browse/TOBAGO-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-765. Resolution: Fixed Fix Version/s: 1.5.0 A test web-application for automated tests -- Key: TOBAGO-765 URL: https://issues.apache.org/jira/browse/TOBAGO-765 Project: MyFaces Tobago Issue Type: Test Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 1.5.0 The basic idea is, to have a web-appliation with test pages for all functionallity of the tobago framework. This application can be used be a normal web-browser to see if all works fine. On the other side, the application should be tested automatically. Here we can use the selenium framework. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces in OSGi
Hi
Really it could be a big help if you could provide an example about how is
your setup in this case. It is very difficult to reproduce this cases
without a proper example and configuration. I only was able to run myfaces
in osgi using spring dm (which solves all those issues doing some things
nasty from osgi point of view) so I could help better if we have some proper
test case for suppor it. It could be a big help to know the hacks to be
done for handle classloading, load resources and so on in a osgi compatible
way.
regards,
Leonardo Uribe
2010/2/22 Jarek Gawor jga...@gmail.com
Hi,
I was wondering if somebody could take a look at MYFACES-2550. Also,
the published snapshot of MyFaces core is a little old.
Thanks,
Jarek
On Thu, Feb 11, 2010 at 12:49 PM, Jarek Gawor jga...@gmail.com wrote:
Thanks for fixing MYFACES-2548! I just opened MYFACES-2550 for the
AnnotationConfigurator.getMyfacesImplJarFile() issue.
Thanks again,
Jarek
On Thu, Feb 11, 2010 at 12:19 AM, Jarek Gawor jga...@gmail.com wrote:
Ok, sure. For now I created MYFACES-2548 with a proposed patch. I
might open one more bug for the
AnnotationConfigurator.getMyfacesImplJarFile() issue once I do little
more testing.
Jarek
On Wed, Feb 10, 2010 at 5:51 PM, Jakob Korherr jakob.korh...@gmail.com
wrote:
Hi Jarek,
It would be great if you could file your problems as issues in the
jira.
Then I will take a look at them!
Thanks,
Jakob
2010/2/10 Jarek Gawor jga...@gmail.com
Hi all,
I'm trying to make latest MyFaces core run in OSGi environment (in
Geronimo 3.0) and I'm running into a few problems. I'm hoping to get
your input on some of these problems. Here's our setup: we deploy
myfaces-api and myfaces-impl as separate bundles and we also have a
separate bundle that is the application (effectively a war file) that
uses jsf. When running the application, Geronimo sets the context
class loader to the application classloader which delegates the calls
to the application bundle.
Now, most of the problems we are running into are due to use of the
context class loader in myfaces code to lookup resources within the
META-INF directory.
For example, IncludeHandler.java looks up
META-INF/rsc/myfaces-dev-error-include.xhtml resource or
FacesConfigurator.java looks up META-INF/standard-faces-config.xml
resource via CCL. This works great in a regular Java environment but
breaks in OSGi. One easy solution for this would be to first ask the
CCL for the resource and if none is found ask the surrounding class
class loader for that resource (assuming the resource we are looking
for lives in the same jar as the class loading it), i.e.:
URL foo = getContextClassLoader().getResource(META-INF/foo);
if (foo == null) {
foo = getClass().getClassLoader().getResource(META-INF/foo);
}
There are other more advanced work-arounds (e.g. ContextFinder in
Equinox) but I'm wondering what people think about updating the
MyFaces code to use this simple solution. Just to be clear, this only
needs to be done for a few known resources that live within the impl
or api jars and not for all resource lookups.
The ErrorPageWriter.java also looks up some resources via CCL and can
fall back to looking for META-INF/rsc/myfaces-dev-error.xml and
META-INF/rsc/myfaces-dev-debug.xml. But these resources live in the
api module for some reason. I'm not sure why but I'm hoping they can
be moved to the impl module. That way the simple solution mentioned
above would still work.
My final problem is with
AnnotationConfigurator.getMyfacesImplJarFile(). Besides the problem
with META-INF lookup using CCL and even if that method successfully
looked up that resource, it won't be able to get a JarFile out it.
Because the url returned from resource lookup in OSGi environment
can't be considered as a url to a jar file. So I think we will need a
way to override that piece of code from Geronimo somehow. Maybe even
making the getMyfacesImplJarFile() method protected would work for us
(we can return a fake JarFile that deletes calls to a bundle object).
Thanks,
Jarek
[jira] Commented: (TOBAGO-765) A test web-application for automated tests
[ https://issues.apache.org/jira/browse/TOBAGO-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844069#action_12844069 ] Leonardo Uribe commented on TOBAGO-765: --- Cool! It could be good to have something like this with myfaces core 2.0.x. I'll try to reuse the code committed here in currrent20 test-webapp. A test web-application for automated tests -- Key: TOBAGO-765 URL: https://issues.apache.org/jira/browse/TOBAGO-765 Project: MyFaces Tobago Issue Type: Test Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 1.5.0 The basic idea is, to have a web-appliation with test pages for all functionallity of the tobago framework. This application can be used be a normal web-browser to see if all works fine. On the other side, the application should be tested automatically. Here we can use the selenium framework. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Google SoC
Hi Martin, If it's ok with everyone, I would also like to be a mentor! Regards, Jakob 2010/3/11, Martin Marinschek mmarinsc...@apache.org: Based on the outcome of this discussion, I will add a few issues to our issue tracker which amount to these proposals. Matthias, did you already sign up to be a mentor? Did anyone else do so already? Who wants to mentor? best regards, Martin On 3/11/10, Martin Marinschek mmarinsc...@apache.org wrote: - Extend Orchestra use Conversations based on the JSF 2.0 custom scope API, Extend Orchestra to work with Spring Conversations, to do File-New Window Handling I was thinking based on a suggestion done on JSFDays to take advantage on trinidad pageFlowScope code (like we did with flash scope on myfaces 2.0), and refactor that code to allow orchestra conversation scope work without spring (using the new JSF 2.0 custom scope). [Mario Ivankovits] Orchestra without Spring, that surely would be great. One thing to keep in mind is that we need AOP or at least proxying to inject the current conversation into the bean. Not too complicated, though. ok, sure - this could be part of the project. But what does this have to do with trinidad's pageFlowScope? If there is common utiltiy methods we can re-use (for example for file--new window detection in IE with JavaScript the generation of this JavaScript), we can and should certainly reuse it. If we leave the EntityManager thing out of line, we just need a JSF 2.0 scope impl and the proxying/interception stuff which is handled by Spring currently. perfect - let's do a proposal for this. best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Google SoC
Hey, nope, have not signed up to be the HTML5 RenderKit mentor. Any URL for that ? -M On Thu, Mar 11, 2010 at 6:05 AM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Martin, If it's ok with everyone, I would also like to be a mentor! Regards, Jakob 2010/3/11, Martin Marinschek mmarinsc...@apache.org: Based on the outcome of this discussion, I will add a few issues to our issue tracker which amount to these proposals. Matthias, did you already sign up to be a mentor? Did anyone else do so already? Who wants to mentor? best regards, Martin On 3/11/10, Martin Marinschek mmarinsc...@apache.org wrote: - Extend Orchestra use Conversations based on the JSF 2.0 custom scope API, Extend Orchestra to work with Spring Conversations, to do File-New Window Handling I was thinking based on a suggestion done on JSFDays to take advantage on trinidad pageFlowScope code (like we did with flash scope on myfaces 2.0), and refactor that code to allow orchestra conversation scope work without spring (using the new JSF 2.0 custom scope). [Mario Ivankovits] Orchestra without Spring, that surely would be great. One thing to keep in mind is that we need AOP or at least proxying to inject the current conversation into the bean. Not too complicated, though. ok, sure - this could be part of the project. But what does this have to do with trinidad's pageFlowScope? If there is common utiltiy methods we can re-use (for example for file--new window detection in IE with JavaScript the generation of this JavaScript), we can and should certainly reuse it. If we leave the EntityManager thing out of line, we just need a JSF 2.0 scope impl and the proxying/interception stuff which is handled by Spring currently. perfect - let's do a proposal for this. best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Google SoC
Hi http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#org_apply http://socghop.appspot.com/ According to the info, there should be someone on ASF that knows how to deal with this stuff, because there is at least one administer from ASF side. regards, Leonardo Uribe 2010/3/11 Matthias Wessendorf mat...@apache.org Hey, nope, have not signed up to be the HTML5 RenderKit mentor. Any URL for that ? -M On Thu, Mar 11, 2010 at 6:05 AM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Martin, If it's ok with everyone, I would also like to be a mentor! Regards, Jakob 2010/3/11, Martin Marinschek mmarinsc...@apache.org: Based on the outcome of this discussion, I will add a few issues to our issue tracker which amount to these proposals. Matthias, did you already sign up to be a mentor? Did anyone else do so already? Who wants to mentor? best regards, Martin On 3/11/10, Martin Marinschek mmarinsc...@apache.org wrote: - Extend Orchestra use Conversations based on the JSF 2.0 custom scope API, Extend Orchestra to work with Spring Conversations, to do File-New Window Handling I was thinking based on a suggestion done on JSFDays to take advantage on trinidad pageFlowScope code (like we did with flash scope on myfaces 2.0), and refactor that code to allow orchestra conversation scope work without spring (using the new JSF 2.0 custom scope). [Mario Ivankovits] Orchestra without Spring, that surely would be great. One thing to keep in mind is that we need AOP or at least proxying to inject the current conversation into the bean. Not too complicated, though. ok, sure - this could be part of the project. But what does this have to do with trinidad's pageFlowScope? If there is common utiltiy methods we can re-use (for example for file--new window detection in IE with JavaScript the generation of this JavaScript), we can and should certainly reuse it. If we leave the EntityManager thing out of line, we just need a JSF 2.0 scope impl and the proxying/interception stuff which is handled by Spring currently. perfect - let's do a proposal for this. best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TOBAGO-861) Generator should be able to process more than one @UIComponentTagAttribute definition per attribute
Generator should be able to process more than one @UIComponentTagAttribute definition per attribute --- Key: TOBAGO-861 URL: https://issues.apache.org/jira/browse/TOBAGO-861 Project: MyFaces Tobago Issue Type: Improvement Affects Versions: 1.5.0-alpha-1 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil So the definition can be overridden in the main declaration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-2598) UIViewParameter does not get an automatic id
[
https://issues.apache.org/jira/browse/MYFACES-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe reopened MYFACES-2598:
-
pushUniqueIdVendorToStack should be called from ComponentTagHandlerDelegate,
not from DefaultFacelet. This code should be reverted. Really that warning is
becoming nasty and starting to have no sense, because it is common to create
components without any explicit id. I'll comment that one and rever the changes.
UIViewParameter does not get an automatic id
Key: MYFACES-2598
URL: https://issues.apache.org/jira/browse/MYFACES-2598
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.0-beta-3
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Fix For: 2.0.0-beta-3
You see the fancy missing id warning when using f:viewParam:
10.03.2010 13:35:36 javax.faces.component.UIComponentBase getClientId
WARNUNG: WARNING: Component j_id12 just got an automatic id, because there
was no id assigned yet. If this component was created dynamically (i.e. not
by a JSP tag) you should assign it an explicit static id or assign it the id
you get from the createUniqueId from the current UIViewRoot component right
after creation! Path to Component: {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /viewparam.xhtml][Class:
javax.faces.component.UIPanel,Id: javax_faces_metadata][Class:
javax.faces.component.UIViewParameter,Id: j_id12]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2598) UIViewParameter does not get an automatic id
[
https://issues.apache.org/jira/browse/MYFACES-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2598.
-
Resolution: Fixed
Assignee: Leonardo Uribe (was: Jakob Korherr)
UIViewParameter does not get an automatic id
Key: MYFACES-2598
URL: https://issues.apache.org/jira/browse/MYFACES-2598
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.0-beta-3
Reporter: Jakob Korherr
Assignee: Leonardo Uribe
Fix For: 2.0.0-beta-3
You see the fancy missing id warning when using f:viewParam:
10.03.2010 13:35:36 javax.faces.component.UIComponentBase getClientId
WARNUNG: WARNING: Component j_id12 just got an automatic id, because there
was no id assigned yet. If this component was created dynamically (i.e. not
by a JSP tag) you should assign it an explicit static id or assign it the id
you get from the createUniqueId from the current UIViewRoot component right
after creation! Path to Component: {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /viewparam.xhtml][Class:
javax.faces.component.UIPanel,Id: javax_faces_metadata][Class:
javax.faces.component.UIViewParameter,Id: j_id12]}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [core] Introducing implee6 - MYFACES-2579
Hi I'm working with jdk 1.5 and when I tried to compile current20 branch I have an error. This means to create myfaces jars it should be compiled with jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific code: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6 \MyFacesContainerInitializer.java:[47,-1] cannot access javax.servlet.ServletCon tainerInitializer bad class file: C:\Documents and Settings\lu4242\.m2\repository\javax\javaee-web -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class) class file has wrong version 50.0, should be 49.0 In theory, we can't do this, because if we do, myfaces-impl has one class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the practice this class is not loaded by any part of myfaces, but maybe some program that tries to scan the classpath and load this class into the classpath will see the problem. My personal opinion is implee6 should have its own separate jar with some OSGi specific stuff, so if someone wants to use it it should put three jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a lot of precedences for that kind of stuff (orchestra core and core15 for example, tomahawk sandbox and sandbox15). I also think this code should be moved to myfaces commons, because keep it as a module in core project means we have to use jdk 1.6 to compile all artifacts and we have a plugin that checks for jdk 1.5 compatibility that will fail (see checkJDK profile on myfaces impl pom). Suggestions are welcome. regards, Leonardo Uribe 2010/3/8 Jakob Korherr jakob.korh...@gmail.com Hi, So I committed everything. Please feel free to test it - I am curious about your opinions :) Regards, Jakob 2010/3/8 Jakob Korherr jakob.korh...@gmail.com Hi, Since there don't seem to be any big concerns about this, I will now commit the new submodule implee6. Regards, Jakob 2010/3/8 Gerhard Petracek gerhard.petra...@gmail.com +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/8 Werner Punz werner.p...@gmail.com +1 for that idea, the less configuration the better. Werner Am 07.03.10 15:44, schrieb Jakob Korherr: I think we don't even need such a parameter, because the idea is that the listener just does nothing if there are already entries for the FacesServlet in web.xml! Regards, Jakob 2010/3/7 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com Agreed, I was only thinking of one parameter: A parameter to turn the entire StartupListener off. I look at it as a binary thing. Either the developer chooses to go with the flow with no custimization, OR he chooses to customize everything. I.e. org.apache.myfaces.DISABLE_FACES_SERVLET_AUTODEPLOY = true (default false) I think this will cover all use cases, where some may require a bit more configuration, but still work... /JK 2010/3/7 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com Yep! We can discuss this stuff when the submodule is in place. Such things are very easy to change/configure in the StartupListener. However, I think we should come up with a very standard default configuration. If the user wants something different, he will have to configure the mapping himself in the web.xml just as it is now. I am not a fan of too many configuration parameters which interfere with other configuration methods. Regards, Jakob 2010/3/7 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com In other words: Convention over configuration ;-) I just think it's important to pick sensible defaults and to be able to turn it off, for example using a context-param. For example, I think the mapping *.xhtml should also be default, but a developer must be able to turn *.xhtml off, since it's a widely used extension also outside of JSF... Regards, Jan-Kees 2010/3/7 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com Hi Bernd, For some users it may be so ;) :D Look Bernd, it's not that big thing. It's just a class and a text file. So it is by no means a problem to ship this with MyFaces Core 2. Also Mojarra does something similar too! To your question: Nope! I just add the FacesServlet and
[jira] Reopened: (MYFACES-2509) @ListenerFor not processed for global system events
[
https://issues.apache.org/jira/browse/MYFACES-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe reopened MYFACES-2509:
-
I have to reopen this issue. The reason is really I don't believe this code
works, or anyone has tested it fully. Look this code carefully:
private void processListenerFor(Application application, Class clazz,
ListenerFor listenerFor)
{
try
{
if (SystemEventListener.class.isAssignableFrom(clazz))
{
Class sourceClass = listenerFor.sourceClass();
Class? extends SystemEvent systemEventClass =
listenerFor.systemEventClass();
if (Void.class.equals(sourceClass))
{
application.subscribeToEvent(systemEventClass,
(SystemEventListener) clazz.newInstance());
}
else
{
application.subscribeToEvent(systemEventClass, sourceClass,
(SystemEventListener) clazz.newInstance());
}
}
}
catch (InstantiationException e)
{
throw new FacesException(e);
}
catch (IllegalAccessException e)
{
throw new FacesException(e);
}
}
Do you see the clazz.newInstance()? This works for classes that does not have
state, but what happen if we need some variable. Since the real is created
somewhere else, the value will not be right.
If we want to make this work, we have to scan for annotations after the
instantiation and if we have a instance wrapping, we should scan properly. What
happen if some user has a @ListenerFor for a PhaseListener? What happen is some
user has a @ListenerFor for a Application/ViewHandler/StateManager instance? Do
we need to do something for CDI?
The spec is silent about that, so the right way to solve this one is propose an
algorithm and submit is first to jsr-314-open mail list, so the experts can
take a look and decide what to do. Maybe we can propose something and do it on
myfaces directly, since we are on beta yet, but the intention about do all this
bureaucracy is keep as close with the spec as possible or in other words, make
applications interchageable between jsf implementations.
Unfortunately, I have to revert this code, because I just can't do another beta
release with this code on it.
@ListenerFor not processed for global system events
---
Key: MYFACES-2509
URL: https://issues.apache.org/jira/browse/MYFACES-2509
Project: MyFaces Core
Issue Type: New Feature
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Jan-Kees van Andel
Assignee: Jan-Kees van Andel
Fix For: 2.0.0-beta-3
Attachments: ListenerFor_support.patch
We currently don't process @ListenerFor and @ListenerFor annotations on
non-component types.
This is specified in the spec for global system events, see:
http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html?javax/faces/event/ListenerFor.html
It would be nice to have it in the beta.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [core] Introducing implee6 - MYFACES-2579
Why not override the compiler plugin in the module to use JDK 6? I think the whole point about the module is ease of development and this will suffer when putting it in a separate jar. About the manual classpath scanning or other runtime stuff. This should not break because of JDK 6 stuff, since the bytecode should be backwards compatible. My 2 cents... /JK 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I'm working with jdk 1.5 and when I tried to compile current20 branch I have an error. This means to create myfaces jars it should be compiled with jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific code: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6 \MyFacesContainerInitializer.java:[47,-1] cannot access javax.servlet.ServletCon tainerInitializer bad class file: C:\Documents and Settings\lu4242\.m2\repository\javax\javaee-web -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class) class file has wrong version 50.0, should be 49.0 In theory, we can't do this, because if we do, myfaces-impl has one class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the practice this class is not loaded by any part of myfaces, but maybe some program that tries to scan the classpath and load this class into the classpath will see the problem. My personal opinion is implee6 should have its own separate jar with some OSGi specific stuff, so if someone wants to use it it should put three jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a lot of precedences for that kind of stuff (orchestra core and core15 for example, tomahawk sandbox and sandbox15). I also think this code should be moved to myfaces commons, because keep it as a module in core project means we have to use jdk 1.6 to compile all artifacts and we have a plugin that checks for jdk 1.5 compatibility that will fail (see checkJDK profile on myfaces impl pom). Suggestions are welcome. regards, Leonardo Uribe 2010/3/8 Jakob Korherr jakob.korh...@gmail.com Hi, So I committed everything. Please feel free to test it - I am curious about your opinions :) Regards, Jakob 2010/3/8 Jakob Korherr jakob.korh...@gmail.com Hi, Since there don't seem to be any big concerns about this, I will now commit the new submodule implee6. Regards, Jakob 2010/3/8 Gerhard Petracek gerhard.petra...@gmail.com +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/8 Werner Punz werner.p...@gmail.com +1 for that idea, the less configuration the better. Werner Am 07.03.10 15:44, schrieb Jakob Korherr: I think we don't even need such a parameter, because the idea is that the listener just does nothing if there are already entries for the FacesServlet in web.xml! Regards, Jakob 2010/3/7 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com Agreed, I was only thinking of one parameter: A parameter to turn the entire StartupListener off. I look at it as a binary thing. Either the developer chooses to go with the flow with no custimization, OR he chooses to customize everything. I.e. org.apache.myfaces.DISABLE_FACES_SERVLET_AUTODEPLOY = true (default false) I think this will cover all use cases, where some may require a bit more configuration, but still work... /JK 2010/3/7 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com Yep! We can discuss this stuff when the submodule is in place. Such things are very easy to change/configure in the StartupListener. However, I think we should come up with a very standard default configuration. If the user wants something different, he will have to configure the mapping himself in the web.xml just as it is now. I am not a fan of too many configuration parameters which interfere with other configuration methods. Regards, Jakob 2010/3/7 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com In other words: Convention over configuration ;-) I just think it's important to pick sensible defaults and to be able to turn it off, for example using a context-param. For example, I think the mapping *.xhtml should also be default, but a developer must be able to turn *.xhtml off, since it's a widely used extension also outside of JSF... Regards, Jan-Kees 2010/3/7 Jakob Korherr
Re: [core] Introducing implee6 - MYFACES-2579
Hi I have sended an email to jsr-314-open mail list just to confirm if it is valid or not to do this kind of stuff. The problem is the class involved on implee6 has dependencies with classes that needs JDK 6 to be compiled, so in a JDK 1.5 environment it will crash if the classes are loaded. It is true ease of development will suffer, but I think prevent bugs like this takes precedence. regards, Leonardo Uribe 2010/3/11 Jan-Kees van Andel jankeesvanan...@gmail.com Why not override the compiler plugin in the module to use JDK 6? I think the whole point about the module is ease of development and this will suffer when putting it in a separate jar. About the manual classpath scanning or other runtime stuff. This should not break because of JDK 6 stuff, since the bytecode should be backwards compatible. My 2 cents... /JK 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I'm working with jdk 1.5 and when I tried to compile current20 branch I have an error. This means to create myfaces jars it should be compiled with jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific code: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6 \MyFacesContainerInitializer.java:[47,-1] cannot access javax.servlet.ServletCon tainerInitializer bad class file: C:\Documents and Settings\lu4242\.m2\repository\javax\javaee-web -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class) class file has wrong version 50.0, should be 49.0 In theory, we can't do this, because if we do, myfaces-impl has one class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the practice this class is not loaded by any part of myfaces, but maybe some program that tries to scan the classpath and load this class into the classpath will see the problem. My personal opinion is implee6 should have its own separate jar with some OSGi specific stuff, so if someone wants to use it it should put three jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a lot of precedences for that kind of stuff (orchestra core and core15 for example, tomahawk sandbox and sandbox15). I also think this code should be moved to myfaces commons, because keep it as a module in core project means we have to use jdk 1.6 to compile all artifacts and we have a plugin that checks for jdk 1.5 compatibility that will fail (see checkJDK profile on myfaces impl pom). Suggestions are welcome. regards, Leonardo Uribe 2010/3/8 Jakob Korherr jakob.korh...@gmail.com Hi, So I committed everything. Please feel free to test it - I am curious about your opinions :) Regards, Jakob 2010/3/8 Jakob Korherr jakob.korh...@gmail.com Hi, Since there don't seem to be any big concerns about this, I will now commit the new submodule implee6. Regards, Jakob 2010/3/8 Gerhard Petracek gerhard.petra...@gmail.com +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/8 Werner Punz werner.p...@gmail.com +1 for that idea, the less configuration the better. Werner Am 07.03.10 15:44, schrieb Jakob Korherr: I think we don't even need such a parameter, because the idea is that the listener just does nothing if there are already entries for the FacesServlet in web.xml! Regards, Jakob 2010/3/7 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com Agreed, I was only thinking of one parameter: A parameter to turn the entire StartupListener off. I look at it as a binary thing. Either the developer chooses to go with the flow with no custimization, OR he chooses to customize everything. I.e. org.apache.myfaces.DISABLE_FACES_SERVLET_AUTODEPLOY = true (default false) I think this will cover all use cases, where some may require a bit more configuration, but still work... /JK 2010/3/7 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com Yep! We can discuss this stuff when the submodule is in place. Such things are very easy to change/configure in the StartupListener. However, I think we should come up with a very standard default configuration. If the user wants something different, he will have to configure the mapping himself in the web.xml just as it is now. I am not a fan of too many configuration parameters which interfere with other configuration methods. Regards, Jakob 2010/3/7 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com In other words:
Re: [core] Introducing implee6 - MYFACES-2579
Hi, I totally agree with Jan-Kees. Just override the compiler plugin in implee6 to use jdk 6! Also I really don't see why you think it is such a big problem to have a class in the jar file which has other dependencies and another version when no other class has any relations to it. It's like a website with no link referring to it: you will never find it unless you know the real address of it! Furthermore if we put it into myfaces commons we can also drop it, because then it makes no sence. The user will rather continue to use the web.xml configuration than bundling some jar, which he maybe does not know that it even exists.. And last but not least: Mojarra also has a similar JDK6 compiled class with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a problem for MyFaces? Please don't make this problem bigger as it is... Regards, Jakob 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I have sended an email to jsr-314-open mail list just to confirm if it is valid or not to do this kind of stuff. The problem is the class involved on implee6 has dependencies with classes that needs JDK 6 to be compiled, so in a JDK 1.5 environment it will crash if the classes are loaded. It is true ease of development will suffer, but I think prevent bugs like this takes precedence. regards, Leonardo Uribe 2010/3/11 Jan-Kees van Andel jankeesvanan...@gmail.com Why not override the compiler plugin in the module to use JDK 6? I think the whole point about the module is ease of development and this will suffer when putting it in a separate jar. About the manual classpath scanning or other runtime stuff. This should not break because of JDK 6 stuff, since the bytecode should be backwards compatible. My 2 cents... /JK 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I'm working with jdk 1.5 and when I tried to compile current20 branch I have an error. This means to create myfaces jars it should be compiled with jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific code: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6 \MyFacesContainerInitializer.java:[47,-1] cannot access javax.servlet.ServletCon tainerInitializer bad class file: C:\Documents and Settings\lu4242\.m2\repository\javax\javaee-web -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class) class file has wrong version 50.0, should be 49.0 In theory, we can't do this, because if we do, myfaces-impl has one class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the practice this class is not loaded by any part of myfaces, but maybe some program that tries to scan the classpath and load this class into the classpath will see the problem. My personal opinion is implee6 should have its own separate jar with some OSGi specific stuff, so if someone wants to use it it should put three jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a lot of precedences for that kind of stuff (orchestra core and core15 for example, tomahawk sandbox and sandbox15). I also think this code should be moved to myfaces commons, because keep it as a module in core project means we have to use jdk 1.6 to compile all artifacts and we have a plugin that checks for jdk 1.5 compatibility that will fail (see checkJDK profile on myfaces impl pom). Suggestions are welcome. regards, Leonardo Uribe 2010/3/8 Jakob Korherr jakob.korh...@gmail.com Hi, So I committed everything. Please feel free to test it - I am curious about your opinions :) Regards, Jakob 2010/3/8 Jakob Korherr jakob.korh...@gmail.com Hi, Since there don't seem to be any big concerns about this, I will now commit the new submodule implee6. Regards, Jakob 2010/3/8 Gerhard Petracek gerhard.petra...@gmail.com +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/8 Werner Punz werner.p...@gmail.com +1 for that idea, the less configuration the better. Werner Am 07.03.10 15:44, schrieb Jakob Korherr: I think we don't even need such a parameter, because the idea is that the listener just does nothing if there are already entries for the FacesServlet in web.xml! Regards, Jakob 2010/3/7 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com Agreed, I was only thinking of one parameter: A parameter to turn the entire StartupListener off. I look at it as a binary thing. Either the developer chooses to go with the flow with no custimization, OR he chooses to customize everything. I.e.
Re: [core] Introducing implee6 - MYFACES-2579
Hi 2010/3/11 Jakob Korherr jakob.korh...@gmail.com Hi, I totally agree with Jan-Kees. Just override the compiler plugin in implee6 to use jdk 6! Also I really don't see why you think it is such a big problem to have a class in the jar file which has other dependencies and another version when no other class has any relations to it. It's like a website with no link referring to it: you will never find it unless you know the real address of it! Furthermore if we put it into myfaces commons we can also drop it, because then it makes no sence. The user will rather continue to use the web.xml configuration than bundling some jar, which he maybe does not know that it even exists.. So the change has no sense outside myfaces impl jar. That means we only have two options: do it like this or remove the code. And last but not least: Mojarra also has a similar JDK6 compiled class with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a problem for MyFaces? The position from jsr-314-open mail list is as long as TCK test pass we could do it, and if mojarra has something similar, we could do the same. If something happens we could remove it and that's all (that means if something happens we'll be forced to remove this feature from myfaces and that is risky), since this is not part of the standard, but users should be aware of that implication. Note from this change, myfaces requires JDK 1.6 to be compiled, but the classes inside api and impl modules requires JDK 1.5. Please don't make this problem bigger as it is... I believe it is important to discuss the possible implications of a change before commit it and make it clear to people (that's one idea about opensource, give the people the power to know what's happening behind courtains and the tools to change it). Just put some code because you like it, or it is cool not always is enough. That's common sense, right?. Also you have to keep into account this is a standard of some spec, not just a custom library, so a lot of care is required before add a new feature outside the spec. So, the idea is not make a problem bigger or start a bizantine war that leads to nowhere, just benefit the community throught constructive discussion, but for a discussion it is necessary a clear and rational position, possible courses of action before start and a open mind, that means, give yourself the possibility of change of opinion anytime. Please note the benefit of this exercise, if someone wants to check why this stuff is done in this or that way, there is a source of knowledge through the mailing list. Please think carefully about what opensource word means. regards, Leonardo Uribe Regards, Jakob 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I have sended an email to jsr-314-open mail list just to confirm if it is valid or not to do this kind of stuff. The problem is the class involved on implee6 has dependencies with classes that needs JDK 6 to be compiled, so in a JDK 1.5 environment it will crash if the classes are loaded. It is true ease of development will suffer, but I think prevent bugs like this takes precedence. regards, Leonardo Uribe 2010/3/11 Jan-Kees van Andel jankeesvanan...@gmail.com Why not override the compiler plugin in the module to use JDK 6? I think the whole point about the module is ease of development and this will suffer when putting it in a separate jar. About the manual classpath scanning or other runtime stuff. This should not break because of JDK 6 stuff, since the bytecode should be backwards compatible. My 2 cents... /JK 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I'm working with jdk 1.5 and when I tried to compile current20 branch I have an error. This means to create myfaces jars it should be compiled with jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific code: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6 \MyFacesContainerInitializer.java:[47,-1] cannot access javax.servlet.ServletCon tainerInitializer bad class file: C:\Documents and Settings\lu4242\.m2\repository\javax\javaee-web -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class) class file has wrong version 50.0, should be 49.0 In theory, we can't do this, because if we do, myfaces-impl has one class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the practice this class is not loaded by any part of myfaces, but maybe some program that tries to scan the classpath and load this class into the classpath will see the problem. My personal opinion is implee6 should have its own separate jar with some OSGi specific stuff, so if someone wants to use it it should put three jars
Re: [core] Introducing implee6 - MYFACES-2579
I agree with Leonardo that changes which affect our base requirements (jdk 6 instead of jdk 5) and which could compromise our certification warrant discussion rather than a commit-and-hope-no-one-complains attitude. Otherwise, without discussion, how would we know that Mojarra allows it? On Thu, Mar 11, 2010 at 4:24 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi 2010/3/11 Jakob Korherr jakob.korh...@gmail.com Hi, I totally agree with Jan-Kees. Just override the compiler plugin in implee6 to use jdk 6! Also I really don't see why you think it is such a big problem to have a class in the jar file which has other dependencies and another version when no other class has any relations to it. It's like a website with no link referring to it: you will never find it unless you know the real address of it! Furthermore if we put it into myfaces commons we can also drop it, because then it makes no sence. The user will rather continue to use the web.xml configuration than bundling some jar, which he maybe does not know that it even exists.. So the change has no sense outside myfaces impl jar. That means we only have two options: do it like this or remove the code. And last but not least: Mojarra also has a similar JDK6 compiled class with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a problem for MyFaces? The position from jsr-314-open mail list is as long as TCK test pass we could do it, and if mojarra has something similar, we could do the same. If something happens we could remove it and that's all (that means if something happens we'll be forced to remove this feature from myfaces and that is risky), since this is not part of the standard, but users should be aware of that implication. Note from this change, myfaces requires JDK 1.6 to be compiled, but the classes inside api and impl modules requires JDK 1.5. Please don't make this problem bigger as it is... I believe it is important to discuss the possible implications of a change before commit it and make it clear to people (that's one idea about opensource, give the people the power to know what's happening behind courtains and the tools to change it). Just put some code because you like it, or it is cool not always is enough. That's common sense, right?. Also you have to keep into account this is a standard of some spec, not just a custom library, so a lot of care is required before add a new feature outside the spec. So, the idea is not make a problem bigger or start a bizantine war that leads to nowhere, just benefit the community throught constructive discussion, but for a discussion it is necessary a clear and rational position, possible courses of action before start and a open mind, that means, give yourself the possibility of change of opinion anytime. Please note the benefit of this exercise, if someone wants to check why this stuff is done in this or that way, there is a source of knowledge through the mailing list. Please think carefully about what opensource word means. regards, Leonardo Uribe Regards, Jakob 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I have sended an email to jsr-314-open mail list just to confirm if it is valid or not to do this kind of stuff. The problem is the class involved on implee6 has dependencies with classes that needs JDK 6 to be compiled, so in a JDK 1.5 environment it will crash if the classes are loaded. It is true ease of development will suffer, but I think prevent bugs like this takes precedence. regards, Leonardo Uribe 2010/3/11 Jan-Kees van Andel jankeesvanan...@gmail.com Why not override the compiler plugin in the module to use JDK 6? I think the whole point about the module is ease of development and this will suffer when putting it in a separate jar. About the manual classpath scanning or other runtime stuff. This should not break because of JDK 6 stuff, since the bytecode should be backwards compatible. My 2 cents... /JK 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I'm working with jdk 1.5 and when I tried to compile current20 branch I have an error. This means to create myfaces jars it should be compiled with jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific code: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6 \MyFacesContainerInitializer.java:[47,-1] cannot access javax.servlet.ServletCon tainerInitializer bad class file: C:\Documents and Settings\lu4242\.m2\repository\javax\javaee-web -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class) class file has wrong version 50.0, should be 49.0 In theory, we can't do this, because if we do, myfaces-impl has one class jdk
Re: [core] Introducing implee6 - MYFACES-2579
Hi Try this one: http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.20100224/ It does not seem to have jdk 1.6 dependencies regards, Leonardo Uribe 2010/3/11 Jakob Korherr jakob.korh...@gmail.com Maybe we can use a dependency to Servlet API 3.0 which is compiled against JDK 5 instead of the javaee-web-api. Is there anything like that? Regards, Jakob 2010/3/11 Jakob Korherr jakob.korh...@gmail.com Hi, So the change has no sense outside myfaces impl jar. That means we only have two options: do it like this or remove the code. -- yeap! Of course this has to be documented and the mailing list (archive) is the first place it already is, which, for sure, is great. In addition, I think we should create a wiki-entry for this. Also and of course I think it is very important to have those discussions, but they have to be constructive. Opening the same problems again and again does not help anyone. Furthermore I openend this thread some days before I committed anything and the response was very good. So I think I did the right thing here. Nethertheless I know that it's not done with the commit. This stuff has to be discussed further, but the commit was a way to let everyone be able to test it for themselves. And your compilation error and your related concerns really do have to be discussed. Really, thank's for pointing that out, because I did not run into this error. However I _really_ can't imagine a scenario where this would affect anything on MyFaces. I really don't. Regards, Jakob 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi 2010/3/11 Jakob Korherr jakob.korh...@gmail.com Hi, I totally agree with Jan-Kees. Just override the compiler plugin in implee6 to use jdk 6! Also I really don't see why you think it is such a big problem to have a class in the jar file which has other dependencies and another version when no other class has any relations to it. It's like a website with no link referring to it: you will never find it unless you know the real address of it! Furthermore if we put it into myfaces commons we can also drop it, because then it makes no sence. The user will rather continue to use the web.xml configuration than bundling some jar, which he maybe does not know that it even exists.. So the change has no sense outside myfaces impl jar. That means we only have two options: do it like this or remove the code. And last but not least: Mojarra also has a similar JDK6 compiled class with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a problem for MyFaces? The position from jsr-314-open mail list is as long as TCK test pass we could do it, and if mojarra has something similar, we could do the same. If something happens we could remove it and that's all (that means if something happens we'll be forced to remove this feature from myfaces and that is risky), since this is not part of the standard, but users should be aware of that implication. Note from this change, myfaces requires JDK 1.6 to be compiled, but the classes inside api and impl modules requires JDK 1.5. Please don't make this problem bigger as it is... I believe it is important to discuss the possible implications of a change before commit it and make it clear to people (that's one idea about opensource, give the people the power to know what's happening behind courtains and the tools to change it). Just put some code because you like it, or it is cool not always is enough. That's common sense, right?. Also you have to keep into account this is a standard of some spec, not just a custom library, so a lot of care is required before add a new feature outside the spec. So, the idea is not make a problem bigger or start a bizantine war that leads to nowhere, just benefit the community throught constructive discussion, but for a discussion it is necessary a clear and rational position, possible courses of action before start and a open mind, that means, give yourself the possibility of change of opinion anytime. Please note the benefit of this exercise, if someone wants to check why this stuff is done in this or that way, there is a source of knowledge through the mailing list. Please think carefully about what opensource word means. regards, Leonardo Uribe Regards, Jakob 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi I have sended an email to jsr-314-open mail list just to confirm if it is valid or not to do this kind of stuff. The problem is the class involved on implee6 has dependencies with classes that needs JDK 6 to be compiled, so in a JDK 1.5 environment it will crash if the classes are loaded. It is true ease of development will suffer, but I think prevent bugs like this takes precedence. regards, Leonardo Uribe 2010/3/11 Jan-Kees van Andel jankeesvanan...@gmail.com Why not override the compiler plugin in the module to use JDK 6? I think the whole point about the module is
Re: [core] Introducing implee6 - MYFACES-2579
Hi It seems the problem is that servlet 3.0 api requires jdk 1.6 to compile, and the classes we are using on implee6 has dependencies. That means, the classes on implee6 has version 49 but the ones in servlet 3.0 has version 50. The ones here: http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.PFD20090525/ compiles against JDK 1.5 but does not contains the required classes used on implee6. We have to let it as is. regards, Leonardo Uribe 2010/3/11 Jakob Korherr jakob.korh...@gmail.com Hi, Thanks Leonardo! I just tried this out locally and it worked fine. So I'll commit this for now! Regards, Jakob 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi Try this one: http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.20100224/ It does not seem to have jdk 1.6 dependencies regards, Leonardo Uribe 2010/3/11 Jakob Korherr jakob.korh...@gmail.com Maybe we can use a dependency to Servlet API 3.0 which is compiled against JDK 5 instead of the javaee-web-api. Is there anything like that? Regards, Jakob 2010/3/11 Jakob Korherr jakob.korh...@gmail.com Hi, So the change has no sense outside myfaces impl jar. That means we only have two options: do it like this or remove the code. -- yeap! Of course this has to be documented and the mailing list (archive) is the first place it already is, which, for sure, is great. In addition, I think we should create a wiki-entry for this. Also and of course I think it is very important to have those discussions, but they have to be constructive. Opening the same problems again and again does not help anyone. Furthermore I openend this thread some days before I committed anything and the response was very good. So I think I did the right thing here. Nethertheless I know that it's not done with the commit. This stuff has to be discussed further, but the commit was a way to let everyone be able to test it for themselves. And your compilation error and your related concerns really do have to be discussed. Really, thank's for pointing that out, because I did not run into this error. However I _really_ can't imagine a scenario where this would affect anything on MyFaces. I really don't. Regards, Jakob 2010/3/11 Leonardo Uribe lu4...@gmail.com Hi 2010/3/11 Jakob Korherr jakob.korh...@gmail.com Hi, I totally agree with Jan-Kees. Just override the compiler plugin in implee6 to use jdk 6! Also I really don't see why you think it is such a big problem to have a class in the jar file which has other dependencies and another version when no other class has any relations to it. It's like a website with no link referring to it: you will never find it unless you know the real address of it! Furthermore if we put it into myfaces commons we can also drop it, because then it makes no sence. The user will rather continue to use the web.xml configuration than bundling some jar, which he maybe does not know that it even exists.. So the change has no sense outside myfaces impl jar. That means we only have two options: do it like this or remove the code. And last but not least: Mojarra also has a similar JDK6 compiled class with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a problem for MyFaces? The position from jsr-314-open mail list is as long as TCK test pass we could do it, and if mojarra has something similar, we could do the same. If something happens we could remove it and that's all (that means if something happens we'll be forced to remove this feature from myfaces and that is risky), since this is not part of the standard, but users should be aware of that implication. Note from this change, myfaces requires JDK 1.6 to be compiled, but the classes inside api and impl modules requires JDK 1.5. Please don't make this problem bigger as it is... I believe it is important to discuss the possible implications of a change before commit it and make it clear to people (that's one idea about opensource, give the people the power to know what's happening behind courtains and the tools to change it). Just put some code because you like it, or it is cool not always is enough. That's common sense, right?. Also you have to keep into account this is a standard of some spec, not just a custom library, so a lot of care is required before add a new feature outside the spec. So, the idea is not make a problem bigger or start a bizantine war that leads to nowhere, just benefit the community throught constructive discussion, but for a discussion it is necessary a clear and rational position, possible courses of action before start and a open mind, that means, give yourself the possibility of change of opinion anytime. Please note the benefit of this exercise, if someone wants to check why this stuff is done in this or that way, there is a source of knowledge through the mailing list. Please think carefully about what opensource word
[jira] Created: (MYFACES-2600) @PostConstruct does not work
@PostConstruct does not work Key: MYFACES-2600 URL: https://issues.apache.org/jira/browse/MYFACES-2600 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr I just tried an example which used @PostConstruct, but the method was never called. Something seems to have been changed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2600) @PostConstruct does not work
[ https://issues.apache.org/jira/browse/MYFACES-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844268#action_12844268 ] Leonardo Uribe commented on MYFACES-2600: - Could you check if 2.0.0-beta-2 and 2.0.0-beta works? @PostConstruct does not work Key: MYFACES-2600 URL: https://issues.apache.org/jira/browse/MYFACES-2600 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr I just tried an example which used @PostConstruct, but the method was never called. Something seems to have been changed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2600) @PostConstruct does not work
[ https://issues.apache.org/jira/browse/MYFACES-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844279#action_12844279 ] Jakob Korherr commented on MYFACES-2600: Just tested: on 2.0.0-beta-2 it works fine! @PostConstruct does not work Key: MYFACES-2600 URL: https://issues.apache.org/jira/browse/MYFACES-2600 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr I just tried an example which used @PostConstruct, but the method was never called. Something seems to have been changed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2600) @PostConstruct does not work
[ https://issues.apache.org/jira/browse/MYFACES-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844284#action_12844284 ] Jakob Korherr commented on MYFACES-2600: Revision 918892 MYFACES-2559 - Google App Engine Support for Myfaces 2 causes this problem by the change in AbstractFacesInitializer. @PostConstruct does not work Key: MYFACES-2600 URL: https://issues.apache.org/jira/browse/MYFACES-2600 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr I just tried an example which used @PostConstruct, but the method was never called. Something seems to have been changed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Google SoC
On Thu, Mar 11, 2010 at 6:16 AM, Matthias Wessendorf mat...@apache.org wrote: Hey, nope, have not signed up to be the HTML5 RenderKit mentor. Any URL for that ? here it is: http://community.apache.org/guide-to-being-a-mentor.html -M On Thu, Mar 11, 2010 at 6:05 AM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Martin, If it's ok with everyone, I would also like to be a mentor! Regards, Jakob 2010/3/11, Martin Marinschek mmarinsc...@apache.org: Based on the outcome of this discussion, I will add a few issues to our issue tracker which amount to these proposals. Matthias, did you already sign up to be a mentor? Did anyone else do so already? Who wants to mentor? best regards, Martin On 3/11/10, Martin Marinschek mmarinsc...@apache.org wrote: - Extend Orchestra use Conversations based on the JSF 2.0 custom scope API, Extend Orchestra to work with Spring Conversations, to do File-New Window Handling I was thinking based on a suggestion done on JSFDays to take advantage on trinidad pageFlowScope code (like we did with flash scope on myfaces 2.0), and refactor that code to allow orchestra conversation scope work without spring (using the new JSF 2.0 custom scope). [Mario Ivankovits] Orchestra without Spring, that surely would be great. One thing to keep in mind is that we need AOP or at least proxying to inject the current conversation into the bean. Not too complicated, though. ok, sure - this could be part of the project. But what does this have to do with trinidad's pageFlowScope? If there is common utiltiy methods we can re-use (for example for file--new window detection in IE with JavaScript the generation of this JavaScript), we can and should certainly reuse it. If we leave the EntityManager thing out of line, we just need a JSF 2.0 scope impl and the proxying/interception stuff which is handled by Spring currently. perfect - let's do a proposal for this. best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2600) @PostConstruct does not work
[ https://issues.apache.org/jira/browse/MYFACES-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844286#action_12844286 ] Leonardo Uribe commented on MYFACES-2600: - MYFACES-2555 is suspicious, so there should be some code on MYFACES-2559 related. This issue is blocker for a release, and we should rollback or fix it soon. @PostConstruct does not work Key: MYFACES-2600 URL: https://issues.apache.org/jira/browse/MYFACES-2600 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr I just tried an example which used @PostConstruct, but the method was never called. Something seems to have been changed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2600) @PostConstruct does not work
[ https://issues.apache.org/jira/browse/MYFACES-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844288#action_12844288 ] Jakob Korherr commented on MYFACES-2600: I'll take care of it asap! @PostConstruct does not work Key: MYFACES-2600 URL: https://issues.apache.org/jira/browse/MYFACES-2600 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr I just tried an example which used @PostConstruct, but the method was never called. Something seems to have been changed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: core 2.0 build
Hi I have updated the snapshots. Usually I do it every time there is a change on shared, myfaces-tests or myfaces builder plugin to prevent this kind of problems. It could be good to have automatic snapshot deploys again, but I don't have access or know the procedure to put this on again. regards, Leonardo Uribe 2010/3/8 Ganesh gan...@j4fry.org yes, works! Thank you, guys. Matthias Wessendorf schrieb: yep, that's the way to go. Since continuum has some issues, it maybe the case that the shared snapshot aren't updated yet. However, checkout of the current20 is not a big deal. -Matthias On Mon, Mar 8, 2010 at 7:25 PM, Jakob Korherr jakob.korh...@gmail.com wrote: The best way is to check out core20. Then you will get the core (api + impl) and the shared project and you won't have problems like that anymore! Regards, Jakob 2010/3/8 Curtiss Howard curtiss.how...@gmail.com Maven does take care of the dependencies, but I believe it takes a little time before the changes to the shared project are pushed to the global Maven repository, so in these cases, unless you can wait you need to build shared and deploy it to your local repository. Curtiss Howard On Mon, Mar 8, 2010 at 11:53 AM, Ganesh gan...@j4fry.org wrote: No, I actually didn't. Shouldn't maven take care of dependencies? Until now it always did! Do I need to set up a seperate shared project now? Best regards, Ganesh Jakob Korherr schrieb: Hi Ganesh, Did you build shared core and shared impl too? Regards, Jakob 2010/3/8 Ganesh gan...@j4fry.org mailto:gan...@j4fry.org Hi, Today I did my usual svn update and mvn and I get: [INFO] Compiling 36 source files to C:\projects\MyFaces_Trunk\impl\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\projects\MyFaces_Trunk\impl\src\main\java\org\apache\myfaces\util\ContainerUtils.java:[25,42] cannot find symbol symbol : class ExternalContextUtils location: package org.apache.myfaces.shared_impl.util C:\projects\MyFaces_Trunk\impl\src\main\java\org\apache\myfaces\util\ContainerUtils.java:[128,52] cannot find symbol symbol : method getServerInfo(javax.faces.context.ExternalContext) location: class org.apache.myfaces.util.ExternalContextUtils [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 minutes 38 seconds [INFO] Finished at: Mon Mar 08 17:14:17 CET 2010 [INFO] Final Memory: 91M/420M [INFO] What's wrong? Best regards, Ganesh
[jira] Commented: (MYFACES-2509) @ListenerFor not processed for global system events
[ https://issues.apache.org/jira/browse/MYFACES-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844406#action_12844406 ] Jan-Kees van Andel commented on MYFACES-2509: - I think you're right. I initially only considered it to be used for startup listeners, and I don't think those classes should contain state, but on the other hand, we shouldn't have such a silend, undocumented requirement. This will indeed cause weird bugs. @ListenerFor not processed for global system events --- Key: MYFACES-2509 URL: https://issues.apache.org/jira/browse/MYFACES-2509 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jan-Kees van Andel Assignee: Jan-Kees van Andel Attachments: ListenerFor_support.patch We currently don't process @ListenerFor and @ListenerFor annotations on non-component types. This is specified in the spec for global system events, see: http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html?javax/faces/event/ListenerFor.html It would be nice to have it in the beta. -- 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-2509) @ListenerFor not processed for global system events
[ https://issues.apache.org/jira/browse/MYFACES-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844406#action_12844406 ] Jan-Kees van Andel edited comment on MYFACES-2509 at 3/12/10 7:57 AM: -- I think you're right. I initially only considered it to be used for startup listeners, and I don't think those classes should contain state, but on the other hand, we shouldn't have such a silent, undocumented requirement. This will indeed cause weird bugs. was (Author: jankeesvanandel): I think you're right. I initially only considered it to be used for startup listeners, and I don't think those classes should contain state, but on the other hand, we shouldn't have such a silend, undocumented requirement. This will indeed cause weird bugs. @ListenerFor not processed for global system events --- Key: MYFACES-2509 URL: https://issues.apache.org/jira/browse/MYFACES-2509 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jan-Kees van Andel Assignee: Jan-Kees van Andel Attachments: ListenerFor_support.patch We currently don't process @ListenerFor and @ListenerFor annotations on non-component types. This is specified in the spec for global system events, see: http://java.sun.com/javaee/javaserverfaces/2.0/docs/api/index.html?javax/faces/event/ListenerFor.html It would be nice to have it in the beta. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
