On Thu, Apr 7, 2011 at 9:17 PM, Thomas Vandahl <[email protected]> wrote:
> On 07.04.11 12:27, Ludwig Magnusson wrote: > > - 1 > > * I have a lot of problems with my security model and generics since we > use our own implementations of User, Group, Role etc. Earlier this was not a > problem since it only caused an unchecked warning. I can take a look at this > and make the implementation of generics better. > > What is wrong with the implementation? > We override the TurbineAccessControlList with our own. The signature for the constructor on TurbineAccessControllist looks like this: public TurbineAccessControlList(Map<Group, RoleSet> roleSets, Map<Group, PermissionSet> permissionSets) When I try to override the constructor with our implementation that passes a Maps with OurGroup instead of Group, I get a compile error, even though OurGroup implements Group. Our constrctor signature looks like this: public OurAccessControlList(Map<OurGroup, RoleSet> roleSets, Map<OurGroup, PermissionSet> permissionSets) For it to work the constructor of TurbineAccessControlList needs to look like this: public TurbineAccessControlList(Map<? extends Group, RoleSet> roleSets, Map<? extends Group, PermissionSet> permissionSets) This is just one example of the errors that we get. I will not be able to test turbine with our application without either improving the code or changing our application a lot in a direction I don't want to. > > > * Sources are not attatched in the "right" way. I.e a jar-file. This is > easily fixed in the pom. > > Feel free to add it. > Sure, not sure about the procedure here though... To the M1 tag or to trunk? > > > * A nice guide on configuring services is important. I'd very much like > something that looks like "this is how you used to configure your services, > this is how you do it now." Showing both configuration in the files and how > to access the services in java. > > Again, feel free to write one. Use the wiki to start with > http://wiki.apache.org/turbine/Turbine4/Turbine4.0M1/Diff Actually, the reason I wrote this is beacuse I don't really feel qualified here... > > > > And a general question: > > In the fulcrum projects, the static acces classes for the services are > gone. Is this a conscious decision? > > In our project, there are ca 50 references to these classes. > > AFAICT, this was intentional. Some of the services still have static > accessors (now mostly called *Facade) or pull tools available in > Turbine. Normally there is no static accessor in the library itself. > > Bye, Thomas. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
