I think right now the best way to see how it works is to look at the tests written for it.
https://github.com/apache/deltaspike/tree/master/deltaspike/modules/partial-bean/impl/src/test/java/org/apache/deltaspike/test/core/api/partialbean The actual implementation is here: https://github.com/apache/deltaspike/blob/master/deltaspike/modules/partial-bean/impl/src/test/java/org/apache/deltaspike/test/core/api/partialbean/shared/TestPartialBeanHandler.java Which may help in understand what's required to build one. On Tue, Oct 8, 2013 at 1:55 PM, David Hooker <[email protected]> wrote: > Ok - I guess my question is more of a how-to. Is there a blog post or > simple guide > for how to use partial beans? > > From what I can gather with the examples, etc., it seems that what it does > is > let me define an interface (or abstract class, too), and annotate the class > with > my own partial bean annotation. Then, if I annotate an InvocationHandler > with the > same annotation, that IH becomes the implementation for the interface. Is > that > basically it? > > Hence my previous question... If I have multiple interfaces annotated, and > a single > IH, I assume the single IH will handle all requests to the > interfaces/beans. Further, > what happens if I have multiple IH implementations annotated with the same > partial bean annotation? > > > On Tue, Oct 8, 2013 at 6:38 AM, John D. Ament <[email protected]>wrote: > >> The PartialBean support is basically an interceptor in CDI. You can >> reuse it as many times as you need. >> >> On Mon, Oct 7, 2013 at 11:26 PM, David Hooker <[email protected]> wrote: >> > Hi John- >> > >> > Yeah, I was thinking that a JCR store was not my ultimate data storage - >> it >> > may be *one* of them, but not the only one. >> > >> > Basically, we will have data in an RDBMS, in a NoSQL store (like HBase), >> > one or more data grids (like Tibco, GridGain, Terracotta), file systems >> and >> > document storage systems (like Alfresco), Lucene/Solr, and potentially >> > others. >> > >> > We are already working on a generic canonical query language which can >> > represent lookups and queries across multiple stores and types of stores >> > like this. We can implement bindings/parsings from that representation >> to >> > the specifics of the store to perform queries and return data. We >> already >> > have a canonical data model, and will be generating language bindings and >> > transport representations of the data. This is all stuff we are >> designing >> > building. What I'm looking at here is the programming model for >> developers >> > to use to access the data - without knowing where or how it is stored and >> > retrieved. >> > >> > Therefore, I basically want to express the "query" in our own DSL (or >> maybe >> > use JPA-like builders? not sure yet), which we will parse into the >> generic >> > query representation... and then pass on to the appropriate data store. >> > >> > I'm still in the infancy of working out this model. CDI is fantastic >> > because it provides the exact framework that I had envisioned (and >> started >> > building on my own - but now don't have to). >> > >> > Your note leads me to another question - basically I have to figure out >> how >> > I'm going to put together the partial bean handlers and annotations to >> > create this programming model. Without a lot of documentation, I guess >> I'm >> > not sure yet the exact relationship between the annotated interfaces and >> > the invocation handlers. Is it strictly one-to-one? Or can it be >> > many-to-one? Many-to-many? How is it managed? >> > >> > Thanks, >> > -David- >> > >> >
