Re: assets caching T5.1
You're Looks like my WebKit browser is the reason. Safari 4 and Firefox 3 do not show this behaviour. I know that Safari is a WebKit based browser but I'm talking about the WebKit browser itself. Tracing the element loading in Safari 4 shows the far future expires header as expected. WebKit does not show this header and thus re-loads the asset on every page hit. M. Am 05.06.2009 um 00:03 schrieb Howard Lewis Ship: This is odd, it should be working out of the box. Perhaps the browser is the problem here. On Thu, Jun 4, 2009 at 11:25 AM, Joachim Van der Auwera wrote: Have you switched off production mode? Perhaps in 5.1, in dev mode we won't specify the far future expires header. In 5.1 I'm pretty sure that far future expires is in force regardless of production mode. Joachim Moritz Gmelin wrote: Hi, after updateing our application to T5.1 I was hoping for noticeable accelleration in loading of pages. However while checking the log output I can see that all the assets are requested from the browser on every loading of a page for example I can see this INFO: Request time: 0 ms, page:/assets/tapestry/5.1.0.5/corelib/components/sort-asc.png, free Memory:69704936 b, language = de_DE everytime I go to a page that contains a table with those sorting icons. And many other assets that do not really need to be re-loaded. I already set the tapestry.app-version property in my AppModule. The application is run on a TOMCAT server behind an apache Web- Server. What else do I need to do to prevent this? M. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Joachim Van der Auwera PROGS bvba, progs.be - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: tapestry-spring-security update
Em Thu, 04 Jun 2009 18:18:32 -0300, Robin Helgelin escreveu: Don't thank me, thank Michael, I'm just the messenger this time :) Thanks Michael for the code and Robin for bringing the good news! :) -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Re: [T5.1] How to break the chain in MasterDispatcher
Hi Christian,
Thanks for pointing me to the fact, that one can specify more than one
constraint. I have completely missed that (Should have taken a closer look to
the signature of the add-method;-)) ). In fact your suggestion solved my
problem.
Kind regards and sleep well, nillehammer
==
http://www.winfonet.eu
- original Nachricht
Betreff: Re: [T5.1] How to break the chain in MasterDispatcher
Gesendet: Fr, 05. Jun 2009
Von: Christian Senk
> Hi nille,
>
> i got the same problem. This part isn't good documented, look at this
> snippet from the TapestryModule:
>
> /**
> * The MasterDispatcher is a chain-of-command of individual Dispatchers,
> each handling (like a servlet) a particular
> * kind of incoming request. RootPath Renders the
> start page for the "/" request
> * Asset Provides access to classpath assets
> VirtualAsset Provides access to combined
> * scripts PageRender Identifies the {...@link
> org.apache.tapestry5.services.PageRenderRequestParameters}
> * and forwards onto {...@link PageRenderRequestHandler}
> ComponentEvent Identifies the {...@link
> * ComponentEventRequestParameters} and forwards onto the {...@link
> ComponentEventRequestHandler}
> */
> public static void
> contributeMasterDispatcher(OrderedConfiguration configuration)
> {
> // Looks for the root path and renders the start page. This is
> maintained for compatibility
> // with earlier versions of Tapestry 5, it is recommended that an
> Index page be used instead.
>
> configuration.addInstance("RootPath", RootPathDispatcher.class,
> "before:Asset");
>
> // This goes first because an asset to be streamed may have an file
> extension, such as
> // ".html", that will confuse the later dispatchers.
>
> configuration.addInstance("Asset", AssetDispatcher.class,
> "before:ComponentEvent");
>
> configuration.addInstance("VirtualAsset",
> VirtualAssetDispatcher.class, "before:Asset");
>
> configuration.addInstance("ComponentEvent",
> ComponentEventDispatcher.class, "before:PageRender");
>
> configuration.addInstance("PageRender",
> PageRenderDispatcher.class);
> }
>
>
> I think you have to specify one more constraint to insert your
> Dispatcher between the ComponentEvent and PageRender dispatcher.
>
> configuration.add("LoginDispatcher", loginDispatcher, "before:PageRender",
> "after:ComponentEvent");
>
> Worked for me :)
>
>
>
> nille hammer schrieb:
> > Hi List,
> >
> > I have implemented a LoginDispatcher like explained in the wiki
> (http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher). Then I
> contributed it to the MasterDispatcher's configuration with the following
> code:
> > configuration.add("LoginDispatcher", loginDispatcher,
> "before:PageRender");
> >
> > So far so good. Everything works up to this point. If I got it right I
> would end up with a chain of Dispatchers in the following order:
> "RootPath", "Asset", "ComponentEvent", "LoginDispatcher", "PageRender".
> Although "LoginDispatcher" is put after "Asset" I still see requests for
> Assets (i.e. /assets/xxx ) in my LoginDispatcher. I thought, this could not
> be the case as these requests should have been handeled by AssetDispatcher.
> What did I get/do wrong?
> >
> > Thanks in advance, nillehammer
> >
> > ==
> > http://www.winfonet.eu
> >
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--- original Nachricht Ende
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: tapestry-spring-security update
On Thu, Jun 4, 2009 at 15:25, Thiago H. de Paula Figueiredo wrote: > It does work! Thank you a lot, Robin! :) Don't thank me, thank Michael, I'm just the messenger this time :) -- regards, Robin - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: How to stream zip file
Em Thu, 04 Jun 2009 18:01:20 -0300, wesleywj2 escreveu: hi, Hi! what i want to achieve now is to create few files in memory (eg. file1.txt & file2.txt), zip itand return it to user's browser. i've googled around and found out an API for ZipOutputStream. But i had no idea how to implement it using Tapestry 5's StreamResponse interface. Instead of trying to do everything at once, think of two different problems: create a ZIP file in memory and then return it as a StreamResponse. ;) -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: assets caching T5.1
This is odd, it should be working out of the box. Perhaps the browser is the problem here. On Thu, Jun 4, 2009 at 11:25 AM, Joachim Van der Auwera wrote: > Have you switched off production mode? Perhaps in 5.1, in dev mode we won't specify the far future expires header. In 5.1 I'm pretty sure that far future expires is in force regardless of production mode. > > Joachim > > Moritz Gmelin wrote: >> >> Hi, >> >> after updateing our application to T5.1 I was hoping for noticeable >> accelleration in loading of pages. However while checking the log output I >> can see that all the assets are requested from the browser on every loading >> of a page for example I can see this >> >> INFO: Request time: 0 ms, >> page:/assets/tapestry/5.1.0.5/corelib/components/sort-asc.png, free >> Memory:69704936 b, language = de_DE >> >> everytime I go to a page that contains a table with those sorting icons. >> And many other assets that do not really need to be re-loaded. >> I already set the tapestry.app-version property in my AppModule. >> >> The application is run on a TOMCAT server behind an apache Web-Server. >> >> What else do I need to do to prevent this? >> >> M. >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > -- > Joachim Van der Auwera > PROGS bvba, progs.be > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.1] How to break the chain in MasterDispatcher
Hi nille,
i got the same problem. This part isn't good documented, look at this
snippet from the TapestryModule:
/**
* The MasterDispatcher is a chain-of-command of individual Dispatchers,
each handling (like a servlet) a particular
* kind of incoming request. RootPath Renders the start page for the
"/" request
* Asset Provides access to classpath assets
VirtualAsset Provides access to combined
* scripts PageRender Identifies the {...@link
org.apache.tapestry5.services.PageRenderRequestParameters}
* and forwards onto {...@link PageRenderRequestHandler}
ComponentEvent Identifies the {...@link
* ComponentEventRequestParameters} and forwards onto the {...@link
ComponentEventRequestHandler}
*/
public static void
contributeMasterDispatcher(OrderedConfiguration configuration)
{
// Looks for the root path and renders the start page. This is
maintained for compatibility
// with earlier versions of Tapestry 5, it is recommended that an Index
page be used instead.
configuration.addInstance("RootPath", RootPathDispatcher.class,
"before:Asset");
// This goes first because an asset to be streamed may have an file
extension, such as
// ".html", that will confuse the later dispatchers.
configuration.addInstance("Asset", AssetDispatcher.class,
"before:ComponentEvent");
configuration.addInstance("VirtualAsset", VirtualAssetDispatcher.class,
"before:Asset");
configuration.addInstance("ComponentEvent", ComponentEventDispatcher.class,
"before:PageRender");
configuration.addInstance("PageRender", PageRenderDispatcher.class);
}
I think you have to specify one more constraint to insert your
Dispatcher between the ComponentEvent and PageRender dispatcher.
configuration.add("LoginDispatcher", loginDispatcher, "before:PageRender",
"after:ComponentEvent");
Worked for me :)
nille hammer schrieb:
Hi List,
I have implemented a LoginDispatcher like explained in the wiki
(http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher). Then I
contributed it to the MasterDispatcher's configuration with the following code:
configuration.add("LoginDispatcher", loginDispatcher, "before:PageRender");
So far so good. Everything works up to this point. If I got it right I would end up with a chain of Dispatchers in the following order:
"RootPath", "Asset", "ComponentEvent", "LoginDispatcher", "PageRender". Although
"LoginDispatcher" is put after "Asset" I still see requests for Assets (i.e. /assets/xxx ) in my LoginDispatcher. I thought, this
could not be the case as these requests should have been handeled by AssetDispatcher. What did I get/do wrong?
Thanks in advance, nillehammer
==
http://www.winfonet.eu
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
[T5.1] How to break the chain in MasterDispatcher
Hi List,
I have implemented a LoginDispatcher like explained in the wiki
(http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher). Then I
contributed it to the MasterDispatcher's configuration with the following code:
configuration.add("LoginDispatcher", loginDispatcher, "before:PageRender");
So far so good. Everything works up to this point. If I got it right I would
end up with a chain of Dispatchers in the following order: "RootPath",
"Asset", "ComponentEvent", "LoginDispatcher", "PageRender". Although
"LoginDispatcher" is put after "Asset" I still see requests for Assets (i.e.
/assets/xxx ) in my LoginDispatcher. I thought, this could not be the case as
these requests should have been handeled by AssetDispatcher. What did I get/do
wrong?
Thanks in advance, nillehammer
==
http://www.winfonet.eu
How to stream zip file
hi, I couldn't figured it out for streaming zip files with "StreamResponse" interface. With my current implementation based on the Tapestry 5 site wiki tutorial example, i stream txt file. what i want to achieve now is to create few files in memory (eg. file1.txt & file2.txt), zip it and return it to user's browser. i've googled around and found out an API for ZipOutputStream. But i had no idea how to implement it using Tapestry 5's StreamResponse interface. please advice. wesley -- View this message in context: http://www.nabble.com/How-to-stream-zip-file-tp23877671p23877671.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Turning on Applicationwide security in 5.1
Hi,
In 5.0, we did this in our AppModule to enbale applicationwide security
public void contributeMetaDataLocator(MappedConfigurationString> configuration)
{
configuration.add(MetaDataConstants.SECURE_PAGE, "true");
}
In 5.1.0.5 this seems to have no effect. Instead I must place this in
the contributed Application defaults
public static void contributeApplicationDefaults(
MappedConfiguration
configuration)
{
configuration.add("tapestry.secure-enabled", "true");
configuration.add(MetaDataConstants.SECURE_PAGE, "true");
}
Is this an intentional change that I missed in the documentation or
what am I doing wrong?
Thanks
Moritz
Re: assets caching T5.1
Have you switched off production mode? Joachim Moritz Gmelin wrote: Hi, after updateing our application to T5.1 I was hoping for noticeable accelleration in loading of pages. However while checking the log output I can see that all the assets are requested from the browser on every loading of a page for example I can see this INFO: Request time: 0 ms, page:/assets/tapestry/5.1.0.5/corelib/components/sort-asc.png, free Memory:69704936 b, language = de_DE everytime I go to a page that contains a table with those sorting icons. And many other assets that do not really need to be re-loaded. I already set the tapestry.app-version property in my AppModule. The application is run on a TOMCAT server behind an apache Web-Server. What else do I need to do to prevent this? M. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Joachim Van der Auwera PROGS bvba, progs.be - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T 5.1] Problem with: Block parameters are only allowed directly within component elements
Too much noise here; that should read
"in your example, the will *always* rfender empty and only if
the user is not null in 5.0."
On Thu, Jun 4, 2009 at 11:18 AM, Howard Lewis Ship wrote:
> What Tapestry is doing now in 5.1 is correct. In you example, the
> will *always* render empty, and only if user is null in 5.0. 5.1
> forces you to put the where it makes sense. The Tapestry 5.0
> documentation should have been more specific, that you place it
> *directly* inside the body of the component (not merely somehwhere
> inside).
>
> On Thu, Jun 4, 2009 at 6:29 AM, Geoffrey Wiseman
> wrote:
>> On Thu, Jun 4, 2009 at 4:04 AM, Stefan Esterer wrote:
>>
>>> This works perfectly fine. Only if I add a additional I get a
>>> problem.
>>>
>>>
>>> Welcome back, ${user.firstName}
>>>
>>>
>>> Login /
>>> Register
>>>
>>>
>>>
>>>
>>
>>
>> Why would you do that, just for previewability? That structure doesn't make
>> a ton of sense to me. If there's a user, should tapestry render:
>>
>>> Welcome back, Stefan Esterer
>>>
>>
>> And if there's no user:
>>
>>> Login / Register
>>>
>>
>> I'm curious for the people who are getting bitten by this what they have in
>> mind.
>>
>> - Geoffrey
>> --
>> Geoffrey Wiseman
>> http://www.geoffreywiseman.ca/
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
> Director of Open Source Technology at Formos
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T 5.1] Problem with: Block parameters are only allowed directly within component elements
What Tapestry is doing now in 5.1 is correct. In you example, the
will *always* render empty, and only if user is null in 5.0. 5.1
forces you to put the where it makes sense. The Tapestry 5.0
documentation should have been more specific, that you place it
*directly* inside the body of the component (not merely somehwhere
inside).
On Thu, Jun 4, 2009 at 6:29 AM, Geoffrey Wiseman
wrote:
> On Thu, Jun 4, 2009 at 4:04 AM, Stefan Esterer wrote:
>
>> This works perfectly fine. Only if I add a additional I get a
>> problem.
>>
>>
>> Welcome back, ${user.firstName}
>>
>>
>> Login /
>> Register
>>
>>
>>
>>
>
>
> Why would you do that, just for previewability? That structure doesn't make
> a ton of sense to me. If there's a user, should tapestry render:
>
>> Welcome back, Stefan Esterer
>>
>
> And if there's no user:
>
>> Login / Register
>>
>
> I'm curious for the people who are getting bitten by this what they have in
> mind.
>
> - Geoffrey
> --
> Geoffrey Wiseman
> http://www.geoffreywiseman.ca/
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Host and cookies
t5 usually stores default cookie under www.example.com, is there a way to let t5 store under some other names like ".example.com", this might solve the www.example.com or http://example.com problem? Bryan Lewis-5 wrote: > > Can't you just use cookie.setDomain()? Set both cookies to the same > domain. Doesn't sound Tapestry- or javascript-related. > > > > On Wed, Jun 3, 2009 at 9:37 PM, Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > >> Em Wed, 03 Jun 2009 21:02:06 -0300, Angelo Chen < >> angelochen...@yahoo.com.hk> escreveu: >> >> Hi, >>> >> >> Hi! >> >> My App has a url: http://example.com, then user can also visit it >>> http://www.example.com. I use T5's cookie service to write some >>> visitor's >>> related info back to the visitor's browser. the problem now is, if user >>> uses http://example.com, cookie will be under example.com, if he uses >>> www.example.com, then the cookie will be under www.example.com, the two >>> now looks different from each other as far as cookie is concerned, any >>> thoughts on keeping only one set of cookie for two urls(http:// or >>> www.)? >>> Thanks, >>> >> >> This is mostly Javascript related than Tapestry related, but I think one >> elegant solution would be to use Tapestry to redirect all requests to the >> same domain (www.example.com to example.com, for example). >> >> Don't forget that, in Tapestry, many problems can be solved using a >> request >> filter or a dispatcher. ;) >> >> -- >> Thiago H. de Paula Figueiredo >> Independent Java consultant, developer, and instructor >> http://www.arsmachina.com.br/thiago >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > -- View this message in context: http://www.nabble.com/T5%3A-Host-and-cookies-tp23861674p23872473.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
assets caching T5.1
Hi, after updateing our application to T5.1 I was hoping for noticeable accelleration in loading of pages. However while checking the log output I can see that all the assets are requested from the browser on every loading of a page for example I can see this INFO: Request time: 0 ms, page:/assets/tapestry/5.1.0.5/corelib/ components/sort-asc.png, free Memory:69704936 b, language = de_DE everytime I go to a page that contains a table with those sorting icons. And many other assets that do not really need to be re-loaded. I already set the tapestry.app-version property in my AppModule. The application is run on a TOMCAT server behind an apache Web-Server. What else do I need to do to prevent this? M. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T 5.1] Problem with: Block parameters are only allowed directly within component elements
On Thu, Jun 4, 2009 at 4:04 AM, Stefan Esterer wrote:
> This works perfectly fine. Only if I add a additional I get a
> problem.
>
>
>Welcome back, ${user.firstName}
>
>
> Login /
> Register
>
>
>
>
Why would you do that, just for previewability? That structure doesn't make
a ton of sense to me. If there's a user, should tapestry render:
> Welcome back, Stefan Esterer
>
And if there's no user:
> Login / Register
>
I'm curious for the people who are getting bitten by this what they have in
mind.
- Geoffrey
--
Geoffrey Wiseman
http://www.geoffreywiseman.ca/
Re: tapestry-spring-security update
It does work! Thank you a lot, Robin! :) -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Host and cookies
Can't you just use cookie.setDomain()? Set both cookies to the same domain. Doesn't sound Tapestry- or javascript-related. On Wed, Jun 3, 2009 at 9:37 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Em Wed, 03 Jun 2009 21:02:06 -0300, Angelo Chen < > angelochen...@yahoo.com.hk> escreveu: > > Hi, >> > > Hi! > > My App has a url: http://example.com, then user can also visit it >> http://www.example.com. I use T5's cookie service to write some visitor's >> related info back to the visitor's browser. the problem now is, if user >> uses http://example.com, cookie will be under example.com, if he uses >> www.example.com, then the cookie will be under www.example.com, the two >> now looks different from each other as far as cookie is concerned, any >> thoughts on keeping only one set of cookie for two urls(http:// or www.)? >> Thanks, >> > > This is mostly Javascript related than Tapestry related, but I think one > elegant solution would be to use Tapestry to redirect all requests to the > same domain (www.example.com to example.com, for example). > > Don't forget that, in Tapestry, many problems can be solved using a request > filter or a dispatcher. ;) > > -- > Thiago H. de Paula Figueiredo > Independent Java consultant, developer, and instructor > http://www.arsmachina.com.br/thiago > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Authentification in Tapestry
> Why don't you use annotations for that? Something like @PublicPage? If the > page hasn't it, it is protected. > > Unless there are pages that need some internal logic to decide if they're > public or protected (hence an interface with a isPublic() method), > annotations are a better solution for the problem. I wanted to make it easy for the developer to have advanced control on who gets access to the page. For the PublicPage this is not so much an issue. For the ProtectedPage the developer can implement/override the isAccessAllowed method. On some pages we need more advanced control on who gets access. Users of our system are typically employees of an organisation and the organisation can decide which modules are accessible to its employees. So for some pages I have more complex rules than simple role-checking. By subclasses/overriding I can put all that logic in a single place on the page. This gives us more freedom. You are right though, if role-checking is all you want, you can indeed use a simple annotation-based system. regards, Onno
Re: tapestry-spring-security update
I, also, can confirm it works under Tapestry 5.1.0.5 + Glassfish Thanks On Sat, May 30, 2009 at 11:01 AM, Juan E. Maya wrote: > I can confirm it works under the Tapestry 5.2.0-SNAPSHOT > Thanks a lot !!! > > On Sat, May 30, 2009 at 9:24 AM, Michael Gerzabek > wrote: > >> Hi Thiago, >> >> yes it should. Anyway more feedback is wanted. >> >> Thiago H. de Paula Figueiredo schrieb: >> >> On Fri, May 29, 2009 at 3:34 PM, Robin Helgelin wrote: >>> >>> >>> Hi, >>> >>> Hi! >>> >>> >>> I've just uploaded a 2.1.0-SNAPSHOT release of tapestry-spring-security with support for Tapestry 5.1. We're releasing this as a SNAPSHOT so that we can see that it actually works for everybody before we make the final release. >>> >>> Thank you! Does it solve the @Secured annotation handling? It is >>> broken in 2.0 when used with T5.1. >>> >>> -- >>> Thiago >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Authentification in Tapestry
>>The thing I don't like about most of the current examples/solutions I've >> seen so far is that access is allowed by default if the developer forgets >> to >> add a specific annotation. Exactly, the wiki examples are a good start but denied by default should be your default policy, for a secure extranet anyhow. If you are going to go the annotations route then use an @Unsecured annotation instead. Personally I don't bother with annotations, I use a request filter and attach the ApplicationStateManager and ComponentClassResolver as dependencies. One RequestFilter with access to the right Tapestry services is all you really need to do everything in one place and have peace of mind. Peter - Original Message - From: "Massimo Lusetti" To: "Tapestry users" Sent: Thursday, 4 June, 2009 11:03:49 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Authentification in Tapestry On Thu, Jun 4, 2009 at 3:41 AM, Thiago H. de Paula Figueiredo wrote: > Em Wed, 03 Jun 2009 22:07:28 -0300, Onno Scheffers > escreveu: > >> I'm also using a custom dispatcher. >> The thing I don't like about most of the current examples/solutions I've >> seen so far is that access is allowed by default if the developer forgets >> to >> add a specific annotation. I'd like the page to be protected unless the >> developers makes it publicly accessible. > > Nice reasoning. :) That's a policy. I could see this implemented as a different protection strategy. Cheers -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session IllegalStateException
>i could imagine to provide a decorator for the ASOManager
A decorator would be better than my solution, but the same result: I simply use
a singleton service to sign out users, and attach a dependancy to the
ApplicationStateManager, the following method is the relevant portion of the
code that you could use in your decorator:
/**
* explicitly destroy all tapestry ASO's on
* logout as a safeguard, only leaving {...@link UserSecurityManager}
in tact
*/
@SuppressWarnings("unchecked")
private void destroySession() {
Enumeration sessionAttributes =
getSession().getAttributeNames();
try {
while (sessionAttributes.hasMoreElements()) {
Class c = null;
String element = (String)
sessionAttributes.nextElement();
if (element.startsWith("aso:")) {
element =
StringUtils.stripStart(element, "aso:");
c = Class.forName(element);
if
(!element.equals(UserSecurityManager.class.getName()))
asm_.set(c, null);
}
}
} catch (ClassNotFoundException e) {
Logger.getLogger(getClass()).error(
"An ASO Class was not resolved when
trying to remove it from state: "
+
e.getLocalizedMessage());
}
}
Just two quick notes:
1. Class.forName("The String canonical class name arg") is my preferred way to
get at the class and avoid any potential classloader issues
2. The line: if (!element.equals(UserSecurityManager.class.getName())) is left
alone as I have a requirement not to touch this class, I have simply left it in
in case you have a
similar issue.
regards,
Peter
- Original Message -
From: "Kristian Marinkovic"
To: "Tapestry users"
Sent: Thursday, 4 June, 2009 10:38:58 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session IllegalStateException
hi peter,
can you share your code. i really don't see a quick fix :)
i could imagine to provide a decorator for the ASOManager
or for the SessionApplicationStatePersistenceStrategy
and store all the objects/fields in an custom wrapper object that
in turn is saved in the HTTPSession. which i then could control
and clear whenever i need it.
g,
kris
Peter Stavrinides
04.06.2009 08:40
Bitte antworten an
"Tapestry users"
An
Tapestry users
Kopie
Thema
Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session IllegalStateException
Hi Kristian,
I experienced similar problems between Tapestry versions (5.0.18 and 5.1)
with exactly the same use case, I never took the time to dig more deeply
though as I simply had to find a quick fix, which was to destroy / remove
all ASO's explicitly... not elegant but efficient, and have had no
problems since. I will glad to share the code if you can't find a
workaround.
Cheers,
Peter
- Original Message -
From: "Kristian Marinkovic"
To: "Tapestry users"
Sent: Thursday, 4 June, 2009 08:57:39 GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session
IllegalStateException
i already use the Tapestry Request service. But the RequestImpl
wont create a new HttpSession even i tell it ;)
i think it is a bug. maybe someone can take a look at it to verify it.
the code and the problem:
if the session has been set once it will never be cleared, thus
ignoring the create parameter. and with create=true i will always
get the old invalidated session.
RequestImpl:
public Session getSession(boolean create)
{
if (session == null)
{
HttpSession hsession = request.getSession(create);
if (hsession != null)
{
session = new SessionImpl(hsession, analyzer);
}
}
if (!create && session != null && session.isInvalidated()) return null;
return session;
}
g,kris
Joachim Van der Auwera
03.06.2009 15:34
Bitte antworten an
"Tapestry users"
An
Tapestry users
Kopie
Thema
Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session IllegalStateException
You should invalidate the session from the (injected) Request object
(not the HTTPServletRequest). This does the necessary bookkeeping.
Kind regards,
Joachim
Kristian Marinkovic wrote:
> hi,
>
> using 5.0.18 it was able to invalidate a HttpSession (via the Request)
> and then to create a new one to store a new object (subject).
>
> in 5.1.0.5 this changed because the Request will always cache the old
> Tapestry Session object and not attempt to create a new Http Session
> as long as the reference is not null although it is invalidated.
>
> Are there any workarounds
Re: [T 5.1] Problem with: Block parameters are only allowed directly within component elements
Refer https://issues.apache.org/jira/browse/TAP5-571.
I've put my comment on this fixing too. I think the fixing is not so perfect.
DH
- Original Message -
From: "Stefan Esterer" Sent: Thursday, June 04, 2009 4:04 PM
Subject: [T 5.1] Problem with: Block parameters are only allowed directly
within component elements
>
> Hi List...
>
> I just switched from Tapestry 5.0.18 to Tapestry 5.1.0.5 and I'm
> experiencing a problem with the IF component.
> I'm not quite sure if this is a bug or feature, so please enlighten me *g*
>
> For demonstration I just use the tutorial IF example
> (http://tapestry.apache.org/tapestry5.1/tapestry-core/ref/org/apache/tapestry5/corelib/components/If.html).
>
> It looks like this
>
>
>Welcome back, ${user.firstName}
>
>Login /
>Register
>
>
>
> This works perfectly fine. Only if I add a additional I get a problem.
>
>
>Welcome back, ${user.firstName}
>
>
> Login /
> Register
>
>
>
>
> Using the template with the additional I get this exception:
>
> java.lang.RuntimeException
> Block parameters are only allowed directly within component elements.
>
> Is this a design decision or a bug?
>
> Thx for your help
> Stefan Esterer
> --
> View this message in context:
> http://www.nabble.com/-T-5.1--Problem-with%3A-Block-parameters-are-only-allowed-directly-within-component-elements-tp23865519p23865519.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
[T 5.1] Problem with: Block parameters are only allowed directly within component elements
Hi List...
I just switched from Tapestry 5.0.18 to Tapestry 5.1.0.5 and I'm
experiencing a problem with the IF component.
I'm not quite sure if this is a bug or feature, so please enlighten me *g*
For demonstration I just use the tutorial IF example
(http://tapestry.apache.org/tapestry5.1/tapestry-core/ref/org/apache/tapestry5/corelib/components/If.html).
It looks like this
Welcome back, ${user.firstName}
Login /
Register
This works perfectly fine. Only if I add a additional I get a problem.
Welcome back, ${user.firstName}
Login /
Register
Using the template with the additional I get this exception:
java.lang.RuntimeException
Block parameters are only allowed directly within component elements.
Is this a design decision or a bug?
Thx for your help
Stefan Esterer
--
View this message in context:
http://www.nabble.com/-T-5.1--Problem-with%3A-Block-parameters-are-only-allowed-directly-within-component-elements-tp23865519p23865519.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Authentification in Tapestry
On Thu, Jun 4, 2009 at 3:41 AM, Thiago H. de Paula Figueiredo wrote: > Em Wed, 03 Jun 2009 22:07:28 -0300, Onno Scheffers > escreveu: > >> I'm also using a custom dispatcher. >> The thing I don't like about most of the current examples/solutions I've >> seen so far is that access is allowed by default if the developer forgets >> to >> add a specific annotation. I'd like the page to be protected unless the >> developers makes it publicly accessible. > > Nice reasoning. :) That's a policy. I could see this implemented as a different protection strategy. Cheers -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Authentification in Tapestry
On Wed, Jun 3, 2009 at 9:13 PM, Thibaut Gadiolet wrote: > OK, I stop using a full T5 solution to handle authentication/authorization. > I am using ACEGI with a basic configuration, you can easily integrate it to > your T5 projects, It's not as heavy as I thought, and it turned out to be > very efficient. > > But if someone gets a better solution full T5, I'm open. I actually don't know if it's a better solution but i'm interested in knowing what you think about chenillekit-access module. Warn: you have to checkout sources Regards -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session IllegalStateException
hi peter,
can you share your code. i really don't see a quick fix :)
i could imagine to provide a decorator for the ASOManager
or for the SessionApplicationStatePersistenceStrategy
and store all the objects/fields in an custom wrapper object that
in turn is saved in the HTTPSession. which i then could control
and clear whenever i need it.
g,
kris
Peter Stavrinides
04.06.2009 08:40
Bitte antworten an
"Tapestry users"
An
Tapestry users
Kopie
Thema
Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session IllegalStateException
Hi Kristian,
I experienced similar problems between Tapestry versions (5.0.18 and 5.1)
with exactly the same use case, I never took the time to dig more deeply
though as I simply had to find a quick fix, which was to destroy / remove
all ASO's explicitly... not elegant but efficient, and have had no
problems since. I will glad to share the code if you can't find a
workaround.
Cheers,
Peter
- Original Message -
From: "Kristian Marinkovic"
To: "Tapestry users"
Sent: Thursday, 4 June, 2009 08:57:39 GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session
IllegalStateException
i already use the Tapestry Request service. But the RequestImpl
wont create a new HttpSession even i tell it ;)
i think it is a bug. maybe someone can take a look at it to verify it.
the code and the problem:
if the session has been set once it will never be cleared, thus
ignoring the create parameter. and with create=true i will always
get the old invalidated session.
RequestImpl:
public Session getSession(boolean create)
{
if (session == null)
{
HttpSession hsession = request.getSession(create);
if (hsession != null)
{
session = new SessionImpl(hsession, analyzer);
}
}
if (!create && session != null && session.isInvalidated()) return null;
return session;
}
g,kris
Joachim Van der Auwera
03.06.2009 15:34
Bitte antworten an
"Tapestry users"
An
Tapestry users
Kopie
Thema
Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session IllegalStateException
You should invalidate the session from the (injected) Request object
(not the HTTPServletRequest). This does the necessary bookkeeping.
Kind regards,
Joachim
Kristian Marinkovic wrote:
> hi,
>
> using 5.0.18 it was able to invalidate a HttpSession (via the Request)
> and then to create a new one to store a new object (subject).
>
> in 5.1.0.5 this changed because the Request will always cache the old
> Tapestry Session object and not attempt to create a new Http Session
> as long as the reference is not null although it is invalidated.
>
> Are there any workarounds? Why i'm doing this: if you're logged in
> as XXX you can re-login as YYY if you want and have a new https
> session.
>
> g,
> kris
>
> used to work
> public void setSubject(Subject subject)
> {
>Session session = request.getSession(false);
>
>// create a new session
>if (session != null && !session.isInvalidated())
>{
> session.invalidate();
>}
>request.getSession(true);
>
>asoManager.set(Subject.class, subject);
> }
>
--
Joachim Van der Auwera
PROGS bvba, progs.be
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Authentification in Tapestry
That's the way I've written the access control on our system. -Original Message- From: Christian Senk [mailto:senk.christ...@googlemail.com] Sent: 03 June 2009 20:24 To: Tapestry users Subject: Re: Authentification in Tapestry We are using a custom dispatcher called "AccessControlDispatcher". It is like the AccessDispatcher described in the howto-wiki, but in addition it checks for certain roles. This works through a SessionState object that implements an interface used by the dispatcher to determine if the SessionState object has the required role(s) or not. All you have to do is to annotate the desired page with "@Secured(Role.ADMIN)" for example. the dispatcher checks if the current user has the required role for this page, if not the dispatcher calls an AccessDeniedCallback, where you can redirect to the login page or something like that. The Callback and the Class of the SessionState object that implements the interface needed by the dispatcher are contributable over a mapped configuration. It is very simple and i think there is a lot potential to improve this, but until now it works for us. Maybe this idea helps you ^.^ Thibaut Gadiolet schrieb: > OK, I stop using a full T5 solution to handle authentication/authorization. > I am using ACEGI with a basic configuration, you can easily integrate it to > your T5 projects, It's not as heavy as I thought, and it turned out to be > very efficient. > > But if someone gets a better solution full T5, I'm open. > > Thanks, > > Thibaut > > On Fri, May 22, 2009 at 4:10 AM, Sergey Didenko wrote: > > >> Thanks for tips, Thiago! >> >> >>> This has been discussed in this list before. Check the archives >>> (http://www.nabble.com/Tapestry---User-f340.html) for some ideas. >>> Usually they are centered around a RequestFilter or a >>> ComponentClassTransformer. >>> >>> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >> > > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org ** Experience the British Library online at www.bl.uk The British Library's new interactive Annual Report and Accounts 2007/08 : www.bl.uk/knowledge Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook The Library's St Pancras site is WiFi - enabled * The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmas...@bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. * - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
