You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Sebastian Hennebrueder <us...@laliluna.de> on 2009/09/21 11:33:29 UTC
Resource access problem, alternative packaging
Hello,
while reading through the JSF 2 spec I found the packaging instruction
of resources.
JSF 2 will allow to pack any kind of resources in a dedicated directory
'resources'.
META-INF/resources/<resourceIdentifier>
If we would follow this approach, we could get rid of the access problem
immediately without the need of a request filter.
What do you think?
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Resource access problem, alternative packaging
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 22 Sep 2009 10:45:58 -0300, Sebastian Hennebrueder
<us...@laliluna.de> escreveu:
> I think it would. hibernate.cfg.xml is in the class path whereas all
> public resources are in
> META-INF/resources. Basically we stop serving directly from the
> classpath but instead deliver content using META-INF/resources as root.
If hibernate.cfg.xml stays in the classpath, your proposed solution does
not solve the problem.
For public resources, putting them in the classpath isn't a problem at all
and makes it very simple for packages to provide their resources (images,
for example). If put in META-INF/resources, Tapestry would need to write
new code to handle them and time is scarce for the committers. As it would
not solve the original problem (configuration files being acessible in the
internet), I don't think it's a good idea.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Resource access problem, alternative packaging
Posted by Sebastian Hennebrueder <us...@laliluna.de>.
Thiago H. de Paula Figueiredo schrieb:
> Em Mon, 21 Sep 2009 06:33:29 -0300, Sebastian Hennebrueder
> <us...@laliluna.de> escreveu:
>
>> Hello,
>
> Hi!
>
>> while reading through the JSF 2 spec I found the packaging instruction
>> of resources.
>> JSF 2 will allow to pack any kind of resources in a dedicated
>> directory 'resources'.
>>
>> META-INF/resources/<resourceIdentifier>
>>
>> If we would follow this approach, we could get rid of the access
>> problem immediately without the need of a request filter.
>>
>> What do you think?
>
> It won't solve the problem, as files that need to go to the classpath
> (hibernate.cfg.xml, for example) will still be downloadable.
>
I think it would. hibernate.cfg.xml is in the class path whereas all
public resources are in
META-INF/resources. Basically we stop serving directly from the
classpath but instead deliver content using META-INF/resources as root.
If you want to have something public available you put it in there.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Resource access problem, alternative packaging
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 21 Sep 2009 06:33:29 -0300, Sebastian Hennebrueder
<us...@laliluna.de> escreveu:
> Hello,
Hi!
> while reading through the JSF 2 spec I found the packaging instruction
> of resources.
> JSF 2 will allow to pack any kind of resources in a dedicated directory
> 'resources'.
>
> META-INF/resources/<resourceIdentifier>
>
> If we would follow this approach, we could get rid of the access problem
> immediately without the need of a request filter.
>
> What do you think?
It won't solve the problem, as files that need to go to the classpath
(hibernate.cfg.xml, for example) will still be downloadable.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org