You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Marcel Casado (JIRA)" <ji...@apache.org> on 2010/02/26 00:56:27 UTC
[jira] Created: (ARIES-204) blueprint-cm property placeholder
parser bug
blueprint-cm property placeholder parser bug
--------------------------------------------
Key: ARIES-204
URL: https://issues.apache.org/jira/browse/ARIES-204
Project: Aries
Issue Type: Bug
Components: Blueprint
Affects Versions: 1.0
Environment: Mac OS , Servicemix 4.2
Reporter: Marcel Casado
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>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (ARIES-204) blueprint-cm property placeholder
parser bug
Posted by "Valentin Mahrwald (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on ARIES-204 started by Valentin Mahrwald.
> blueprint-cm property placeholder parser bug
> --------------------------------------------
>
> Key: ARIES-204
> URL: https://issues.apache.org/jira/browse/ARIES-204
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
> Affects Versions: 1.0
> Environment: Mac OS , Servicemix 4.2
> Reporter: Marcel Casado
> Assignee: Valentin Mahrwald
>
> 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>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ARIES-204) blueprint-cm property placeholder
parser bug
Posted by "Valentin Mahrwald (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839217#action_12839217 ]
Valentin Mahrwald commented on ARIES-204:
-----------------------------------------
Hi Marcel, I have fixed (or believe to have done so at least) the issue in Apache Aries blueprint. Is there a version of servicemix that pulls in Apache Aries blueprint, so you could test whether the fix indeed solves your root issue?
> blueprint-cm property placeholder parser bug
> --------------------------------------------
>
> Key: ARIES-204
> URL: https://issues.apache.org/jira/browse/ARIES-204
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
> Affects Versions: 1.0
> Environment: Mac OS , Servicemix 4.2
> Reporter: Marcel Casado
> Assignee: Valentin Mahrwald
>
> 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>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ARIES-204) blueprint-cm property placeholder
parser bug
Posted by "Valentin Mahrwald (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Valentin Mahrwald reassigned ARIES-204:
---------------------------------------
Assignee: Valentin Mahrwald
> blueprint-cm property placeholder parser bug
> --------------------------------------------
>
> Key: ARIES-204
> URL: https://issues.apache.org/jira/browse/ARIES-204
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
> Affects Versions: 1.0
> Environment: Mac OS , Servicemix 4.2
> Reporter: Marcel Casado
> Assignee: Valentin Mahrwald
>
> 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>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ARIES-204) blueprint-cm property placeholder
parser bug
Posted by "Bartosz Kowalewski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868042#action_12868042 ]
Bartosz Kowalewski commented on ARIES-204:
------------------------------------------
Hi guys,
I had the same issue in Fuse ESB 4.2. I've just run a simple pax exam test that verified that it now works fine.
Unfortunately, Fuse ESB 4.x is still running on Geronimo Blueprint - not on Apache Aries. As far as I know, the migration to Aries is planned for Fuse ESB 4.3. Deploying Aries Blueprint instead of Geronimo Blueprint for the purpose of closing this issue would not be a trival task. There are several Fuse ESB built-in bundles that are based on Blueprint and are using blueprint-cm. As you know the namespace for blueprint-cm is different in Geronimo and in Aries, so these bundles would need to be modified ;(.
I would go and close this issue, but I'm neither the reporter nor the assignee :).
Thanks,
Bartek
> blueprint-cm property placeholder parser bug
> --------------------------------------------
>
> Key: ARIES-204
> URL: https://issues.apache.org/jira/browse/ARIES-204
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
> Affects Versions: 1.0
> Environment: Mac OS , Servicemix 4.2
> Reporter: Marcel Casado
> Assignee: Valentin Mahrwald
>
> 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>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (ARIES-204) blueprint-cm property placeholder parser
bug
Posted by "Valentin Mahrwald (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Valentin Mahrwald closed ARIES-204.
-----------------------------------
Fix Version/s: 0.1
Resolution: Fixed
Thanks Bartek, I'll close it then until further notice :)
> blueprint-cm property placeholder parser bug
> --------------------------------------------
>
> Key: ARIES-204
> URL: https://issues.apache.org/jira/browse/ARIES-204
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
> Affects Versions: 1.0
> Environment: Mac OS , Servicemix 4.2
> Reporter: Marcel Casado
> Assignee: Valentin Mahrwald
> Fix For: 0.1
>
>
> 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>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.