Re: Role based security
you can edit to modify assignments and such). Even our service layer was almost entirely unchanged, since all filters and other auth checks are applied in an AOP interceptor. Basically, we modified the hibernate mapping docs to add the filters, added interceptors on the service methods in our spring config, and modified the schema to add the necessary new tables (no changes were necessary to the entity tables themelves, but new relations were added). It took a fair amount of research to get the design right, but actual implementation was surprisingly easy, especially considering that we had never explicltly implemented a hibernate filter or an AOP interceptor prior to implementing the row level auth mechanism. Once we got the db config dialed in, it only adds about 20% to the worst queries in the system and is usually much better than that. If there's interest in the details, let me know. Maybe that will motivate me to write the thing up properly. We had code freeze on Friday, so I'm just catching my breath from the effort of the release now. Here's the basic list of requirements we had to meet: * Role based authorization on each page (this already existed in our app) * Role based authorization on each property of any domain object (already in app) * User based authorization on a per-record basis * Actual auth is intersection of role and record auth. If user has write access to an entity, they still can only write the fields that roles they are assigned to have write permission on. * Must have hierarchical record-level auth (but not hierarchical role assignment) * Must be able to assign a user to cover another and then restore back to original state without having to externally track what original state was. Also, if original owner signs on from vacation, they should still have access (usually) * Must be able to assign record level auth to groups of users as well as individuals (also have world assignment, but that is really just a special group in our implementation) * Must have multiple 'owners' on any entity (sales maneger, account manager, external user, etc), each of whom shares the 'owner' permission * Must have ability to assign read, write, and reassign permission independantly to each of owners, group, and world. Engineering requirements included: * hierarchy to be dynamically computed rather than manually adding users to entities based on hierarchy. * minimize changes to existing code * must not break any existing functionality like table paging or lazy loading of collections * Allow for each owner to have different permission instead of sharing single owner permission. I know they will ask for it, even if they don't. Amazingly, despite extreme misgivings about delivering all of this functionality along with acceptable performance, I was able to concoct a mechansim that did all this. I really had my doubts right up until I finished my last experiment prior to writing up the design. --sam On 2/27/07, Jonathan Barker <[EMAIL PROTECTED]> wrote: > Mark, > > Do a Google search using the search string: > > site:http://mail-archives.apache.org/mod_mbox "Jonathan Barker" > > I posted some information and code in June 2006 about creating @Authorize > and @AclAuthorize based on the code for the tapestry @If component, and the > Authorize and AclAuthorize JSP taglibs. > > I've had this in production since last May and it's been working > beautifully. > > Jonathan > > > > -Original Message- > > From: Borut Bolčina [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, February 27, 2007 12:31 PM > > To: Tapestry users > > Subject: Re: Role based security > > > > Hello Mark, > > > > Mark Stang wrote: > > > Ignore the Mediator class it is one of ours. The real logic is in the > > else. We store user and role in the visit and check when needed. > > > > > > > > > hth, > > > > > sorry, but it doesn't. I am looking for a more general solution - if at > > all exists. I wish to lay grounds for security in my Tapestry app beyond > > those described in Kent's book EWDT, Tapestry 101 or Beginning POJOS > > (Novice to Professional). Imagine a portal with several portlets. Each > > of the portlet is visible and/or editable only to some roles. In a > > portal server such as Liferay or JBoss Portal you can do this by > > assigning certain rights to portlets. I don't want to make a portal(!), > > but I want to have blocks of code on a Tapestry page protected with a > > pluggable authorization/authentication mechanism (memory based, LDAP, > > JDBC, maybe even Active Directory). > > > > Cheers, > > Borut > > > Mark > > > > > > Mark J. Stang > > > Senior Engineer/Architec
Re: Role based security
hi sam... sounds pretty interesting... I especially like the sounds of something that slips in the cracks without imposing expectations of knowledge on developers. I will be looking at the hibernate filters now in a whole new light.. -Pat
RE: Role based security
Borut, Sorry. I don't have this in a library yet - the applications I've been working on lately have rather flat security requirements so I haven't extracted this out into a library. Here's a little snippet out of the menu section of my Border component for sample usage: Month Calendar Agent Console New Estimate I could have cleaned this up by getting rid of a few tags and specifying the "element" property for the @Authorize component. (Remember, it really does behave like an "If" - you can even use the Else with it.) The hard part I found was the Spring side of my plumbing - I jumped into the deep end implementing org.acegisecurity.userdetails.UserDetailsService. I also have a rather hacked-up way of doing my authentication borrowing from EWDT. If you can start out getting things working as described in the Wiki, and then incorporate my stuff that's what I would suggest. Basically, once you have a SecurityContextHolder containing your SecurityContext, things get much easier. Jonathan > -Original Message- > From: Borut Bolčina [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 28, 2007 3:43 AM > To: Tapestry users > Subject: Re: Role based security > > Hello Jonathan, > > I found > http://mail-archives.apache.org/mod_mbox/tapestry- > users/200606.mbox/[EMAIL PROTECTED] > > I will have to study the code, as my T4 mileage is short. You don't happen > to have a component library set up with some examples would you? > > Thanks, > Borut > > > 2007/2/27, Jonathan Barker <[EMAIL PROTECTED]>: > > > > Mark, > > > > Do a Google search using the search string: > > > > site:http://mail-archives.apache.org/mod_mbox "Jonathan Barker" > > > > I posted some information and code in June 2006 about creating > @Authorize > > and @AclAuthorize based on the code for the tapestry @If component, and > > the > > Authorize and AclAuthorize JSP taglibs. > > > > I've had this in production since last May and it's been working > > beautifully. > > > > Jonathan > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Role based security
auth mechanism. Once we got the db config dialed in, it only adds about 20% to the worst queries in the system and is usually much better than that. If there's interest in the details, let me know. Maybe that will motivate me to write the thing up properly. We had code freeze on Friday, so I'm just catching my breath from the effort of the release now. Here's the basic list of requirements we had to meet: * Role based authorization on each page (this already existed in our app) * Role based authorization on each property of any domain object (already in app) * User based authorization on a per-record basis * Actual auth is intersection of role and record auth. If user has write access to an entity, they still can only write the fields that roles they are assigned to have write permission on. * Must have hierarchical record-level auth (but not hierarchical role assignment) * Must be able to assign a user to cover another and then restore back to original state without having to externally track what original state was. Also, if original owner signs on from vacation, they should still have access (usually) * Must be able to assign record level auth to groups of users as well as individuals (also have world assignment, but that is really just a special group in our implementation) * Must have multiple 'owners' on any entity (sales maneger, account manager, external user, etc), each of whom shares the 'owner' permission * Must have ability to assign read, write, and reassign permission independantly to each of owners, group, and world. Engineering requirements included: * hierarchy to be dynamically computed rather than manually adding users to entities based on hierarchy. * minimize changes to existing code * must not break any existing functionality like table paging or lazy loading of collections * Allow for each owner to have different permission instead of sharing single owner permission. I know they will ask for it, even if they don't. Amazingly, despite extreme misgivings about delivering all of this functionality along with acceptable performance, I was able to concoct a mechansim that did all this. I really had my doubts right up until I finished my last experiment prior to writing up the design. --sam On 2/27/07, Jonathan Barker <[EMAIL PROTECTED]> wrote: > Mark, > > Do a Google search using the search string: > > site:http://mail-archives.apache.org/mod_mbox "Jonathan Barker" > > I posted some information and code in June 2006 about creating @Authorize > and @AclAuthorize based on the code for the tapestry @If component, and the > Authorize and AclAuthorize JSP taglibs. > > I've had this in production since last May and it's been working > beautifully. > > Jonathan > > > > -Original Message- > > From: Borut Bolčina [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, February 27, 2007 12:31 PM > > To: Tapestry users > > Subject: Re: Role based security > > > > Hello Mark, > > > > Mark Stang wrote: > > > Ignore the Mediator class it is one of ours. The real logic is in the > > else. We store user and role in the visit and check when needed. > > > > > > > > > hth, > > > > > sorry, but it doesn't. I am looking for a more general solution - if at > > all exists. I wish to lay grounds for security in my Tapestry app beyond > > those described in Kent's book EWDT, Tapestry 101 or Beginning POJOS > > (Novice to Professional). Imagine a portal with several portlets. Each > > of the portlet is visible and/or editable only to some roles. In a > > portal server such as Liferay or JBoss Portal you can do this by > > assigning certain rights to portlets. I don't want to make a portal(!), > > but I want to have blocks of code on a Tapestry page protected with a > > pluggable authorization/authentication mechanism (memory based, LDAP, > > JDBC, maybe even Active Directory). > > > > Cheers, > > Borut > > > Mark > > > > > > Mark J. Stang > > > Senior Engineer/Architect > > > office: +1 303.468.2900 > > > mobile: +1 303.507.2833 > > > Ping Identity > > > > > > > > > > > > -Original Message- > > > From: Borut Bolcina [mailto:[EMAIL PROTECTED] > > > Sent: Tue 2/27/2007 7:08 AM > > > To: Tapestry users > > > Subject: Role based security > > > > > > Hello list, > > > > > > I was wondering if there is a better way of securing page components > > > than using @If components (example from VirtualLibrary for Tapestry > > > v4.0, Border.html) > > > > > > > > > > > >
Re: Role based security
Hello Jonathan, I found http://mail-archives.apache.org/mod_mbox/tapestry-users/200606.mbox/[EMAIL PROTECTED] I will have to study the code, as my T4 mileage is short. You don't happen to have a component library set up with some examples would you? Thanks, Borut 2007/2/27, Jonathan Barker <[EMAIL PROTECTED]>: Mark, Do a Google search using the search string: site:http://mail-archives.apache.org/mod_mbox "Jonathan Barker" I posted some information and code in June 2006 about creating @Authorize and @AclAuthorize based on the code for the tapestry @If component, and the Authorize and AclAuthorize JSP taglibs. I've had this in production since last May and it's been working beautifully. Jonathan
Re: Role based security
Sorry, but have to also point out authsum. It has some tapestry components that also manage login/authorization, but it's very different from anything else out there. It's a search engine for authorizations (uses's lucene to search for authorizations) and it accesses lucene via webservices. Using hessian now, but moving to xfire because I am developing a dotnet and ruby clients. The site will give you a good overview of what it is. http://www.authsum.org (apache license) If it's interesting to you, drop me a line. - Original Message - From: "Borut Bolčina" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Tuesday, February 27, 2007 9:08:17 AM (GMT-0500) America/New_York Subject: Role based security Hello list, I was wondering if there is a better way of securing page components than using @If components (example from VirtualLibrary for Tapestry v4.0, Border.html) ... I read all I could find on the list about acegi and a wiki entries starting at http://wiki.apache.org/tapestry/AcegiSpringJava5, but none of the texts mention or suggests something like ... How about creating such component? How do you guys do it? Cheers, Borut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Role based security
e now. Here's the basic list of requirements we had to meet: * Role based authorization on each page (this already existed in our app) * Role based authorization on each property of any domain object (already in app) * User based authorization on a per-record basis * Actual auth is intersection of role and record auth. If user has write access to an entity, they still can only write the fields that roles they are assigned to have write permission on. * Must have hierarchical record-level auth (but not hierarchical role assignment) * Must be able to assign a user to cover another and then restore back to original state without having to externally track what original state was. Also, if original owner signs on from vacation, they should still have access (usually) * Must be able to assign record level auth to groups of users as well as individuals (also have world assignment, but that is really just a special group in our implementation) * Must have multiple 'owners' on any entity (sales maneger, account manager, external user, etc), each of whom shares the 'owner' permission * Must have ability to assign read, write, and reassign permission independantly to each of owners, group, and world. Engineering requirements included: * hierarchy to be dynamically computed rather than manually adding users to entities based on hierarchy. * minimize changes to existing code * must not break any existing functionality like table paging or lazy loading of collections * Allow for each owner to have different permission instead of sharing single owner permission. I know they will ask for it, even if they don't. Amazingly, despite extreme misgivings about delivering all of this functionality along with acceptable performance, I was able to concoct a mechansim that did all this. I really had my doubts right up until I finished my last experiment prior to writing up the design. --sam On 2/27/07, Jonathan Barker <[EMAIL PROTECTED]> wrote: Mark, Do a Google search using the search string: site:http://mail-archives.apache.org/mod_mbox "Jonathan Barker" I posted some information and code in June 2006 about creating @Authorize and @AclAuthorize based on the code for the tapestry @If component, and the Authorize and AclAuthorize JSP taglibs. I've had this in production since last May and it's been working beautifully. Jonathan > -Original Message- > From: Borut Bolčina [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 27, 2007 12:31 PM > To: Tapestry users > Subject: Re: Role based security > > Hello Mark, > > Mark Stang wrote: > > Ignore the Mediator class it is one of ours. The real logic is in the > else. We store user and role in the visit and check when needed. > > > > > > hth, > > > sorry, but it doesn't. I am looking for a more general solution - if at > all exists. I wish to lay grounds for security in my Tapestry app beyond > those described in Kent's book EWDT, Tapestry 101 or Beginning POJOS > (Novice to Professional). Imagine a portal with several portlets. Each > of the portlet is visible and/or editable only to some roles. In a > portal server such as Liferay or JBoss Portal you can do this by > assigning certain rights to portlets. I don't want to make a portal(!), > but I want to have blocks of code on a Tapestry page protected with a > pluggable authorization/authentication mechanism (memory based, LDAP, > JDBC, maybe even Active Directory). > > Cheers, > Borut > > Mark > > > > Mark J. Stang > > Senior Engineer/Architect > > office: +1 303.468.2900 > > mobile: +1 303.507.2833 > > Ping Identity > > > > > > > > -Original Message- > > From: Borut Bolcina [mailto:[EMAIL PROTECTED] > > Sent: Tue 2/27/2007 7:08 AM > > To: Tapestry users > > Subject: Role based security > > > > Hello list, > > > > I was wondering if there is a better way of securing page components > > than using @If components (example from VirtualLibrary for Tapestry > > v4.0, Border.html) > > > > > > > > > src="/vlib/images/nav/nav_6x1.png" width="178" height="19" border="0" > > alt="Admin"/> > > > > ... > > > > > > > > > > > jwcid="logout"> > src="/vlib/images/nav/nav_10x1.png" width="178" height="29" border="0" > > alt="Logout"/> > > > > > > > > > > > > > jwcid="login"> > src="/vlib/images/nav/nav_10x1.png" width="178" height="29" border="0" >
Re: Role based security
Sorry, I obviously meant to address this to Borut. On 2/27/07, Jonathan Barker <[EMAIL PROTECTED]> wrote: Mark, Do a Google search using the search string: site:http://mail-archives.apache.org/mod_mbox "Jonathan Barker" I posted some information and code in June 2006 about creating @Authorize and @AclAuthorize based on the code for the tapestry @If component, and the Authorize and AclAuthorize JSP taglibs. I've had this in production since last May and it's been working beautifully. Jonathan > -Original Message- > From: Borut Bolčina [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 27, 2007 12:31 PM > To: Tapestry users > Subject: Re: Role based security > > Hello Mark, > > Mark Stang wrote: > > Ignore the Mediator class it is one of ours. The real logic is in the > else. We store user and role in the visit and check when needed. > > > > > > hth, > > > sorry, but it doesn't. I am looking for a more general solution - if at > all exists. I wish to lay grounds for security in my Tapestry app beyond > those described in Kent's book EWDT, Tapestry 101 or Beginning POJOS > (Novice to Professional). Imagine a portal with several portlets. Each > of the portlet is visible and/or editable only to some roles. In a > portal server such as Liferay or JBoss Portal you can do this by > assigning certain rights to portlets. I don't want to make a portal(!), > but I want to have blocks of code on a Tapestry page protected with a > pluggable authorization/authentication mechanism (memory based, LDAP, > JDBC, maybe even Active Directory). > > Cheers, > Borut > > Mark > > > > Mark J. Stang > > Senior Engineer/Architect > > office: +1 303.468.2900 > > mobile: +1 303.507.2833 > > Ping Identity > > > > > > > > -Original Message- > > From: Borut Bolcina [mailto:[EMAIL PROTECTED] > > Sent: Tue 2/27/2007 7:08 AM > > To: Tapestry users > > Subject: Role based security > > > > Hello list, > > > > I was wondering if there is a better way of securing page components > > than using @If components (example from VirtualLibrary for Tapestry > > v4.0, Border.html) > > > > > > > > > src="/vlib/images/nav/nav_6x1.png" width="178" height="19" border="0" > > alt="Admin"/> > > > > ... > > > > > > > > > > > jwcid="logout"> > src="/vlib/images/nav/nav_10x1.png" width="178" height="29" border="0" > > alt="Logout"/> > > > > > > > > > > > > > jwcid="login"> > src="/vlib/images/nav/nav_10x1.png" width="178" height="29" border="0" > > alt="Login"/> > > > > > > > > > > I read all I could find on the list about acegi and a wiki entries > > starting at http://wiki.apache.org/tapestry/AcegiSpringJava5, but none > > of the texts mention or suggests something like > > > > > > > > > src="/vlib/images/nav/nav_6x1.png" width="178" height="19" border="0" > > alt="Admin"/> > > > > ... > > > > > > How about creating such component? How do you guys do it? > > > > Cheers, > > Borut > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Jonathan Barker Consultant
RE: Role based security
Mark, Do a Google search using the search string: site:http://mail-archives.apache.org/mod_mbox "Jonathan Barker" I posted some information and code in June 2006 about creating @Authorize and @AclAuthorize based on the code for the tapestry @If component, and the Authorize and AclAuthorize JSP taglibs. I've had this in production since last May and it's been working beautifully. Jonathan > -Original Message- > From: Borut Bolčina [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 27, 2007 12:31 PM > To: Tapestry users > Subject: Re: Role based security > > Hello Mark, > > Mark Stang wrote: > > Ignore the Mediator class it is one of ours. The real logic is in the > else. We store user and role in the visit and check when needed. > > > > > > hth, > > > sorry, but it doesn't. I am looking for a more general solution - if at > all exists. I wish to lay grounds for security in my Tapestry app beyond > those described in Kent's book EWDT, Tapestry 101 or Beginning POJOS > (Novice to Professional). Imagine a portal with several portlets. Each > of the portlet is visible and/or editable only to some roles. In a > portal server such as Liferay or JBoss Portal you can do this by > assigning certain rights to portlets. I don't want to make a portal(!), > but I want to have blocks of code on a Tapestry page protected with a > pluggable authorization/authentication mechanism (memory based, LDAP, > JDBC, maybe even Active Directory). > > Cheers, > Borut > > Mark > > > > Mark J. Stang > > Senior Engineer/Architect > > office: +1 303.468.2900 > > mobile: +1 303.507.2833 > > Ping Identity > > > > > > > > -Original Message- > > From: Borut Bolcina [mailto:[EMAIL PROTECTED] > > Sent: Tue 2/27/2007 7:08 AM > > To: Tapestry users > > Subject: Role based security > > > > Hello list, > > > > I was wondering if there is a better way of securing page components > > than using @If components (example from VirtualLibrary for Tapestry > > v4.0, Border.html) > > > > > > > > > src="/vlib/images/nav/nav_6x1.png" width="178" height="19" border="0" > > alt="Admin"/> > > > > ... > > > > > > > > > > > jwcid="logout"> > src="/vlib/images/nav/nav_10x1.png" width="178" height="29" border="0" > > alt="Logout"/> > > > > > > > > > > > > > jwcid="login"> > src="/vlib/images/nav/nav_10x1.png" width="178" height="29" border="0" > > alt="Login"/> > > > > > > > > > > I read all I could find on the list about acegi and a wiki entries > > starting at http://wiki.apache.org/tapestry/AcegiSpringJava5, but none > > of the texts mention or suggests something like > > > > > > > > > src="/vlib/images/nav/nav_6x1.png" width="178" height="19" border="0" > > alt="Admin"/> > > > > ... > > > > > > How about creating such component? How do you guys do it? > > > > Cheers, > > Borut > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Role based security
Hello Mark, Mark Stang wrote: Ignore the Mediator class it is one of ours. The real logic is in the else. We store user and role in the visit and check when needed. hth, sorry, but it doesn't. I am looking for a more general solution - if at all exists. I wish to lay grounds for security in my Tapestry app beyond those described in Kent's book EWDT, Tapestry 101 or Beginning POJOS (Novice to Professional). Imagine a portal with several portlets. Each of the portlet is visible and/or editable only to some roles. In a portal server such as Liferay or JBoss Portal you can do this by assigning certain rights to portlets. I don't want to make a portal(!), but I want to have blocks of code on a Tapestry page protected with a pluggable authorization/authentication mechanism (memory based, LDAP, JDBC, maybe even Active Directory). Cheers, Borut Mark Mark J. Stang Senior Engineer/Architect office: +1 303.468.2900 mobile: +1 303.507.2833 Ping Identity -Original Message- From: Borut Bolcina [mailto:[EMAIL PROTECTED] Sent: Tue 2/27/2007 7:08 AM To: Tapestry users Subject: Role based security Hello list, I was wondering if there is a better way of securing page components than using @If components (example from VirtualLibrary for Tapestry v4.0, Border.html) src="/vlib/images/nav/nav_6x1.png" width="178" height="19" border="0" alt="Admin"/> ... jwcid="logout">src="/vlib/images/nav/nav_10x1.png" width="178" height="29" border="0" alt="Logout"/> jwcid="login">src="/vlib/images/nav/nav_10x1.png" width="178" height="29" border="0" alt="Login"/> I read all I could find on the list about acegi and a wiki entries starting at http://wiki.apache.org/tapestry/AcegiSpringJava5, but none of the texts mention or suggests something like src="/vlib/images/nav/nav_6x1.png" width="178" height="19" border="0" alt="Admin"/> ... How about creating such component? How do you guys do it? Cheers, Borut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Role based security
Ignore the Mediator class it is one of ours. The real logic is in the else.
We store user and role in the visit and check when needed.
public class ValidatePage
extends BasePage
implements PageValidateListener
{
public void pageValidate(PageEvent event)
{
Mediator mediator = MgmtFactory.getMediator();
if (!mediator.isConsole())
{
IPage messagePage = getRequestCycle().getPage("nonAdminConsole");
throw new PageRedirectException(messagePage);
}
else
{
// If there is no visit object or the user isn't auth'd ship
// them off to the login page
Visit visit = (Visit)getVisit();
if (visit == null || !visit.isUserAuthenticated())
{
Login login = (Login)getRequestCycle().getPage("login");
throw new PageRedirectException(login);
}
}
}
}
hth,
Mark
Mark J. Stang
Senior Engineer/Architect
office: +1 303.468.2900
mobile: +1 303.507.2833
Ping Identity
-Original Message-
From: Borut Bolcina [mailto:[EMAIL PROTECTED]
Sent: Tue 2/27/2007 7:08 AM
To: Tapestry users
Subject: Role based security
Hello list,
I was wondering if there is a better way of securing page components
than using @If components (example from VirtualLibrary for Tapestry
v4.0, Border.html)
...
I read all I could find on the list about acegi and a wiki entries
starting at http://wiki.apache.org/tapestry/AcegiSpringJava5, but none
of the texts mention or suggests something like
...
How about creating such component? How do you guys do it?
Cheers,
Borut
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
