Aaron Mulder wrote:
<snip/>
So to get around to my point, I'd like to propose an alternative:
- We make the key generator into a "key generator factory" -- that is,
something that knows how to produce a certain type of key generator (based
on sequence or table or auto increment or whatever), but is not itself a
generator and does not have EJB-specific configuration attached.
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.
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
