blueprint-cm parser bug

[Marcel Casado <ma...@ucar.edu>]

Hi,

I'm not sure if this is the right place to report what seems to me a
bug. I'm using servicemix 4.2 that uses the geronimo blueprint
implementation
(http://geronimo.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0) . I
have a blueprint xml   config file that use "blueprint-cm" to read a
properties file and pass them to the beans. It seem there is a bug with
parsing the properties placehodler.


For example the property placeholder
${ldap.server.host}:${ldap.server.port} is parsed as
"ldap.server.host}:${ldap.server.port" one property instead of two
differnet properties.



Exception in servicemix (fuse) 4.2

16:29:53,402 | DEBUG | pool-2-thread-1  |
PropertyPlaceholder              | lueprint.ext.PropertyPlaceholder  138
| Property ldap.server.host}:${ldap.server.port not found


Complete blueprint file :

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:jaas="http://felix.apache.org/karaf/xmlns/jaas/v1.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:cm="http://geronimo.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0"

xmlns:ext="http://geronimo.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
       >

    <type-converters>
        <bean
class="org.apache.felix.karaf.jaas.modules.properties.PropertiesConverter"
/>
    </type-converters>

   <!--  Reads properties in $FUSE_HOME/etc/nnew_security.cfg if exist.
          If not provides the defaults. -->
      <cm:property-placeholder persistent-id="nnew_security">
        <cm:default-properties>
           <cm:property name="nnew_security_realm" value="nnew"/>
           <!-- Port number where LDAP server runs. Ex. 389 -->
           <cm:property name="ldap.server.port"
value="DEFINED_IN_nnew_security.cfg"/>
           <!-- Host name or IP address where the LDAP server runs -->
           <cm:property name="ldap.server.host"
value="localhost"/>           <!-- The DN of the user that opens the
connection to the directory server. For example, cn=nnewServices,ou=Admin,dc
=nnew,dc=com. -->
           <cm:property name="ldap.connectionUsername" value=""/>
           <!-- The password that matches the DN from
connectionUsername. In the directory server, in the DIT, the
password                 is normally stored as a userPassword attribute
in the corresponding directory entry. -->
           <cm:property name="ldap.connectionPassword" value=""/>
           <!-- Currently, the only supported value is a blank string.
In future, this option will allow you to select the
                 Secure Socket Layer (SSL) for the connection to the
directory server.  -->
           <cm:property name="ldap.connectionProtocol" value=""/>
           <!-- Selects a particular subtree of the DIT to search for
user entries. The subtree is specified by a DN,
                 which specifes the base node of the subtree. For
example, ou=User,ou=WebCoverageService,ou=services,dc=nnew,dc=com -->
           <cm:property name="ldap.constraint.userBase"
value="DEFINED_IN_nnew_security.cfg"/>
           <!-- Specify the search depth for user entries, relative to
the node specified by userBase -->
           <cm:property name="ldap.constraint.userSearchSubtree"
value="nnew"/>
           <cm:property name="nnew_security_realm" value="false"/>
           <!-- Specifies an LDAP search filter, which is applied to the
subtree selected by userBase. For example, (uid={0})
-->
           <cm:property name="ldap.filter.userSearchMatching"
value="DEFINED_IN_nnew_security.cfg"/>
           <!-- specifies the name of the multi-valued attribute of the
user entry that contains a list of role names for the
user
                . If you omit this option, no role names are extracted
from the user entry. -->
           <cm:property name="ldap.filter.userRoleName" value=""/>
           <!-- you want to store role data directly in the directory
server, you can use a combination of role options
                 (roleBase, roleSearchMatching, roleSearchSubtree, and
roleName) as an alternative to (or in addition to) spec
ifying the
                  userRoleName option. For example,
ou=Group,ou=WebCoverageService,ou=services,dc=nnew,dc=com -->
           <cm:property name="ldap.constraint.roleBase"
value="DEFINED_IN_nnew_security.cfg"/>
           <!-- Specify the search depth for role entries, relative to
the node specified by roleBase -->
           <cm:property name="ldap.constraint.roleSearchSubtree"
value="nnew"/>
           <!-- Specifies the name of the multi-valued attribute of the
role entry that contains a list of role names for the
current user.
                 If you omit this option, the role search feature is
effectively disabled. For example, cn -->
           <cm:property name="ldap.filter.roleName"
value="DEFINED_IN_nnew_security.cfg"/>
           <!-- Specifies an LDAP search filter, which is applied to the
subtree selected by roleBase. For example, (member=ui
d={1}) -->
           <cm:property name="ldap.filter.roleSearchMatching"
value="DEFINED_IN_nnew_security.cfg"/>
        </cm:default-properties>
    </cm:property-placeholder>

  <jaas:config name="nnew" rank="1">
       <!--  Each realm can contain one or more module definition. Each
module identify a LoginModule and
             the "className" attribute must be set to the class name of
the login module to use. Note that
             this login module must be available from the bundle
classloader -->
       <!--  The "flags" attribute controls the overall behavior as
authentication proceeds down the stack.
             The following represents a description of the valid values
for Flag and their respective semantics:

            1) required     - The LoginModule is required to succeed.
                           If it succeeds or fails, authentication still
continue to proceed down the LoginModule list.
            2) requisite    - The LoginModule is required to succeed.
                           If it succeeds, authentication continues down
the LoginModule list.  If it fails, control immediately returns to the
application
                       (authentication does not proceed down the
LoginModule list).
            3) sufficient   - The LoginModule is not required to succeed.
               If it does succeed, control immediately returns to the
application  (authentication does not proceed down the LoginModule list).
                           If it fails, authentication continues down
the LoginModule list.
            4) optional     - The LoginModule is not required to succeed.
               If it succeeds or fails, authentication still continues
to proceed down the LoginModule list. -->

        <jaas:module
className="edu.ucar.ral.security.jaas.login.LDAPLoginModule"
flags="required">
            <!-- For more info about module configuration :
http://fusesource.com/docs/broker/5.3/security/Auth-JAAS-LDAPAuthentPlugin.html 

-->
            <!-- List of properties key=value to pass to the login
module as a Map -->
                       debug=false

initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory

connectionURL=ldap://${ldap.server.host}:${ldap.server.port}
                       connectionUsername=${ldap.connectionUsername}
                       connectionPassword=${ldap.connectionPassword}
                       connectionProtocol=s
                       authentication=simple
                       userBase=${ldap.constraint.userBase}
                       userSearchMatching=${ldap.filter.userSearchMatching}
                       userRoleName=${ldap.filter.userRoleName}

userSearchSubtree=${ldap.constraint.userSearchSubtree}
                       roleBase=${ldap.constraint.roleBase}
                       roleName=${ldap.filter.roleName}
                       roleSearchMatching=${ldap.filter.roleSearchMatching}

roleSearchSubtree=${ldap.constraint.roleSearchSubtree}
        </jaas:module>

    </jaas:config>

</blueprint>

Thanks,

Marcel