MongoUriHandlerProvider can handle just one MongoDatabaseProvider

28 views
Skip to first unread message

Mark Hoffmann

unread,
Apr 12, 2015, 10:13:20 AM4/12/15
to mong...@googlegroups.com
Hi,
I wanna use MongoEMF with more than just one database. For that the MongoUriHandlerProvoider should reference to the database providers using 0..n dynamics in the components.xml instead of 1..1 static. Can you tell me, if this is intended? And if it is, why?

In my opinion it should work with dynamic refernces too.

Mark

Bryan Hunt

unread,
Apr 14, 2015, 9:03:02 PM4/14/15
to mong...@googlegroups.com
It looks like the code was intended for the cardinality to be 1..n dynamic and it was an oversight on my part to make it 1..1 static. Please open an issue or (even better) submit a PR.

Bryan
> --
> You received this message because you are subscribed to the Google Groups "MongoEMF" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mongoemf+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Mark Hoffmann

unread,
Apr 17, 2015, 2:36:36 AM4/17/15
to mong...@googlegroups.com, j.al...@data-in-motion.biz
Hi Bryan,

thank you, I will make the change.

Further I would like to know, what do you think about supporting the latest mongo driver in version 3.x. I would try to OSGify the jar. And the Import-Package Version have to be updated and the client properties have to be checked at the first step.

Is there any idea to make the MongoEMF, eModeling, eMongo part of an Eclipse project like, similar like Teneo?

mARK

Bryan Hunt

unread,
Apr 17, 2015, 9:16:28 PM4/17/15
to mong...@googlegroups.com, j.al...@data-in-motion.biz
Hi Mark,

I would like to update the code to support the latest MongoDB driver.  The driver should already be an OSGi bundle - it just needs to be put into a repository to be easily consumed by p2 and Bndtools.  One additional change I think I want to make for 0.9.0 is to move all of the EMF persisted metadata to an embedded object.

As for creating an Eclipse project, that might be nice, but I don’t see that happening until there are multiple committers on these projects.  The overhead of being an Eclipse project is significant.

Bryan

Mark Hoffmann

unread,
Apr 22, 2015, 12:48:01 PM4/22/15
to mong...@googlegroups.com, j.al...@data-in-motion.biz
Hi Bryan,

I have made some bugfixes and created a pull request (user axtmann :-)). I took a look into the latest mongo driver. The Mongo guys did some major changes.

1. User can not be authenticated via DB.authenticate anymore, which is currently done in the MongoDatabaseProviderComponent
2. Credentials are given as list in the MongoClient  constructor. There is a method getCredentialsList in the MongoClient, but I dont now if it is a modifiable list, I will take a look into it
3. Mongo#getDB is deprecated we should use MongoClient#getMongoDatabase instead. Therefore we can now a MongoDatabase object instead of the DB object
4. If we use MongoDatabase instead of DB we have no DBCollection anymore but a MongoCollection

It looks as it is just a rename of classes.

Mark

Mark Hoffmann

unread,
Apr 22, 2015, 3:44:21 PM4/22/15
to mong...@googlegroups.com
Hi,

unfortunatly, the MongoClient#getCredentialsList is an unmodifiable list. That means, that all credentials for all databases have to be available in the MongoClientProviderComponent, because the list of credentials have to be given to the MongoClient in the constructor :-(. Maybe we should use the modify-callback in the component to submit new credentials for new databases via ConfigAdmin. The existing credentials from the current client instance in the component could be used via MongoClient#getCredentialsList and create a new MongoClient instance then. The bad thing I see with this solution is that not only the MongoDatabaseProvider has to be configured. Further the corresponding MongoClientProvider has to be updated when using authentication.

Mark  

Bryan Hunt

unread,
Apr 22, 2015, 10:32:02 PM4/22/15
to mong...@googlegroups.com
This sounds like a huge step backwards.  I’ll open a support ticket and see if there is any chance of getting the old behavior brought back.  If not I’ll probably re-design the whole client service.  Not looking forward to that.

Bryan

Bryan Hunt

unread,
Apr 27, 2015, 8:27:01 AM4/27/15
to mong...@googlegroups.com
I talked with MongoDB support.  There are security implications of the old authentication mechanism.  The current design is the way forward.  eMongo needs a 2.0 API design.  I, or someone else, should open an issue to track this and discuss the design.  Maybe morph the database provider into a credential provider and change the reference to static - just thinking out loud here.

Bryan

Mark Hoffmann

unread,
Apr 27, 2015, 8:48:08 AM4/27/15
to mong...@googlegroups.com
... or leave it like it is and: 
- Remove just the authentication from the database provider. 
- Introduce a CredentialProvider that can be consumed by the MongoClientProviderComponent (0..n static)
- CredentialProvider provides one or more MongoCredentials for one or more clientIds (MongoClientProvider)

The database provider would do nothing else than just return a database (I think it is ok). MongoClientProvider, MongoDatabaseProviderand MongoCredentialProvider are well separated. So if a database provider needs authentication, a MongoCredentialProvider can be used for one or more clientId's.


Mark

Bryan Hunt

unread,
Apr 27, 2015, 9:01:17 AM4/27/15
to mong...@googlegroups.com
That’s probably a good way to go.

Bryan
Reply all
Reply to author
Forward
0 new messages