You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Oliver Rossmueller <ol...@tuxerra.com> on 2005/03/14 02:32:18 UTC
Split (or kill) Extensions filter
I'm no longer willing to pay the runtime penalty ExtensionFilter adds to
an application (javascript files loaded over and over again, in-memory
buffering of the complete response) just for the benefit of 10 minutes
of saved developer time for adding the javascript stuff to the header of
any jsf page.
So my plan is to split up ExtensionFilter to MultipartFilter (in the
form it was before ExtensionFilter was introduced) and ExtensionFilter
(just dealing with extensions stuff). Actually I would like to drop the
extensions stuff completely as I don't see any benefit in having this
kind of filter at hand. We could create a myfaces-resources.jar instead
where we place all the image and javascript resources so it's easy to
add all the resources to your war file by just adding a zipfileset tag
to your build file.
Comments? Objections?
Oliver
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Re: Split (or kill) Extensions filter
Posted by Martin Cooper <ma...@apache.org>.
On Mon, 14 Mar 2005, Sylvain Vieujot wrote:
> Yes, I don't think we should split off MultipartFilter from
> ExtensionsFilter, for several reasons :
>
> 1) It will require to set 2 filters, which goes against the main purpose
> of this filter, that is to keep things simple.
> 2) A nice feature with the ExtensionsFilter would be to ensure that the
> form has enctype="multipart/form-data" when it contains a file upload
> component.
>
> If the reason you want to do this is performance, did you do any
> benchmark ?
> I would guess that the ExtensionsFilter doesn't impact performance a
> lot.
> I even think it would rather improve the client overall response time as
> it includes the needed resources only when needed, and it (now) provides
> better client side caching.
> For example, if you have a page with a tab panel, and many components on
> each tab, as you switch tab, it will only include the needed resources.
> The only drawback of the filter is the in-memory buffering of the
> complete response, which is indeed a penalty for pages with no complex
> setup.
>
> If you really need a MultipartFilter only, I rather recommend adding a
> disableExtensions attribute to this filter, the same way it's done for
> the uploadMaxFileSize attribute.
Or you could base the filter on Commons Chain. This would give you a very
general-purpose extension mechanism, so that you could configure out
multipart of you don't need it, and configure in only what you need. No
special purpose code, but general extensibility for the future and for
custom applications.
--
Martin Cooper
> It keeps things simple while achieving the goal you have. Plus, it's
> very easy to do.
> You could also leave the ExtensionsFilter as it is, and write a stripped
> down version, handling only the Multipart stuffs.
> Anyway, I strongly think you should not oblige the user that still want
> to use the ExtensionsFilter to setup 2 filters (one for extensions and
> one for multipart).
>
> If you want to include the disableExtensions filter parameter, just tell
> me, I can do that quickly.
>
> Thanks,
>
> Sylvain.
>
> On Tue, 2005-03-15 at 02:50 +0100, Oliver Rossmueller wrote:
>
>> So from my POV there is consensus to split off MultipartFilter from
>> ExtensionsFilter as proposed but to keep ExtensionsFilter and give users
>> the choice to use it. If I missed an argument against the split please
>> let me know. Otherwise I'll do the split until the end of the week.
>>
>> Oliver
>>
>>
>> Oliver Rossmueller wrote:
>>
>>> I'm no longer willing to pay the runtime penalty ExtensionFilter adds
>>> to an application (javascript files loaded over and over again,
>>> in-memory buffering of the complete response) just for the benefit of
>>> 10 minutes of saved developer time for adding the javascript stuff to
>>> the header of any jsf page.
>>>
>>> So my plan is to split up ExtensionFilter to MultipartFilter (in the
>>> form it was before ExtensionFilter was introduced) and ExtensionFilter
>>> (just dealing with extensions stuff). Actually I would like to drop
>>> the extensions stuff completely as I don't see any benefit in having
>>> this kind of filter at hand. We could create a myfaces-resources.jar
>>> instead where we place all the image and javascript resources so it's
>>> easy to add all the resources to your war file by just adding a
>>> zipfileset tag to your build file.
>>>
>>> Comments? Objections?
>>>
>>> Oliver
>>>
>>
>>
>
Re: Split (or kill) Extensions filter
Posted by Sylvain Vieujot <sv...@apache.org>.
Please note that one other reason to keep the ExtensionsFilter is that
it provides great flexibility to upgrade the components, while keeping
transparent backward compatibility.
For example, with the htmlEditor, when a new version of kupu is
released, I can upgrade MyFaces' component with no problem for the
current applications.
Without this filter, it would be a nightmare, as the needed java scripts
changes (file names & content).
Another example is the calendar popup.
Moving to another implementation of the javascript part (as we plan it)
is a breeze. If the scripts had to be included in the clients
applications it wouldn't be that easy.
On Mon, 2005-03-14 at 22:35 -0400, Sylvain Vieujot wrote:
> Yes, I don't think we should split off MultipartFilter from
> ExtensionsFilter, for several reasons :
>
> 1) It will require to set 2 filters, which goes against the main
> purpose of this filter, that is to keep things simple.
> 2) A nice feature with the ExtensionsFilter would be to ensure that
> the form has enctype="multipart/form-data" when it contains a file
> upload component.
>
> If the reason you want to do this is performance, did you do any
> benchmark ?
> I would guess that the ExtensionsFilter doesn't impact performance a
> lot.
> I even think it would rather improve the client overall response time
> as it includes the needed resources only when needed, and it (now)
> provides better client side caching.
> For example, if you have a page with a tab panel, and many components
> on each tab, as you switch tab, it will only include the needed
> resources.
> The only drawback of the filter is the in-memory buffering of the
> complete response, which is indeed a penalty for pages with no complex
> setup.
>
> If you really need a MultipartFilter only, I rather recommend adding a
> disableExtensions attribute to this filter, the same way it's done for
> the uploadMaxFileSize attribute.
> It keeps things simple while achieving the goal you have. Plus, it's
> very easy to do.
> You could also leave the ExtensionsFilter as it is, and write a
> stripped down version, handling only the Multipart stuffs.
> Anyway, I strongly think you should not oblige the user that still
> want to use the ExtensionsFilter to setup 2 filters (one for
> extensions and one for multipart).
>
> If you want to include the disableExtensions filter parameter, just
> tell me, I can do that quickly.
>
> Thanks,
>
> Sylvain.
>
> On Tue, 2005-03-15 at 02:50 +0100, Oliver Rossmueller wrote:
>
> > So from my POV there is consensus to split off MultipartFilter from
> > ExtensionsFilter as proposed but to keep ExtensionsFilter and give users
> > the choice to use it. If I missed an argument against the split please
> > let me know. Otherwise I'll do the split until the end of the week.
> >
> > Oliver
> >
> >
> > Oliver Rossmueller wrote:
> >
> > > I'm no longer willing to pay the runtime penalty ExtensionFilter adds
> > > to an application (javascript files loaded over and over again,
> > > in-memory buffering of the complete response) just for the benefit of
> > > 10 minutes of saved developer time for adding the javascript stuff to
> > > the header of any jsf page.
> > >
> > > So my plan is to split up ExtensionFilter to MultipartFilter (in the
> > > form it was before ExtensionFilter was introduced) and ExtensionFilter
> > > (just dealing with extensions stuff). Actually I would like to drop
> > > the extensions stuff completely as I don't see any benefit in having
> > > this kind of filter at hand. We could create a myfaces-resources.jar
> > > instead where we place all the image and javascript resources so it's
> > > easy to add all the resources to your war file by just adding a
> > > zipfileset tag to your build file.
> > >
> > > Comments? Objections?
> > >
> > > Oliver
> > >
> >
> >
Re: Split (or kill) Extensions filter
Posted by Sylvain Vieujot <sv...@apache.org>.
Yes, I don't think we should split off MultipartFilter from
ExtensionsFilter, for several reasons :
1) It will require to set 2 filters, which goes against the main purpose
of this filter, that is to keep things simple.
2) A nice feature with the ExtensionsFilter would be to ensure that the
form has enctype="multipart/form-data" when it contains a file upload
component.
If the reason you want to do this is performance, did you do any
benchmark ?
I would guess that the ExtensionsFilter doesn't impact performance a
lot.
I even think it would rather improve the client overall response time as
it includes the needed resources only when needed, and it (now) provides
better client side caching.
For example, if you have a page with a tab panel, and many components on
each tab, as you switch tab, it will only include the needed resources.
The only drawback of the filter is the in-memory buffering of the
complete response, which is indeed a penalty for pages with no complex
setup.
If you really need a MultipartFilter only, I rather recommend adding a
disableExtensions attribute to this filter, the same way it's done for
the uploadMaxFileSize attribute.
It keeps things simple while achieving the goal you have. Plus, it's
very easy to do.
You could also leave the ExtensionsFilter as it is, and write a stripped
down version, handling only the Multipart stuffs.
Anyway, I strongly think you should not oblige the user that still want
to use the ExtensionsFilter to setup 2 filters (one for extensions and
one for multipart).
If you want to include the disableExtensions filter parameter, just tell
me, I can do that quickly.
Thanks,
Sylvain.
On Tue, 2005-03-15 at 02:50 +0100, Oliver Rossmueller wrote:
> So from my POV there is consensus to split off MultipartFilter from
> ExtensionsFilter as proposed but to keep ExtensionsFilter and give users
> the choice to use it. If I missed an argument against the split please
> let me know. Otherwise I'll do the split until the end of the week.
>
> Oliver
>
>
> Oliver Rossmueller wrote:
>
> > I'm no longer willing to pay the runtime penalty ExtensionFilter adds
> > to an application (javascript files loaded over and over again,
> > in-memory buffering of the complete response) just for the benefit of
> > 10 minutes of saved developer time for adding the javascript stuff to
> > the header of any jsf page.
> >
> > So my plan is to split up ExtensionFilter to MultipartFilter (in the
> > form it was before ExtensionFilter was introduced) and ExtensionFilter
> > (just dealing with extensions stuff). Actually I would like to drop
> > the extensions stuff completely as I don't see any benefit in having
> > this kind of filter at hand. We could create a myfaces-resources.jar
> > instead where we place all the image and javascript resources so it's
> > easy to add all the resources to your war file by just adding a
> > zipfileset tag to your build file.
> >
> > Comments? Objections?
> >
> > Oliver
> >
>
>
Re: Split (or kill) Extensions filter
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
So from my POV there is consensus to split off MultipartFilter from
ExtensionsFilter as proposed but to keep ExtensionsFilter and give users
the choice to use it. If I missed an argument against the split please
let me know. Otherwise I'll do the split until the end of the week.
Oliver
Oliver Rossmueller wrote:
> I'm no longer willing to pay the runtime penalty ExtensionFilter adds
> to an application (javascript files loaded over and over again,
> in-memory buffering of the complete response) just for the benefit of
> 10 minutes of saved developer time for adding the javascript stuff to
> the header of any jsf page.
>
> So my plan is to split up ExtensionFilter to MultipartFilter (in the
> form it was before ExtensionFilter was introduced) and ExtensionFilter
> (just dealing with extensions stuff). Actually I would like to drop
> the extensions stuff completely as I don't see any benefit in having
> this kind of filter at hand. We could create a myfaces-resources.jar
> instead where we place all the image and javascript resources so it's
> easy to add all the resources to your war file by just adding a
> zipfileset tag to your build file.
>
> Comments? Objections?
>
> Oliver
>
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Added caching to the Extensions filter
Posted by Sylvain Vieujot <sv...@apache.org>.
As I couldn't get the jar Implementation Version.
So, I implemented this by adding a cacheKey that's generated during the
build.
It isn't as elegant as getting it from the jar's manifest, but it works.
Re: Split (or kill) Extensions filter
Posted by Sylvain Vieujot <sv...@apache.org>.
Thanks Manfred,
I'll look at this, and try to replace the code I just commited bu
something using this.
Sylvain.
On Mon, 2005-03-14 at 18:05 +0100, Manfred Geiler wrote:
> Sylvain Vieujot schrieb:
> > By the way, does someone know how to get the Implementation Version from
> > the jar file ?
> > I used implementationHash =
> > AddResource.class.getPackage().getImplementationVersion().hashCode();
> > but the getImplementationVersion return null.
>
> You mean the ImplementationVersion from the Manifest?
>
> Try to get the META-INF/MANIFEST.MF file through an InputStream. Have a
> look at the FacesConfigurator. It does something similar for
> "META-INF/faces-config.xml".
> Once you have the InputStream try the following:
>
> Manifest manifest = new Manifest(is);
> Attributes attributes = manifest.getAttributes("myfaces.apache.org");
> version = attributes.getValue(Attributes.Name.IMPLEMENTATION_VERSION);
>
> HTH,
> Manfred
Re: Split (or kill) Extensions filter
Posted by Sylvain Vieujot <sv...@apache.org>.
I just checked this, but it doesn't appear to help much :-(
Indeed, in FacesConfigurator , the file is at a known place (much like a
resource, or the .properties file I'm using now).
My problem is getting the MANIFEST.MF URL.
Plus, as you may use more than 1 MyFaces jar files (implementation,
extensions, ...), I wonder if this approach would even work.
Thanks anyway.
Sylvain.
On Mon, 2005-03-14 at 18:05 +0100, Manfred Geiler wrote:
> Sylvain Vieujot schrieb:
> > By the way, does someone know how to get the Implementation Version from
> > the jar file ?
> > I used implementationHash =
> > AddResource.class.getPackage().getImplementationVersion().hashCode();
> > but the getImplementationVersion return null.
>
> You mean the ImplementationVersion from the Manifest?
>
> Try to get the META-INF/MANIFEST.MF file through an InputStream. Have a
> look at the FacesConfigurator. It does something similar for
> "META-INF/faces-config.xml".
> Once you have the InputStream try the following:
>
> Manifest manifest = new Manifest(is);
> Attributes attributes = manifest.getAttributes("myfaces.apache.org");
> version = attributes.getValue(Attributes.Name.IMPLEMENTATION_VERSION);
>
> HTH,
> Manfred
Re: Split (or kill) Extensions filter
Posted by Manfred Geiler <ma...@apache.org>.
Sylvain Vieujot schrieb:
> By the way, does someone know how to get the Implementation Version from
> the jar file ?
> I used implementationHash =
> AddResource.class.getPackage().getImplementationVersion().hashCode();
> but the getImplementationVersion return null.
You mean the ImplementationVersion from the Manifest?
Try to get the META-INF/MANIFEST.MF file through an InputStream. Have a
look at the FacesConfigurator. It does something similar for
"META-INF/faces-config.xml".
Once you have the InputStream try the following:
Manifest manifest = new Manifest(is);
Attributes attributes = manifest.getAttributes("myfaces.apache.org");
version = attributes.getValue(Attributes.Name.IMPLEMENTATION_VERSION);
HTH,
Manfred
Re: Split (or kill) Extensions filter
Posted by Sylvain Vieujot <sv...@apache.org>.
I use the extensions filter A LOT, and I think it's quite useful when
you have to deal with complex pages.
The biggest drawback it has in that the resources aren't cached. I
started to work on that this week-end, and hope to have this resolved
during the week.
If you want to explicitly disable it, I've no problem with that, but
please don't remove it.
It would make it almost impossible for me to maintain all the
javascripts for the components in both MyFaces and my applications.
Thanks,
Sylvain.
By the way, does someone know how to get the Implementation Version from
the jar file ?
I used implementationHash = AddResource.class.getPackage
().getImplementationVersion().hashCode();
but the getImplementationVersion return null.
On Mon, 2005-03-14 at 00:38 -0500, Sean Schofield wrote:
> I agree with Kalle that the extension filter is kind of cool. It has
> its drawbacks sure but I wouldn't throw it out just because there is a
> few issues. Perhaps we could split it apart in the manner that Oliver
> or Martin are suggesting. In tree2 I provide the user the option of
> using the extension filter or specifying their own locations for
> javascript and images. Ultimately the more choices the user has the
> better.
>
> sean
>
>
> On Sun, 13 Mar 2005 21:20:14 -0800 (PST), Martin Cooper
> <ma...@apache.org> wrote:
> > First off, I know next to nothing about this filter, other than reading a
> > few messages on this list, so feel free to take my comments with a grain
> > of salt. ;-)
> >
> > You could consider the approach that I believe Shale is taking, and base
> > the filter on Commons Chain. This lets people (a) configure only the
> > commands they need for a given application, and (b) write additional
> > commands to be plugged into the filter very easily.
> >
> > For the issue of JavaScript files mentioned below, there are a couple of
> > things that can be done. First off is to ensure that the browser caches
> > the JavaScript once it has it. Secondly, a very nice trick that Isomorphic
> > SmartClient uses is that a filter sits there waiting for requests for .js
> > files, and looks for a corresponding .js.gz file, returning that instead
> > if the browser supports gzip encoding. These two techniques, taken
> > together, resulted in massive performance gains in one of our
> > applications.
> >
> > My 2 cents...
> >
> > --
> > Martin Cooper
> >
> >
> > On Mon, 14 Mar 2005, Oliver Rossmueller wrote:
> >
> > > I'm no longer willing to pay the runtime penalty ExtensionFilter adds to an
> > > application (javascript files loaded over and over again, in-memory buffering
> > > of the complete response) just for the benefit of 10 minutes of saved
> > > developer time for adding the javascript stuff to the header of any jsf page.
> > >
> > > So my plan is to split up ExtensionFilter to MultipartFilter (in the form it
> > > was before ExtensionFilter was introduced) and ExtensionFilter (just dealing
> > > with extensions stuff). Actually I would like to drop the extensions stuff
> > > completely as I don't see any benefit in having this kind of filter at hand.
> > > We could create a myfaces-resources.jar instead where we place all the image
> > > and javascript resources so it's easy to add all the resources to your war
> > > file by just adding a zipfileset tag to your build file.
> > >
> > > Comments? Objections?
> > >
> > > Oliver
> > >
> > > --
> > > Oliver Rossmueller
> > > Software Engineer and IT-Consultant
> > > Hamburg, Germany
> > > http://www.rossmueller.com
> > >
> > >
> >
Re: Split (or kill) Extensions filter
Posted by Sean Schofield <se...@gmail.com>.
I agree with Kalle that the extension filter is kind of cool. It has
its drawbacks sure but I wouldn't throw it out just because there is a
few issues. Perhaps we could split it apart in the manner that Oliver
or Martin are suggesting. In tree2 I provide the user the option of
using the extension filter or specifying their own locations for
javascript and images. Ultimately the more choices the user has the
better.
sean
On Sun, 13 Mar 2005 21:20:14 -0800 (PST), Martin Cooper
<ma...@apache.org> wrote:
> First off, I know next to nothing about this filter, other than reading a
> few messages on this list, so feel free to take my comments with a grain
> of salt. ;-)
>
> You could consider the approach that I believe Shale is taking, and base
> the filter on Commons Chain. This lets people (a) configure only the
> commands they need for a given application, and (b) write additional
> commands to be plugged into the filter very easily.
>
> For the issue of JavaScript files mentioned below, there are a couple of
> things that can be done. First off is to ensure that the browser caches
> the JavaScript once it has it. Secondly, a very nice trick that Isomorphic
> SmartClient uses is that a filter sits there waiting for requests for .js
> files, and looks for a corresponding .js.gz file, returning that instead
> if the browser supports gzip encoding. These two techniques, taken
> together, resulted in massive performance gains in one of our
> applications.
>
> My 2 cents...
>
> --
> Martin Cooper
>
>
> On Mon, 14 Mar 2005, Oliver Rossmueller wrote:
>
> > I'm no longer willing to pay the runtime penalty ExtensionFilter adds to an
> > application (javascript files loaded over and over again, in-memory buffering
> > of the complete response) just for the benefit of 10 minutes of saved
> > developer time for adding the javascript stuff to the header of any jsf page.
> >
> > So my plan is to split up ExtensionFilter to MultipartFilter (in the form it
> > was before ExtensionFilter was introduced) and ExtensionFilter (just dealing
> > with extensions stuff). Actually I would like to drop the extensions stuff
> > completely as I don't see any benefit in having this kind of filter at hand.
> > We could create a myfaces-resources.jar instead where we place all the image
> > and javascript resources so it's easy to add all the resources to your war
> > file by just adding a zipfileset tag to your build file.
> >
> > Comments? Objections?
> >
> > Oliver
> >
> > --
> > Oliver Rossmueller
> > Software Engineer and IT-Consultant
> > Hamburg, Germany
> > http://www.rossmueller.com
> >
> >
>
Re: Split (or kill) Extensions filter
Posted by Martin Cooper <ma...@apache.org>.
First off, I know next to nothing about this filter, other than reading a
few messages on this list, so feel free to take my comments with a grain
of salt. ;-)
You could consider the approach that I believe Shale is taking, and base
the filter on Commons Chain. This lets people (a) configure only the
commands they need for a given application, and (b) write additional
commands to be plugged into the filter very easily.
For the issue of JavaScript files mentioned below, there are a couple of
things that can be done. First off is to ensure that the browser caches
the JavaScript once it has it. Secondly, a very nice trick that Isomorphic
SmartClient uses is that a filter sits there waiting for requests for .js
files, and looks for a corresponding .js.gz file, returning that instead
if the browser supports gzip encoding. These two techniques, taken
together, resulted in massive performance gains in one of our
applications.
My 2 cents...
--
Martin Cooper
On Mon, 14 Mar 2005, Oliver Rossmueller wrote:
> I'm no longer willing to pay the runtime penalty ExtensionFilter adds to an
> application (javascript files loaded over and over again, in-memory buffering
> of the complete response) just for the benefit of 10 minutes of saved
> developer time for adding the javascript stuff to the header of any jsf page.
>
> So my plan is to split up ExtensionFilter to MultipartFilter (in the form it
> was before ExtensionFilter was introduced) and ExtensionFilter (just dealing
> with extensions stuff). Actually I would like to drop the extensions stuff
> completely as I don't see any benefit in having this kind of filter at hand.
> We could create a myfaces-resources.jar instead where we place all the image
> and javascript resources so it's easy to add all the resources to your war
> file by just adding a zipfileset tag to your build file.
>
> Comments? Objections?
>
> Oliver
>
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
>
>