El 19/02/10 12:06, Thomas Mueller escribió: > What about using the Java "service provider mechanism" for extensions? > How this works is explained here: > http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html - > this mechanism also work in Java 5, H2 would use > javax.imageio.spi.ServiceRegistry (which sounds a bit weird, but it's > basically the same thing). >
This seems an standard and very clean way to handle alternative providers for an actual or expected H2 service , but I can see how this help for extensions. In this way H2 extensibility must to be defined in terms of "what's can to be provided as an extension ?" and I don't know if that question have a concrete answer. For and alternate table engine implementation (as Sergi propose) or full text search engine, or new index types , an spi definition can fit perfectly. But for an extension stated as a pack of related UDFs and support code , in don't believe that an SPI approach can be used. I think that we are talking of two different things: 1) Plug-ins: SPI candidate with tight relation to core central functions. 2) Extensions: Addons of UDF sets with minimal core compromise that must to be part of database itself. Plugins can be database configuration components , on the other hand Extensions must to be database's objects. If someone create a database and define a view that use and UDF ; then create a backup and send to another place; all need components to maintain that view operative must to be in the backup as any other database object. For extension suppose there are ways to simply modify the classpath dynamically to make jar contained classes available (http://www.coderanch.com/t/402870/Beginning-Java/java/Adding-jar-classpath-dynamically ); maybe more tricky than standard or elegant but much more direct. > To register an H2 extensions, either > > B) add the file "META-INF/services/org.h2.Service" to the jar file > with the list of extension classes > B) or register the extensions at runtime using a Java API > > Registering a file system implementation is already possible using > org.h2.store.fs.FileSystem.register (some built-in file systems use > this mechanism already). What is needed is extend this mechanism for > functions and other components. There are already some candidates, for > example org.h2.mode.FunctionsMySQL. > Yes , database compatibility modes can be implemented as SPI , one for MySql , PgSql, etc. and as SPI class loading is lazy even if all db mode plugins are installed, only the used one will be loaded. This can reduce core jar size and runtime needed resources. regards, Dario -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
