Well, since you asked :-) I would be delighted if you would apply this patch:
https://issues.apache.org/jira/browse/TOMAHAWK-1249 Thanks! -Jan On Wed, Sep 3, 2008 at 10:40 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > > > On Wed, Sep 3, 2008 at 8:37 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote: >> >> https://issues.apache.org/jira/browse/TOMAHAWK-1323 is solved now. > > TOMAHAWK-1324 it is fixed right now too. > > If any developer in the community feels that something is missing to release > tomahawk, this is the right moment to talk and contribute. > > In this release there is a lot of changes and enhancements (about 227 issues > fixed). The full tag class and component class hierarchy was reorganized > according to myfaces-builder-plugin introduction (in clirr report almost all > binary incompatibilities are related to this fact), and a lot of code now is > generated to allow easy migration to 1.2. Facelets support was added too, > and required tag handler classes are now inside tomahawk. > > If no suggestions/objections, I'll try again a vote of this stuff soon. > > regards > > Leonardo Uribe > > >> >> On Thu, Sep 4, 2008 at 12:05 AM, simon <[EMAIL PROTECTED]> wrote: >>> >>> On Wed, 2008-09-03 at 04:06 -0500, Leonardo Uribe wrote: >>> >>> > >>> >>> > >>> > Ok, I understand the missing point. There are some config init params >>> > for use TomahawkFacesContextWrapper or not (this was discussed and >>> > solved). But it could be good to have config params for set the values >>> > used by TomahawkFacesContextWrapper for handle the multipart request >>> > case (what you are proposing in a difficult to understand way). >>> >>> Yes, that's what I meant. >>> >>> > >>> > One problem is do any cast to PortletContext to get the init param >>> > (any cast to PortletContext or any portlet class creates a requeriment >>> > portlet api when loading this class, so introduce >>> > ClassNotFoundExceptions on servlet environments). I believe it is >>> > possible to do this using reflection (or create a separate class that >>> > has the portlet api code, so it is only called when the app is on >>> > portlet environment). >>> >>> Yep, agreed. Some reflection stuff will probably be needed, but not too >>> complex. >>> >>> > Suggestions, patches and any help are welcome (if you want it do it >>> > yourself!). >>> >>> I'll do my best to find some time to help. I would love to see a >>> tomahawk release out, and know that you've already put a huge amount of >>> time into getting things into shape for a release. >>> >>> However I am really really busy at the moment, and can't promise a lot. >>> I have never written a Portlet before, so testing any patch that I >>> prepare would be tricky for a start... >>> >>> Just as a side note: when someone proposes a new feature, I agree that >>> the burden is on them to provide a patch. But this is a QA issue, which >>> is somewhat different; it's not entirely fair to people who have spent >>> time reviewing code to also be solely responsible for providing patches >>> for stuff they find. Reading patches is a thankless enough task without >>> that! >>> >>> But changing this after it is part of an official release will be >>> tricky/impossible without breaking backwards compatibility so it's >>> really worth doing now. >>> >>> Cheers, >>> Simon >>> >>> > >>> >> >> >> >> -- >> Hazem Ahmed Saleh Ahmed >> >> Web blog: http://www.jroller.com/page/HazemBlog >> >> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j: >> http://code.google.com/p/gmaps4jsf/ > >
