[jira] [Created] (TOMAHAWK-1606) Tomahawk 1.1.11 - HtmlDataScroller possible tablib.xml problem in NetBeans
Tomahawk 1.1.11 - HtmlDataScroller possible tablib.xml problem in NetBeans -- Key: TOMAHAWK-1606 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1606 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Affects Versions: 1.1.11 Environment: win xp, netbeans 7.0.1, maven 3.0.3, myfaces 2.1.3 Reporter: Bruno Marti I've got a strange behavior of tomahawk 1.1.11 and the HtmlDataScroller class (see added NetBeans sample project). There is a session bean with a HtmlDataScroller property (with getter and setter). Everything compiles fine under maven and also through NetBeans, but NetBeans shows a compile error hint all the time (see attachement). If I use tomahawk 1.1.10 everything is fine and no compile hint is shown. I think its not a problem of NetBeans. Could there something be wrong in the taglib.xml of 1.1.11? -- 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-3259) Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode
[ https://issues.apache.org/jira/browse/MYFACES-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3259. - Resolution: Fixed Fix Version/s: 2.1.4 2.0.10 Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode -- Key: MYFACES-3259 URL: https://issues.apache.org/jira/browse/MYFACES-3259 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson Assignee: Leonardo Uribe Fix For: 2.0.10, 2.1.4 Attachments: MYFACES-3259-1.patch, MYFACES-3259.tar.gz, MYFACES-3259.tar.gz demo forthcoming; it would seem the FaceletCompositionContext would need to keep track of the delegate as well as the id of enclosing validators in order to be able to apply the xml attributes. -- 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] (EXTCDI-235) add javadoc to DefaultWindowContextManager#closeAllWindowContexts
add javadoc to DefaultWindowContextManager#closeAllWindowContexts - Key: EXTCDI-235 URL: https://issues.apache.org/jira/browse/EXTCDI-235 Project: MyFaces CODI Issue Type: Task Components: JEE-JSF12-Module, JEE-JSF20-Module Affects Versions: 1.0.2 Reporter: Gerhard Petracek Priority: Trivial esp. the difference to WindowContext#close (see e.g. attributes.clear()) -- 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] (EXTCDI-73) optional beans with optional dependencies
[ https://issues.apache.org/jira/browse/EXTCDI-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-73. Resolution: Won't Fix can't be implemented in a portable way - needs to be specified by the cdi specification optional beans with optional dependencies - Key: EXTCDI-73 URL: https://issues.apache.org/jira/browse/EXTCDI-73 Project: MyFaces CODI Issue Type: Task Reporter: Gerhard Petracek Attachments: EXTCDI-73.patch we have to check if it is needed to provide an annotation like @RequiredDependency for beans which are only used if the specified class/es exist/s. currently e.g. owb blocks such a feature (see OWB-475) - as soon as OWB-475 is fixed, owb skips such beans automatically. so we have to check if we need the annotation e.g. for weld. -- 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] (EXTCDI-225) upgrade to myfaces-parent-10
[ https://issues.apache.org/jira/browse/EXTCDI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140417#comment-13140417 ] Mark Struberg commented on EXTCDI-225: -- myfaces-parent-10 is broken, will need to wait for mf-parent-11 upgrade to myfaces-parent-10 Key: EXTCDI-225 URL: https://issues.apache.org/jira/browse/EXTCDI-225 Project: MyFaces CODI Issue Type: Improvement Components: Core Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg upgrade to myfaces-parent-10 -- 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] (EXTCDI-123) EditableAnnotatedType
[ https://issues.apache.org/jira/browse/EXTCDI-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-123. - Resolution: Won't Fix we don't have that many cases where we need it. EditableAnnotatedType - Key: EXTCDI-123 URL: https://issues.apache.org/jira/browse/EXTCDI-123 Project: MyFaces CODI Issue Type: New Feature Components: Core Reporter: Gerhard Petracek Priority: Minor it should be possible to use a generic implementation for manipulating an AnnotatedType during the bootstrapping process of cdi. e.g. processAnnotatedType.setAnnotatedType( new EditableAnnotatedType(processAnnotatedType.getAnnotatedType()).addAnnotation(customAnnotationLiteral)) -- 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] (EXTCDI-179) GAE support
[ https://issues.apache.org/jira/browse/EXTCDI-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-179. - Resolution: Won't Fix we didn't see users asking for it GAE support --- Key: EXTCDI-179 URL: https://issues.apache.org/jira/browse/EXTCDI-179 Project: MyFaces CODI Issue Type: Improvement Affects Versions: 1.0.0 Reporter: Gerhard Petracek Assignee: Jakob Korherr if some classes aren't allowed by GAE we have to catch NoClassDefFoundError and log the unsupported feature. we might have to do the same for owb. -- 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] (EXTCDI-194) evaluate @ComponentBindingAware
[ https://issues.apache.org/jira/browse/EXTCDI-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-194. - Resolution: Won't Fix we would need a detailed documentation about it. instead we can write a detailed one about the workaround itself. that won't introduce an overhead (compared to the interceptor). evaluate @ComponentBindingAware --- Key: EXTCDI-194 URL: https://issues.apache.org/jira/browse/EXTCDI-194 Project: MyFaces CODI Issue Type: Task Components: JEE-JSF12-Module, JEE-JSF20-Module Affects Versions: 1.0.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek we should think about including: https://bitbucket.org/os890/myfaces-extcdi-incubator/changeset/c34af18ff396 -- 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-3350) Error data payload attribute names
[ https://issues.apache.org/jira/browse/MYFACES-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140586#comment-13140586 ] Leonardo Uribe commented on MYFACES-3350: - Change converted to unified diff patch format against 2.1.x (trunk) Error data payload attribute names -- Key: MYFACES-3350 URL: https://issues.apache.org/jira/browse/MYFACES-3350 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.9, 2.1.3 Reporter: Keith Wong Priority: Minor Attachments: Impl.js, MYFACES-3350-1.patch, jsf.js According to JSF 2.0 and 2.1 spec section 14.4.2 table 14-6, the attributes of error data payload are: type status description source responseCode responseXML responseText errorName errorMessage However, the attributes errorName and errorMessage are named as serverErrorName and serverErrorMessage respectively. I have identified the changes and attached as follows. -- 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] (MYFACES-3350) Error data payload attribute names
[ https://issues.apache.org/jira/browse/MYFACES-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3350: Status: Patch Available (was: Open) Error data payload attribute names -- Key: MYFACES-3350 URL: https://issues.apache.org/jira/browse/MYFACES-3350 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.9, 2.1.3 Reporter: Keith Wong Priority: Minor Attachments: Impl.js, MYFACES-3350-1.patch, jsf.js According to JSF 2.0 and 2.1 spec section 14.4.2 table 14-6, the attributes of error data payload are: type status description source responseCode responseXML responseText errorName errorMessage However, the attributes errorName and errorMessage are named as serverErrorName and serverErrorMessage respectively. I have identified the changes and attached as follows. -- 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,
So do you think myfaces/incubator/html5 is a good place?
Greetings,
Ali
On Sat, Oct 22, 2011 at 1:37 PM, Ali Ok al...@aliok.com.tr wrote:
Hi,
In my opinion as long this lib is html5 only it should not be part of
the tomahawk project
I agree, no relation with Tomahawk.
a different idea would be a small myfaces-incubator for new project-ideas
(esp. for gsoc projects).
Makes more sense to me than Tomahawk.
I think (almost) everyone is in favor of moving the project to somewhere
else, I am also ok with it.
Important thing for the project is having the ability for releases and the
jars are deployed to maven repo.
Cheers,
Ali
On Sat, Oct 22, 2011 at 11:05 AM, Mark Struberg strub...@yahoo.de wrote:
including our very own little 'attic' :)
Actually the big difference between the incubator and a mf subproject
would be the IP clearance. We really need to do this upfront before
importing.
But actually I like this much more than having projects developed outside
and only later brought into our SVN - because this causes lots of paperwork
(gas grants and a IP clearance review is mandatory).
Thus a +1
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Saturday, October 22, 2011 10:58 AM
Subject: Re: [html5] alpha release for myfaces html5
a different idea would be a small myfaces-incubator for new
project-ideas (esp. for gsoc projects).
we can release parts easily and drop them if we see that something
doesn't work for our community. if an idea works for the community, we can
discuss the correct place for it.
we might see new gsoc projects (related to myfaces) every year. imo it's
the wrong approach to just add them as new sub-project and we don't have
the resources/community to maintain them.
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 Bernd Bohmann bernd.bohm...@atanion.com
Ha, I don't think we should wait for the jsf-eg.
Hey guys they are asking for a alpha release.
In my opinion as long this lib is html5 only it should not be part of
the tomahawk project.
I don't see any problems in releasing an alpha release. But before a
beta we should decide own extension or tomahawk.
Regards
Bernd
On Sat, Oct 22, 2011 at 9:31 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
it's planned that jsf2.2 will get some sort of html5 support.
imo we should work together with the jsf-eg to ensure that we won't
promote
incompatible components.
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 Mark Struberg strub...@yahoo.de
+1 for moving it to tomahawk.
One big open question for me is our html5 strategy at all.
Will the html5 components provide legacy html support themselfs?
Thus a calendar component will use jQuery (or whatever) calendar
when a
non-html5 browser is detected,
or is this in the responsibility of the developer?
if (html5){
} else{
//fallback
}
?
Afaik our current html5 components 'only' support pure html5
rendering,
isn't?
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Friday, October 21, 2011 10:22 PM
Subject: 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
[VOTE] Internal Incubator
Hi, in order to check if there is a community for a new sub-project (esp. GSoC projects for MyFaces), we discussed [1] the introduction of an internal incubator. We would release such projects early and e.g. after a quarter we decide if we keep and promote a project (as a sub-project or a module of an existing sub-project) or if we drop it. Please vote: [+1] I like the idea [0] I'm not convinced but I'm ok with it [-1] I don't agree Regards, Gerhard [1] http://markmail.org/message/d7oogfabvliwn7fg
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13140871#comment-13140871 ] Keith Wong commented on MYFACES-3361: - It seems Messages_zh_HK.js is missing in the change set #1190363 and #1190364. 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
