Re: Setting up SDO2 factories
Style 1 seems more in line with SDO practice. There is already a
DataFactory helper that allows the creation of instances:
class commonj.sdo.helper.DataFactory {
DataObject create(Class interfaceClass);
}
and with suitable metadata it could easily return an enhanced POJO or
some subclass that derived from it.
It would be nice to update for Java5:
class DataFactory {
T T create(ClassT interfaceClass);
}
IMO this is easier to use than the form that returns DataObject as if
people are passing in Java interfaces that is a strong implication
that they are using a static API.
As you say, Style 2 will require weaving which may be less popular in
some circles (and more popular in others).
I would also be interested in helping with this.
--
Jeremy
On 1/19/06, Jim Marino [EMAIL PROTECTED] wrote:
On Jan 19, 2006, at 9:44 AM, Frank Budinsky wrote:
An further step would be to allow for full
POJO support where people could provide their own implementations
which could be turned into SDOs (through subclassing or some other
mechanism with the caveat this would only work for non-final
classes). Perhaps there are some corner cases which limit this but it
seems like it would be a very useful capability.
The EMF project actually did something similar to this in their SDO 1
implementation: they could mixed-in the DataObject imlementation in a
subclass to turn an existing EObject into an SDO DataObject. I
think you
are suggesting doing the same but starting from a JavaBean.
I think the key would be to identify the corner cases ... there may be
many ... and undertand what can and can't be easily supported.
Deciding
how to mix-in things like change notification (for change summary
support)
and container management into classes that don't already implement
the SDO
semantics might be tricky.
There have also been suggestions in the past that Aspect-J would be an
interesting way to try to SDOify an existing class.
For change notification, there are probably a number of options. In
most cases, I would just use ASM or JDK proxies as opposed to
dragging in all of AspectJ (which also uses ASM). Here are a couple
of scenarios:
1. We require that POJO based SDO's be acquired from a factory. The
factory would just create a dynamic proxy that delegates to an
instance of the original class (requires an interface) or a dynamic
subclass, intercepting method calls for change tracking and then
delegating to the corresponding parent method. The factory would also
mixin support for DataObject.
Some API like:
interface SDOFactory{
public T T create(Class claz);
}
Given the class:
public class Foo{
//...
}
Could be used as:
Foo foo = factory.create(Foo.class);
(DataObject)foo;
2. We go the full POJO route and support newing of SDOs, e.g.:
Given:
public class Foo{
//...
}
This can be done:
Foo foo = new Foo();
(DataObject) foo;
We would have to use a bytecode library such as ASM or CGLIB in this
case. One of the tricky things here is that for this to work, I
believe the SDO library would have to access the class bytecode prior
to when it was loaded by the classloader. We would have to ensure the
model did not load classes without first passing to the SDO
enhancer. We should probably do this anyway in the runtime.
I'd be willing to help out implementing this if people are interested
but we should first decide which style we would want (as well as the
corner cases not supported).
Jim
Frank.
Jim Marino [EMAIL PROTECTED] wrote on 01/18/2006 08:34:34 PM:
On Jan 18, 2006, at 3:14 PM, Jeremy Boynes wrote:
Frank Budinsky wrote:
Ultimately though it would be good if people could use SDO2
without
needed to generate any code at all. Wouldn't it be possible to
provide
implementations of user interfaces using Java Proxies (perhaps
with
codegen using ASM or something to boost performance)?
Well, a big part of SDO is the DataObject (reflective API).
Dynamic SDO
already provides a full implementation for that, so I suspect that
what
you're asking for would be to 1) dynamically load the metadata
given a
Java interface, and then 2) Bind a Java Proxy for the interface to
the
dynamic impl. It all sounds possible, but isn't currently part of
the
spec we're implementing.
Something like that - have the proxy implement the user's interface
and
DataObject and delegate invocations to the dynamic SDO
implementation.
If the performance of dynamic SDO is acceptable the the proxy
overhead
is easy to fix.
That would be helpful. An further step would be to allow for full
POJO support where people could provide their own implementations
which could be turned into SDOs (through subclassing or some other
mechanism with the caveat this would only work for non-final
classes). Perhaps there are some corner cases which limit this but it
seems like it
Re: Setting up SDO2 factories
Jeremy,
I think this should work, but you need to register the statically
generated model by calling SDOUtil.registerStaticTypes().
You need to first generate the classes (if you already have SDO 1
generated classes, it may also work, but I'd recommend regening with the
SDO 2 generator).
Then, you need to make sure to add a call like this (somewhere early
during startup):
SDOUtil.registerStaticTypes(MyFactory.class);
Frank.
Jeremy Boynes [EMAIL PROTECTED] wrote on 01/18/2006 12:52:26 PM:
I'm trying to convert the account sample over to using just the SDO2
APIs.
I tried using the XSDHelper to define the XSD for the account service
but it does not map up to the Java interfaces we have. Apparently the
XSDHelper can only be used to define dynamic types.
The implementations of the services use SDO2 helpers (e.g. DataFactory)
to create instances of the data interfaces. If I can't use XSDHelper,
how do I set up the SDO2 factories to be able to do this?
This is the simple testcase I am trying to get running:
public class AccountServiceTestCase extends TestCase {
private AccountService service;
public void testAccountReport() {
AccountReport report = service.getAccountReport(BOB);
}
protected void setUp() throws Exception {
super.setUp();
service = new AccountServiceImpl(
DataFactory.INSTANCE,
USD,
new AccountDataServiceImpl(),
new StockQuoteServiceImpl()
);
}
}
which fails when the AccountServiceImpl does:
AccountReport accountReport =
(AccountReport) dataFactory.create(AccountReport.class);
--
Jeremy
Re: Setting up SDO2 factories
Frank Budinsky wrote: Ultimately though it would be good if people could use SDO2 without needed to generate any code at all. Wouldn't it be possible to provide implementations of user interfaces using Java Proxies (perhaps with codegen using ASM or something to boost performance)? Well, a big part of SDO is the DataObject (reflective API). Dynamic SDO already provides a full implementation for that, so I suspect that what you're asking for would be to 1) dynamically load the metadata given a Java interface, and then 2) Bind a Java Proxy for the interface to the dynamic impl. It all sounds possible, but isn't currently part of the spec we're implementing. Something like that - have the proxy implement the user's interface and DataObject and delegate invocations to the dynamic SDO implementation. If the performance of dynamic SDO is acceptable the the proxy overhead is easy to fix. The spec talks a lot about the generation of Java interfaces but nothing about the associated implementation beyond it having to implement DataObject. It does, however, describe the compatibility for applications used to using JavaBeans. It may help build adoption if we provide ways that make it easy for people coming from that environment to migrate without having to regenerate their code. There are lots of things we should be doing that are not part of the specifications - this value add is what makes the difference between a useful implementation and an RI, or between a successful project and one that fades to obscurity. are there directions some place for using the command line tool? It's described in contrib/java/trunk/docs/SDO_Java_Project_Overview.doc. I'll check it out,thanks -- Jeremy
Re: Setting up SDO2 factories
On Jan 18, 2006, at 3:14 PM, Jeremy Boynes wrote: Frank Budinsky wrote: Ultimately though it would be good if people could use SDO2 without needed to generate any code at all. Wouldn't it be possible to provide implementations of user interfaces using Java Proxies (perhaps with codegen using ASM or something to boost performance)? Well, a big part of SDO is the DataObject (reflective API). Dynamic SDO already provides a full implementation for that, so I suspect that what you're asking for would be to 1) dynamically load the metadata given a Java interface, and then 2) Bind a Java Proxy for the interface to the dynamic impl. It all sounds possible, but isn't currently part of the spec we're implementing. Something like that - have the proxy implement the user's interface and DataObject and delegate invocations to the dynamic SDO implementation. If the performance of dynamic SDO is acceptable the the proxy overhead is easy to fix. That would be helpful. An further step would be to allow for full POJO support where people could provide their own implementations which could be turned into SDOs (through subclassing or some other mechanism with the caveat this would only work for non-final classes). Perhaps there are some corner cases which limit this but it seems like it would be a very useful capability. The spec talks a lot about the generation of Java interfaces but nothing about the associated implementation beyond it having to implement DataObject. It does, however, describe the compatibility for applications used to using JavaBeans. It may help build adoption if we provide ways that make it easy for people coming from that environment to migrate without having to regenerate their code. There are lots of things we should be doing that are not part of the specifications - this value add is what makes the difference between a useful implementation and an RI, or between a successful project and one that fades to obscurity. are there directions some place for using the command line tool? It's described in contrib/java/trunk/docs/ SDO_Java_Project_Overview.doc. I'll check it out,thanks -- Jeremy
