Eagle server includes different modules for metadata access: 1. IMetadata is for alert (We should rename that to contain alert keyword) 2. Application framework metadata 3. Application specific metadata. For example security monitoring use case normally contains sensitivity information.
For each of the above metadata access modules, we need both memory and JDBC implementations. Thanks Edward On Wed, Aug 24, 2016 at 7:59 PM, Hao Chen <[email protected]> wrote: > Basically for any metadata persistence function, > > 1) you should firstly define a interface say SomeService > > interface SomeService { > void doSomeThing(); > } > > 2) Then you need to implement the interface for different kind of storeage > type say memory (test purpose only), jdbc and mongodb, and bind the > implementation to interface in different MetadataStore module. > > 3) When you call @Inject SomeService, eagle server would inject the > configured type of implementation instance. > > So: > > 1) As to your first question, I think it's YES, we currently only implement > memory-based store, but leave jdbc/mongodb later, if you would like to > contribute, I think you could do it. > 2) As to your second question, I think it maybe NOT SURE, IMetadataDao is > only for alert related metadata only, if you would to extend alert related > metadata then it should be ok, if not, please define another interface and > bind in related storage module. > > Please let me know if you have any more concern. > > - Hao > > On Thu, Aug 25, 2016 at 12:30 AM, Chang Chen <[email protected]> wrote: > > > Hi Edward > > > > Do you mean implement SiteEntityEntityServiceJDBCImpl > > and ApplicationEntityJDBCImpl, so that we can bind them in > > JDBCMetadataStore? i.e. > > > > bind(SiteEntityService.class).to(SiteEntityEntityServiceJDBCI > > mpl .class).in(Singleton.class); > > > > bind(ApplicationEntityService.class).to(ApplicationEntityJDBCImpl. > > class).in(Singleton.class); > > Right? > > > > If so, that looks like we need define an interface like IMetadataDao(or > > directly update this interface). > > > > Any Idea? And Please correct me if I am wrong > > > > Thanks > > Chang > > > > > > On Tuesday, August 23, 2016, Edward Zhang <[email protected]> > wrote: > > > > > Yes, SiteEntityEntityServiceMemoryImpl is not thread safe, we need > make > > it > > > thread safe. > > > Also one thing to mention is memory implementation is only for testing > > > purpose, we should have JDBC service implementation. > > > In JDBCMetadataStore, we have not registered jdbc implementation > module. > > > Besides Site, for application, we also need jdbc implementation. > > > If you are interested, please help with it. > > > > > > Thanks > > > Edward > > > > > > On Mon, Aug 22, 2016 at 6:57 AM, Chang Chen <[email protected] > > > <javascript:;>> wrote: > > > > > > > Hi > > > > > > > > I am not very familiar with CompletableFuture, but highly suspect > > > > SiteResource isn't thread safe. > > > > > > > > Its member functions(i.e. createSite, getSiteBySiteId) could be > called > > > > concurrently, and each member function run its callback via > > > > CompletableFuture. This requires SiteEntityEntityServiceMemoryImpl > > > thread > > > > safe, but it's not , because siteId2EntityMap is HashMap. > > > > > > > > > > > > Thanks > > > > Chang > > > > > > > > > >
