You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Ludwig Magnusson <lu...@itcatapult.com> on 2011/04/09 20:34:38 UTC
The generics problem
Hello!
I have been working on the problems with generics and the security model and
it's not that trivial.
The problem is this:
Let's say that in your project, you have a User class called MyUser (same
for role, permission, group). In Turbine, there are methods like
List<User> UserManager. retrieveList (Object criteria);
If we keep this method this way, you always need do cast your user class to
MyUser when you want to access methods in MyUser. In my experience, the user
class is often heavily changed and therefore a good solution here would be
valuable.
There are solutions, but implementing it is quite a bit of work, that's why
I want to discuss the solution before I begin. If anyone comes up with a
simpler solution, I would be very happy =)
To be able to have methods like:
public MyUser getUser(String username)
public boolean accountExists(MyUser user)
List<MyUser> retrieveList(Object criteria)
These steps needs to be taken:
1 Add a type parameter to the UserManager interface:
public Interfae UserManager<U>
All the methods that returned User now returns U. All the methods that took
user arguments now takes U arguments.
This also needs to be done to the implementing classes.
2 Alll the methods concerning users now needs to go through the user
manager. But this seems to have been the plan with fulcrum-security anyway.
3 We can never escape the fact that the type of the User class needs to be
defined at compile time. I'm guessing that the best solution would be that
the developer that is using turbine would instantiate their class somewhere:
UserManager<MyUser> manager = new TorqueUserManager<MyUser>();
4 Now the developer needs to be able to access the UserManager with the
specified parameter..
He can write his own access class where the the type is defined
public static UserManager<MyUser> getUserManagerInstance()
There is also a "trick" that I found in the book Effective Java by Joshua
Bloch (which I very much recommend btw).
You can create a general method that looks like this:
public <U> UserManager<U> getUserManager(Class<U> type)
I can explain the inner workings at a later stage but the point is that you
call a method where the argument is MyUser.class and you will get the
UserManager for MyUser. It's not totally magical though. Somewhere the
developer will need to instantiate his user manager by himself.
I hope you'll find some time for feedback on my research =)
/Ludwig
SV: SV: The generics problem
Posted by Ludwig Magnusson <lu...@itcatapult.com>.
Sure. If all the generics are removed from the security model. I will be
able to participate in the tests. After that, we can remove security from
turbine core and focus on fulcrum security. I think this is the best idea.
I will not be able to do the roll back this week, but perhaps next. If
anyone else has time this week, I say go for it.
/Ludwig
-----Ursprungligt meddelande-----
Från: Thomas Vandahl [mailto:tv@apache.org]
Skickat: den 14 april 2011 22:04
Till: Turbine Developers List
Ämne: Re: SV: The generics problem
On 14.04.11 18:03, Ludwig Magnusson wrote:
> If you still want to release M1 my vote will be [0] and I don't think
> I will be giving feedback this round. I will on the next though.
Given the fact that Turbine committers are a rare species nowadays, I'm
pretty sure that we cannot afford this. On the other hand, the last release
was more than two years ago and my impression is that it is time to get our
act together.
What if we roll back the generics changes for the security stuff for now? As
I see it, everything would be back to normal (2.3.3, I mean), including
casts and stuff. WDYT?
Bye, Thomas.
PS: I'm ready to bet that the security is not the only part of the
application that would need changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: SV: The generics problem
Posted by Thomas Vandahl <tv...@apache.org>.
On 14.04.11 18:03, Ludwig Magnusson wrote:
> If you still want to release M1 my vote will be [0] and I don't think I will
> be giving feedback this round. I will on the next though.
Given the fact that Turbine committers are a rare species nowadays, I'm
pretty sure that we cannot afford this. On the other hand, the last
release was more than two years ago and my impression is that it is time
to get our act together.
What if we roll back the generics changes for the security stuff for
now? As I see it, everything would be back to normal (2.3.3, I mean),
including casts and stuff. WDYT?
Bye, Thomas.
PS: I'm ready to bet that the security is not the only part of the
application that would need changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
SV: The generics problem
Posted by Ludwig Magnusson <lu...@itcatapult.com>.
>I have a similar problem with the generic handling of the modules (Action,
Screen and friends). I guess this is what annotations were invented for in
the first place. My suggestion would be to do only the things absolutely
necessary to get the milestone 1 out of the door and postpone the "real"
solution to >milestone 2 where the security stuff is about to be replaced
anyway. Rather put your energy into tuning the fulcrum-security stuff. LDAP
needs some testing, for example.
The thing is...
Like I said in my introduction when i became a Turbine comitter, I run a
company where we develop a web-app that is now 2 years old based on turbine.
I intend to test Turbine4 through our web-app. If we don't generify turbines
security model before the release of M1 I would have to change a lot in our
code just to make it compile. I'm not sure that I want to put my time there.
I'd rather develop turbine one step further to test it. And as you say, I'd
probably focus on fulcrum security. I have no experience of LDAP however and
I would probably but all my energy into torque.
>> There is also a "trick" that I found in the book Effective Java by
>> Joshua Bloch (which I very much recommend btw).
>>
>> You can create a general method that looks like this:
>>
>> public <U> UserManager<U> getUserManager(Class<U> type)
> I like this one. That's how ArrayList.toArray(T[]) works. Maybe this can
help me with the AssemblerBrokerService.
If the team feels that this is a good solution I will start working on it as
fast as I can.
If you still want to release M1 my vote will be [0] and I don't think I will
be giving feedback this round. I will on the next though.
/Ludwig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: The generics problem
Posted by Thomas Vandahl <tv...@apache.org>.
Hi Ludwig,
On 09.04.11 20:34, Ludwig Magnusson wrote:
> If we keep this method this way, you always need do cast your user class to
> MyUser when you want to access methods in MyUser. In my experience, the user
> class is often heavily changed and therefore a good solution here would be
> valuable.
>
> There are solutions, but implementing it is quite a bit of work, that's why
> I want to discuss the solution before I begin. If anyone comes up with a
> simpler solution, I would be very happy =)
I have a similar problem with the generic handling of the modules
(Action, Screen and friends). I guess this is what annotations were
invented for in the first place. My suggestion would be to do only the
things absolutely necessary to get the milestone 1 out of the door and
postpone the "real" solution to milestone 2 where the security stuff is
about to be replaced anyway. Rather put your energy into tuning the
fulcrum-security stuff. LDAP needs some testing, for example.
> There is also a "trick" that I found in the book Effective Java by Joshua
> Bloch (which I very much recommend btw).
>
> You can create a general method that looks like this:
>
> public <U> UserManager<U> getUserManager(Class<U> type)
I like this one. That's how ArrayList.toArray(T[]) works. Maybe this can
help me with the AssemblerBrokerService.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org