RE: Lightweight TapestryTools update site

[Athneria, Mahendra]

Hi Gavin,

Thanks for the reply. It would be great if you can add that feature too. I want 
to see the list of components from jar to the auto complete list.

Thanks Gavin,

Regards,
Mahendra

-Original Message-
From: Gavin Lei [mailto:gavingui2...@gmail.com] 
Sent: Wednesday, August 08, 2012 6:54 PM
To: Tapestry users
Subject: Re: Lightweight TapestryTools update site

Hi Athneria,

This feature support only custom components in project's source
directory, not consider components in jars, maybe i should also add
jars support.

2012/8/7 Athneria, Mahendra :
> Hi Gavin,
>
> I took the update and trying to test the custom components support feature 
> with different prefix.
> I have some doubts regarding the same.
>
> A) - We have a nice editor in which developer enters mapping :> - we can only 
> edit the custom components by right click on the project. And when I click on 
> (+) button I can only see the packages from my project only. I am not able to 
> see the components package from different libraries. So how I can do the 
> same. I tried to achieve the same by editing "components.tcc" file. Below is 
> the example.
>
> 
> 
> 
>  
> 
>  
>  path="net.awl.tapestry5.kawwa.components"/>
> 
> 
>
> Even thought I am not able to get the " Breadcrumb " name when I press 
> "ctrl+space" on tml file.
>
> Any idea Gavin??
>
> Regards,
> Mahendra Athneria
>
>
> -Original Message-
> From: Gavin Lei [mailto:gavingui2...@gmail.com]
> Sent: Monday, August 06, 2012 6:21 PM
> To: Tapestry users
> Cc: Igor Drobiazko
> Subject: Re: Lightweight TapestryTools update site
>
>
> Hi all,
>
> In TapestryTools' components auto-complete feature, by default only
> components defined in these two packages are in the list:
>
> 1.org.apache.tapestry5.corelib.components (Tapestry 5's build-in components)
> 2.app-package.components, whereby app-package is the applications root
> package defined in the web.xml (Tapestry web application's root
> components)
>
> Now, I have add custom components support for TapestryTools. It means
> besides these components, TapestryTools support also custom components
> with different prefix with "t:". It allow you to provide
> autocompletion for custom components from different libraries, and we
> have a nice editor in which developer enters mapping:
>
> x: org.example.components
> y: org.acme.lib.components
>
> In this mapping, a library prefix is mapped to a component package.
> So, every component from org.example.components package would have x
> prefix. For example:
>
> 
> 
>
> This feature is alreay available in TapestryTools' update site [1],
> and you can find detailed guide about this feature and the "Custom
> components mapping editor" here [2] (It is in Section 7).
>
> Looking forward to your feedbacks about TapestryTools and this new
> feature, thanks.
>
> [1] http://tapestrytools.googlecode.com/svn/TapestryTools/
> [2] 
> http://code.google.com/p/tapestrytools/wiki/Install_Guide_Lightweight_TapestryTools
> --
> -
> Best Regards
> Gavin Lei (雷银)
> Email: gavingui2...@gmail.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org



-- 
-
Best Regards
Gavin Lei (雷银)
Email: gavingui2...@gmail.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: T5.3 application level singleton cache with Hibernate injection

[Kalle Korhonen]

On Wed, Aug 8, 2012 at 9:46 PM, Daniel Jue  wrote:
> Problem:
> I want to initialize this cache on server startup, before any pages are
> served, since it can take a few minutes.
> I want to pass it session from tapestry hibernate, since I use that
> configuration in the pages (I'm guessing there is some way to get an
> instance of HibernateSessionSource)
> I'm sure I could brute force a way to load it's own HibernateSessionManager
> and then read stuff into memory, but I wanted to see if I could
> @injectservice somehow.
> The objects being stored in memory are not necessarily hibernate objects,
> but we want to use hibernate to construct the caches.
> Once the in memory cache is created, the session it used to communicate
> with the DB is no longer needed.
> Looking around online, it seems that what I want is closest to a service
> and something like a DAO+Cache.  Again, the DAO part is understandable, but
> is there a proper way to get a Hibernate session injected into it at
> startup so it can be built, without having to access any web resource to
> kick it off?

Yes, create your service (or create a helper service) to start with
@EagerLoad. Lots of things use this but for an example, you could take
a look at SeedEntityImpl, an implementation class in Tynamo's
seedentity module
(http://tynamo.org/tapestry-hibernate-seedentity+guide).

Kalle

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

T5.3 application level singleton cache with Hibernate injection

[Daniel Jue]

After a long hiatus from web development, I have a chance to get back into
Tapestry for a small project.  I kind of need a refresher for an approach I
haven't had to do before:

Context note: Running T5.3 on Tomcat or Jetty, from latest Tynamo release
with Tynamo hibernate/resteasy modules.

Application:
I'm adapting/restructuring an existing application where I have an in
memory, RO cache of several GB in a singleton object.  Requests hit this
cache for some things, and my plan is to have my tapestry pages and rest
services bounce against that.
A call to the custom cache from a page/rest service will take a session in
case it needs to forward the request to databases, etc.
Access from rest services/pages are not a problem because I can just inject
a session and pass it to the cache.
It's a requirement that this cache be in memory.

Problem:
I want to initialize this cache on server startup, before any pages are
served, since it can take a few minutes.
I want to pass it session from tapestry hibernate, since I use that
configuration in the pages (I'm guessing there is some way to get an
instance of HibernateSessionSource)

I'm sure I could brute force a way to load it's own HibernateSessionManager
and then read stuff into memory, but I wanted to see if I could
@injectservice somehow.
The objects being stored in memory are not necessarily hibernate objects,
but we want to use hibernate to construct the caches.
Once the in memory cache is created, the session it used to communicate
with the DB is no longer needed.


Looking around online, it seems that what I want is closest to a service
and something like a DAO+Cache.  Again, the DAO part is understandable, but
is there a proper way to get a Hibernate session injected into it at
startup so it can be built, without having to access any web resource to
kick it off?

Thanks

Import/export in tapestry

[gonzalomp87]

Hi

I used the fileupload component to upload files to my web server. Now,  I'm
trying to make the option of exporting these files. (Copied from the server
to my local machine)

Now the exported file directory is fixed and known by me, I want to select
the destination directory.

No way to do it?



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Import-export-in-tapestry-tp5715176.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: Tapestry get Post Data

[Lance Java]

You can also use @RequestParameter on parameters in render phase methods.

eg
void onActivate(@RequestParameter("foo") String foo) { ... }

Normal tapestry coercion rules apply for types

Re: Tree Session Management Issue

[Thiago H de Paula Figueiredo]

On Wed, 08 Aug 2012 21:40:57 -0300, tapestry.kung.fu  
 wrote:


Bump!  Come on somebody must know what's going on! There are many  
tapestry experts read this forum! Non of them knows what's going on here!


This is not a forum, this is a mailing list. Nabble is just an interface  
over the mailing list.


What objects do you use as values in the Tree model? They should have good  
implementations of hashcode() and equals(), as any other object that can  
be put inside a collection.


--
Thiago H. de Paula Figueiredo

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Tapestry get Post Data

[Thiago H de Paula Figueiredo]

On Wed, 08 Aug 2012 16:02:00 -0300, Sam.Roberts   
wrote:



I have a page that I am linking to from outside (a different webapp) to
Tapestry and I want to pass auth data and some other information along  
via POST data rather than GET data, but I can't really figure out how to  
access the POST data while in the onActivate for the page I'm going.


If the POST data is a query string, just @Inject Request and use  
Request.getParameter() as you would do with GET parameters. This is the  
same you used HttpServletRequest instead of Tapestry's Request. If not  
@Inject HttpServletRequest and follow the example in the answer to this  
question:  
http://stackoverflow.com/questions/3831680/httpservletrequest-get-post-data


--
Thiago H. de Paula Figueiredo

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Changing default session behavior.

[Lenny Primak]

Wouldn't the problem be that tapestry uses web/server sessions for lots of 
things and doesn't really know about Shiro sessions?  Or are you planning to 
get tapestry to use Shiro sessions?

On Aug 8, 2012, at 12:44 PM, Kalle Korhonen  wrote:

> On Wed, Aug 8, 2012 at 8:24 AM, kata  wrote:
>> Having two sessions is actually what I'm trying to avoid - I want to use
>> shiro native sessions exclusively. My problem is that Tapestry by default
>> uses the servlet API to access the underlying HttpSession, so using
>> annotations like @Persist cause a second session to be created. If I can
>> intercept Tapestry calls to the servlet API and direct them to the shiro
>> session, then I can have only one session, properly clustered and, above
>> all, it'll be completely transparent to the application.
> 
> Actually, Shiro should be wrapping the request so that even if you are
> using native sessions, the given session would be created by Shiro,
> not the container. Now I haven't used native sessions myself so things
> may not work as expected. We should be able to get this working though
> fairly easily, please open an issue and I'll work on it at some point
> (unless you want to take a crack at it yourself first).
> 
> While I generally agree with the "just use JEE" sentiment, there are
> perfectly valid reasons for using Shiro's native sessions. They are
> pretty handy if you are working in heterogeneous environment, for
> example comprising aspects from desktop and web applications.
> 
> Kalle
> 
> 
>>> The whole point of a web session is to have only one.  Now he is winding
>>> up with two sessions.
>>> One web and one shiro native.
>>> How is he clustering the web session if he clusters
>>> the shiro native session differently?  Sounds like the 'web session' isn't
>>> working correctly in his case
>>> and he is trying to 'compensate' with Shiro, which is sooo wrong path to
>>> go.
>>> 
>>> On Aug 8, 2012, at 11:07 AM, Alex Kotchnev wrote:
>>> 
 Lenny - why do you think it would be a problem ?
 
 Cheers - Alex K
 
 On Wed, Aug 8, 2012 at 11:02 AM, Lenny Primak wrote:
 
> I wouldn't use native shiro sessions with Tapestry.  This is a recipe
> for
> disaster.
> 
> On Aug 8, 2012, at 10:59 AM, kata wrote:
> 
>> Alex,
>> 
>> thanks, I'll look into it.
>> 
>> Regards,
>> Martin
>> 
>> 
>> Alex Kotchnev-2 wrote
>>> 
>>> Martin,
>>> it sounds like you might need to crack open the Tapestry source, but
>>> it
>>> seems doable. Although I don't know the details, I know for sure that
> the
>>> @Persist annotation allows for different persistence strategies (e.g.
>>> @Persist("flash")), which can be plugged by different modules (e.g.
>>> JPA
>>> and
>>> Hibernate provide an "entity" strategy). So, it seems like if you look
> at
>>> how Tapestry JPA contributes the "entity" strategy, you might be able
>>> to
>>> replace or add your own (e.g. 'shiroSession'). There probably is a way
> to
>>> override the existing 'session' strategy w/ the one backed by Shiro's
>>> Session (e.g. anywhere where you can "contribute" as the code below
> does,
>>> you can also override).
>>> 
>>> Another example is Tynamo's tapestry-jdo module, e.g. :
>>> 
> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/JDOModule.html
> ;
>>> 
> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/internal/EntityPersistentFieldStrategy.html
>>> 
>>> 
>>> Sorry I don't have more specific answers. I hope this helps.
>>> 
>>> Cheers,
>>> 
>>> Alex K
>>> 
>>> On Wed, Aug 8, 2012 at 10:04 AM, kata  >wrote:
>>> 
 Alex,
 
 I'm sorry, I wasn't clear - I'm using native shiro sessions, so I
> switch
 the
 session manager to shiro's DefaultWebSessionManager. I do it this way
> to
 later cache and cluster session data with EhCache.
 What I need is a way to substitute the HttpSession tapestry is using
> with
 shiros' Session implementation. If I can do that, then I hope I can
 use
 the
 servlet API in the application instead of the shiro-specific calls.
 Ideally
 annotations would also work as intended, with clustering and all.
 
 Regards,
 Martin
 
 
 Alex Kotchnev-2 wrote
> 
> Martin,
> you really should be able to continue using @Persist and
 @SessionState.
> Both Shiro's subject.getSession() and the @Persist annotation store
 their
> values in the same http session. Is that not working for you ?
> 
> Cheers,
> 
> Alex K
>

Re: Tree Session Management Issue

[tapestry.kung.fu]

Bump!  Come on somebody must know what's going on! There are many tapestry
experts read this forum! Non of them knows what's going on here!



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Tree-Session-Management-Issue-tp5715132p5715171.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

Tapestry get Post Data

[Sam.Roberts]

I have a page that I am linking to from outside (a different webapp) to
Tapestry and I want to pass auth data and some other information along via
POST data rather than GET data, but I can't really figure out how to access
the POST data while in the onActivate for the page I'm going.

The closest answer to this that I've found by searching is from 2006 and
refers to HiveMind, which is certainly not up to date.

Thanks in advance.



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Tapestry-get-Post-Data-tp5715170.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: Changing default session behavior.

[Kalle Korhonen]

On Wed, Aug 8, 2012 at 8:24 AM, kata  wrote:
> Having two sessions is actually what I'm trying to avoid - I want to use
> shiro native sessions exclusively. My problem is that Tapestry by default
> uses the servlet API to access the underlying HttpSession, so using
> annotations like @Persist cause a second session to be created. If I can
> intercept Tapestry calls to the servlet API and direct them to the shiro
> session, then I can have only one session, properly clustered and, above
> all, it'll be completely transparent to the application.

Actually, Shiro should be wrapping the request so that even if you are
using native sessions, the given session would be created by Shiro,
not the container. Now I haven't used native sessions myself so things
may not work as expected. We should be able to get this working though
fairly easily, please open an issue and I'll work on it at some point
(unless you want to take a crack at it yourself first).

While I generally agree with the "just use JEE" sentiment, there are
perfectly valid reasons for using Shiro's native sessions. They are
pretty handy if you are working in heterogeneous environment, for
example comprising aspects from desktop and web applications.

Kalle


>> The whole point of a web session is to have only one.  Now he is winding
>> up with two sessions.
>> One web and one shiro native.
>> How is he clustering the web session if he clusters
>> the shiro native session differently?  Sounds like the 'web session' isn't
>> working correctly in his case
>> and he is trying to 'compensate' with Shiro, which is sooo wrong path to
>> go.
>>
>> On Aug 8, 2012, at 11:07 AM, Alex Kotchnev wrote:
>>
>>> Lenny - why do you think it would be a problem ?
>>>
>>> Cheers - Alex K
>>>
>>> On Wed, Aug 8, 2012 at 11:02 AM, Lenny Primak wrote:
>>>
 I wouldn't use native shiro sessions with Tapestry.  This is a recipe
 for
 disaster.

 On Aug 8, 2012, at 10:59 AM, kata wrote:

> Alex,
>
> thanks, I'll look into it.
>
> Regards,
> Martin
>
>
> Alex Kotchnev-2 wrote
>>
>> Martin,
>> it sounds like you might need to crack open the Tapestry source, but
>> it
>> seems doable. Although I don't know the details, I know for sure that
 the
>> @Persist annotation allows for different persistence strategies (e.g.
>> @Persist("flash")), which can be plugged by different modules (e.g.
>> JPA
>> and
>> Hibernate provide an "entity" strategy). So, it seems like if you look
 at
>> how Tapestry JPA contributes the "entity" strategy, you might be able
>> to
>> replace or add your own (e.g. 'shiroSession'). There probably is a way
 to
>> override the existing 'session' strategy w/ the one backed by Shiro's
>> Session (e.g. anywhere where you can "contribute" as the code below
 does,
>> you can also override).
>>
>>  Another example is Tynamo's tapestry-jdo module, e.g. :
>>
 http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/JDOModule.html
 ;
>>
 http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/internal/EntityPersistentFieldStrategy.html
>>
>>
>>  Sorry I don't have more specific answers. I hope this helps.
>>
>> Cheers,
>>
>> Alex K
>>
>> On Wed, Aug 8, 2012 at 10:04 AM, kata wrote:
>>
>>> Alex,
>>>
>>> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I
 switch
>>> the
>>> session manager to shiro's DefaultWebSessionManager. I do it this way
 to
>>> later cache and cluster session data with EhCache.
>>> What I need is a way to substitute the HttpSession tapestry is using
 with
>>> shiros' Session implementation. If I can do that, then I hope I can
>>> use
>>> the
>>> servlet API in the application instead of the shiro-specific calls.
>>> Ideally
>>> annotations would also work as intended, with clustering and all.
>>>
>>> Regards,
>>> Martin
>>>
>>>
>>> Alex Kotchnev-2 wrote

 Martin,
 you really should be able to continue using @Persist and
>>> @SessionState.
 Both Shiro's subject.getSession() and the @Persist annotation store
>>> their
 values in the same http session. Is that not working for you ?

 Cheers,

 Alex K

 On Wed, Aug 8, 2012 at 7:20 AM, kata 
>>> wrote:

> Hi all,
>
> I am currently using shiro and the tapestry-security plugin to
> manage
> sessions and persist data. Everything works fine when getting the
>>> session
> by
> SecurityUtils.getSubject().getSession(). However, this means that
> the
>>>

Re: Autosubmit for Select Component

[Thiago H de Paula Figueiredo]

On Wed, 08 Aug 2012 07:16:40 -0300, Gruber Reinhold   
wrote:



Hi,


Hi!

I'm transfering an application from Tapestry 3 to Tapestry 5. In Tap3  
there was a "submitOnChange" Parameter for the PropertySelection  
Component. Is there something similar in Tapestry 5,


No.


and if not what is the preferred way to make this work?
The submit can be a normal GET-Request, no need for Ajax.


Just a little bit of JavaScript should suffice.

--
Thiago H. de Paula Figueiredo

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Autosubmit for Select Component

[Gruber Reinhold]

Hi,

I'm transfering an application from Tapestry 3 to Tapestry 5. In Tap3 there was 
a "submitOnChange" Parameter for the PropertySelection Component.
Is there something similar in Tapestry 5, and if not what is the preferred way 
to make this work?
The submit can be a normal GET-Request, no need for Ajax.

Thanks
Reinhold

Re: Changing default session behavior.

[Lenny Primak]

I would avoid using shiro native sessions.
Saying that, one thing you might try to do is to override Tapestry Session 
service.
I don't know if that's possible.  Using Alex K's approach would only override 
@Persist annotations, etc.
which would only solve part of the problem for you, not all of it.


On Aug 8, 2012, at 11:24 AM, kata wrote:

> Having two sessions is actually what I'm trying to avoid - I want to use
> shiro native sessions exclusively. My problem is that Tapestry by default
> uses the servlet API to access the underlying HttpSession, so using
> annotations like @Persist cause a second session to be created. If I can
> intercept Tapestry calls to the servlet API and direct them to the shiro
> session, then I can have only one session, properly clustered and, above
> all, it'll be completely transparent to the application.
> 
> 
> lprimak wrote
>> 
>> The whole point of a web session is to have only one.  Now he is winding
>> up with two sessions.
>> One web and one shiro native.
>> How is he clustering the web session if he clusters
>> the shiro native session differently?  Sounds like the 'web session' isn't
>> working correctly in his case
>> and he is trying to 'compensate' with Shiro, which is sooo wrong path to
>> go.
>> 
>> On Aug 8, 2012, at 11:07 AM, Alex Kotchnev wrote:
>> 
>>> Lenny - why do you think it would be a problem ?
>>> 
>>> Cheers - Alex K
>>> 
>>> On Wed, Aug 8, 2012 at 11:02 AM, Lenny Primak wrote:
>>> 
 I wouldn't use native shiro sessions with Tapestry.  This is a recipe
 for
 disaster.
 
 On Aug 8, 2012, at 10:59 AM, kata wrote:
 
> Alex,
> 
> thanks, I'll look into it.
> 
> Regards,
> Martin
> 
> 
> Alex Kotchnev-2 wrote
>> 
>> Martin,
>> it sounds like you might need to crack open the Tapestry source, but
>> it
>> seems doable. Although I don't know the details, I know for sure that
 the
>> @Persist annotation allows for different persistence strategies (e.g.
>> @Persist("flash")), which can be plugged by different modules (e.g.
>> JPA
>> and
>> Hibernate provide an "entity" strategy). So, it seems like if you look
 at
>> how Tapestry JPA contributes the "entity" strategy, you might be able
>> to
>> replace or add your own (e.g. 'shiroSession'). There probably is a way
 to
>> override the existing 'session' strategy w/ the one backed by Shiro's
>> Session (e.g. anywhere where you can "contribute" as the code below
 does,
>> you can also override).
>> 
>> Another example is Tynamo's tapestry-jdo module, e.g. :
>> 
 http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/JDOModule.html
 ;
>> 
 http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/internal/EntityPersistentFieldStrategy.html
>> 
>> 
>> Sorry I don't have more specific answers. I hope this helps.
>> 
>> Cheers,
>> 
>> Alex K
>> 
>> On Wed, Aug 8, 2012 at 10:04 AM, kata wrote:
>> 
>>> Alex,
>>> 
>>> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I
 switch
>>> the
>>> session manager to shiro's DefaultWebSessionManager. I do it this way
 to
>>> later cache and cluster session data with EhCache.
>>> What I need is a way to substitute the HttpSession tapestry is using
 with
>>> shiros' Session implementation. If I can do that, then I hope I can
>>> use
>>> the
>>> servlet API in the application instead of the shiro-specific calls.
>>> Ideally
>>> annotations would also work as intended, with clustering and all.
>>> 
>>> Regards,
>>> Martin
>>> 
>>> 
>>> Alex Kotchnev-2 wrote
 
 Martin,
 you really should be able to continue using @Persist and
>>> @SessionState.
 Both Shiro's subject.getSession() and the @Persist annotation store
>>> their
 values in the same http session. Is that not working for you ?
 
 Cheers,
 
 Alex K
 
 On Wed, Aug 8, 2012 at 7:20 AM, kata 
>>> wrote:
 
> Hi all,
> 
> I am currently using shiro and the tapestry-security plugin to
> manage
> sessions and persist data. Everything works fine when getting the
>>> session
> by
> SecurityUtils.getSubject().getSession(). However, this means that
> the
> application is peppered with fragments of shiro-specific code.
> Since
> shiro
> uses the servlet session API, is there a way to do this in a way
> that
>>> is
> transparent to the application, and hopefully still allow me to use
> annotations like @Persist and @Sessio

Re: Changing default session behavior.

[kata]

Having two sessions is actually what I'm trying to avoid - I want to use
shiro native sessions exclusively. My problem is that Tapestry by default
uses the servlet API to access the underlying HttpSession, so using
annotations like @Persist cause a second session to be created. If I can
intercept Tapestry calls to the servlet API and direct them to the shiro
session, then I can have only one session, properly clustered and, above
all, it'll be completely transparent to the application.


lprimak wrote
> 
> The whole point of a web session is to have only one.  Now he is winding
> up with two sessions.
> One web and one shiro native.
> How is he clustering the web session if he clusters
> the shiro native session differently?  Sounds like the 'web session' isn't
> working correctly in his case
> and he is trying to 'compensate' with Shiro, which is sooo wrong path to
> go.
> 
> On Aug 8, 2012, at 11:07 AM, Alex Kotchnev wrote:
> 
>> Lenny - why do you think it would be a problem ?
>> 
>> Cheers - Alex K
>> 
>> On Wed, Aug 8, 2012 at 11:02 AM, Lenny Primak wrote:
>> 
>>> I wouldn't use native shiro sessions with Tapestry.  This is a recipe
>>> for
>>> disaster.
>>> 
>>> On Aug 8, 2012, at 10:59 AM, kata wrote:
>>> 
 Alex,
 
 thanks, I'll look into it.
 
 Regards,
 Martin
 
 
 Alex Kotchnev-2 wrote
> 
> Martin,
> it sounds like you might need to crack open the Tapestry source, but
> it
> seems doable. Although I don't know the details, I know for sure that
>>> the
> @Persist annotation allows for different persistence strategies (e.g.
> @Persist("flash")), which can be plugged by different modules (e.g.
> JPA
> and
> Hibernate provide an "entity" strategy). So, it seems like if you look
>>> at
> how Tapestry JPA contributes the "entity" strategy, you might be able
> to
> replace or add your own (e.g. 'shiroSession'). There probably is a way
>>> to
> override the existing 'session' strategy w/ the one backed by Shiro's
> Session (e.g. anywhere where you can "contribute" as the code below
>>> does,
> you can also override).
> 
>  Another example is Tynamo's tapestry-jdo module, e.g. :
> 
>>> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/JDOModule.html
>>> ;
> 
>>> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/internal/EntityPersistentFieldStrategy.html
> 
> 
>  Sorry I don't have more specific answers. I hope this helps.
> 
> Cheers,
> 
> Alex K
> 
> On Wed, Aug 8, 2012 at 10:04 AM, kata >> >wrote:
> 
>> Alex,
>> 
>> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I
>>> switch
>> the
>> session manager to shiro's DefaultWebSessionManager. I do it this way
>>> to
>> later cache and cluster session data with EhCache.
>> What I need is a way to substitute the HttpSession tapestry is using
>>> with
>> shiros' Session implementation. If I can do that, then I hope I can
>> use
>> the
>> servlet API in the application instead of the shiro-specific calls.
>> Ideally
>> annotations would also work as intended, with clustering and all.
>> 
>> Regards,
>> Martin
>> 
>> 
>> Alex Kotchnev-2 wrote
>>> 
>>> Martin,
>>> you really should be able to continue using @Persist and
>> @SessionState.
>>> Both Shiro's subject.getSession() and the @Persist annotation store
>> their
>>> values in the same http session. Is that not working for you ?
>>> 
>>> Cheers,
>>> 
>>> Alex K
>>> 
>>> On Wed, Aug 8, 2012 at 7:20 AM, kata 
>> wrote:
>>> 
 Hi all,
 
 I am currently using shiro and the tapestry-security plugin to
 manage
 sessions and persist data. Everything works fine when getting the
>> session
 by
 SecurityUtils.getSubject().getSession(). However, this means that
 the
 application is peppered with fragments of shiro-specific code.
 Since
 shiro
 uses the servlet session API, is there a way to do this in a way
 that
>> is
 transparent to the application, and hopefully still allow me to use
 annotations like @Persist and @SessionState?
 
 Thanks,
 Martin
 
 
 
 --
 View this message in context:
 
>> 
>>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
 Sent from the Tapestry - User mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscribe@.apache
 For additional 

Re: Changing default session behavior.

[Lenny Primak]

The whole point of a web session is to have only one.  Now he is winding up 
with two sessions.
One web and one shiro native.
How is he clustering the web session if he clusters
the shiro native session differently?  Sounds like the 'web session' isn't 
working correctly in his case
and he is trying to 'compensate' with Shiro, which is sooo wrong path to go.

On Aug 8, 2012, at 11:07 AM, Alex Kotchnev wrote:

> Lenny - why do you think it would be a problem ?
> 
> Cheers - Alex K
> 
> On Wed, Aug 8, 2012 at 11:02 AM, Lenny Primak wrote:
> 
>> I wouldn't use native shiro sessions with Tapestry.  This is a recipe for
>> disaster.
>> 
>> On Aug 8, 2012, at 10:59 AM, kata wrote:
>> 
>>> Alex,
>>> 
>>> thanks, I'll look into it.
>>> 
>>> Regards,
>>> Martin
>>> 
>>> 
>>> Alex Kotchnev-2 wrote
 
 Martin,
 it sounds like you might need to crack open the Tapestry source, but it
 seems doable. Although I don't know the details, I know for sure that
>> the
 @Persist annotation allows for different persistence strategies (e.g.
 @Persist("flash")), which can be plugged by different modules (e.g. JPA
 and
 Hibernate provide an "entity" strategy). So, it seems like if you look
>> at
 how Tapestry JPA contributes the "entity" strategy, you might be able to
 replace or add your own (e.g. 'shiroSession'). There probably is a way
>> to
 override the existing 'session' strategy w/ the one backed by Shiro's
 Session (e.g. anywhere where you can "contribute" as the code below
>> does,
 you can also override).
 
  Another example is Tynamo's tapestry-jdo module, e.g. :
 
>> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/JDOModule.html
>> ;
 
>> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/internal/EntityPersistentFieldStrategy.html
 
 
  Sorry I don't have more specific answers. I hope this helps.
 
 Cheers,
 
 Alex K
 
 On Wed, Aug 8, 2012 at 10:04 AM, kata > >wrote:
 
> Alex,
> 
> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I
>> switch
> the
> session manager to shiro's DefaultWebSessionManager. I do it this way
>> to
> later cache and cluster session data with EhCache.
> What I need is a way to substitute the HttpSession tapestry is using
>> with
> shiros' Session implementation. If I can do that, then I hope I can use
> the
> servlet API in the application instead of the shiro-specific calls.
> Ideally
> annotations would also work as intended, with clustering and all.
> 
> Regards,
> Martin
> 
> 
> Alex Kotchnev-2 wrote
>> 
>> Martin,
>> you really should be able to continue using @Persist and
> @SessionState.
>> Both Shiro's subject.getSession() and the @Persist annotation store
> their
>> values in the same http session. Is that not working for you ?
>> 
>> Cheers,
>> 
>> Alex K
>> 
>> On Wed, Aug 8, 2012 at 7:20 AM, kata 
> wrote:
>> 
>>> Hi all,
>>> 
>>> I am currently using shiro and the tapestry-security plugin to manage
>>> sessions and persist data. Everything works fine when getting the
> session
>>> by
>>> SecurityUtils.getSubject().getSession(). However, this means that the
>>> application is peppered with fragments of shiro-specific code. Since
>>> shiro
>>> uses the servlet session API, is there a way to do this in a way that
> is
>>> transparent to the application, and hopefully still allow me to use
>>> annotations like @Persist and @SessionState?
>>> 
>>> Thanks,
>>> Martin
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> 
> 
>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@.apache
>>> For additional commands, e-mail: users-help@.apache
>>> 
>>> 
>> 
> 
> 
> 
> 
> --
> View this message in context:
> 
>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscribe@.apache
> For additional commands, e-mail: users-help@.apache
> 
> 
 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715160.html
>>> Sent from the Tapestry - User maili

Re: Changing default session behavior.

[Alex Kotchnev]

Lenny - why do you think it would be a problem ?

Cheers - Alex K

On Wed, Aug 8, 2012 at 11:02 AM, Lenny Primak wrote:

> I wouldn't use native shiro sessions with Tapestry.  This is a recipe for
> disaster.
>
> On Aug 8, 2012, at 10:59 AM, kata wrote:
>
> > Alex,
> >
> > thanks, I'll look into it.
> >
> > Regards,
> > Martin
> >
> >
> > Alex Kotchnev-2 wrote
> >>
> >> Martin,
> >>  it sounds like you might need to crack open the Tapestry source, but it
> >> seems doable. Although I don't know the details, I know for sure that
> the
> >> @Persist annotation allows for different persistence strategies (e.g.
> >> @Persist("flash")), which can be plugged by different modules (e.g. JPA
> >> and
> >> Hibernate provide an "entity" strategy). So, it seems like if you look
> at
> >> how Tapestry JPA contributes the "entity" strategy, you might be able to
> >> replace or add your own (e.g. 'shiroSession'). There probably is a way
> to
> >> override the existing 'session' strategy w/ the one backed by Shiro's
> >> Session (e.g. anywhere where you can "contribute" as the code below
> does,
> >> you can also override).
> >>
> >>   Another example is Tynamo's tapestry-jdo module, e.g. :
> >>
> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/JDOModule.html
> ;
> >>
> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/internal/EntityPersistentFieldStrategy.html
> >>
> >>
> >>   Sorry I don't have more specific answers. I hope this helps.
> >>
> >> Cheers,
> >>
> >> Alex K
> >>
> >> On Wed, Aug 8, 2012 at 10:04 AM, kata  >wrote:
> >>
> >>> Alex,
> >>>
> >>> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I
> switch
> >>> the
> >>> session manager to shiro's DefaultWebSessionManager. I do it this way
> to
> >>> later cache and cluster session data with EhCache.
> >>> What I need is a way to substitute the HttpSession tapestry is using
> with
> >>> shiros' Session implementation. If I can do that, then I hope I can use
> >>> the
> >>> servlet API in the application instead of the shiro-specific calls.
> >>> Ideally
> >>> annotations would also work as intended, with clustering and all.
> >>>
> >>> Regards,
> >>> Martin
> >>>
> >>>
> >>> Alex Kotchnev-2 wrote
> 
>  Martin,
>   you really should be able to continue using @Persist and
> >>> @SessionState.
>  Both Shiro's subject.getSession() and the @Persist annotation store
> >>> their
>  values in the same http session. Is that not working for you ?
> 
>  Cheers,
> 
>  Alex K
> 
>  On Wed, Aug 8, 2012 at 7:20 AM, kata 
> >>> wrote:
> 
> > Hi all,
> >
> > I am currently using shiro and the tapestry-security plugin to manage
> > sessions and persist data. Everything works fine when getting the
> >>> session
> > by
> > SecurityUtils.getSubject().getSession(). However, this means that the
> > application is peppered with fragments of shiro-specific code. Since
> > shiro
> > uses the servlet session API, is there a way to do this in a way that
> >>> is
> > transparent to the application, and hopefully still allow me to use
> > annotations like @Persist and @SessionState?
> >
> > Thanks,
> > Martin
> >
> >
> >
> > --
> > View this message in context:
> >
> >>>
> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
> > Sent from the Tapestry - User mailing list archive at Nabble.com.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscribe@.apache
> > For additional commands, e-mail: users-help@.apache
> >
> >
> 
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context:
> >>>
> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.html
> >>> Sent from the Tapestry - User mailing list archive at Nabble.com.
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscribe@.apache
> >>> For additional commands, e-mail: users-help@.apache
> >>>
> >>>
> >>
> >
> >
> >
> >
> > --
> > View this message in context:
> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715160.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
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: Changing default session behavior.

[Lenny Primak]

I wouldn't use native shiro sessions with Tapestry.  This is a recipe for 
disaster.

On Aug 8, 2012, at 10:59 AM, kata wrote:

> Alex,
> 
> thanks, I'll look into it.
> 
> Regards,
> Martin
> 
> 
> Alex Kotchnev-2 wrote
>> 
>> Martin,
>>  it sounds like you might need to crack open the Tapestry source, but it
>> seems doable. Although I don't know the details, I know for sure that the
>> @Persist annotation allows for different persistence strategies (e.g.
>> @Persist("flash")), which can be plugged by different modules (e.g. JPA
>> and
>> Hibernate provide an "entity" strategy). So, it seems like if you look at
>> how Tapestry JPA contributes the "entity" strategy, you might be able to
>> replace or add your own (e.g. 'shiroSession'). There probably is a way to
>> override the existing 'session' strategy w/ the one backed by Shiro's
>> Session (e.g. anywhere where you can "contribute" as the code below does,
>> you can also override).
>> 
>>   Another example is Tynamo's tapestry-jdo module, e.g. :
>> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/JDOModule.html;
>> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/internal/EntityPersistentFieldStrategy.html
>> 
>> 
>>   Sorry I don't have more specific answers. I hope this helps.
>> 
>> Cheers,
>> 
>> Alex K
>> 
>> On Wed, Aug 8, 2012 at 10:04 AM, kata wrote:
>> 
>>> Alex,
>>> 
>>> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I switch
>>> the
>>> session manager to shiro's DefaultWebSessionManager. I do it this way to
>>> later cache and cluster session data with EhCache.
>>> What I need is a way to substitute the HttpSession tapestry is using with
>>> shiros' Session implementation. If I can do that, then I hope I can use
>>> the
>>> servlet API in the application instead of the shiro-specific calls.
>>> Ideally
>>> annotations would also work as intended, with clustering and all.
>>> 
>>> Regards,
>>> Martin
>>> 
>>> 
>>> Alex Kotchnev-2 wrote
 
 Martin,
  you really should be able to continue using @Persist and
>>> @SessionState.
 Both Shiro's subject.getSession() and the @Persist annotation store
>>> their
 values in the same http session. Is that not working for you ?
 
 Cheers,
 
 Alex K
 
 On Wed, Aug 8, 2012 at 7:20 AM, kata 
>>> wrote:
 
> Hi all,
> 
> I am currently using shiro and the tapestry-security plugin to manage
> sessions and persist data. Everything works fine when getting the
>>> session
> by
> SecurityUtils.getSubject().getSession(). However, this means that the
> application is peppered with fragments of shiro-specific code. Since
> shiro
> uses the servlet session API, is there a way to do this in a way that
>>> is
> transparent to the application, and hopefully still allow me to use
> annotations like @Persist and @SessionState?
> 
> Thanks,
> Martin
> 
> 
> 
> --
> View this message in context:
> 
>>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscribe@.apache
> For additional commands, e-mail: users-help@.apache
> 
> 
 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@.apache
>>> For additional commands, e-mail: users-help@.apache
>>> 
>>> 
>> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715160.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
> 


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Changing default session behavior.

[Alex Kotchnev]

It seems that you could override the session persistence strategy and
replace the usage of http session with Shiro's session -e.g. the
implementation seems to be pretty straightforward e.g. inside of Tapestry ,
look at SessionApplicationStatePersistenceStrategy (
http://www.koders.com/java/fidD25B085EE97B4962767F605CD9762E1E9A50DFA6.aspx?s=base64
).

Cheers,

Alex K

On Wed, Aug 8, 2012 at 10:51 AM, Lenny Primak wrote:

> So you are using native Shiro session management.  Tapestry / Servlet API
> don't support that.
> If you use a 'real' JEE server like Glassfish, web sessions are clustered
> / cached properly for you,
> without Shiro native sessions or customDAO etc.
>
> You cannot use Shiro native session management and expect it to propagate
> to Servlet sessions.  This just doesn't make sense.
>
>
> On Aug 8, 2012, at 10:48 AM, kata wrote:
>
> > i
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Re: Changing default session behavior.

[kata]

Alex,

thanks, I'll look into it.

Regards,
Martin


Alex Kotchnev-2 wrote
> 
> Martin,
>   it sounds like you might need to crack open the Tapestry source, but it
> seems doable. Although I don't know the details, I know for sure that the
> @Persist annotation allows for different persistence strategies (e.g.
> @Persist("flash")), which can be plugged by different modules (e.g. JPA
> and
> Hibernate provide an "entity" strategy). So, it seems like if you look at
> how Tapestry JPA contributes the "entity" strategy, you might be able to
> replace or add your own (e.g. 'shiroSession'). There probably is a way to
> override the existing 'session' strategy w/ the one backed by Shiro's
> Session (e.g. anywhere where you can "contribute" as the code below does,
> you can also override).
> 
>Another example is Tynamo's tapestry-jdo module, e.g. :
> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/JDOModule.html;
> http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/internal/EntityPersistentFieldStrategy.html
> 
> 
>Sorry I don't have more specific answers. I hope this helps.
> 
> Cheers,
> 
> Alex K
> 
> On Wed, Aug 8, 2012 at 10:04 AM, kata wrote:
> 
>> Alex,
>>
>> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I switch
>> the
>> session manager to shiro's DefaultWebSessionManager. I do it this way to
>> later cache and cluster session data with EhCache.
>> What I need is a way to substitute the HttpSession tapestry is using with
>> shiros' Session implementation. If I can do that, then I hope I can use
>> the
>> servlet API in the application instead of the shiro-specific calls.
>> Ideally
>> annotations would also work as intended, with clustering and all.
>>
>> Regards,
>> Martin
>>
>>
>> Alex Kotchnev-2 wrote
>> >
>> > Martin,
>> >   you really should be able to continue using @Persist and
>> @SessionState.
>> > Both Shiro's subject.getSession() and the @Persist annotation store
>> their
>> > values in the same http session. Is that not working for you ?
>> >
>> > Cheers,
>> >
>> > Alex K
>> >
>> > On Wed, Aug 8, 2012 at 7:20 AM, kata 
>> wrote:
>> >
>> >> Hi all,
>> >>
>> >> I am currently using shiro and the tapestry-security plugin to manage
>> >> sessions and persist data. Everything works fine when getting the
>> session
>> >> by
>> >> SecurityUtils.getSubject().getSession(). However, this means that the
>> >> application is peppered with fragments of shiro-specific code. Since
>> >> shiro
>> >> uses the servlet session API, is there a way to do this in a way that
>> is
>> >> transparent to the application, and hopefully still allow me to use
>> >> annotations like @Persist and @SessionState?
>> >>
>> >> Thanks,
>> >> Martin
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
>> >> Sent from the Tapestry - User mailing list archive at Nabble.com.
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscribe@.apache
>> >> For additional commands, e-mail: users-help@.apache
>> >>
>> >>
>> >
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscribe@.apache
>> For additional commands, e-mail: users-help@.apache
>>
>>
> 




--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715160.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: Changing default session behavior.

[Lenny Primak]

So you are using native Shiro session management.  Tapestry / Servlet API don't 
support that.
If you use a 'real' JEE server like Glassfish, web sessions are clustered / 
cached properly for you,
without Shiro native sessions or customDAO etc.

You cannot use Shiro native session management and expect it to propagate to 
Servlet sessions.  This just doesn't make sense.


On Aug 8, 2012, at 10:48 AM, kata wrote:

> i


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Changing default session behavior.

[kata]

The problem with this is that while the servlet session manager doesn't
support a custom sessoinDAO, which i need for caching and clustering
sessions. Using native session is the only way to do that (as far as i
know).


lprimak wrote
> 
> Are you 'forcing' Shiro's native session management?  If you are then you
> will get that behavior.
> My suggestion is for you not to do it.  The Tynamo security's default
> configuration works just great.
> Tapestry does not have its own session management, it's just a wrapper for
> Servlet's one.
> Shiro, on the other hand, does, if you enable it.  You shouldn't do that
> in a web/tapestry environment.
> 
> On Aug 8, 2012, at 10:30 AM, kata wrote:
> 
>> Then there must be some crucial bit of configuration I'm missing. Every
>> time
>> I visit a page which uses a @Persist annotation, tapestry ignores shiros'
>> session and tries to access its own. If I don't change the cookie names,
>> shiro and tapestry overwrite the default JSESSION cookie and nothing
>> works.
>> If i change shiros cookie name then values managed by @Persist are
>> persisted, but not clustered like values managed by shiro.
>> 
>> 
>> lprimak wrote
>>> 
>>> As Alex said before, the backing objects for all session management,
>>> Shiro's, Tapestry, and Servlet
>>> are the same objects.  You are already using the exact same session
>>> management objects.
>>> 
>>> On Aug 8, 2012, at 10:04 AM, kata wrote:
>>> 
 Alex,
 
 I'm sorry, I wasn't clear - I'm using native shiro sessions, so I
 switch
 the
 session manager to shiro's DefaultWebSessionManager. I do it this way
 to
 later cache and cluster session data with EhCache.
 What I need is a way to substitute the HttpSession tapestry is using
 with
 shiros' Session implementation. If I can do that, then I hope I can use
 the
 servlet API in the application instead of the shiro-specific calls.
 Ideally
 annotations would also work as intended, with clustering and all.
 
 Regards,
 Martin
 
 
 Alex Kotchnev-2 wrote
> 
> Martin,
> you really should be able to continue using @Persist and
> @SessionState.
> Both Shiro's subject.getSession() and the @Persist annotation store
> their
> values in the same http session. Is that not working for you ?
> 
> Cheers,
> 
> Alex K
> 
> On Wed, Aug 8, 2012 at 7:20 AM, kata 
> wrote:
> 
>> Hi all,
>> 
>> I am currently using shiro and the tapestry-security plugin to manage
>> sessions and persist data. Everything works fine when getting the
>> session
>> by
>> SecurityUtils.getSubject().getSession(). However, this means that the
>> application is peppered with fragments of shiro-specific code. Since
>> shiro
>> uses the servlet session API, is there a way to do this in a way that
>> is
>> transparent to the application, and hopefully still allow me to use
>> annotations like @Persist and @SessionState?
>> 
>> Thanks,
>> Martin
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscribe@.apache
>> For additional commands, e-mail: users-help@.apache
>> 
>> 
> 
 
 
 
 
 --
 View this message in context:
 http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.html
 Sent from the Tapestry - User mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscribe@.apache
 For additional commands, e-mail: users-help@.apache
 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@.apache
>>> For additional commands, e-mail: users-help@.apache
>>> 
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715155.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscribe@.apache
>> For additional commands, e-mail: users-help@.apache
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscribe@.apache
> For additional commands, e-mail: users-help@.apache
> 




--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715157.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

---

Re: Changing default session behavior.

[Lenny Primak]

Are you 'forcing' Shiro's native session management?  If you are then you will 
get that behavior.
My suggestion is for you not to do it.  The Tynamo security's default 
configuration works just great.
Tapestry does not have its own session management, it's just a wrapper for 
Servlet's one.
Shiro, on the other hand, does, if you enable it.  You shouldn't do that in a 
web/tapestry environment.

On Aug 8, 2012, at 10:30 AM, kata wrote:

> Then there must be some crucial bit of configuration I'm missing. Every time
> I visit a page which uses a @Persist annotation, tapestry ignores shiros'
> session and tries to access its own. If I don't change the cookie names,
> shiro and tapestry overwrite the default JSESSION cookie and nothing works.
> If i change shiros cookie name then values managed by @Persist are
> persisted, but not clustered like values managed by shiro.
> 
> 
> lprimak wrote
>> 
>> As Alex said before, the backing objects for all session management,
>> Shiro's, Tapestry, and Servlet
>> are the same objects.  You are already using the exact same session
>> management objects.
>> 
>> On Aug 8, 2012, at 10:04 AM, kata wrote:
>> 
>>> Alex,
>>> 
>>> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I switch
>>> the
>>> session manager to shiro's DefaultWebSessionManager. I do it this way to
>>> later cache and cluster session data with EhCache.
>>> What I need is a way to substitute the HttpSession tapestry is using with
>>> shiros' Session implementation. If I can do that, then I hope I can use
>>> the
>>> servlet API in the application instead of the shiro-specific calls.
>>> Ideally
>>> annotations would also work as intended, with clustering and all.
>>> 
>>> Regards,
>>> Martin
>>> 
>>> 
>>> Alex Kotchnev-2 wrote
 
 Martin,
 you really should be able to continue using @Persist and @SessionState.
 Both Shiro's subject.getSession() and the @Persist annotation store
 their
 values in the same http session. Is that not working for you ?
 
 Cheers,
 
 Alex K
 
 On Wed, Aug 8, 2012 at 7:20 AM, kata 
 wrote:
 
> Hi all,
> 
> I am currently using shiro and the tapestry-security plugin to manage
> sessions and persist data. Everything works fine when getting the
> session
> by
> SecurityUtils.getSubject().getSession(). However, this means that the
> application is peppered with fragments of shiro-specific code. Since
> shiro
> uses the servlet session API, is there a way to do this in a way that
> is
> transparent to the application, and hopefully still allow me to use
> annotations like @Persist and @SessionState?
> 
> Thanks,
> Martin
> 
> 
> 
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscribe@.apache
> For additional commands, e-mail: users-help@.apache
> 
> 
 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@.apache
>>> For additional commands, e-mail: users-help@.apache
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscribe@.apache
>> For additional commands, e-mail: users-help@.apache
>> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715155.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
> 


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Changing default session behavior.

[kata]

Then there must be some crucial bit of configuration I'm missing. Every time
I visit a page which uses a @Persist annotation, tapestry ignores shiros'
session and tries to access its own. If I don't change the cookie names,
shiro and tapestry overwrite the default JSESSION cookie and nothing works.
If i change shiros cookie name then values managed by @Persist are
persisted, but not clustered like values managed by shiro.


lprimak wrote
> 
> As Alex said before, the backing objects for all session management,
> Shiro's, Tapestry, and Servlet
> are the same objects.  You are already using the exact same session
> management objects.
> 
> On Aug 8, 2012, at 10:04 AM, kata wrote:
> 
>> Alex,
>> 
>> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I switch
>> the
>> session manager to shiro's DefaultWebSessionManager. I do it this way to
>> later cache and cluster session data with EhCache.
>> What I need is a way to substitute the HttpSession tapestry is using with
>> shiros' Session implementation. If I can do that, then I hope I can use
>> the
>> servlet API in the application instead of the shiro-specific calls.
>> Ideally
>> annotations would also work as intended, with clustering and all.
>> 
>> Regards,
>> Martin
>> 
>> 
>> Alex Kotchnev-2 wrote
>>> 
>>> Martin,
>>>  you really should be able to continue using @Persist and @SessionState.
>>> Both Shiro's subject.getSession() and the @Persist annotation store
>>> their
>>> values in the same http session. Is that not working for you ?
>>> 
>>> Cheers,
>>> 
>>> Alex K
>>> 
>>> On Wed, Aug 8, 2012 at 7:20 AM, kata 
>>> wrote:
>>> 
 Hi all,
 
 I am currently using shiro and the tapestry-security plugin to manage
 sessions and persist data. Everything works fine when getting the
 session
 by
 SecurityUtils.getSubject().getSession(). However, this means that the
 application is peppered with fragments of shiro-specific code. Since
 shiro
 uses the servlet session API, is there a way to do this in a way that
 is
 transparent to the application, and hopefully still allow me to use
 annotations like @Persist and @SessionState?
 
 Thanks,
 Martin
 
 
 
 --
 View this message in context:
 http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
 Sent from the Tapestry - User mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscribe@.apache
 For additional commands, e-mail: users-help@.apache
 
 
>>> 
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscribe@.apache
>> For additional commands, e-mail: users-help@.apache
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscribe@.apache
> For additional commands, e-mail: users-help@.apache
> 




--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715155.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: Changing default session behavior.

[Alex Kotchnev]

Martin,
  it sounds like you might need to crack open the Tapestry source, but it
seems doable. Although I don't know the details, I know for sure that the
@Persist annotation allows for different persistence strategies (e.g.
@Persist("flash")), which can be plugged by different modules (e.g. JPA and
Hibernate provide an "entity" strategy). So, it seems like if you look at
how Tapestry JPA contributes the "entity" strategy, you might be able to
replace or add your own (e.g. 'shiroSession'). There probably is a way to
override the existing 'session' strategy w/ the one backed by Shiro's
Session (e.g. anywhere where you can "contribute" as the code below does,
you can also override).

   Another example is Tynamo's tapestry-jdo module, e.g. :
http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/JDOModule.html
http://tynamo.org/constant/sites/tapestry-jdo/tapestry-jdo/xref/org/tynamo/jdo/internal/EntityPersistentFieldStrategy.html


   Sorry I don't have more specific answers. I hope this helps.

Cheers,

Alex K

On Wed, Aug 8, 2012 at 10:04 AM, kata wrote:

> Alex,
>
> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I switch
> the
> session manager to shiro's DefaultWebSessionManager. I do it this way to
> later cache and cluster session data with EhCache.
> What I need is a way to substitute the HttpSession tapestry is using with
> shiros' Session implementation. If I can do that, then I hope I can use the
> servlet API in the application instead of the shiro-specific calls. Ideally
> annotations would also work as intended, with clustering and all.
>
> Regards,
> Martin
>
>
> Alex Kotchnev-2 wrote
> >
> > Martin,
> >   you really should be able to continue using @Persist and @SessionState.
> > Both Shiro's subject.getSession() and the @Persist annotation store their
> > values in the same http session. Is that not working for you ?
> >
> > Cheers,
> >
> > Alex K
> >
> > On Wed, Aug 8, 2012 at 7:20 AM, kata 
> wrote:
> >
> >> Hi all,
> >>
> >> I am currently using shiro and the tapestry-security plugin to manage
> >> sessions and persist data. Everything works fine when getting the
> session
> >> by
> >> SecurityUtils.getSubject().getSession(). However, this means that the
> >> application is peppered with fragments of shiro-specific code. Since
> >> shiro
> >> uses the servlet session API, is there a way to do this in a way that is
> >> transparent to the application, and hopefully still allow me to use
> >> annotations like @Persist and @SessionState?
> >>
> >> Thanks,
> >> Martin
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
> >> Sent from the Tapestry - User mailing list archive at Nabble.com.
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscribe@.apache
> >> For additional commands, e-mail: users-help@.apache
> >>
> >>
> >
>
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.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: Changing default session behavior.

[Kalle Korhonen]

On Wed, Aug 8, 2012 at 4:20 AM, kata  wrote:
> I am currently using shiro and the tapestry-security plugin to manage
> sessions and persist data. Everything works fine when getting the session by
> SecurityUtils.getSubject().getSession(). However, this means that the
> application is peppered with fragments of shiro-specific code. Since shiro
> uses the servlet session API, is there a way to do this in a way that is
> transparent to the application, and hopefully still allow me to use
> annotations like @Persist and @SessionState?

You should never need to use SecurityUtils. Use SecurityService
(http://tynamo.org/constant/sites/tapestry-security/apidocs/org/tynamo/security/services/SecurityService.html)
and it's getSubject() if you need to access the Subject directly. Note
that Subject is a Shiro specific class, so calling anything after that
is a fair game. However, for regular session access you don't need to
use anything Shiro specific. For basic cases, you can also stick with
servlet-api's security support (namely
HttpServletREquest.getRemoteUser() and isUserInRole(...) ),
tapestry-security fully supports the standard servlet api.

Kalle

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Changing default session behavior.

[Lenny Primak]

As Alex said before, the backing objects for all session management, Shiro's, 
Tapestry, and Servlet
are the same objects.  You are already using the exact same session management 
objects.

On Aug 8, 2012, at 10:04 AM, kata wrote:

> Alex,
> 
> I'm sorry, I wasn't clear - I'm using native shiro sessions, so I switch the
> session manager to shiro's DefaultWebSessionManager. I do it this way to
> later cache and cluster session data with EhCache.
> What I need is a way to substitute the HttpSession tapestry is using with
> shiros' Session implementation. If I can do that, then I hope I can use the
> servlet API in the application instead of the shiro-specific calls. Ideally
> annotations would also work as intended, with clustering and all.
> 
> Regards,
> Martin
> 
> 
> Alex Kotchnev-2 wrote
>> 
>> Martin,
>>  you really should be able to continue using @Persist and @SessionState.
>> Both Shiro's subject.getSession() and the @Persist annotation store their
>> values in the same http session. Is that not working for you ?
>> 
>> Cheers,
>> 
>> Alex K
>> 
>> On Wed, Aug 8, 2012 at 7:20 AM, kata  wrote:
>> 
>>> Hi all,
>>> 
>>> I am currently using shiro and the tapestry-security plugin to manage
>>> sessions and persist data. Everything works fine when getting the session
>>> by
>>> SecurityUtils.getSubject().getSession(). However, this means that the
>>> application is peppered with fragments of shiro-specific code. Since
>>> shiro
>>> uses the servlet session API, is there a way to do this in a way that is
>>> transparent to the application, and hopefully still allow me to use
>>> annotations like @Persist and @SessionState?
>>> 
>>> Thanks,
>>> Martin
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@.apache
>>> For additional commands, e-mail: users-help@.apache
>>> 
>>> 
>> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.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
> 


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Changing default session behavior.

[kata]

Alex,

I'm sorry, I wasn't clear - I'm using native shiro sessions, so I switch the
session manager to shiro's DefaultWebSessionManager. I do it this way to
later cache and cluster session data with EhCache.
What I need is a way to substitute the HttpSession tapestry is using with
shiros' Session implementation. If I can do that, then I hope I can use the
servlet API in the application instead of the shiro-specific calls. Ideally
annotations would also work as intended, with clustering and all.

Regards,
Martin


Alex Kotchnev-2 wrote
> 
> Martin,
>   you really should be able to continue using @Persist and @SessionState.
> Both Shiro's subject.getSession() and the @Persist annotation store their
> values in the same http session. Is that not working for you ?
> 
> Cheers,
> 
> Alex K
> 
> On Wed, Aug 8, 2012 at 7:20 AM, kata  wrote:
> 
>> Hi all,
>>
>> I am currently using shiro and the tapestry-security plugin to manage
>> sessions and persist data. Everything works fine when getting the session
>> by
>> SecurityUtils.getSubject().getSession(). However, this means that the
>> application is peppered with fragments of shiro-specific code. Since
>> shiro
>> uses the servlet session API, is there a way to do this in a way that is
>> transparent to the application, and hopefully still allow me to use
>> annotations like @Persist and @SessionState?
>>
>> Thanks,
>> Martin
>>
>>
>>
>> --
>> View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscribe@.apache
>> For additional commands, e-mail: users-help@.apache
>>
>>
> 




--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141p5715150.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: Changing default session behavior.

[Alex Kotchnev]

Martin,
  you really should be able to continue using @Persist and @SessionState.
Both Shiro's subject.getSession() and the @Persist annotation store their
values in the same http session. Is that not working for you ?

Cheers,

Alex K

On Wed, Aug 8, 2012 at 7:20 AM, kata  wrote:

> Hi all,
>
> I am currently using shiro and the tapestry-security plugin to manage
> sessions and persist data. Everything works fine when getting the session
> by
> SecurityUtils.getSubject().getSession(). However, this means that the
> application is peppered with fragments of shiro-specific code. Since shiro
> uses the servlet session API, is there a way to do this in a way that is
> transparent to the application, and hopefully still allow me to use
> annotations like @Persist and @SessionState?
>
> Thanks,
> Martin
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.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: Lightweight TapestryTools update site

[Gavin Lei]

Hey,

Sorry to hear that, i did not test it in the condition of many tml
files open in the workbench.

Yeah, it was built on XML editor, just add many tapestry features,
auto-complete features, i have no ideas how it happen. I will test it
and find out the reason.

2012/8/8 antalk :
> Hi Gavin,
>
> I had to uninstall your plugin from my eclipse environment (juno) it became
> terribly slow when i had about 30 tml pages open. I just could not work with
> it anymore.
>
> I'm sorry that i have no logs or errors, it just became awfully slow..
>
> It may have something todo with the fact that the TML editor is based (or
> derived) from the XML editor ?? i know link 'tml' pages to the JSP editor
> and it works much faster.
>
> Antal
>
>
>
> --
> View this message in context: 
> http://tapestry.1045711.n5.nabble.com/Lightweight-TapestryTools-update-site-tp5610392p5715142.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
>



-- 
-
Best Regards
Gavin Lei (雷银)
Email: gavingui2...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Lightweight TapestryTools update site

[Gavin Lei]

Hi Athneria,

This feature support only custom components in project's source
directory, not consider components in jars, maybe i should also add
jars support.

2012/8/7 Athneria, Mahendra :
> Hi Gavin,
>
> I took the update and trying to test the custom components support feature 
> with different prefix.
> I have some doubts regarding the same.
>
> A) - We have a nice editor in which developer enters mapping :> - we can only 
> edit the custom components by right click on the project. And when I click on 
> (+) button I can only see the packages from my project only. I am not able to 
> see the components package from different libraries. So how I can do the 
> same. I tried to achieve the same by editing "components.tcc" file. Below is 
> the example.
>
> 
> 
> 
>  
> 
>  
>  path="net.awl.tapestry5.kawwa.components"/>
> 
> 
>
> Even thought I am not able to get the " Breadcrumb " name when I press 
> "ctrl+space" on tml file.
>
> Any idea Gavin??
>
> Regards,
> Mahendra Athneria
>
>
> -Original Message-
> From: Gavin Lei [mailto:gavingui2...@gmail.com]
> Sent: Monday, August 06, 2012 6:21 PM
> To: Tapestry users
> Cc: Igor Drobiazko
> Subject: Re: Lightweight TapestryTools update site
>
>
> Hi all,
>
> In TapestryTools' components auto-complete feature, by default only
> components defined in these two packages are in the list:
>
> 1.org.apache.tapestry5.corelib.components (Tapestry 5's build-in components)
> 2.app-package.components, whereby app-package is the applications root
> package defined in the web.xml (Tapestry web application's root
> components)
>
> Now, I have add custom components support for TapestryTools. It means
> besides these components, TapestryTools support also custom components
> with different prefix with "t:". It allow you to provide
> autocompletion for custom components from different libraries, and we
> have a nice editor in which developer enters mapping:
>
> x: org.example.components
> y: org.acme.lib.components
>
> In this mapping, a library prefix is mapped to a component package.
> So, every component from org.example.components package would have x
> prefix. For example:
>
> 
> 
>
> This feature is alreay available in TapestryTools' update site [1],
> and you can find detailed guide about this feature and the "Custom
> components mapping editor" here [2] (It is in Section 7).
>
> Looking forward to your feedbacks about TapestryTools and this new
> feature, thanks.
>
> [1] http://tapestrytools.googlecode.com/svn/TapestryTools/
> [2] 
> http://code.google.com/p/tapestrytools/wiki/Install_Guide_Lightweight_TapestryTools
> --
> -
> Best Regards
> Gavin Lei (雷银)
> Email: gavingui2...@gmail.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org



-- 
-
Best Regards
Gavin Lei (雷银)
Email: gavingui2...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Lightweight TapestryTools update site

[Gavin Lei]

HI Christian,

Thanks for your feedback, this issue is in my schedule now :-)

2012/8/7 Christian Riedel :
> Hi Gavin,
>
> I've been using the jump-to-file function of your plugin for a while now and 
> I also noticed something that might be quite easy to fix:
> When you have multiple Index pages the plugin always jumps to the first index 
> page it finds, which is in my case the root Index page.
>
> com.tap.pages.Index.java
> com.tap.pages.profile.Index.java
>
> Jumping back and forth between those always leads me to the root Index page. 
> Maybe you should also take the package into account not only the filename. 
> Maybe it will also fail if other pages have the same name but different 
> packages (didn't test that case).
>
> But thanks for the plugin anyway! You did a good job! :-)
>
> Cheers,
> Christian
>
>
>
> Am 07.08.2012 um 12:25 schrieb Gavin Lei:
>
>> Hi,
>>
>> Thanks for your feedback, TapestryTools now just look for the "same"
>> filename, it does not support your situation yet.
>>
>> 2012/8/6 antalk :
>>> Hi,
>>>
>>> I just installed the plugin in eclipse 'juno'. It works fine but it can not
>>> match named translated TML pages to the correct class.
>>>
>>> What i mean:
>>>
>>> I have several template pages which end with a locale identifier, eg:
>>>
>>> About_nl.tml
>>> About_en.tml
>>> About_de.tml
>>>
>>> The plugin should be able to link this to the 'About.java' class,  but ( as
>>> of now) it does not.  Should be great if this could be implemented.
>>>
>>> Thx
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: 
>>> http://tapestry.1045711.n5.nabble.com/Lightweight-TapestryTools-update-site-tp5610392p5715091.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
>>>
>>
>>
>>
>> --
>> -
>> Best Regards
>> Gavin Lei (雷银)
>> Email: gavingui2...@gmail.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
>



-- 
-
Best Regards
Gavin Lei (雷银)
Email: gavingui2...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Error on contributeMasterObjectProvider: org/apache/tapestry5/ioc/internal/util/LockSupport

[Jonathan Barker]

Check your class path.  You likely have duplicate or mixed versions of
jars introduced by Maven figuring out which artifact versions to
include.

On Tue, Aug 7, 2012 at 9:35 PM, Jaypax Ginete  wrote:
> Running Tapestry5.3.4 generated from a Maven artifact. Since I'm using
> Hibernate I changed my POM from tapestry-core to tapestry-hibernate then
> added Hibernate dependencies. Ran jetty:run and the app bootstraps OK.
>
> The problem is when I add either Tynamo's Tapestry-security or Got5's
> Tapestry-jquery (or both). When I run jetty:run it doesn't bootstrap and
> throws the exception.
>
> Attached a more detailed exception report.
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org



-- 
Jonathan Barker
ITStrategic

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Lightweight TapestryTools update site

[antalk]

Hi Gavin,

I had to uninstall your plugin from my eclipse environment (juno) it became
terribly slow when i had about 30 tml pages open. I just could not work with
it anymore.

I'm sorry that i have no logs or errors, it just became awfully slow..

It may have something todo with the fact that the TML editor is based (or
derived) from the XML editor ?? i know link 'tml' pages to the JSP editor
and it works much faster.

Antal



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Lightweight-TapestryTools-update-site-tp5610392p5715142.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

Changing default session behavior.

[kata]

Hi all,

I am currently using shiro and the tapestry-security plugin to manage
sessions and persist data. Everything works fine when getting the session by
SecurityUtils.getSubject().getSession(). However, this means that the
application is peppered with fragments of shiro-specific code. Since shiro
uses the servlet session API, is there a way to do this in a way that is
transparent to the application, and hopefully still allow me to use
annotations like @Persist and @SessionState?

Thanks,
Martin



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Changing-default-session-behavior-tp5715141.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: Tapestry Jquery slider problem

[bhorvat]

Ok I see, well then my bad again. Sorry for the spam



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Tapestry-Jquery-slider-problem-tp5715130p5715140.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