On Jan 30, 2011, at 1:27 AM, Jean-Baptiste Onofré wrote:
> Hi all,
>
> I have some questions about the current scm repo:
>
> - @David: I saw that you created an assemblies module. We still have the
> assembly module defined and used in the <modules/> main POM. I guess it's a
> temporary situation and, after some more tests, the assemblies module will
> replace the assembly module ? What about profiles implementation and
> brainstorm ?
I hope this is a temporary situation -- the one assembly in assemblies now is
just something to show how to set up an assembly. Although I have some
high-priority unrelated problems to fix in geronimo I'll try to set up some
more stuff to show how we can build profiles using these new maven packagings.
> - @Achim: I saw that you added a src/main/configfiles directory (containing a
> jetty.xml) in the assembly module. Why not used the
> src/main/filtered-resources directory (and eventually create a new directory
> in this one) or define a new sub-module ? I don't wanna split the resources
> in a lot of directories. WDYT ?
>
> Now regarding the JAAS configuration. Correct me if I'm wrong, but up to now,
> the JAAS configuration is defined in the blueprint
> (OSGI-INF/blueprint/karaf-jaas-module.xml) descriptor of the jaas/modules
> module:
>
> <jaas:config name="karaf">
> <jaas:module
> className="org.apache.karaf.jaas.modules.properties.PropertiesLoginModule"
> flags="required">
> users = $[karaf.base]/etc/users.properties
> encryption.name = ${encryption.name}
> encryption.enabled = ${encryption.enabled}
> encryption.prefix = ${encryption.prefix}
> encryption.suffix = ${encryption.suffix}
> encryption.algorithm = ${encryption.algorithm}
> encryption.encoding = ${encryption.encoding}
> </jaas:module>
> </jaas:config>
>
> So by default, we "force" the usage of the PropertiesLoginModule.
>
> It could be helpful for the end users to have access to a
> etc/login.properties file to be able to define the login modules to use with
> the policy associated (required, sufficient, optional).
> For instance, we can add a property in the etc/org.apache.karaf.jaas.cfg file
> to define the location of this login.properties file (etc/login.properties by
> default) and reference the PropertiesLoginModule by default. It could be more
> clear for the users.
We've had this problem in geronimo for a long time. I think a translation of
our solution into karafosgi terms would be that we have a feature that provides
a named security realm service that uses a simple properties file login module.
If users want they can replace this feature with another that provides a
different security realm service with the same name. I don't think you can
parameterize class names in blueprint, but I don't know for sure. I pretty
much hope not :-)
thanks
david jencks
>
> WDYT ?
>
> Thank
> Regards
> JB
>
>
>
>
>
