Re: MyfacesBuilderPlugin
Hi
I have a design question. I'm working on generate component tag classes
using velocity.
In this part it is common to found some situations when you need utility
methods. There are several methods
to do this:
1) Implementing this methods on a java class, and use the following code
using a macro file on inside the template:
## [ Setting Utility Classes to use ]
##
#set($utils =
$classes.forName("org.apache.commons.lang.StringUtils").newInstance())
In this case, we can copy
org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util form
myfaces-faces-plugin and use it
inside the templates. like this
$utils.lowerCase($field.getAttributeValue("name"))
2) Use a file to create velocity macros and implement this here. Inside we
need to use StringUtils like in (1), but from the point of view of the
template designer, He/she doesn't see this.
3) Create methods on each Model and XXXMeta. Sometimes this is unavoidable
(like getting the properties from a component) and is more clean. For
example:
package ${component.tagPackage};
public class ${component.tagName}{
#foreach( $property in ${component.propertyList} )
//getter and setter methods
#end
}
This two methods (getTagPackage and getTagName and derived properties of
tagClass).
What option could be better? If no suggestions, I will go for option 1 and
3.
regards
Leonardo Uribe
On Wed, Apr 2, 2008 at 3:07 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Apr 2, 2008 at 2:49 AM, [EMAIL PROTECTED] <
> [EMAIL PROTECTED]> wrote:
>
> >
> > I'm not quite clear what your description above means. I think we are
> > talking about the same thing, but just to be clear this is how I would
> > see it working:
> >
> > == for goal build-metadata:
> >
> > start with an empty model
> > for each jarfile containing a META-INF/myfaces-metadata.xml file
> > read that myfaces-metadata.xml file
> > add the resulting objects into the model[1]
> > run the ModelBuilder for the current project, which adds more objects to
> > the model
> > save the model into META-INF/myfaces-metadata.xml in the current project
> >
> > An alternative would be to do the merging just at the xml level, then
> > build a model from the resulting merged xml file. That also seems
> > reasonable.
> >
> > == for other goals (eg generate faces.xml, generate tag classes):
> > start with an empty model
> > read META-INF/myfaces-metadata.xml for the current project only
> > add the resulting objects to the model
> > pass the model object to the appropriate generator class[3]
> >
> > [1] Hmm..might need to somehow detect and handle duplicate data.
> >
>
> Yes, duplicated data is the problem.
>
>
> >
> > In particular, tomahawk will depend on both myfaces-api and
> > myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a
> > copy of all the data from the myfaces-metadata.xml contained in
> > myfaces-api jarfile. So if *all* jars in the classpath are processed,
> > the data from myfaces-api.jar will be processed twice.
> >
>
> Tomahawk sandbox depends on tomahawk core and myfaces api. Tomahawk
> core depends of myfaces api only (because it should be compatible with jsf
> ri, no
> impl dependences should be present). So the problem ilustrated here raises
> on sandbox.
>
>
> >
> > Options I see are
> > (a) don't worry; the data will just be identical
>
>
> Right.
>
>
> >
> > (b) check that if a model object is being overwritten, the new data is
> > identical
> > (c) have the plugin configured with an explicit list of jars to process
> > metadata from. Then in the pom it must be configured so that
> > myfaces-impl is processed and myfaces-api is ignored. Then make it an
> > error for the same model object to be defined twice.
> > (d) have a myfaces-metadata.xml file *not* include data inherited from
> > parent projects. That's cleaner in a way, but means that when processing
> > other goals we cannot just load the metadata file from the local project
> > but need to merge in all the ancestor projects too. Ecch.
> > (e) in the myfaces-metadata.xml, somehow mark entries with the jarfile
> > they came from.
> >
>
> Really, the option that likes me more is (e). One option to do this is
> create a
> modelId parameter (for components and other stuff inside Model), assigned
> on the pom as a param.
> This param can be used in several situations:
>
> (a) In tomahawk core, we need to generate a hierarchy of tag classes for
> myfaces api components.
> From this classes, tomahawk tag classes inherit. Note we need to change
> package for myfaces
> api component tag classes group (only html components). One option is give
> the possibility to apply a XSTL
> filter to myfaces-metadata.xml that do this.
> (b) Specify that some goal should be applied to a specific group of
> components, identified with a modelId.
>
> I will test this ideas and see what happen.
>
> regards
>
> Leonardo Uribe
>
Re: NavigationTree skinning/refactored? (TRINIDAD-655)
Hi, AFAIK the navigationTree renderer is an old UIX deprecated renderer and doesn't handle skinning correctly as you noticed. It should be refactored, but neither I nor somebody else found time to do it. But, I think you can use the normal tree component with command components in it. cheers On Wed, Apr 2, 2008 at 11:03 PM, DuBois, Joseph < [EMAIL PROTECTED]> wrote: > Hello again, > > Since I didn't see a response to my question I did a bit more searching > and noticed the following BUG listing (655), and was wondering, since it > is listed as still open, if this was something that is being looked at > or should I look for an alternative implementation? (which seems to be > my problem). > > I am not fully sure how you guys go about doing fixes and such, so > figured I would ask. > > https://issues.apache.org/jira/browse/TRINIDAD-655 > >Despite documentation saying that > af|navigationTree::disclosed-icon and > af|navigationTree::undisclosed-icon may be used to style the > navigationTree icons, they are not used by the current renderer which > hard-codes the icons to unicode text values in the renderExpandCell > method of TreeRenderer > >Documented at: > >http://myfaces.apache.org/trinidad/skin-selectors.html > > > Thanks again for any assistance. > Joe > > > -Original Message- > From: DuBois, Joseph [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 26, 2008 1:32 PM > To: MyFaces Development > Subject: NavigationTree skinning/refactored? > > Well met all, > > First time posting here, and new to Trinidad, so hopefully following > proper etiquette. > > I am looking to re-skin the navigationTree element and in searching the > archives on MarkMail I found several threads with references, the most > recent was on 2007/10/08 by A.Winer where he talked about it requiring > refactoring because it was using the "older" UIX component and that we'd > have a new one in core.xhtml. I contacted Adam, but he said he was no > longer working on the project, thus he never was able to do it, so I was > wondering if this has been done? > > Second I found a post back in 2007/01/08 again about a skinning the > navigationTree, but no responses to that query? > > So again, looking for help/advise. I need to change the ">" symbol that > is displayed to a graphical image. > > Joe DuBois > Children's Hospital Boston > [EMAIL PROTECTED] > > > > > > > -- Cristi Toth - Codebeat www.codebeat.ro
[jira] Commented: (TRINIDAD-1030) IE7 memory leak
[ https://issues.apache.org/jira/browse/TRINIDAD-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584883#action_12584883 ] Scott O'Bryan commented on TRINIDAD-1030: - Davide, Does this happen in FF? I know we've been very careful about closures in the past and while I don't deny we have any, this test gives us no indication as to where these closures might be. There may not even BE any closures as we don't generally control when the browser garbage collects. It would be helpful to us if you could: 1. Track down the closures and/or 2. Try to use a utility which forces garbage collection of the browsers rather then relying on nulling things out. Explicitly nulling things out may be triggering a gc in IE that would not happen otherwise. Scott > IE7 memory leak > --- > > Key: TRINIDAD-1030 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1030 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.0.5-core, 1.0.6-core, 1.0.7-core > Environment: IE7 running on Windows XP. >Reporter: Davide Bonicelli >Priority: Minor > Attachments: leak.jspx > > > Pages generated with Trinidad can cause a memory leak in IE7. > This problem can be verified using sIEve to track the memory usage of IE > while automatically refreshing a page generated with Trinidad. > The problem does not affect all the pages generated with Trinidad, thus it is > probably connected to some Trinidad tags. > The bug can be reproduced running sIEve on the Trinidad Online Demo > (http://www.irian.at/trinidad-demo/faces/index.jspx). > It is possible to notice how pages like "index.jspx", "tree.jspx" and > "outputText.jspx" cause the memory leak. > "componentDemos.jspx" is an example of page not causing the memory leak. > sIEve does not identify any memory leak in the affected pages, but the memory > usage of IE keeps increasing. The leakage could be caused by what Microsoft > describes as the "DOM Insertion Order Leak Model" that is transparent to most > leak-detection algorithms. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1030) IE7 memory leak
[ https://issues.apache.org/jira/browse/TRINIDAD-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584847#action_12584847 ] Davide Bonicelli commented on TRINIDAD-1030: I set up a plain Trinidad page to run some tests and I've added a javascript function that is invoked on "onunload". The function sets to null all the global variables defined in Common1_0_X.js. Running the page in sIEve without the script, shows how no memory is released when the page is refreshed. When instead the script is added to the page, some of the memory is released. This shows how Common1_0_X.js is leaking memory in IE. The script probably breakes some Circular References and/or Closures. You find the file with the script in the attachment files as "leak.jspx". > IE7 memory leak > --- > > Key: TRINIDAD-1030 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1030 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.0.5-core, 1.0.6-core, 1.0.7-core > Environment: IE7 running on Windows XP. >Reporter: Davide Bonicelli >Priority: Minor > > Pages generated with Trinidad can cause a memory leaks in IE7. > This problem can be verified using sIEve to track the memory usage of IE > while automatically refreshing a page generated with Trinidad. > The problem does not affect all the pages generated with Trinidad, thus it is > probably connected to some Trinidad tags. > The bug can be reproduced running sIEve on the Trinidad Online Demo > (http://www.irian.at/trinidad-demo/faces/index.jspx). > It is possible to notice how pages like "index.jspx", "tree.jspx" and > "outputText.jspx" cause the memory leak. > "componentDemos.jspx" is an example of page not causing memory leak. > sIEve does not identify any memory leak in the affected pages, but the memory > usage of IE keeps increasing. The leakage could be then caused by what > Microsoft describes as the "DOM Insertion Order Leak Model" that is > transparent to most leak-detection algorithms. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: All MyFaces logos are finished :)
+1 As I always said. They look great! Where's the t-shirt? :) Bruno On 02/04/2008, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > Matt, > > > On Wed, Apr 2, 2008 at 9:33 PM, Matt Cooper <[EMAIL PROTECTED]> wrote: > > Thank you Adonis. > > > > I think they all look great. I noticed there is one minor anomaly in > > the Tomahawk logo on the far-left side, there's a portion of the green > > logo that shows up as all gray whereas in the other logos, that kind > > of area shows up green in the other logos. > > > > My only request would be that if you could make available a PDF of > > these files so that we would have resolution-independent versions of > > these graphics (e.g. for t-shirts or print). > > > I want a t-shirt, too :-) > > > > > > At some point one of us can create some standard png graphics to be of > > each individual logo so that we use consistent sizing across our > > websites, docs, and GUIs. > > > > Thank you for all the great work! > > > +1 thanks, Adonis. > (the next dance ?) > > > - Matt > > > > > > > > On Wed, Apr 2, 2008 at 1:06 PM, Scott O'Bryan <[EMAIL PROTECTED]> > wrote: > > > Yeah, I had already modified it, but it's fine with me... I've got a > > > fix to do anyway (because I somehow hosed the graphic) so I'll be > sure > > > to incorporate this one. > > > > > > Scott > > > > > > > > > > > > Adonis Raduca wrote: > > > > Hi, > > > > > > > > In the final all MyFaces logos are finished. > > > > I placed all of them in one image for a good overview. :) > > > > Please take a look in the atached PNG file. > > > > > > > > What is your final impression about those logos? > > > > Did they individually fit with each project? > > > > Did they fit together? > > > > > > > > Have a nice day ! > > > > Adonis > > > > > > > > P.S. > > > > With respect for you Scott, I modified a little the PortletBridge > logo > > > > in order to fit with the general MyFaces logo pattern. > > > > Is this OK for you? > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org >
[jira] Commented: (TRINIDAD-997) tag with no attributes is not rendered when using Trinidad
[
https://issues.apache.org/jira/browse/TRINIDAD-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584777#action_12584777
]
Piotr Steininger commented on TRINIDAD-997:
---
This is definitely a good example of flexibility Trinidad would greatly benefit
from +1
> tag with no attributes is not rendered when using Trinidad
> -
>
> Key: TRINIDAD-997
> URL: https://issues.apache.org/jira/browse/TRINIDAD-997
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components, Facelets, Skinning
>Affects Versions: 1.0.6-core
>Reporter: Jonathan Herr
>Priority: Critical
> Attachments: elementOptimization.patch
>
>
> We recently integrated Trinidad into our application to evaluate it.
> Immediately we noticed that most pages would not render correctly. We
> discovered the problem was that if a tag had no attributes (id, class,
> etc.), it would not be rendered. For example:
>
> Example
>
>
> Renders as:
> Example
>
> In most applications this would not matter since by default the tag
> has no style, but we overrode the CSS of the tag to have very unique
> styles:
> form fieldset span { position: relative; display: block; width: 100%;
> margin-bottom: 6px; overflow: hidden; }
> If the tag was removed, we lost these styles and the page would be
> very distorted.
> Our only workaround right now is to update the hundreds of tags
> throughout our application and give them a class attribute so they will
> render.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: NavigationTree skinning/refactored? (TRINIDAD-655)
Hello again, Since I didn't see a response to my question I did a bit more searching and noticed the following BUG listing (655), and was wondering, since it is listed as still open, if this was something that is being looked at or should I look for an alternative implementation? (which seems to be my problem). I am not fully sure how you guys go about doing fixes and such, so figured I would ask. https://issues.apache.org/jira/browse/TRINIDAD-655 Despite documentation saying that af|navigationTree::disclosed-icon and af|navigationTree::undisclosed-icon may be used to style the navigationTree icons, they are not used by the current renderer which hard-codes the icons to unicode text values in the renderExpandCell method of TreeRenderer Documented at: http://myfaces.apache.org/trinidad/skin-selectors.html Thanks again for any assistance. Joe -Original Message- From: DuBois, Joseph [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 1:32 PM To: MyFaces Development Subject: NavigationTree skinning/refactored? Well met all, First time posting here, and new to Trinidad, so hopefully following proper etiquette. I am looking to re-skin the navigationTree element and in searching the archives on MarkMail I found several threads with references, the most recent was on 2007/10/08 by A.Winer where he talked about it requiring refactoring because it was using the "older" UIX component and that we'd have a new one in core.xhtml. I contacted Adam, but he said he was no longer working on the project, thus he never was able to do it, so I was wondering if this has been done? Second I found a post back in 2007/01/08 again about a skinning the navigationTree, but no responses to that query? So again, looking for help/advise. I need to change the ">" symbol that is displayed to a graphical image. Joe DuBois Children's Hospital Boston [EMAIL PROTECTED]
Re: New Tomahawk sandbox component - PDF Exporter :)
> After checking its license, I found it LGPL and MPL. the MPL works, IMO > Here is the url : > http://www.lowagie.com/iText/download.html > Please tell me if I can use it or not. > Thanks all. > > -- > Hazem Ahmed Saleh Ahmed > http://www.jroller.com/page/HazemBlog -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: All MyFaces logos are finished :)
Matt, On Wed, Apr 2, 2008 at 9:33 PM, Matt Cooper <[EMAIL PROTECTED]> wrote: > Thank you Adonis. > > I think they all look great. I noticed there is one minor anomaly in > the Tomahawk logo on the far-left side, there's a portion of the green > logo that shows up as all gray whereas in the other logos, that kind > of area shows up green in the other logos. > > My only request would be that if you could make available a PDF of > these files so that we would have resolution-independent versions of > these graphics (e.g. for t-shirts or print). I want a t-shirt, too :-) > > At some point one of us can create some standard png graphics to be of > each individual logo so that we use consistent sizing across our > websites, docs, and GUIs. > > Thank you for all the great work! +1 thanks, Adonis. (the next dance ?) > - Matt > > > > On Wed, Apr 2, 2008 at 1:06 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > Yeah, I had already modified it, but it's fine with me... I've got a > > fix to do anyway (because I somehow hosed the graphic) so I'll be sure > > to incorporate this one. > > > > Scott > > > > > > > > Adonis Raduca wrote: > > > Hi, > > > > > > In the final all MyFaces logos are finished. > > > I placed all of them in one image for a good overview. :) > > > Please take a look in the atached PNG file. > > > > > > What is your final impression about those logos? > > > Did they individually fit with each project? > > > Did they fit together? > > > > > > Have a nice day ! > > > Adonis > > > > > > P.S. > > > With respect for you Scott, I modified a little the PortletBridge logo > > > in order to fit with the general MyFaces logo pattern. > > > Is this OK for you? > > > > > > > > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Updated: (TRINIDAD-822) Add additional accessibility features to skinning
[ https://issues.apache.org/jira/browse/TRINIDAD-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Cooper updated TRINIDAD-822: - Resolution: Fixed Fix Version/s: 1.2.8-core 1.0.8-core Status: Resolved (was: Patch Available) > Add additional accessibility features to skinning > - > > Key: TRINIDAD-822 > URL: https://issues.apache.org/jira/browse/TRINIDAD-822 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Skinning >Affects Versions: 1.0.5-core, 1.2.4-core >Reporter: Matt Cooper >Assignee: Matt Cooper > Fix For: 1.0.8-core, 1.2.8-core > > Attachments: TRINIDAD-822-1.2.x.patch, TRINIDAD-822-trunk.patch > > > It is important to be able to define skin settings based on accessibility > policies such as: > @accessibility-policy [low-vision, any-vision, high-contrast, any-contrast, > keyboard, mouse, touch] > If this is added then a corresponding accessibility-policy property/object > for trinidad-config.xml would be needed. There is an existing > accessibility-mode property/object available today so we may want to > incorporate that or otherwise deprecate it if it is not possible to use it to > enumerate all of the possible combinations of the above noted policies. > Basically people should be able to define skin properties specific to > accessibility needs. In the past the answer was to create a separate skin > for each need but it is becoming apparent that this is not ideal. Take this > scenario for example: > The Apache MyFaces Trinidad community has spent a lot of effort working on a > skin that meets all of the accessibility requirements of their customers. > You're a random customer of Trinidad, working on making an app for your own > organization and don't have the resources or expertise to make a skin that > meets the same needs on your own. You are happy with most of what the > default skin provides but you really just want to make some minor color, > image, and font changes to match your organization's branding. You really > just want to extend the provided skin and don't want to risk breaking > accessibility needs. If you change the base styles, you'll be responsible > for coming up with low-vision, high-contrast styles too. If you could > somehow just change the styles that won't impact the special needs users then > you can make your skin extension with much less effort--the "any-contrast" > and "any-vision" @accessibility-policy would enable you to do this. Or the > inverse if some third party created a skin but you needed to make some tweaks > for high-contrast, low-vision, or touch-based entry users, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New Tomahawk sandbox component - PDF Exporter :)
Thank you :). On Wed, Apr 2, 2008 at 10:12 PM, Cagatay Civici <[EMAIL PROTECTED]> wrote: > If it's LPGL, nope:) > > > On Wed, Apr 2, 2008 at 10:57 PM, Hazem Saleh <[EMAIL PROTECTED]> > wrote: > > > Hi guys, > > Iam planning to start a new Tomahawk sandbox component that generates > > PDF files. > > I just want to ask whether I can use (iText) java library or not. > > After checking its license, I found it LGPL and MPL. > > Here is the url : > > http://www.lowagie.com/iText/download.html > > Please tell me if I can use it or not. > > Thanks all. > > > > -- > > Hazem Ahmed Saleh Ahmed > > http://www.jroller.com/page/HazemBlog > > > -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: ppr component update funcation hook [was: Re: country/zip show city problem]
Sounds like a good idea. While we are at that we could also add a general before- and afterUpdateJSHook="jsFunction" which will be executed before and after the group has been updated. this way users could for instance implement their own loading message display or just postprocess the updated DOM-elements. regards Ernst On Mon, Mar 31, 2008 at 8:06 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > What do you think about an enhancement for ppr which allows to customize > the DOM update of the response? > So, instead of the simple "domElement.innerHtml=xx" stuff, one is able > to hook into that and provide his/hers own dom update. > > > > where "javascript-function-name" points to a function with the signature > of "function(componentDataInResponse, targetDomElement)" > > All the script handling will stay the same with this solution: If there > is a script tag in the resulting innerHTML it will be executed. > > That way I'll be able to have a function like > "pprResponseCopyValuesOnly()" which will not replace the whole DOM but > just the wanted attributes of a given element. > > Later on we can also add a domUpdateFunction which will replace most of > the ppr.handleCallback logic ... but that is another story. > > Thoughts? > > Ciao, > Mario > >
Re: New Tomahawk sandbox component - PDF Exporter :)
If it's LPGL, nope:) On Wed, Apr 2, 2008 at 10:57 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote: > Hi guys, > Iam planning to start a new Tomahawk sandbox component that generates PDF > files. > I just want to ask whether I can use (iText) java library or not. > After checking its license, I found it LGPL and MPL. > Here is the url : > http://www.lowagie.com/iText/download.html > Please tell me if I can use it or not. > Thanks all. > > -- > Hazem Ahmed Saleh Ahmed > http://www.jroller.com/page/HazemBlog
Re: MyfacesBuilderPlugin
On Wed, Apr 2, 2008 at 2:49 AM, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > I'm not quite clear what your description above means. I think we are > talking about the same thing, but just to be clear this is how I would > see it working: > > == for goal build-metadata: > > start with an empty model > for each jarfile containing a META-INF/myfaces-metadata.xml file > read that myfaces-metadata.xml file > add the resulting objects into the model[1] > run the ModelBuilder for the current project, which adds more objects to > the model > save the model into META-INF/myfaces-metadata.xml in the current project > > An alternative would be to do the merging just at the xml level, then > build a model from the resulting merged xml file. That also seems > reasonable. > > == for other goals (eg generate faces.xml, generate tag classes): > start with an empty model > read META-INF/myfaces-metadata.xml for the current project only > add the resulting objects to the model > pass the model object to the appropriate generator class[3] > > [1] Hmm..might need to somehow detect and handle duplicate data. > Yes, duplicated data is the problem. > > In particular, tomahawk will depend on both myfaces-api and > myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a > copy of all the data from the myfaces-metadata.xml contained in > myfaces-api jarfile. So if *all* jars in the classpath are processed, > the data from myfaces-api.jar will be processed twice. > Tomahawk sandbox depends on tomahawk core and myfaces api. Tomahawk core depends of myfaces api only (because it should be compatible with jsf ri, no impl dependences should be present). So the problem ilustrated here raises on sandbox. > > Options I see are > (a) don't worry; the data will just be identical Right. > > (b) check that if a model object is being overwritten, the new data is > identical > (c) have the plugin configured with an explicit list of jars to process > metadata from. Then in the pom it must be configured so that > myfaces-impl is processed and myfaces-api is ignored. Then make it an > error for the same model object to be defined twice. > (d) have a myfaces-metadata.xml file *not* include data inherited from > parent projects. That's cleaner in a way, but means that when processing > other goals we cannot just load the metadata file from the local project > but need to merge in all the ancestor projects too. Ecch. > (e) in the myfaces-metadata.xml, somehow mark entries with the jarfile > they came from. > Really, the option that likes me more is (e). One option to do this is create a modelId parameter (for components and other stuff inside Model), assigned on the pom as a param. This param can be used in several situations: (a) In tomahawk core, we need to generate a hierarchy of tag classes for myfaces api components. >From this classes, tomahawk tag classes inherit. Note we need to change package for myfaces api component tag classes group (only html components). One option is give the possibility to apply a XSTL filter to myfaces-metadata.xml that do this. (b) Specify that some goal should be applied to a specific group of components, identified with a modelId. I will test this ideas and see what happen. regards Leonardo Uribe
New Tomahawk sandbox component - PDF Exporter :)
Hi guys, Iam planning to start a new Tomahawk sandbox component that generates PDF files. I just want to ask whether I can use (iText) java library or not. After checking its license, I found it LGPL and MPL. Here is the url : http://www.lowagie.com/iText/download.html Please tell me if I can use it or not. Thanks all. -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: All MyFaces logos are finished :)
Thank you Adonis. I think they all look great. I noticed there is one minor anomaly in the Tomahawk logo on the far-left side, there's a portion of the green logo that shows up as all gray whereas in the other logos, that kind of area shows up green in the other logos. My only request would be that if you could make available a PDF of these files so that we would have resolution-independent versions of these graphics (e.g. for t-shirts or print). At some point one of us can create some standard png graphics to be of each individual logo so that we use consistent sizing across our websites, docs, and GUIs. Thank you for all the great work! - Matt On Wed, Apr 2, 2008 at 1:06 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Yeah, I had already modified it, but it's fine with me... I've got a > fix to do anyway (because I somehow hosed the graphic) so I'll be sure > to incorporate this one. > > Scott > > > > Adonis Raduca wrote: > > Hi, > > > > In the final all MyFaces logos are finished. > > I placed all of them in one image for a good overview. :) > > Please take a look in the atached PNG file. > > > > What is your final impression about those logos? > > Did they individually fit with each project? > > Did they fit together? > > > > Have a nice day ! > > Adonis > > > > P.S. > > With respect for you Scott, I modified a little the PortletBridge logo > > in order to fit with the general MyFaces logo pattern. > > Is this OK for you? > > > > > > > >
Re: All MyFaces logos are finished :)
Yeah, I had already modified it, but it's fine with me... I've got a fix to do anyway (because I somehow hosed the graphic) so I'll be sure to incorporate this one. Scott Adonis Raduca wrote: Hi, In the final all MyFaces logos are finished. I placed all of them in one image for a good overview. :) Please take a look in the atached PNG file. What is your final impression about those logos? Did they individually fit with each project? Did they fit together? Have a nice day ! Adonis P.S. With respect for you Scott, I modified a little the PortletBridge logo in order to fit with the general MyFaces logo pattern. Is this OK for you?
Re: [Tobago] Merging maven-apt-plugin with Codehaus'
Thanks Mark, just some short notes inline Mark Hobson schrieb: > Hi Bernd, > > I've finished with the major changes in tidying up the Codehaus > apt-maven-plugin if you fancy taking a look: > > http://svn.codehaus.org/mojo/trunk/sandbox/apt-maven-plugin/ > > Major changes: > - Manually merged in any exclusive features I could see in the Tobago version > - Big refactor to simplify code > - Added integration test intrastructure with a few tests to start with > - Supported plugin dependencies (TOBAGO-130/MOJO-1072) > > I've also just removed any Java compliation support from the plugin > since I couldn't see any advantage of duplicating this with the > maven-compiler-plugin. Can you see any problems with that? I don't use this parameter, but this would break backwards compatibility. > > A few further points I'd like to ask you about: > > 1) Do you use extra source roots? I'm tempted to remove this > parameter since it tends to go against the standard of using the > project's current source roots. Yes, I need this parameter. We unpack a source artifact and process the containing source code too. But the extra source root should not included in the compile. > > 2) Do you use the resource target path parameter? I'd have thought > that the apt factory should control this. Yes, I think the apt processor should only generate files and the resource plugin should copy the resources. > > 3) Do you use the target files parameter? I wouldn't have thought > you'd need such fine-grained control of source files to process when > using Maven. Yes, we did see 4 > > 4) Do you use staleness checking? I'm not too convinced by this > implementation since it checks source files against class files to > determine staleness. This is a problem when using -nocompile as the > class file timestamp has no correlation with the staleness of > generated resources. Auto-compiling IDEs then also pose a further > problem since they never let a class file become stale, hence > resources are never generated with apt. Yes, with the target file parameter the apt plugin is only called if the source code has changed. > > I'd be interested in any feedback on using this plugin with Tobago. > Feel free to move any existing JIRA issues across to the apt component > in MOJO: > > http://jira.codehaus.org/browse/MOJO/component/13192 > > Cheers, > > Mark You can look at http://svn.apache.org/repos/asf/myfaces/tobago/trunk/core/pom.xml for some usages of the tobago apt plugin The old apt plugin from codehaus provides a 'generateToBuildDir' property. I think this parameter is useless. What do you think? Regards Bernd >
[jira] Resolved: (TOBAGO-643) ajax requests looses viewRoot locale setting
[ https://issues.apache.org/jira/browse/TOBAGO-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-643. - Resolution: Fixed Fix Version/s: 1.1.0 > ajax requests looses viewRoot locale setting > > > Key: TOBAGO-643 > URL: https://issues.apache.org/jira/browse/TOBAGO-643 > Project: MyFaces Tobago > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Volker Weber >Assignee: Volker Weber > Fix For: 1.1.0 > > > the RendererCacheKey is not restored in restoreViewPhase, this results in > wrong resourceBundleLocale usage in rerendering a view. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-643) ajax requests looses viewRoot locale setting
ajax requests looses viewRoot locale setting Key: TOBAGO-643 URL: https://issues.apache.org/jira/browse/TOBAGO-643 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.1.0 Reporter: Volker Weber the RendererCacheKey is not restored in restoreViewPhase, this results in wrong resourceBundleLocale usage in rerendering a view. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Tobago] a project to a source of spam
On Wed, Apr 2, 2008 at 5:43 PM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > > I found some more (Trinidad and Tobago). > > Reason (as mostly) => continuum). > > Okay, thanks for looking into it. Maybe I should create a new filter > for these guys. yes. or check for "ContinuumBuildCancelledException" inside the content, or SVN failed (or any of these typical continuum issues) :-) -M > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Tobago] a project to a source of spam
> I found some more (Trinidad and Tobago). > Reason (as mostly) => continuum). Okay, thanks for looking into it. Maybe I should create a new filter for these guys.
[jira] Created: (TOMAHAWK-1224) Conversion issue - Schedule_editsettings.jsp not working with Schedule.Mode setting
Conversion issue - Schedule_editsettings.jsp not working with Schedule.Mode
setting
---
Key: TOMAHAWK-1224
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1224
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Examples
Environment: Tomcat, Windows XP, Firefox and IE7
Reporter: Frederic Filiatrault
Priority: Minor
The actual mode selected is returning a "Value is not a valid option." due to a
conversion issue.
This can be fix very easily with 2 steps:
STEP 1 - Adding this code to
org.apache.myfaces.examples.schedule.ScheduleSettings.java :
private String mode;
public String getMode() { return mode;}
public void setMode(String value) {
if (value != null) {
int mode = Integer.parseInt(value);
model.setMode(mode);
this.mode = value;
}
}
STEP 2 - Changing the value attribute of the mode from
"scheduleSettings2.model.mode" to "scheduleSettings2.mode" :
Hope this helps. thk
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: JSF 2.0 component set
>From: "Kito D. Mann" <[EMAIL PROTECTED]> > > I just want to add that when we were talking about moving Shale over to > MyFaces, people were worried about resources for maintaining it. And Shale > is an *existing* code base :-). I think it'd make a lot more sense to > migrate the existing suites to JSF 2 branches. > The big issue I had with merging was that the majority didn't want to bring over all of shale. At this point, I don't think it would be responsible just to drop support unless you could offer a comparable feature. The shale's test library is one of the few that have not been reinvented over and over and that seemed to be where the root interest is with myfaces. In terms of maintaining Shale, we most certainly encourage contributions the same as myfaces :-) Gary > ~~~ > Kito D. Mann - Author, JavaServer Faces in Action > http://www.virtua.com - JSF/Java EE consulting, training, and mentoring > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info > phone: +1 203-653-2989 > fax: +1 203-653-2988 > > > > -Original Message- > > From: Scott O'Bryan [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 31, 2008 4:39 PM > > To: MyFaces Development > > Subject: Re: JSF 2.0 component set > > > > Bruno, I totally agree, but we don't want a lot of dead projects out > > there either. My point, and I think Simon's as well, is that much of > > the contributions to the MyFaces Projects and renderkits comes from > > companies and individuals who have a vested interest in supporting the > > existing renderkits going forward. Getting MyFaces core up to 2.0 is > > going to take away interest from the new project as is getting > > renderkits like Trinidad to be JSF 2.0 compatible. This is not to say > > that there isn't an interest in this, but one could spend hundreds of > > developer hours getting their head around Trinidad alone, and without > > the support of the majority of those currently active in the community, > > this project may be doomed from the start. You may be able to leverage > > some resources from other projects by moving as much stuff as possible > > into the commons, but projects of this scope take a lot of time and my > > guess is that you're basically looking at growing a new community. > > > > I would seriously look at bringing a project of this scope into > > incubator first. It'll hopefully help you to build the community you > > need. > > > > Scott > > > > Bruno Aranda wrote: > > > I don't see why not we could start a new component set for jsf 2.0 if > > > there is enough interest within the developers and users. This is a > > > community thing and if people worked heavily in such a project and > > the > > > result was good, I don't see why it should not exist. If others want > > > to maintain Trinidad and Tobago, any help is welcome too. At the end, > > > it is up to each individual :) > > > > > > Cheers, > > > > > > Bruno > > > > > > On 31/03/2008, *simon* > > > > wrote: > > > > > > Tomahawk certainly does need a radical refresh. It's got some > > useful > > > stuff, but is very ugly internally. > > > > > > There is slow work going on at the moment on something called the > > > myfaces "commons projects" (or some similar name). The idea is to > > > split > > > up tomahawk into about 4 different pieces. At the same time it's > > > therefore possible to discard the bits that have too much overlap > > with > > > other projects (esp Trinidad). > > > > > > That doesn't mean that the current Tomahawk will be abandoned, > > but > > > it is > > > an opportunity to scavenge the best bits for commons and discard > > the > > > rest. But I'd really like to see new stuff go into the "commons" > > > projects myself. Whether commons is JSF1.2 or JSF2.0 depends on > > the > > > relative progress of commons vs the JSF spec I suppose :-). > > > > > > I can't see Trinidad being rewritten anytime soon; that's a > > pretty big > > > job. Just getting a core JSF-2.0 implementation done is likely to > > suck > > > up all the spare time of the current myfaces contributors. And, > > > like for > > > Tomahawk, there is a big pool of people who want to use Trinidad > > on > > > JSF1.2 (including the committers employed by Oracle) so the > > > current form > > > of Trinidad will not be going away in the near future. > > > > > > I'm not aware of anything in JSF2.0 that is a radical improvement > > over > > > JSF1.2. Lots of nice bits, but does it really make components > > work > > > faster or vastly more efficient than can be done within JSF1.2? > > > > > > Regards, > > > > > > Simon > > > > > > > > > On Mon, 2008-03-31 at 13:50 -0600, Scott O'Bryan wrote: > > > > +0 > > > > > > > > While I see the merit of starting over (and certainly wouldn't > > argue > > > > against a new component set based off of 2.0), I don't th
[jira] Updated: (TRINIDAD-1038) PanelFrameLayout improvement to allow frames resizing and border coloring
[ https://issues.apache.org/jira/browse/TRINIDAD-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Havelka updated TRINIDAD-1038: Status: Patch Available (was: Open) > PanelFrameLayout improvement to allow frames resizing and border coloring > - > > Key: TRINIDAD-1038 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1038 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Components >Reporter: Tomas Havelka > > To work with frames more comfortable, resizing feature has to be possible. > My patch adds new frame component attribute to specify whether it should be > resizable or not. Another improvement is to specify panelFrameLayout border > color. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1038) PanelFrameLayout improvement to allow frames resizing and border coloring
PanelFrameLayout improvement to allow frames resizing and border coloring - Key: TRINIDAD-1038 URL: https://issues.apache.org/jira/browse/TRINIDAD-1038 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Reporter: Tomas Havelka To work with frames more comfortable, resizing feature has to be possible. My patch adds new frame component attribute to specify whether it should be resizable or not. Another improvement is to specify panelFrameLayout border color. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Tobago] a project to a source of spam
On Wed, Apr 2, 2008 at 4:30 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 2, 2008 at 4:25 PM, Andrew Robinson > <[EMAIL PROTECTED]> wrote: > > Sorry to be a grouch, but I am starting to wonder if people ever test > > Tobago builds before checking in code. It is a continuous source of > > spam by having continuum failure and success messages at least a few > > days every week. Is there anything that can be done to stop this? I > > suppose I could create a mail filter, but I cannot think of a valid > > reason why a build should break anywhere near this often. > > the current one is because of this: > ContinuumBuildCancelledException I found some more (Trinidad and Tobago). Reason (as mostly) => continuum). sure, there was a timeframe when their commits didn't pass, but I think the setup from our box is a little bit ... buggy ? Not sure, just a hunch .. -M > > blame continuum... > > > > > Thanks, > > Andrew > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [continuum] BUILD ERROR: Apache MyFaces Trinidad
this is a Trinidad one ==> continuum On Tue, Apr 1, 2008 at 10:14 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Online report : > http://myfaces.zones.apache.org:8080/continuum/buildResult.action?buildId=8030&projectId=48 > > Build statistics: > State: Error > Previous State: Ok > Started at: Tue 1 Apr 2008 07:01:10 + > Finished at: Tue 1 Apr 2008 08:14:12 + > Total time: 1h 13m 1s > Build Trigger: Schedule > Build Number: 94 > Exit code: 0 > Building machine hostname: myfaces.zones.apache.org > Operating system : SunOS(unknown) > Java Home version : java version "1.5.0_15" > Java(TM) 2 Runtime Environment, Standard Edition (build > 1.5.0_15-b04) > Java HotSpot(TM) Server VM (build 1.5.0_15-b04, mixed mode) > Builder version : > Maven version: 2.0.8 > Java version: 1.5.0_15 > OS name: "sunos" version: "5.10" arch: "x86" Family: "unix" > > > SCM Changes: > > > Changed: matzew @ Tue 1 Apr 2008 04:55:44 + > Comment: TRINIDAD-1005 > Files changed: > > /myfaces/trinidad/trunk/trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/javax/faces/Component.xml > ( 643280 ) > > > > Dependencies Changes: > > > No dependencies changed > > > > Test Summary: > > > Tests: 1285 > Failures: 0 > Total time: 57385 > > > > Build Error: > > > org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The > build was cancelled > at > org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:215) > at > org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:140) > at > org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:145) > at > org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) > at > edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) > at > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) > at java.lang.Thread.run(Thread.java:595) > Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while > executing external command, process killed. > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:164) > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) > at > org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:114) > at > org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:59) > at > org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:203) > ... 11 more > Caused by: java.lang.InterruptedException > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:474) > at java.lang.UNIXProcess.waitFor(UNIXProcess.java:115) > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:128) > ... 15 more > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [continuum] BUILD ERROR: Theme Charlotteville
from yesterday, ==> continuum On Tue, Apr 1, 2008 at 3:24 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Online report : > http://myfaces.zones.apache.org:8080/continuum/buildResult.action?buildId=8034&projectId=13 > > Build statistics: > State: Error > Previous State: Ok > Started at: Tue 1 Apr 2008 13:24:04 + > Finished at: Tue 1 Apr 2008 13:24:32 + > Total time: 27s > Build Trigger: Schedule > Build Number: 0 > Exit code: 0 > Building machine hostname: myfaces.zones.apache.org > Operating system : SunOS(unknown) > Java Home version : java version "1.5.0_15" > Java(TM) 2 Runtime Environment, Standard Edition (build > 1.5.0_15-b04) > Java HotSpot(TM) Server VM (build 1.5.0_15-b04, mixed mode) > Builder version : > Maven version: 2.0.8 > Java version: 1.5.0_15 > OS name: "sunos" version: "5.10" arch: "x86" Family: "unix" > > > SCM Changes: > > > No files changed > > > > Dependencies Changes: > > > No dependencies changed > > > > Build Error: > > > Provider message: The svn command failed. > Command output: > --- > svn: PROPFIND request failed on > '/repos/asf/myfaces/tobago/trunk/theme/charlotteville' > svn: PROPFIND of '/repos/asf/myfaces/tobago/trunk/theme/charlotteville': > Could not read status line: Connection reset by peer (http://svn.apache.org) > > --- > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Tobago] a project to a source of spam
On Wed, Apr 2, 2008 at 4:25 PM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > Sorry to be a grouch, but I am starting to wonder if people ever test > Tobago builds before checking in code. It is a continuous source of > spam by having continuum failure and success messages at least a few > days every week. Is there anything that can be done to stop this? I > suppose I could create a mail filter, but I cannot think of a valid > reason why a build should break anywhere near this often. the current one is because of this: ContinuumBuildCancelledException blame continuum... > > Thanks, > Andrew > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[Tobago] a project to a source of spam
Sorry to be a grouch, but I am starting to wonder if people ever test Tobago builds before checking in code. It is a continuous source of spam by having continuum failure and success messages at least a few days every week. Is there anything that can be done to stop this? I suppose I could create a mail filter, but I cannot think of a valid reason why a build should break anywhere near this often. Thanks, Andrew
Re: JspStateManagerImpl into shared?
On Wed, Apr 2, 2008 at 3:18 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > > Orchestra having its own JspStateManagerImpl sounds "interesting" > > though. Enabling this on Sun Mojarra for example will quite radically > > change the way that a JSF app on Mojarra performs. That's not really > > Orchestra's role. > > > I thought about this like an optional feature one has to configure in > their own faces-config.xml > > > > What is *really* needed is for the StateManager spec to have some > > mechanism to externalise the state, then have Orchestra override just > > that. > +1 But that is not here yet! > > > > Is it not possible to apply the "decorator" pattern to whatever > > StateManager implementation the current JSF implementation provides? > > > No, unfortunately, no! I'd file an spec enhancement request for that, perhaps it will be there in 2.x -M > On the other hand, if you replace the state manager it should work with > any other JSF impl too ... as long as it follows the standard by > dispatching anything through the StateManager, no? > > Ciao, > Mario > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: JspStateManagerImpl into shared?
> Myfaces Core should not be dependent on a > commons library. It has an obligation to the TCK. currently we have dependencies on some apache commons lib, that's fine, I think (we passed the TCK thing). Or did I got you wrong ? > > Unlike everyone else though, I don't like the "base" name. It implies that > other commons projects would be dependent on it. > > Scott > > > > On Apr 2, 2008, at 7:18 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > > > Hi! > > > > > Orchestra having its own JspStateManagerImpl sounds "interesting" > > > though. Enabling this on Sun Mojarra for example will quite radically > > > change the way that a JSF app on Mojarra performs. That's not really > > > Orchestra's role. > > > > > > > > I thought about this like an optional feature one has to configure in > > their own faces-config.xml > > > > > > > What is *really* needed is for the StateManager spec to have some > > > mechanism to externalise the state, then have Orchestra override just > > > that. > > > > > +1 But that is not here yet! > > > > > > > Is it not possible to apply the "decorator" pattern to whatever > > > StateManager implementation the current JSF implementation provides? > > > > > > > > No, unfortunately, no! > > On the other hand, if you replace the state manager it should work with > > any other JSF impl too ... as long as it follows the standard by > > dispatching anything through the StateManager, no? > > > > Ciao, > > Mario > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Resolved: (TOBAGO-630) Selection of rows in long sheets is slow on IE
[ https://issues.apache.org/jira/browse/TOBAGO-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-630. Resolution: Fixed > Selection of rows in long sheets is slow on IE > -- > > Key: TOBAGO-630 > URL: https://issues.apache.org/jira/browse/TOBAGO-630 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Themes >Affects Versions: 1.0.15 >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Minor > Fix For: 1.0.16, 1.1.0 > > > we must not use Tobago.element() or document.getElementById() because the IE > 6? doen't index the ids. > to the performace is quadratic aka. O(N*N) when N is the number of rows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JspStateManagerImpl into shared?
I largely agree with Simon here.. Myfaces Core should not be dependent on a commons library. It has an obligation to the TCK. I see no reason, though that if this library has universal appeal, it can't be duplicated in commons. Unlike everyone else though, I don't like the "base" name. It implies that other commons projects would be dependent on it. Scott On Apr 2, 2008, at 7:18 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: Hi! Orchestra having its own JspStateManagerImpl sounds "interesting" though. Enabling this on Sun Mojarra for example will quite radically change the way that a JSF app on Mojarra performs. That's not really Orchestra's role. I thought about this like an optional feature one has to configure in their own faces-config.xml What is *really* needed is for the StateManager spec to have some mechanism to externalise the state, then have Orchestra override just that. +1 But that is not here yet! Is it not possible to apply the "decorator" pattern to whatever StateManager implementation the current JSF implementation provides? No, unfortunately, no! On the other hand, if you replace the state manager it should work with any other JSF impl too ... as long as it follows the standard by dispatching anything through the StateManager, no? Ciao, Mario
Re: shared discuss again [was Re: JspStateManagerImpl into shared?]
> > we already have a very raw starting point in the current commons, > > not yet finished, but it's there ;-) > > The started commons-(converters|validators) are IMHO a other type of commons, > not for use in jsf-impl classes but for application developper. This > is for nice and convenient utils stuff . didn't scott commit something? But even when not, some utils should be placed in commons. -M > > > > > > > > > > > > > > > I think that if we find a good name and define some strict rules we > > > > could move most (or all?) stuff from myfaces-shared to this lib. And > > > > perhaps even get rid of shard in the long run! > > > > > > > One rule can be to allow only stuff which itself directly implements a > > > JSF API but do not provide any functionality on its own, you see, no > > > enum converter or soo. Probably only abstract classes? > > > > > > > Of course, some well-known issues pop up immediately: which JSF-Spec > - > > > > 1.1 and 1.2 or only 1.2? What about JSF 2.0? > > > > > > > I'd like to see one project per version, e.g. myfaces-base11, > > > myfaces-base12, myfaces-base20 (with namespaced package names: > > > org.apache.myfaces.base11, etc) > > > > > > yeah, base11, base12, base20 > > what about a base, for those things that are independent from > > the spec diffs ? > > > > > > > FacesContextWrapper. But there is no need for that, we can't forsee any > > > future change e.g. in JSF 2.0 > > > > > > :-) True, all this is discussed behind closed doors > > > > -M > > > > > > > > Ciao, > > > Mario > > > > > > > > > > > > > > > > -- > > Matthias Wessendorf > > > > further stuff: > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > mail: matzew-at-apache-dot-org > > > > > Regards, > Volker > -- > inexso - information exchange solutions GmbH > Bismarckstraße 13 | 26122 Oldenburg > Tel.: +49 441 4082 356 | > FAX: +49 441 4082 355 | www.inexso.de > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Commented: (TRINIDAD-992) Validator as child of tr:inputText causes "label jumping" when client side validation enabled
[
https://issues.apache.org/jira/browse/TRINIDAD-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584564#action_12584564
]
Paul Mander commented on TRINIDAD-992:
--
I've got a solution to this problem now. It appears there is a defect in
Core.js - _function _validateInline(form, source, validators).
In this function, the code attempts to clear the old message by setting the
innerHTML to "". This works in Firefox but takes up space in IE.
if (msgElem)
msgElem.innerHTML = "";
A better check would be
if (msgElem && messageElem.innerHTML !="")
msgElem.innerHTML = "";
Or even better, use some IE save way of removing all children from the msgElem.
Can someone commit a fix for this please?
> Validator as child of tr:inputText causes "label jumping" when client side
> validation enabled
> -
>
> Key: TRINIDAD-992
> URL: https://issues.apache.org/jira/browse/TRINIDAD-992
> Project: MyFaces Trinidad
> Issue Type: Bug
>Affects Versions: 1.0.6-core
> Environment: IE7
>Reporter: Paul Mander
> Attachments: pre submit.jpg, submit.jpg
>
>
> Using panelFormLayout, an inputText and a validator causes labels to jump if
> client side validation is enabled.
> Consider the following markup
>
>
>
> value="#{pageBean.cardNumber}">
>
>
>
>
>
>
> If the minimal skin is used or client validation is disabled (amounts to the
> same thing), then labels do not jump when the page is submitted.
> See attached screen shots
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: JspStateManagerImpl into shared?
Hi! > Orchestra having its own JspStateManagerImpl sounds "interesting" > though. Enabling this on Sun Mojarra for example will quite radically > change the way that a JSF app on Mojarra performs. That's not really > Orchestra's role. > I thought about this like an optional feature one has to configure in their own faces-config.xml > What is *really* needed is for the StateManager spec to have some > mechanism to externalise the state, then have Orchestra override just > that. +1 But that is not here yet! > Is it not possible to apply the "decorator" pattern to whatever > StateManager implementation the current JSF implementation provides? > No, unfortunately, no! On the other hand, if you replace the state manager it should work with any other JSF impl too ... as long as it follows the standard by dispatching anything through the StateManager, no? Ciao, Mario
Re: shared discuss again [was Re: JspStateManagerImpl into shared?]
Hi, 2008/4/2, Matthias Wessendorf <[EMAIL PROTECTED]>: > > > Problem here again is the name of such a lib: > > > "myfaces-commons-base"? > > > "myfaces-commons-core"? > > > "myfaces-commons-super"? > > > "myfaces-commons-commons"? ;-) > > > > > I'd opt for myfaces-base, but to say the truth, I do not care about the > > name, whatever name it has will be good for me as long as the goal is > > the same. > > > I'd vote for -base as well. +1 for "-base" for this project > > > > > It is no place where we swiftly drop some > > > nice and convenient utils stuff and the API is nothing to play around > > > with. > > > > > +1 > > > we already have a very raw starting point in the current commons, > not yet finished, but it's there ;-) The started commons-(converters|validators) are IMHO a other type of commons, not for use in jsf-impl classes but for application developper. This is for nice and convenient utils stuff . > > > > > > > I think that if we find a good name and define some strict rules we > > > could move most (or all?) stuff from myfaces-shared to this lib. And > > > perhaps even get rid of shard in the long run! > > > > > One rule can be to allow only stuff which itself directly implements a > > JSF API but do not provide any functionality on its own, you see, no > > enum converter or soo. Probably only abstract classes? > > > > > Of course, some well-known issues pop up immediately: which JSF-Spec - > > > 1.1 and 1.2 or only 1.2? What about JSF 2.0? > > > > > I'd like to see one project per version, e.g. myfaces-base11, > > myfaces-base12, myfaces-base20 (with namespaced package names: > > org.apache.myfaces.base11, etc) > > > yeah, base11, base12, base20 > what about a base, for those things that are independent from > the spec diffs ? > > > > FacesContextWrapper. But there is no need for that, we can't forsee any > > future change e.g. in JSF 2.0 > > > :-) True, all this is discussed behind closed doors > > -M > > > > > Ciao, > > Mario > > > > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > Regards, Volker -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de
Re: Shared module (was Re: JspStateManagerImpl into shared?)
Matthias Wessendorf schrieb: > >> I'm also sceptical that it will be possible to create a "super stable >> API". Just look at what is in shared at the moment! And in addition to >> the API, the *implementation* will also need to be super-stable. For >> example, if a Tomahawk issue (whether bug or new feature) needs changes >> in the "commons" module to resolve, then deploying that commons change >> will immediately impact myfaces-core too. Suddenly people will be >> > +1 that's a side effect > > >> running a version of myfaces-core together with a commons version that >> it was never tested against. I don't like that idea at all. It was >> precisely this issue that the shared repackaging idea was invented for. >> > yup, I guess I now move to your direction, or... > base-tomahawk :-) but... that doesn't fly at all. > I guess what we really want is for servlet engines to explicitly permit OSGi use. Then myfaces-core can depend on version X of the "common" lib, while tomahawk can run in the same webapp using version Y. That would solve my major objection. Package-renaming is just a hack to get a similar effect without having to mess with classloaders. But with this setup, we would still have people complaining that they do not know where to put their breakpoints. In fact, it's even worse. At least with the current stuff, you can clearly see "o.a.m.shared_core.Foo", rather than dealing with two different concurrently-loaded versions of the "o.a.m.Foo" class. How do people interactively debug OSGi apps, I wonder.. Regards, Simon
Re: JspStateManagerImpl into shared?
Mario Ivankovits schrieb: > Hi! > Does this qualify to move JspStateManagerImpl into shared? Or should I better copy the source over? >> There are some jira issues and email threads that might be relevant: >> >> > Thanks for the links, for me it seems there is need for this for other > "experiments" too. So, I'd move this class to shared and refactor it a > little bit so that it can be easier subclassed and allow only the bits > changed one is interested in. > > However, I don't want to go to solve the window-problem for MyFaces at > all, but just for Orchestra which seems to be easy due to the already > existent conversationContext parameter. > Ah. The point you were making is that things other than myfaces-core might want a basic JspStateManagerImpl implementation for them to subclass. And that is what "shared" is for. Whether JspStateManagerImpl could be refactored to support alternative strategies is a different issue. Sorry about the red herring. Orchestra having its own JspStateManagerImpl sounds "interesting" though. Enabling this on Sun Mojarra for example will quite radically change the way that a JSF app on Mojarra performs. That's not really Orchestra's role. What is *really* needed is for the StateManager spec to have some mechanism to externalise the state, then have Orchestra override just that. Is it not possible to apply the "decorator" pattern to whatever StateManager implementation the current JSF implementation provides? Regards, Simon
Re: Shared module (was Re: JspStateManagerImpl into shared?)
> Personally, I think the shared concept works fine. fine is a bit to much, right? But, yeah it works > > One problem with a "commons" jar used by core is that Sun Mojarra will > need two jars (jsf-api, jsf-impl) and myfaces will need three (jsf-api, > jsf-impl, commons-whatever.jar). This is rather ugly. true. but since everybody uses maven... that shouldn't be a big deal, IMO but I can see that both approves have their "issues" > I'm also sceptical that it will be possible to create a "super stable > API". Just look at what is in shared at the moment! And in addition to > the API, the *implementation* will also need to be super-stable. For > example, if a Tomahawk issue (whether bug or new feature) needs changes > in the "commons" module to resolve, then deploying that commons change > will immediately impact myfaces-core too. Suddenly people will be +1 that's a side effect > running a version of myfaces-core together with a commons version that > it was never tested against. I don't like that idea at all. It was > precisely this issue that the shared repackaging idea was invented for. yup, I guess I now move to your direction, or... base-tomahawk :-) but... that doesn't fly at all. > We can improve the build process by having a maven plugin that > imports-then-renames, rather than messing with the shared project to > generate the per-user variant. That's really quite simple, and could be > a nice general-purpose plugin. The maven-shade-plugin does something > similar, but at the binary level. > > Earlier releases of myfaces did not include the "shared" source in the > -sources jar which was a major nuisance. But that is now fixed. So for > most users, there is no need to ever deal with the original shared project. +1 -M > > Regards, > Simon > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: shared discuss again [was Re: JspStateManagerImpl into shared?]
> > Problem here again is the name of such a lib: > > "myfaces-commons-base"? > > "myfaces-commons-core"? > > "myfaces-commons-super"? > > "myfaces-commons-commons"? ;-) > > > I'd opt for myfaces-base, but to say the truth, I do not care about the > name, whatever name it has will be good for me as long as the goal is > the same. I'd vote for -base as well. > > It is no place where we swiftly drop some > > nice and convenient utils stuff and the API is nothing to play around > > with. > > > +1 we already have a very raw starting point in the current commons, not yet finished, but it's there ;-) > > > I think that if we find a good name and define some strict rules we > > could move most (or all?) stuff from myfaces-shared to this lib. And > > perhaps even get rid of shard in the long run! > > > One rule can be to allow only stuff which itself directly implements a > JSF API but do not provide any functionality on its own, you see, no > enum converter or soo. Probably only abstract classes? > > > Of course, some well-known issues pop up immediately: which JSF-Spec - > > 1.1 and 1.2 or only 1.2? What about JSF 2.0? > > > I'd like to see one project per version, e.g. myfaces-base11, > myfaces-base12, myfaces-base20 (with namespaced package names: > org.apache.myfaces.base11, etc) yeah, base11, base12, base20 what about a base, for those things that are independent from the spec diffs ? > FacesContextWrapper. But there is no need for that, we can't forsee any > future change e.g. in JSF 2.0 :-) True, all this is discussed behind closed doors -M > > Ciao, > Mario > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Shared module (was Re: JspStateManagerImpl into shared?)
Manfred Geiler schrieb: > Mario, you are not alone in hating the shared concept. ;-) > > This is exactly where the "myfaces-commons-xxx" library comes into > play, I often mentioned before. > What we need is a module, that > 1) has a super stable API > 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces > projects > Personally, I think the shared concept works fine. One problem with a "commons" jar used by core is that Sun Mojarra will need two jars (jsf-api, jsf-impl) and myfaces will need three (jsf-api, jsf-impl, commons-whatever.jar). This is rather ugly. I'm also sceptical that it will be possible to create a "super stable API". Just look at what is in shared at the moment! And in addition to the API, the *implementation* will also need to be super-stable. For example, if a Tomahawk issue (whether bug or new feature) needs changes in the "commons" module to resolve, then deploying that commons change will immediately impact myfaces-core too. Suddenly people will be running a version of myfaces-core together with a commons version that it was never tested against. I don't like that idea at all. It was precisely this issue that the shared repackaging idea was invented for. We can improve the build process by having a maven plugin that imports-then-renames, rather than messing with the shared project to generate the per-user variant. That's really quite simple, and could be a nice general-purpose plugin. The maven-shade-plugin does something similar, but at the binary level. Earlier releases of myfaces did not include the "shared" source in the -sources jar which was a major nuisance. But that is now fixed. So for most users, there is no need to ever deal with the original shared project. Regards, Simon
shared discuss again [was Re: JspStateManagerImpl into shared?]
Hi! > Mario, you are not alone in hating the shared concept. ;-) > Good! > 1) has a super stable API > That is true, that might be the hardest part. > 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces > projects > Sure! > 3) may be used by the experienced JSF app developer who wants to write > his own StateManager or ELResolver or some other pluggable/replaceable > JSF thingy (ie. all the things you can replace via faces-config.xml) > Yepp! > Problem here again is the name of such a lib: > "myfaces-commons-base"? > "myfaces-commons-core"? > "myfaces-commons-super"? > "myfaces-commons-commons"? ;-) > I'd opt for myfaces-base, but to say the truth, I do not care about the name, whatever name it has will be good for me as long as the goal is the same. > It is no place where we swiftly drop some > nice and convenient utils stuff and the API is nothing to play around > with. > +1 > I think that if we find a good name and define some strict rules we > could move most (or all?) stuff from myfaces-shared to this lib. And > perhaps even get rid of shard in the long run! > One rule can be to allow only stuff which itself directly implements a JSF API but do not provide any functionality on its own, you see, no enum converter or soo. Probably only abstract classes? > Of course, some well-known issues pop up immediately: which JSF-Spec - > 1.1 and 1.2 or only 1.2? What about JSF 2.0? > I'd like to see one project per version, e.g. myfaces-base11, myfaces-base12, myfaces-base20 (with namespaced package names: org.apache.myfaces.base11, etc) This might lead to code duplication for every new project, but is the only way I can think of making it possible for this project to succeed. It would not be nice if myfaces-base12 has to deal with backward-compatibility. Parts of myfaces-base12 MIGHT be backward-compatible, e.g. like any FacesContextWrapper. But there is no need for that, we can't forsee any future change e.g. in JSF 2.0 Ciao, Mario
Re: JspStateManagerImpl into shared?
Hi! >>> Does this qualify to move JspStateManagerImpl into shared? Or should I >>> better copy the source over? >>> >>> > > There are some jira issues and email threads that might be relevant: > Thanks for the links, for me it seems there is need for this for other "experiments" too. So, I'd move this class to shared and refactor it a little bit so that it can be easier subclassed and allow only the bits changed one is interested in. However, I don't want to go to solve the window-problem for MyFaces at all, but just for Orchestra which seems to be easy due to the already existent conversationContext parameter. Ciao, Mario
Re: JspStateManagerImpl into shared?
Mario, you are not alone in hating the shared concept. ;-) This is exactly where the "myfaces-commons-xxx" library comes into play, I often mentioned before. What we need is a module, that 1) has a super stable API 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces projects 3) may be used by the experienced JSF app developer who wants to write his own StateManager or ELResolver or some other pluggable/replaceable JSF thingy (ie. all the things you can replace via faces-config.xml) Problem here again is the name of such a lib: "myfaces-commons-base"? "myfaces-commons-core"? "myfaces-commons-super"? "myfaces-commons-commons"? ;-) The name MUST reflect the fact that this jar is a very basic lib all other JSF stuff depends on. It is no place where we swiftly drop some nice and convenient utils stuff and the API is nothing to play around with. I think that if we find a good name and define some strict rules we could move most (or all?) stuff from myfaces-shared to this lib. And perhaps even get rid of shard in the long run! Of course, some well-known issues pop up immediately: which JSF-Spec - 1.1 and 1.2 or only 1.2? What about JSF 2.0? Thoughts? --Manfred On Tue, Apr 1, 2008 at 9:31 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > Just to reiterate: I hate shared! ;-) > > Seriously, it seems that Orchestra has to implement a StateManager which > holds the view state in the conversationContext instead of the session. > At the moment it seems that large portions of JspStateManagerImpl can be > reused, but requires to copy it over into Orchestra. > > With slight refactoring of JspStateManagerImpl it should be possible to > just replace the actual storing/loading stuff. > > Does this qualify to move JspStateManagerImpl into shared? Or should I > better copy the source over? > > Ciao, > Mario > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: JspStateManagerImpl into shared?
Mario Ivankovits schrieb: > Ping! > >> It seems that Orchestra has to implement a StateManager which >> holds the view state in the conversationContext instead of the session. >> At the moment it seems that large portions of JspStateManagerImpl can be >> reused, but requires to copy it over into Orchestra. >> >> With slight refactoring of JspStateManagerImpl it should be possible to >> just replace the actual storing/loading stuff. >> >> Does this qualify to move JspStateManagerImpl into shared? Or should I >> better copy the source over? >> There are some jira issues and email threads that might be relevant: http://issues.apache.org/jira/browse/MYFACES-1791 http://issues.apache.org/jira/browse/TRINIDAD-816 http://www.nabble.com/state-saving-%28StateManager%29-and-multiple-frames-%28HACKATHON-points-4-and-6%29-td13913845.html http://www.nabble.com/RE%3A-Proposal-to-Externalize-the-ViewCache.-td13516998.html Regards, Simon
[jira] Resolved: (TOBAGO-642) Problem with SheetSelection-JavaScript
[
https://issues.apache.org/jira/browse/TOBAGO-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Schnurpfeil resolved TOBAGO-642.
Resolution: Fixed
Handling of the "seleced" was fixed:
Javacode on Server uses as format: e. g. ,1,2,3,4,
but the JavascriptCode uses ,1,,2,,3,,4, in that case.
The bug makes it possible that the upper sample will be modified to ,12,,3,,4,
which is totally wrong.
So, I've fixed the Javascript-Code with uses now the same format.
> Problem with SheetSelection-JavaScript
> --
>
> Key: TOBAGO-642
> URL: https://issues.apache.org/jira/browse/TOBAGO-642
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.15
>Reporter: Matthias Wronka
>Assignee: Udo Schnurpfeil
>Priority: Critical
> Fix For: 1.0.16, 1.1.0
>
>
> There is a problem in the JavaScript-Code, that handels the RowSelection
> within a sheet. In larger sheets the index exeeds the int-range and a
> NumberFormatException occurs. Apparently there is a problem with commata as
> seperators:
>
>key = component.getClientId(facesContext) + SELECTED_POSTFIX;
> if (requestParameterMap.containsKey(key)) {
> String selected = (String) requestParameterMap.get(key);
> if (LOG.isDebugEnabled()) {
> LOG.debug("selected = " + selected);
> }
> List selectedRows;
> try {
> selectedRows = StringUtil.parseIntegerList(selected);
> } catch (NumberFormatException e) {
> LOG.warn(selected, e);
> selectedRows = Collections.emptyList();
> }
> component.getAttributes().put(
> ATTR_SELECTED_LIST_STRING, selectedRows);
> }
>
> [3/19/08 17:17:06:369 CET] 0e88 AjaxUtils I
> org.apache.myfaces.tobago.ajax.api.AjaxUtils parseAndStoreComponents
> ajaxComponentIds = "main:DokumenteSheet2"
> [3/19/08 17:17:06:397 CET] 0e88 AjaxUtils I
> org.apache.myfaces.tobago.ajax.api.AjaxUtils parseAndStoreComponents
> ajaxComponent for "main:DokumenteSheet2" = "[EMAIL PROTECTED]"
> [3/19/08 17:17:06:416 CET] 0e88 UIDataI
> org.apache.myfaces.tobago.component.UIData queueEvent queueEvent = "[EMAIL
> PROTECTED]"
> [3/19/08 17:17:06:438 CET] 0e88 SheetRenderer W
> org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.SheetRenderer
> decode 1357911131517,18,19,20,21,22,
> java.lang.NumberFormatException: For input
> string: "1357911131517"
>at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java(Compiled
> Code))
>at java.lang.Integer.parseInt(Integer.java(Compiled Code))
>at java.lang.Integer.(Integer.java(Inlined Compiled
> Code))
>at
> org.apache.myfaces.tobago.util.StringUtil.parseIntegerList(StringUtil.java(Compiled
> Code))
>at
> org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.SheetRenderer.decode(SheetRenderer.java(Compiled
> Code))
>at
> javax.faces.component.UIComponentBase.decode(UIComponentBase.java(Compiled
> Code))
>at
> javax.faces.component.UIData.processDecodes(UIData.java(Compiled Code))
>at
> org.apache.myfaces.tobago.util.ApplyRequestValuesCallback.execute(ApplyRequestValuesCallback.java:34)
>at
> org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
> Code))
>at
> org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
> Compiled Code))
>at
> org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
> Code))
>at
> org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
> Compiled Code))
>at
> org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
> Code))
>at
> org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
> Compiled Code))
>at
> org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
> Code))
>at
> org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
> Compiled Code))
>at
> org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
> Code))
>at
> org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
> Compiled Code))
>at
> org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
> Code))
>
[jira] Commented: (MYFACES-1326) adding metadata to jsf standard components, shipped by myfaces
[ https://issues.apache.org/jira/browse/MYFACES-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584528#action_12584528 ] Simon Kitching commented on MYFACES-1326: - Matthias, what sort of metadata do you mean here? Is there some standard format? > adding metadata to jsf standard components, shipped by myfaces > -- > > Key: MYFACES-1326 > URL: https://issues.apache.org/jira/browse/MYFACES-1326 > Project: MyFaces Core > Issue Type: Improvement >Reporter: Matthias Weßendorf > > adding metadata makes it much more convenient to use MyFaces with specialized > JSF editors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JspStateManagerImpl into shared?
Ping! > It seems that Orchestra has to implement a StateManager which > holds the view state in the conversationContext instead of the session. > At the moment it seems that large portions of JspStateManagerImpl can be > reused, but requires to copy it over into Orchestra. > > With slight refactoring of JspStateManagerImpl it should be possible to > just replace the actual storing/loading stuff. > > Does this qualify to move JspStateManagerImpl into shared? Or should I > better copy the source over? > Ciao, Mario
[jira] Commented: (TOMAHAWK-843) myfaces not releasing memory gracefully?
[ https://issues.apache.org/jira/browse/TOMAHAWK-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584500#action_12584500 ] Simon Kitching commented on TOMAHAWK-843: - One thing I see from the UIData implementation is that it does keep a reference to the DataModel in a member of the UIData class. It does not save this in its saveState method, ie this is effectively a "transient" member - providing the saveState/restoreState methods are used. They are always used for client-side state. And they are called by default in at least the most recent myfaces versions (SERIALIZE_STATE_IN_SESSION=true); see JspStateManagerImpl. But I think that in some older versions it was not the default. And in that case, a reference to the DataModel would be held until the UIData component was garbage-collected, even for a read-only table. > myfaces not releasing memory gracefully? > > > Key: TOMAHAWK-843 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-843 > Project: MyFaces Tomahawk > Issue Type: Bug >Affects Versions: 1.1.3 > Environment: tomcat 5.5.12 >Reporter: Dez > > Hi, > I've been using Myfaces implementation of JSF for couple of months and > just noticed that memory usage is pretty high - > many times I got out of > memory error. It works fine for simple pages, but when the page is large and > complex, it doesn't seem to release the memory used by component states. > Here is the scenario: > I'm using t:datatable for rendering employees info. Each row corresponds to > a employee object, the row has 10 columns. > It works fine in terms of memory footprint and CPU, when the dataset the > table renders is small, but when the size of the datasets is large(talking > about 500 or more), I get Out of memory error even though the Managed Bean > is request-scoped. No pagination being employed(that's the last resort). So > when the number of user increases, this leads to a serious issues of server > crash, hang etc. >On profiling using yourtoolkit, I found that faces context never releases > the memory used by UI Components and the behaviour is erratic. The GC kicks > in after certain stage which is not very useful. Even for a table of small > data rows(20-30), it doesn't seem to release the memory, in fact it > accumulates the memory. > So even the pagination doesn't seem to solve the out- of- memory issue as > the web site will be used by large number of users. FYI, I'm using the > client STATE_SAVING_METHOD. > > javax.faces.STATE_SAVING_METHOD > client > > Has anyone faced similar issues? Is this a bug or known issues of myfaces? > No one seem to have resolved this issues, I did see similar issues being > posted in different forums. > Would appreciate your help in this regard. > thanks > Dezmax -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-843) myfaces not releasing memory gracefully?
[ https://issues.apache.org/jira/browse/TOMAHAWK-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584486#action_12584486 ] Simon Kitching commented on TOMAHAWK-843: - Are you using session-scoped backing beans and component bindings? If so, then that would cause this problem. And the solution is - don't do that. MyFaces has been used by some people for large projects, so this is a problem that is only occuring in some webapps. I'm not saying that there is not a bug, but that it does not always happen. If you can attach to this issue a simple webapp that demonstrates this problem (or even better, a junit test case that demonstrates it) then it will get attention much faster than if a myfaces developer has to spend time trying to duplicate this problem on their own... Re: "not releasing UIComponent memory": When using server-side state-saving, MyFaces keeps a set of the most recent N views cached in order to support back-button usage. The default value for N is 20. It keeps extra views in a weakly-referenced cache which might also show up in profiling, but is not "real" memory use as it will be released if memory is needed elsewhere. This default value of "20" can be configured - although of course less back-button presses are then supported. All this is not relevant if client-side state saving is used; in that case it is up to the browser to cache old data if it wants back-button to work. Re: "data table uses lots of memory" PageContextImpl would be an interesting class to be hogging memory: that is a JSP tag support class, not a JSF class (it is in org.apache.taglibs.*). Does anyone know what the role and lifecycle of a PageContext class is? Are the tables you are having problems with "display-only", or do they contain input components? A UIData component does not keep a reference to its DataModel object, but the tree does keep the internal state of any input components. > myfaces not releasing memory gracefully? > > > Key: TOMAHAWK-843 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-843 > Project: MyFaces Tomahawk > Issue Type: Bug >Affects Versions: 1.1.3 > Environment: tomcat 5.5.12 >Reporter: Dez > > Hi, > I've been using Myfaces implementation of JSF for couple of months and > just noticed that memory usage is pretty high - > many times I got out of > memory error. It works fine for simple pages, but when the page is large and > complex, it doesn't seem to release the memory used by component states. > Here is the scenario: > I'm using t:datatable for rendering employees info. Each row corresponds to > a employee object, the row has 10 columns. > It works fine in terms of memory footprint and CPU, when the dataset the > table renders is small, but when the size of the datasets is large(talking > about 500 or more), I get Out of memory error even though the Managed Bean > is request-scoped. No pagination being employed(that's the last resort). So > when the number of user increases, this leads to a serious issues of server > crash, hang etc. >On profiling using yourtoolkit, I found that faces context never releases > the memory used by UI Components and the behaviour is erratic. The GC kicks > in after certain stage which is not very useful. Even for a table of small > data rows(20-30), it doesn't seem to release the memory, in fact it > accumulates the memory. > So even the pagination doesn't seem to solve the out- of- memory issue as > the web site will be used by large number of users. FYI, I'm using the > client STATE_SAVING_METHOD. > > javax.faces.STATE_SAVING_METHOD > client > > Has anyone faced similar issues? Is this a bug or known issues of myfaces? > No one seem to have resolved this issues, I did see similar issues being > posted in different forums. > Would appreciate your help in this regard. > thanks > Dezmax -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-843) myfaces not releasing memory gracefully?
[ https://issues.apache.org/jira/browse/TOMAHAWK-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584472#action_12584472 ] Thomas Jonsson commented on TOMAHAWK-843: - Hi, I'm also facing the same problem. When rendering a data table memory is allocated that doesn't get gc:d. The class consuming the memory is PageContextImpl. Is there any solution? /Thomas > myfaces not releasing memory gracefully? > > > Key: TOMAHAWK-843 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-843 > Project: MyFaces Tomahawk > Issue Type: Bug >Affects Versions: 1.1.3 > Environment: tomcat 5.5.12 >Reporter: Dez > > Hi, > I've been using Myfaces implementation of JSF for couple of months and > just noticed that memory usage is pretty high - > many times I got out of > memory error. It works fine for simple pages, but when the page is large and > complex, it doesn't seem to release the memory used by component states. > Here is the scenario: > I'm using t:datatable for rendering employees info. Each row corresponds to > a employee object, the row has 10 columns. > It works fine in terms of memory footprint and CPU, when the dataset the > table renders is small, but when the size of the datasets is large(talking > about 500 or more), I get Out of memory error even though the Managed Bean > is request-scoped. No pagination being employed(that's the last resort). So > when the number of user increases, this leads to a serious issues of server > crash, hang etc. >On profiling using yourtoolkit, I found that faces context never releases > the memory used by UI Components and the behaviour is erratic. The GC kicks > in after certain stage which is not very useful. Even for a table of small > data rows(20-30), it doesn't seem to release the memory, in fact it > accumulates the memory. > So even the pagination doesn't seem to solve the out- of- memory issue as > the web site will be used by large number of users. FYI, I'm using the > client STATE_SAVING_METHOD. > > javax.faces.STATE_SAVING_METHOD > client > > Has anyone faced similar issues? Is this a bug or known issues of myfaces? > No one seem to have resolved this issues, I did see similar issues being > posted in different forums. > Would appreciate your help in this regard. > thanks > Dezmax -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1847) View to be restored was removed and cannot be retrieved from the map (JspStatemanagerImpl)
View to be restored was removed and cannot be retrieved from the map
(JspStatemanagerImpl)
--
Key: MYFACES-1847
URL: https://issues.apache.org/jira/browse/MYFACES-1847
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.6-SNAPSHOT
Environment: WinXP, Weblogic 9.2
Reporter: Mohamed Thowbick
Priority: Critical
Affected version: myfaces-impl-1.1.6-SNAPSHOT.jar
We have an web application which used myfaces,tomahawk and freemarker. The
manin page of the application is been divided into 3 parts (Top Menu links),
Tree menu (Left frame) and selected page to be displayed on the right side
frame.
During the module test, we observed that myfaces is creating two serialized
views. One for the left side tree2 menu jsf and the other for right side
content jsf corresponding to the report item selected. Since the default number
of views in the session is 20, myfaces will remove the weak referenced view if
the number of views in the session exceeds the threshold. So we have done some
regression on the tree menu items which had created more than 20 views. But the
wierd thing is, it has removed the serialized view of the tree2 jsf in the mid
of regression which was created in the initial stage and supposed to be made
available in the map and to be restored when the other report menu items are
selected. Due to this bug, our application is displaying the tree2 menu in the
right side frame as well. We have to refresh/reload the page to get out of this
issue.
When the other report items are selected, the application is trying to get the
view from the serialized map but due to the bug in the code it's unable to find
the view which was removed earlier and prints the message
Exiting restoreTreeStructure - No serialized view found in server session!
Below is the suspected code snippet from
JspStatemanagerImpl$SerializedViewCollection class
while (_keys.remove(key)) ;
_keys.add(key);
int views = getNumberOfViewsInSession(context);
while (_keys.size() > views) {
key = _keys.remove(0);//View will be removed here
Object oldView = _serializedViews.remove(key);
if (oldView != null) {
getOldSerializedViewsMap().put(key, oldView);
}
}
Did anyone ever faced the same issue and managed to fix?
I hope someone out there might be able to help me out of this issue. I
understand that there were some out of memory and perfomance issues in
JspStatemanagerImpl of release myfaces-impl-1.1.6-SNAPSHOT which was fixed in
myfaces-impl-1.2.X. But to use myfaces-impl-1.2.X, we should run the
application in a server which supports JSP 2.1. We are using weblogic 9.2 which
has JSP 2.0 container.
I am currently working on this issue to avoid removing the view which is to be
restored later for release myfaces-impl-1.1.6-SNAPSHOT.
Let me know if further details required.
Would greatly appreciate if anyone help me out on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOBAGO-619) Avoid usages of javascript:false in iframe src attribute
[ https://issues.apache.org/jira/browse/TOBAGO-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-619. -- Resolution: Fixed > Avoid usages of javascript:false in iframe src attribute > > > Key: TOBAGO-619 > URL: https://issues.apache.org/jira/browse/TOBAGO-619 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Themes >Affects Versions: 1.0.14 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 1.0.16, 1.1.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-639) Optimize layout token parsing
[ https://issues.apache.org/jira/browse/TOBAGO-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-639. -- Resolution: Fixed > Optimize layout token parsing > - > > Key: TOBAGO-639 > URL: https://issues.apache.org/jira/browse/TOBAGO-639 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.15 >Reporter: Arvid Hülsebus >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 1.0.16, 1.1.0 > > > Avoid usage of implicit regular expressions in parsing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-18) Cannot get access-scoped beans from a servlet
Cannot get access-scoped beans from a servlet
-
Key: ORCHESTRA-18
URL: https://issues.apache.org/jira/browse/ORCHESTRA-18
Project: MyFaces Orchestra
Issue Type: Bug
Affects Versions: 1.1
Reporter: Simon Kitching
As reported by Stephan Frai:
A servlet does this:
ApplicationContext appContext =
WebApplicationContextUtils.getWebApplicationContext(getServletContext());
PwdForgottenJSF pwdForgottenBean = (PwdForgottenJSF)
appContext.getBean("pwdForgottenJSF");
web.xml is set up to correctly map a BasicFrameworkAdapter to the current
request.
But when pwdForgottenJSF is access-scoped, then this occurs:
SCHWERWIEGEND: Servlet.service() for servlet ControllerServlet threw exception
java.lang.IllegalArgumentException: No AccessScopeManager found.
at ...conversation.AccessScopeManager.getInstance(AccessScopeManager.java:97)
at
...conversation.ConversationAccessLifetimeAspect.markAsAccessed(ConversationAccessLifetimeAspect.java:35)
at
...conversation.spring.SpringConversationScope.notifyAccessConversation(SpringConversationScope.java:194)
at
conversation.spring.AbstractSpringOrchestraScope.getRealBean(AbstractSpringOrchestraScope.java:333)
The problem is that the AccessScopeManager.getInstance method calls
frameworkAdapter.getBean(), but a BasicFrameworkAdapter has no knowledge of
Spring; it just looks up request/session/application scopes.
A possible workaround is for the servlet to manually fetch the
AccessScopeManager instance and store it in the request scope.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-642) Problem with SheetSelection-JavaScript
Problem with SheetSelection-JavaScript
--
Key: TOBAGO-642
URL: https://issues.apache.org/jira/browse/TOBAGO-642
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 1.0.15
Reporter: Matthias Wronka
There is a problem in the JavaScript-Code, that handels the RowSelection within
a sheet. In larger sheets the index exeeds the int-range and a
NumberFormatException occurs. Apparently there is a problem with commata as
seperators:
key = component.getClientId(facesContext) + SELECTED_POSTFIX;
if (requestParameterMap.containsKey(key)) {
String selected = (String) requestParameterMap.get(key);
if (LOG.isDebugEnabled()) {
LOG.debug("selected = " + selected);
}
List selectedRows;
try {
selectedRows = StringUtil.parseIntegerList(selected);
} catch (NumberFormatException e) {
LOG.warn(selected, e);
selectedRows = Collections.emptyList();
}
component.getAttributes().put(
ATTR_SELECTED_LIST_STRING, selectedRows);
}
[3/19/08 17:17:06:369 CET] 0e88 AjaxUtils I
org.apache.myfaces.tobago.ajax.api.AjaxUtils parseAndStoreComponents
ajaxComponentIds = "main:DokumenteSheet2"
[3/19/08 17:17:06:397 CET] 0e88 AjaxUtils I
org.apache.myfaces.tobago.ajax.api.AjaxUtils parseAndStoreComponents
ajaxComponent for "main:DokumenteSheet2" = "[EMAIL PROTECTED]"
[3/19/08 17:17:06:416 CET] 0e88 UIDataI
org.apache.myfaces.tobago.component.UIData queueEvent queueEvent = "[EMAIL
PROTECTED]"
[3/19/08 17:17:06:438 CET] 0e88 SheetRenderer W
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.SheetRenderer
decode 1357911131517,18,19,20,21,22,
java.lang.NumberFormatException: For input
string: "1357911131517"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java(Compiled
Code))
at java.lang.Integer.parseInt(Integer.java(Compiled Code))
at java.lang.Integer.(Integer.java(Inlined Compiled
Code))
at
org.apache.myfaces.tobago.util.StringUtil.parseIntegerList(StringUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.SheetRenderer.decode(SheetRenderer.java(Compiled
Code))
at
javax.faces.component.UIComponentBase.decode(UIComponentBase.java(Compiled
Code))
at
javax.faces.component.UIData.processDecodes(UIData.java(Compiled Code))
at
org.apache.myfaces.tobago.util.ApplyRequestValuesCallback.execute(ApplyRequestValuesCallback.java:34)
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIForm(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.prepareOnUIComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOrPrepare(ComponentUtil.java(Compiled
Code))
at
org.apache.myfaces.tobago.component.ComponentUtil.invokeOnComponent(ComponentUtil.java(Inlined
Compiled Code))
at
org.apache.myfaces.tobago.lifecycle.ApplyRequestValuesExecutor.execute(ApplyRequestValuesExecutor.java(Compiled
Code))
at
org.apa
Re: MyfacesBuilderPlugin
Leonardo Uribe schrieb: > Hi > > The problem with xml files to make faces-plugin test work is now fixed. Great. > > I have a question about how myfaces-metadata works. > > The idea is have one file per jar, and when the model is readed, it > should scan every artifact and merge it with the generated > myfaces-metadata.xml. I'm right or wrong (This is what I'm doing right > now, and in my opinion is the preferred way)? I'm not quite clear what your description above means. I think we are talking about the same thing, but just to be clear this is how I would see it working: == for goal build-metadata: start with an empty model for each jarfile containing a META-INF/myfaces-metadata.xml file read that myfaces-metadata.xml file add the resulting objects into the model[1] run the ModelBuilder for the current project, which adds more objects to the model save the model into META-INF/myfaces-metadata.xml in the current project An alternative would be to do the merging just at the xml level, then build a model from the resulting merged xml file. That also seems reasonable. == for other goals (eg generate faces.xml, generate tag classes): start with an empty model read META-INF/myfaces-metadata.xml for the current project only add the resulting objects to the model pass the model object to the appropriate generator class[3] [1] Hmm..might need to somehow detect and handle duplicate data. In particular, tomahawk will depend on both myfaces-api and myfaces-impl. But the META-INF/myfaces-metadata.xml file will have a copy of all the data from the myfaces-metadata.xml contained in myfaces-api jarfile. So if *all* jars in the classpath are processed, the data from myfaces-api.jar will be processed twice. Options I see are (a) don't worry; the data will just be identical (b) check that if a model object is being overwritten, the new data is identical (c) have the plugin configured with an explicit list of jars to process metadata from. Then in the pom it must be configured so that myfaces-impl is processed and myfaces-api is ignored. Then make it an error for the same model object to be defined twice. (d) have a myfaces-metadata.xml file *not* include data inherited from parent projects. That's cleaner in a way, but means that when processing other goals we cannot just load the metadata file from the local project but need to merge in all the ancestor projects too. Ecch. (e) in the myfaces-metadata.xml, somehow mark entries with the jarfile they came from. Option (c) is probably the safest..and not too complicated. [2] eg something that executes a velocity template against the model Regards, Simon
