On Fri, 17 Jun 2005, Jeremy Boynes wrote:
> I would suggest that instead of this being a runtime component, the
> factory is actually built into the builder subsystem (like the naming
> and security stuff is). There would be a "key-generation" XML-Schema
> that users would use to define what one looked like which would be used
> by the builder to generate the actual GBean.
I'm OK with this idea, so long as we all recognize that we'll need
to rev the schemas if our key generator options change. Then the main
outstanding question is whether we should support user-provided key
generators too. Right now you can write one and pop in a GBean for it,
and if we do it the way you propose then a new generator has to be added
to the guts of Geronimo and the schemas. We could leave the current GBean
plumbing in as an alternative, perhaps, and you'd just have to deal with
creating one GBean per EJB for custom generators, or try to combine the
best elements from both proposals.
Anyway, I don't want to give the impression that I don't agree --
I prefer the syntax in the example you gave below. I'll think about how
to pull in the best of both.
Aaron
>
> This would be then be re-usable outside just the EJB file e.g. for web
> applications that needed to generate keys too.
>
> The primary use for this is to define a "shared" generator that can be
> referenced by many components.
>
> > - We provide some additional XML elements where the EJB defines a key
> > generator -- to let you provide configuration data there. It would also
> > let you refer to an arbitrary GBean like now, to handle custom generators.
> >
>
> I agree we should replace the generic GBean reference (or at least
> deprecate it). I think we need both of two alternatives:
>
> 1) an element that refers to a "shared" generator defined above
>
> 2) elements that define the generation technique to use in conjunction
> with creation of this individual entity. This could be openejb
> specific or could be part of the "key-generation" XML-Schema - I tend
> to prefer the latter as we can then keep all keygen like stuff
> together
>
> > - In our code, when we process an EJB with a reference to a generator, we
> > construct some kind of properties object, pop in the data source for the
> > EJB, and add any properties specified in the new config elements. We pass
> > the properties object to the named generator factory, and it returns a
> > configured generator for the EJB to use. So the factory would have a
> > method like "public KeyGenerator createGenerator(Hashtable properties)".
> >
>
> I don't think you need this if you have the XML defined for producing
> generator instances
>
> > - We define our 3 known generator factories in the standard server plans,
> > so they'll have known/expected GBean Names and types
> >
>
> With the approach above these would be replaced by the builder; if they
> needed to be added anywhere it would be to the deployer plans but not
> the runtime ones.
>
> <snip/>
>
> An example of this would be:
>
> <ejb-jar>
> <enterprise-beans>
> <entity>
> <ejb-name>fooEJB</ejb-name>
> <key-generator>foo</key-generator>
> </entity>
> <entity>
> <ejb-name>barEJB</ejb-name>
> <generated-identity>
> <identity-column>BAR_ID</identity-column>
> </generated-identity>
> </entity>
> </enterprise-beans>
> <key-generators xmlns="http://tranql.org/xsd/keygen/1.0";>
> <database-sequence name="foo">
> <sql>SELECT SOME_SEQUENCE.NEXTVAL FROM DUAL</sql>
> <block-size>10</block-size>
> </database-sequence>
> </key-generators>
> </ejb-jar>
>
> Where for "foo" we pre-fetch the identity from the shared sequence and
> for "bar" we are extracting it after the insert. This plan is providing
> the definition for the "foo" generator but it could actually be
> elsewhere (e.g. in the EAR plan or in a separate one).
>
> We should be able to keep the stuff in OpenEJB fairly generic and
> delegate all the db-specific stuff to TranQL and the associated dialect.
>
> --
> Jeremy
>
