> wonder if it couldnt reuse ImportSql class and just use a well know file
Sure, but this is just only an example. In fact in our production environment it won't be as easier as this. Probably there will be a person who pushes the button of "create the schema". > I'd add few more things like the name of the id of theresource Sure this is only a basic class. > why not using a request scope bean Don't catch you about this hehehe. You mean NewTenantListener scope, or add a @RequestScope for TenantId instead of setting it? > Note that the thread local should be clean up So true I have implemented it. > provide your own API and hide internals behind something Had this on mind, but to not complicate now the example I decided to reuse existing classes. > replace CDI by an extension When you say replace CDI you mean only for registration or also the CDI annotations used like @Inject or Observers? Alex. El dj., 4 juny 2015 a les 16:45, Romain Manni-Bucau (<[email protected]>) va escriure: > Hi > > few notes but this looks a super great start: > - > > https://github.com/lordofthejars/multi/blob/master/src/main/java/com/scytl/multi/CreateDatabaseSchemaListener.java > : > wonder if it couldnt reuse ImportSql class and just use a well know file > - > > https://github.com/lordofthejars/multi/blob/master/src/main/java/com/scytl/multi/CreatedDataSourceEvent.java > : > I'd add few more things like the name of the id of theresource > (logging/audit purpose) > - > > https://github.com/lordofthejars/multi/blob/master/src/main/java/com/scytl/multi/MultitenancyRouter.java > : > why not using a request scope bean? would make the code simpler for webapps > (but wouldnt support batches/async). Note that the thread local should be > clean up otherwise it will leak or can have side effect if you reuse an old > value (better to fail if you forget to set it than using previous customer > datasource) > - I would probably get rid of org.apache.openejb imports in events (provide > your own API and hide internals behind something) > > Now the issues to bring it in tomee would surely be to: > - have a flag in application.properties to switch it on > - replace CDI by an extension (with the META-INF/service registration but > the flag will add it or not) to ensure it works even if the container jar > is not scanned > > Nothing blocking but a small rework to do > > wdyt? > > > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2015-06-04 16:32 GMT+02:00 Alex Soto <[email protected]>: > > > Hi guys, as I mention on the twitter, currently I am developing a PoC for > > solving the problem of multi-tenancy with schema-based approach. This > means > > that for each tenant has its own schema inside database. Moreover the > same > > approach can be used just in case of database-based approach. > > > > Another of the requirements we are having in my company is that a tenant > > should any tenant should be able to be added dynamically, without having > to > > stop the server. > > > > To implement this in TomEE I have implemented my own Router. Of course it > > is a PoC so some parts needs more validations and/or some refactor, but I > > think that as first approach to see the idea is enough. > > You can see the code here: https://github.com/lordofthejars/multi > > > > I think that TomEE could provide this feature out of the box, it is > really > > not so hard and with the inclusion of CDI you will see that it is pretty > > simple. > > This email is only to open the discussion about if it is interesting to > add > > it in TomEE or not. > > > > My next steps will be present the solution to my teams, and after some > > discussions, implement it as final solution (which I am sure we will be > > able if you agree to implement it as module inside TomEE). > > > > And that's all, for any question about the PoC feel free to ask it. > > > > Alex. > > >
