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: build error
On 1/19/06, Jim Marino [EMAIL PROTECTED] wrote: When I run maven from 'java', I get the following failure on OS X. Is this something people know about? No. I built this morning on WinXP for the first time in a while and did not have any issues. Derby used to have problems on OSX. There was a workaround that required setting a system property and I thought it was fixed in newer versions of Derby/Mac JRE See: http://issues.apache.org/jira/browse/DERBY-1 -- Jeremy
Re: build error
I built and ran the unit tests successfully on OS X about a month ago with no problems; not recently though. Can you provide the last 38 lines of the stack trace? Is there any chance that a previous execution of the build had not completed? --Kevin Jim Marino wrote: When I run maven from 'java', I get the following failure on OS X. Is this something people know about? [INFO] [INFO] Building Tuscany DAS for Relational Databases [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Setting reports dir: /Users/jmarino/workspace/tuscany/tuscany/ tuscany/java/das/rdb/target/surefire-reports --- T E S T S --- ERROR XBM01: Startup failed due to an exception. See next exception for details. at org.apache.derby.iapi.error.StandardException.newException (Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.exceptionStartingModule (Unknown Source) at org.apache.derby.impl.store.raw.log.LogToFile.boot (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot (Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule (Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule (Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory( Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFact ory(Unknown Source) at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot (Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule (Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule (Unknown Source) at org.apache.derby.impl.store.access.RAMAccessManager.boot (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot (Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule (Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule (Unknown Source) at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source) at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot (Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.createPersistentServi ce(Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.createPersistentService (Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.createDatabase (Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection30.init (Unknown Source) at org.apache.derby.jdbc.Driver30.getNewEmbedConnection (Unknown Source) at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java:525) at java.sql.DriverManager.getConnection(DriverManager.java:193) at org.apache.tuscany.das.rdb.test.framework.DatabaseSetup.initConnection (DatabaseSetup.java:55) at org.apache.tuscany.das.rdb.test.framework.DatabaseSetup.init (DatabaseSetup.java:42) at org.apache.tuscany.das.rdb.test.framework.DerbySetup.init (DerbySetup.java:26) at org.apache.tuscany.das.rdb.test.suites.AllTestsDerby.suite (AllTestsDerby.java:30) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at
C++ build opinions/help
The current cpp SDO and SCA were developed using MS Visual Studio on Windows and eclipse + CDT on Linux. For a command line build on linux we simply created a shell script that used the makefiles generated by the CDT managed make. I would like to create a more robust and portable build environment for the cpp code and would welcome some guidance on what the best build style is for C++. Options: 1) Handcrafted Makefiles 2) Use Autotools (autoconf/automake) 3) Eclipse + CDT only 4) Ant + cpptasks 5) ??? Does Maven help with any of these? Any help or opinions would be greatly appreciated before I set off down the wrong path ;-) Pete
Re: C++ build opinions/help
I was chatting with one of the Maven guys at ApacheCon and was told that although it is early days they have done some C++ projects. Although it might be atypical for a C++ project, it may make the integration with the Java project easier (e.g. when we want to host C++ components in Java or Java one in C++). It might be worth exploring that approach. If it doesn't play out my (uninformed) opinion is that autoconf/automake is the most used mechanism. -- Jeremy On 1/19/06, Pete Robbins [EMAIL PROTECTED] wrote: The current cpp SDO and SCA were developed using MS Visual Studio on Windows and eclipse + CDT on Linux. For a command line build on linux we simply created a shell script that used the makefiles generated by the CDT managed make. I would like to create a more robust and portable build environment for the cpp code and would welcome some guidance on what the best build style is for C++. Options: 1) Handcrafted Makefiles 2) Use Autotools (autoconf/automake) 3) Eclipse + CDT only 4) Ant + cpptasks 5) ??? Does Maven help with any of these? Any help or opinions would be greatly appreciated before I set off down the wrong path ;-) Pete
Re: build error
The problem was the issue Jeremy pointed to (http://issues.apache.org/ jira/browse/DERBY-1). I ran into this problem on two separate OS X machines. A workaround is to set the command line option - Dderby.storage.fileSyncTransactionLog=true when running Maven. Ideally, we should have some conditional in the build script that puts this in for OS X. I would normally do this myself, but since it's not my area and I don't want to break the build, do someone more familiar want to do this? I should have included the Derby log in the original. Here is the culprit: 2006-01-19 22:25:56.499 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.1.1.0 - (208786): instance c013800d-0108-e4c6-2217-cb7e7191 on database directory /Users/jmarino/workspace/tuscany/tuscany/ tuscany/java/target/dastest 2006-01-19 22:25:56.632 GMT: Shutting down instance c013800d-0108-e4c6-2217-cb7e7191 2006-01-19 22:25:56.675 GMT Thread[main,5,main] Cleanup action starting ERROR XBM01: Startup failed due to an exception. See next exception for details. at org.apache.derby.iapi.error.StandardException.newException (Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.exceptionStartingModule (Unknown Source) at org.apache.derby.impl.store.raw.log.LogToFile.boot(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot (Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule (Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule (Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory( Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFact ory(Unknown Source) at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot (Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule (Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule (Unknown Source) at org.apache.derby.impl.store.access.RAMAccessManager.boot (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot (Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule (Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule (Unknown Source) at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source) at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot (Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.createPersistentServi ce(Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.createPersistentService (Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.createDatabase (Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection30.init(Unknown Source) at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Unknown Source) at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java:525) at java.sql.DriverManager.getConnection(DriverManager.java:193) at org.apache.tuscany.das.rdb.test.framework.DatabaseSetup.initConnection (DatabaseSetup.java:55) at org.apache.tuscany.das.rdb.test.framework.DatabaseSetup.init (DatabaseSetup.java:42) at org.apache.tuscany.das.rdb.test.framework.DerbySetup.init (DerbySetup.java:26) at org.apache.tuscany.das.rdb.test.suites.AllTestsDerby.suite (AllTestsDerby.java:30) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.battery.JUnitBattery.processTestClass (JUnitBattery.java:130) at org.apache.maven.surefire.battery.JUnitBattery.init (JUnitBattery.java:81) at org.apache.maven.surefire.SurefireUtils.instantiateBattery (SurefireUtils.java:63) at
Re: build error
Jim Marino wrote:
The problem was the issue Jeremy pointed to (http://issues.apache.org/
jira/browse/DERBY-1). I ran into this problem on two separate OS X
machines. A workaround is to set the command line option -
Dderby.storage.fileSyncTransactionLog=true when running Maven. Ideally,
we should have some conditional in the build script that puts this in
for OS X. I would normally do this myself, but since it's not my area
and I don't want to break the build, do someone more familiar want to
do this?
Can you try with Derby 10.1.2.1 available from here:
http://db.apache.org/derby/releases/release-10.1.2.1.cgi
It's not on ibiblio yet so you will need to install the jar in your
local maven repo:
$ mvn install:install-file -Dpackaging=jar -DgroupId=org.apache.derby \
-Dartifact=derby -Dversion=10.1.2.1 -Dfile=${file}
where ${file} is the derby.jar file from that download.
If that works it's simpler just to upgrade the Derby version. If not,
can you tell me the version of OSX and JRE so we can document that for
Derby.
Thanks
--
Jeremy
