Bugzilla – Full Text Bug Listing
| Summary: | Allow userManager to take parameters in cdo-server.xml | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Erdal Karaca <erdal.karaca.de> |
| Component: | cdo.core | Assignee: | Project Inbox <emf.cdo-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | stepper |
| Version: | 4.13 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Erdal Karaca
Just realized that the 'dataSource' solution is more convenient: <dataSource ... user="myuser" password="pwd" /> In this case, user and password are set reflectively to the generated data source instance... This should be possible for userManager as well... (In reply to comment #0) > I need to parameterize my user manager. The only parameter a user manager can > take is the 'description' attribute. This is not enough. It's perhaps not the most convenient solution but it's definitely "enough" as all imaginable kind of additional data can be String-encoded. > Sugestion/Example: > > <repository> > > <userManager type="ldap"> > <property name="bindHost" value="ldap://localhost" /> > </userManager> > > </repository> > > The IUserManger could maybe have an additional method: > > public void setProperties(Map<String, String> props); We could consider a general PropertiesAware interface with this method and use it to pass the collected properties into any kind of element. It strikes me that we should wait with this proposal until we've seen how bug 358506 unfolds. It's supposed to solve the wiring challenge more generally and more sophisticated. What do you think about it? (In reply to comment #1) > Just realized that the 'dataSource' solution is more convenient: <dataSource > ... user="myuser" password="pwd" /> > > In this case, user and password are set reflectively to the generated data > source instance... > This should be possible for userManager as well... That's not my favorite approach because reflection comes with a number of subtle issues (case of setters, etc...). (In reply to comment #2) > (In reply to comment #0) > > I need to parameterize my user manager. The only parameter a user manager can > > take is the 'description' attribute. This is not enough. > > It's perhaps not the most convenient solution but it's definitely "enough" as > all imaginable kind of additional data can be String-encoded. > Yes, sure. It is just about convenience. > > Sugestion/Example: > > > > <repository> > > > > <userManager type="ldap"> > > <property name="bindHost" value="ldap://localhost" /> > > </userManager> > > > > </repository> > > > > The IUserManger could maybe have an additional method: > > > > public void setProperties(Map<String, String> props); > > We could consider a general PropertiesAware interface with this method and use > it to pass the collected properties into any kind of element. Yes, that would be great. > > It strikes me that we should wait with this proposal until we've seen how bug > 358506 unfolds. It's supposed to solve the wiring challenge more generally and > more sophisticated. What do you think about it? If it solves the problem by other means, then we should wait for it... Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. Moving all outstanding enhancements to 4.3 Moving all open enhancement requests to 4.4 Moving all open enhancement requests to 4.4 Moving all open bugzillas to 4.5. Moving all unaddressed bugzillas to 4.6. Moving all open bugs to 4.7 Moving all unresolved issues to version 4.8- Moving all unresolved issues to version 4.9 Moving to 4.13. |