[jira] Created: (ORCHESTRA-39) Conversations are not cleaned up if session timeout is near conversation timeout
Conversations are not cleaned up if session timeout is near conversation timeout Key: ORCHESTRA-39 URL: https://issues.apache.org/jira/browse/ORCHESTRA-39 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching The ConversationManager can be removed by the ConversationManagerSessionListener before the ConversationWiperThread has timed out the Conversations. This can cause open PersistenceContext if the session timed out or is invalidated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ORCHESTRA-39) Conversations are not cleaned up if session timeout is near conversation timeout
[ https://issues.apache.org/jira/browse/ORCHESTRA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann updated ORCHESTRA-39: --- Status: Patch Available (was: Open) Conversations are not cleaned up if session timeout is near conversation timeout Key: ORCHESTRA-39 URL: https://issues.apache.org/jira/browse/ORCHESTRA-39 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching The ConversationManager can be removed by the ConversationManagerSessionListener before the ConversationWiperThread has timed out the Conversations. This can cause open PersistenceContext if the session timed out or is invalidated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1170) Partial Page Rendering does not work on Weblogic 10
[ https://issues.apache.org/jira/browse/TRINIDAD-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689089#action_12689089 ] Vadim Dmitriev commented on TRINIDAD-1170: -- I deployed trinidad demo.war on our WLS and ppr worked there just fine. It seems that this misbehavior relates to some other lib we are using. Sorry for any inconvenience. Partial Page Rendering does not work on Weblogic 10 --- Key: TRINIDAD-1170 URL: https://issues.apache.org/jira/browse/TRINIDAD-1170 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.8-core, 1.2.8-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core Run Trinidad PPR on a Weblogic 10 server and see that an invalid XML response is generated. = text/html is returned instead of text/xml See also this discussion on the myfaces list: http://www.mail-archive.com/us...@myfaces.apache.org/msg49162.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[OT] The ASF is ten years old today!
FYI http://tinyurl.com/asf10years -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TRINIDAD-1436) component inputDate allways bloqued by security constraint on my app
component inputDate allways bloqued by security constraint on my app Key: TRINIDAD-1436 URL: https://issues.apache.org/jira/browse/TRINIDAD-1436 Project: MyFaces Trinidad Issue Type: Improvement Environment: trinidad 1.2.5, jsf 1.2.1 Reporter: Thomas Modeneis Priority: Blocker On my app i got some areas that users can view without login, and some aread user have to be logged. but inputDate component open this url: f/__ADFv__?_t=fred_red=cdvalue=1237992755752loc=enenc=utf-8 and i can´t make this url away from security constraint, i try many things like: security-constraint display-namefree/display-name descriptionPublic/description web-resource-collection url-pattern/f/__ADFv__?_t/url-pattern /web-resource-collection /security-constraint but this dont work i want use tinidad component, but if i cant solve thisi will not have another try, so i will implement rich:calendar. Thank you, Thomas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Fwd: [jira] Created: (TRINIDAD-1436) component inputDate allways bloqued by security constraint on my app
Anyone have fix to solve this problem ? Thks. -- Forwarded message -- From: Thomas Modeneis (JIRA) dev@myfaces.apache.org Date: Wed, Mar 25, 2009 at 11:04 AM Subject: [jira] Created: (TRINIDAD-1436) component inputDate allways bloqued by security constraint on my app To: thomas.moden...@soujava.org.br component inputDate allways bloqued by security constraint on my app Key: TRINIDAD-1436 URL: https://issues.apache.org/jira/browse/TRINIDAD-1436 Project: MyFaces Trinidad Issue Type: Improvement Environment: trinidad 1.2.5, jsf 1.2.1 Reporter: Thomas Modeneis Priority: Blocker On my app i got some areas that users can view without login, and some aread user have to be logged. but inputDate component open this url: f/__ADFv__?_t=fred_red=cdvalue=1237992755752loc=enenc=utf-8 and i can´t make this url away from security constraint, i try many things like: security-constraint display-namefree/display-name descriptionPublic/description web-resource-collection url-pattern/f/__ADFv__?_t/url-pattern /web-resource-collection /security-constraint but this dont work i want use tinidad component, but if i cant solve thisi will not have another try, so i will implement rich:calendar. Thank you, Thomas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Sun Certified Programmer for Java Platform, SE 5.0 – 310-055. thomas.moden...@soujava.org.br
Re: [jira] Created: (TRINIDAD-1436) component inputDate allways bloqued by security constraint on my app
Why did you put part of the query string - ?_t - in the pattern? On Wed, Mar 25, 2009 at 8:25 AM, Thomas Modeneis thomas.moden...@soujava.org.br wrote: Anyone have fix to solve this problem ? Thks. -- Forwarded message -- From: Thomas Modeneis (JIRA) dev@myfaces.apache.org Date: Wed, Mar 25, 2009 at 11:04 AM Subject: [jira] Created: (TRINIDAD-1436) component inputDate allways bloqued by security constraint on my app To: thomas.moden...@soujava.org.br component inputDate allways bloqued by security constraint on my app Key: TRINIDAD-1436 URL: https://issues.apache.org/jira/browse/TRINIDAD-1436 Project: MyFaces Trinidad Issue Type: Improvement Environment: trinidad 1.2.5, jsf 1.2.1 Reporter: Thomas Modeneis Priority: Blocker On my app i got some areas that users can view without login, and some aread user have to be logged. but inputDate component open this url: f/__ADFv__?_t=fred_red=cdvalue=1237992755752loc=enenc=utf-8 and i can´t make this url away from security constraint, i try many things like: security-constraint display-namefree/display-name descriptionPublic/description web-resource-collection url-pattern/f/__ADFv__?_t/url-pattern /web-resource-collection /security-constraint but this dont work i want use tinidad component, but if i cant solve thisi will not have another try, so i will implement rich:calendar. Thank you, Thomas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Sun Certified Programmer for Java Platform, SE 5.0 – 310-055. thomas.moden...@soujava.org.br
[jira] Created: (TRINIDAD-1437) Vertical breadcrumbs illegally mix in-line and block DOM elements
Vertical breadcrumbs illegally mix in-line and block DOM elements - Key: TRINIDAD-1437 URL: https://issues.apache.org/jira/browse/TRINIDAD-1437 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.11-core Reporter: Andrew Robinson Assignee: Andrew Robinson 1) Run the breadcrumbs demo page. 2) Change the orientation to vertical and set inline style to : background-color:red 3) Click on update. Note that in FF and safari browser the style change does not take effect. The problem is the resulting DOM: span style=background-color: red; class=x4vdiv... As you can see, a DIV (block) got rendered in a SPAN (in-line). This is an illegal DOM hierarchy as the spec. clearly states that in-line elements must only ever include other in-line elements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-39) Conversations are not cleaned up if session timeout is near conversation timeout
[ https://issues.apache.org/jira/browse/ORCHESTRA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689192#action_12689192 ] Simon Kitching commented on ORCHESTRA-39: - This looks pretty good to me. One minor note: I think new method ConversationWiperThread.removeAndInvalidateConversationManager is better as a private method on the ConversationManagerSessionListener class. There is also a spelling mistake in this method name: removeAndInvalidateConversationContextAndChilden Childen -- Children Possibly new methods protected ConversationManager.removeAndInvalidateAllConversationContexts private ConversationManager.removeAndInvalidateConversationContextAndChildren could be public. There are already public methods that act on the flat contexts, and we expose the concept of child contexts through public APIs. So I don't see any reason not to make these new methods generally available. I suggest making them public now, and if anyone (eg mario) objects, we can reduce the visibility before the next release. If you're ok with making these minor changes, then please go ahead and commit your patch...and thanks for the fix! Conversations are not cleaned up if session timeout is near conversation timeout Key: ORCHESTRA-39 URL: https://issues.apache.org/jira/browse/ORCHESTRA-39 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-39.patch The ConversationManager can be removed by the ConversationManagerSessionListener before the ConversationWiperThread has timed out the Conversations. This can cause open PersistenceContext if the session timed out or is invalidated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1902) Allow to use different ExpressionFactory implementation
[ https://issues.apache.org/jira/browse/MYFACES-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689197#action_12689197 ] Christian Kaltepoth commented on MYFACES-1902: -- Since I am very interested in this feature I have developed a fix for the issue. Find attached the patch against core12 trunk. The changes can be summarized as follows. The existing code for loading the custom ExpressionFactory has been moved from Jsp20FacesInitializer to AbstractFacesInitializer. Both AbstractFacesInitializer implementations now check for a custom ExpressionFactory by calling getUserDefinedExpressionFactory() before they proceed with their default behavior for finding the ExpressionFactory. I attached a small webapp for a proof of concept. The webapp can be started either in a JSP 2.1 or JSP 2.0 container by using different maven profiles. The demo shows basic features of JBossEL. See the webapp's source for details. Tomcat 6.0 (JSP 2.1) environment: # mvn -Ptomcat60 clean package cargo:start Tomcat 5.5 (JSP 2.0) environment: # mvn -Ptomcat55 clean package cargo:start The demo webapp can be accessed with this url: http://localhost:8080/eldemo/ Allow to use different ExpressionFactory implementation --- Key: MYFACES-1902 URL: https://issues.apache.org/jira/browse/MYFACES-1902 Project: MyFaces Core Issue Type: New Feature Components: Extension Feature Affects Versions: 1.2.4-SNAPSHOT Reporter: Christian Kaltepoth Assignee: Matthias Weßendorf Attachments: MYFACES-1902-webapp.zip, MYFACES-1902.patch It should be possible to use a different ExpressionFactory implementation. This feature is required to use 3rd party EL implementations like JBoss EL. Mojarra already supports this with the 'com.sun.faces.expressionFactory' context parameter. MyFaces Core 1.2.x already supports a context parameter 'org.apache.myfaces.EXPRESSION_FACTORY' but it is only evaluated in a JSP 2.0 environment (see MYFACES-1693 for details). It should be possible to use this parameter with JSP 2.1 as well. The corresponding code should be refactored from Jsp20FacesInitializer to AbstractFacesInitializer to be usable in both JSP 2.0 and 2.1. Discussion on myfaces-users: http://www.nabble.com/Replacing-expression-factory-td18867420.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1902) Allow to use different ExpressionFactory implementation
[ https://issues.apache.org/jira/browse/MYFACES-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Kaltepoth updated MYFACES-1902: - Status: Patch Available (was: Open) Allow to use different ExpressionFactory implementation --- Key: MYFACES-1902 URL: https://issues.apache.org/jira/browse/MYFACES-1902 Project: MyFaces Core Issue Type: New Feature Components: Extension Feature Affects Versions: 1.2.4-SNAPSHOT Reporter: Christian Kaltepoth Assignee: Matthias Weßendorf Attachments: MYFACES-1902-webapp.zip, MYFACES-1902.patch It should be possible to use a different ExpressionFactory implementation. This feature is required to use 3rd party EL implementations like JBoss EL. Mojarra already supports this with the 'com.sun.faces.expressionFactory' context parameter. MyFaces Core 1.2.x already supports a context parameter 'org.apache.myfaces.EXPRESSION_FACTORY' but it is only evaluated in a JSP 2.0 environment (see MYFACES-1693 for details). It should be possible to use this parameter with JSP 2.1 as well. The corresponding code should be refactored from Jsp20FacesInitializer to AbstractFacesInitializer to be usable in both JSP 2.0 and 2.1. Discussion on myfaces-users: http://www.nabble.com/Replacing-expression-factory-td18867420.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-39) Conversations are not cleaned up if session timeout is near conversation timeout
[ https://issues.apache.org/jira/browse/ORCHESTRA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689200#action_12689200 ] Bernd Bohmann commented on ORCHESTRA-39: I'm fine with the changes. I will commit the changes tomorrow. Conversations are not cleaned up if session timeout is near conversation timeout Key: ORCHESTRA-39 URL: https://issues.apache.org/jira/browse/ORCHESTRA-39 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Attachments: ORCHESTRA-39.patch The ConversationManager can be removed by the ConversationManagerSessionListener before the ConversationWiperThread has timed out the Conversations. This can cause open PersistenceContext if the session timed out or is invalidated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1438) M2 Plugins: Need a way to define a new converter or validator tag with the existing Id
M2 Plugins: Need a way to define a new converter or validator tag with the existing Id -- Key: TRINIDAD-1438 URL: https://issues.apache.org/jira/browse/TRINIDAD-1438 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 1.2.10-plugins Reporter: Max Starets If a converter or a validator references the Id already associated with the existing tag, then the base Faces plugin finds ValidatorBean or ConverterBean for the existing tag instead of creating a new bean instance. This means that we cannot create validator/converter tags in ADF Faces that reference converter/validator IDs defined in Trinidad. The proposed fix is to add new extension properties in metadata: mfp:root-converter-id and mfp:root-validator-id. If these are defined, Facelet tag generation will write out the 'root' (real) Id instead of the ID specified as validator-id or converter-id. This will allow us to use new (fake) IDs as validator-id/converter-id to distinguish the new tags, while still writing out the correct Id in the .taglib.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1438) M2 Plugins: Need a way to define a new converter or validator tag with the existing Id
[ https://issues.apache.org/jira/browse/TRINIDAD-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1438: -- Status: Patch Available (was: Open) M2 Plugins: Need a way to define a new converter or validator tag with the existing Id -- Key: TRINIDAD-1438 URL: https://issues.apache.org/jira/browse/TRINIDAD-1438 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 1.2.10-plugins Reporter: Max Starets Attachments: trinidad-1438.patch If a converter or a validator references the Id already associated with the existing tag, then the base Faces plugin finds ValidatorBean or ConverterBean for the existing tag instead of creating a new bean instance. This means that we cannot create validator/converter tags in ADF Faces that reference converter/validator IDs defined in Trinidad. The proposed fix is to add new extension properties in metadata: mfp:root-converter-id and mfp:root-validator-id. If these are defined, Facelet tag generation will write out the 'root' (real) Id instead of the ID specified as validator-id or converter-id. This will allow us to use new (fake) IDs as validator-id/converter-id to distinguish the new tags, while still writing out the correct Id in the .taglib.xml. -- 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: (TRINIDAD-1170) Partial Page Rendering does not work on Weblogic 10
[ https://issues.apache.org/jira/browse/TRINIDAD-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689089#action_12689089 ] Vadim Dmitriev edited comment on TRINIDAD-1170 at 3/25/09 12:10 PM: I deployed trinidad demo.war on our WLS and ppr worked there just fine. It seems that this misbehavior relates to some other lib we are using. Sorry for any inconvenience. [edit] Just found out why PPR wasn't working: I used JSP-style taglib declarations (i.e. %@ taglib ... %) instead of XML-style (jsp:root ... xmlns:tr=http://myfaces.apache.org/trinidad; ). When jsp:root is used PPR works just fine. It still looks like a WLS bug to me, but at least it has a workaround. was (Author: allati): I deployed trinidad demo.war on our WLS and ppr worked there just fine. It seems that this misbehavior relates to some other lib we are using. Sorry for any inconvenience. Partial Page Rendering does not work on Weblogic 10 --- Key: TRINIDAD-1170 URL: https://issues.apache.org/jira/browse/TRINIDAD-1170 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.8-core, 1.2.8-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core Run Trinidad PPR on a Weblogic 10 server and see that an invalid XML response is generated. = text/html is returned instead of text/xml See also this discussion on the myfaces list: http://www.mail-archive.com/us...@myfaces.apache.org/msg49162.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1437) Vertical breadcrumbs illegally mix in-line and block DOM elements
[ https://issues.apache.org/jira/browse/TRINIDAD-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-1437. --- Resolution: Fixed Fix Version/s: 1.2.12-core Added CSS to the base desktop skin to change the display of the breadcrumb DOM elements so that the display attributes work as desired for gecko and webkit browsers. I used this approach to avoid DOM changes that are more likely to adversely affect existing users. Vertical breadcrumbs illegally mix in-line and block DOM elements - Key: TRINIDAD-1437 URL: https://issues.apache.org/jira/browse/TRINIDAD-1437 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.11-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 1.2.12-core 1) Run the breadcrumbs demo page. 2) Change the orientation to vertical and set inline style to : background-color:red 3) Click on update. Note that in FF and safari browser the style change does not take effect. The problem is the resulting DOM: span style=background-color: red; class=x4vdiv... As you can see, a DIV (block) got rendered in a SPAN (in-line). This is an illegal DOM hierarchy as the spec. clearly states that in-line elements must only ever include other in-line elements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1438) M2 Plugins: Need a way to define a new converter or validator tag with the existing Id
[ https://issues.apache.org/jira/browse/TRINIDAD-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1438: - Resolution: Fixed Fix Version/s: 1.2.10-plugins Assignee: Matthias Weßendorf Status: Resolved (was: Patch Available) M2 Plugins: Need a way to define a new converter or validator tag with the existing Id -- Key: TRINIDAD-1438 URL: https://issues.apache.org/jira/browse/TRINIDAD-1438 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 1.2.10-plugins Reporter: Max Starets Assignee: Matthias Weßendorf Fix For: 1.2.10-plugins Attachments: trinidad-1438.patch If a converter or a validator references the Id already associated with the existing tag, then the base Faces plugin finds ValidatorBean or ConverterBean for the existing tag instead of creating a new bean instance. This means that we cannot create validator/converter tags in ADF Faces that reference converter/validator IDs defined in Trinidad. The proposed fix is to add new extension properties in metadata: mfp:root-converter-id and mfp:root-validator-id. If these are defined, Facelet tag generation will write out the 'root' (real) Id instead of the ID specified as validator-id or converter-id. This will allow us to use new (fake) IDs as validator-id/converter-id to distinguish the new tags, while still writing out the correct Id in the .taglib.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] New API: RequestContext isInternalViewRequest
I plan to commit this tomorrow (3-26-09), so if people could let me know
of any objections ASAP.
Thanks,
Gabrielle
Jeanne Waldman wrote:
+1
Maria Kaval wrote, On 3/24/2009 11:42 AM PT:
We would like to add a new API for Trinidad, as discussed in
https://issues.apache.org/jira/browse/TRINIDAD-1432
Internal views are viewIds that may be requested by a client and are
handled internal to the web application, without necessarily
dispatching to a resource like a JSP. An internal view handler is
implemented by extending the
org.apache.myfaces.trinidad.render.InternalView abstract class.
Certain controllers keep track of the viewId of the currently
displayed view in a window. When a request is received on the server
the controller checks to see if the requested viewId is different
from the last known viewId for that window. If the viewIds are
different then the controller recognizes this situation as a
navigation and releases any state it had for the previous view.
The problem is internal views doesn't always result in display of a
new view in window, i.e. in navigation. Instead, they may just
request some logic be executed or that a new window be opened.
In order to prevent incorrectly triggering the controller's
navigation detection, the controller needs to be able to determine if
the current View Root is an internal view or not. The proposed API is
thus:
RequestContext
{
/**
* Determines whether the current View Root is an internal view
* @param context Faces context
* @return true if the current View Root is an internal view, false
otherwise
*/
public abstract boolean isInternalViewRequest(FacesContext context);
}
Are there objections or other suggestions on how to achieve this, or
is the new API acceptable?
Thanks, Maria
*Maria Kaval*
Software Development Director
ADF View Run Time
Oracle Corporation
tel: (650) 506 2045 cell: (650) 430 1888
mailto:maria.ka...@oracle.com | web:_ _www.oracle.com
http://www.oracle.com/
[jira] Created: (MYFACES-2168) Add documentation for myfaces-builder-plugin
Add documentation for myfaces-builder-plugin Key: MYFACES-2168 URL: https://issues.apache.org/jira/browse/MYFACES-2168 Project: MyFaces Core Issue Type: Task Components: build process Reporter: Leonardo Uribe Assignee: Leonardo Uribe Add documentation for myfaces-builder-plugin, to make easier users to use it -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2169) force parameter does not work on make-components, make-tags, make-converter-tags and make-validator-tags goals of myfaces-builder-plugin
force parameter does not work on make-components, make-tags, make-converter-tags and make-validator-tags goals of myfaces-builder-plugin Key: MYFACES-2169 URL: https://issues.apache.org/jira/browse/MYFACES-2169 Project: MyFaces Core Issue Type: Bug Reporter: Leonardo Uribe force parameter does not work on make-components, make-tags, make-converter-tags and make-validator-tags goals of myfaces-builder-plugin If force == true and some file fails to generate, log and continue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2170) Missing attribute for @JSFValidator and @JSFConverter on myfaces-builder-annotations
Missing attribute for @JSFValidator and @JSFConverter on myfaces-builder-annotations Key: MYFACES-2170 URL: https://issues.apache.org/jira/browse/MYFACES-2170 Project: MyFaces Core Issue Type: Bug Reporter: Leonardo Uribe Assignee: Leonardo Uribe The attribute serialuidtag is available on myfaces- builder-plugin doclets but not on annotations for @JSFValidator and @JSFConverter. The ideal is that the plugin generates it but right now the plugin does not have way to decide when generate one file or not, so it just generate all files each time it runs. Also the attribute clazz is not available on @JSFValidator, so we need to define in to make the goal make-validators work using annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
