Re: Need some help
Hi Charuka, I contributed the LDAP DAS a while back. It knows how to create a ApacheDS schema dynamically based on metadata on the SDO Objects (EMF objects really) and store, retrieve, delete DataGraph instances. There's more work needed in the areas of: Querying SQL queries would have to be converted to JNDI queries, since LDAP works with JNDI. Also as it is right now if someone attempts to load an Object in a graph, that objects children are also automatically loaded. So it needs to have proxy references established that will automatically fetch these children if the client wants to lazy load them. Interface / API A API layer that matches Tuscany's RDB DAS needs to wrap the current API. Support for Tuscany SDO I used the EMF API to develop the initial as is verison. Ideally the DAS would work the same with both Tuscany SDO Objects and EMF SDO Objects. So those are just a few areas that need work. Please let me know if this is something of interest, and I'll do my best to provide further support. Cheers, - Ole Dear all, I am a Masters student in Georgia State University, and hope to work on my Theses with some contribution to Tuscany. My adviser is fine with my suggestion to take over a Tuscany project and work on that as for my theses. He advises me to take over a project which has enough intellectual contribution as well as it should be a novel idea resulting a publishable paper at the end. I appreciate if you can help me finding some potential areas having above requirements fulfilled. Thank you Charuka
Re: XSD -- DB and Vice Versa
Hi Amita, Amita Vadhavkar wrote: For SDO Types - XSD , there is XSDHelper.generate(List of Types) support existing in SDO Impl. Super. Thanks for the heads up. For XSD- DB Schema - I have a question, as far as SDO does not support IDREF/KEYREF in SDO definitions, how a containment relationship in XSD model can get successfully translated into referential integrity constraint (relationship) in a database? It's a good question. Do you know whether the following cases are true (I'm just assuming it at the moment)? == SDO XSD DB Schema == In this case the SDO to XSD transformation will only generate XSD types that exclude attributes with the IDREF/KEYREF type, so the transformation does not need to be done when going to DB Schema? -- I'm also assuming this: == XSD SDO == In this case the XSD to SDO transformation will map XSD IDREF/KEYREF types to a corresponding SDO types. --- If these two are true, then it seems like the way SDO database schema creation via XSD DB Schema would be supported by doing XSD SDO XSD DB Schema just to get a clean mapping of SDO types. Thoughts? Thanks, - Ole For this (i.e. lack of IDREF) RDB DAS has provided config/relationship where user can specify the required information. And it is used during data access. Regards, Amita On Jan 7, 2008 11:13 AM, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I know Amita is looking into DB XSD. I was wondering if there is any work being done on XSD DB? Also can the SDO implementation generate the XSD if the SDO types are provided, enabling SDO Type XSD DB? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] What's next for Tuscany DAS?
Hi Amita, I saw someone else mention support for database schema generation, similar to what Hibernate has, as a feature request, so just echoing it. In the Support for Non SDO Types category, I think EMF EObject support would be cool. The Tuscany DAS seems to be competing with the EMFT Elver project which uses Hibernate to bring DAS like capabilities to EMF. If the Tuscany DAS supported EMF EObject's then maybe Elver developers would consider joining in on Tuscany DAS development. I imagine this would also get a lot of attention from other Eclipse MDA projects. Cheers, - Ole Amita Vadhavkar wrote: Hi, Thinking about RDB DAS Next release, there can be different interesting features to add like - 1- Integration with SCA policy and transaction support 2- Data Services (following DAS Specification investigations/directions) 3- DAS WebServices 4- DAS integration with JPA (Fluid) 5 - XML Types and deeper integration with XML Databases 6- Data Feeds 7- Support for non-SDO types It will be great to add more to this list, provide pointers to some user requirements that may have come up in the past. There is some discussion - for 1- in http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Design+Discussion and 3- in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25701.html Please pour your thoughts there and also start new ML threads for any other topics. We can use the current thread as a place to consolidate what items get prioritized for the next release and what major features are added to RDB DAS as a result. Appreciate your comments. Regards, Amita - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generating Eclipse WTP Web Projects for our Webapp samples
That's extremely cool! Thanks for the tip Jean Sebastien, - Ole Jean-Sebastien Delfino wrote: Hi all, I just thought I'd share this as I found it pretty useful when working with our Webapp samples. If you're using Eclipse WTP and want to get WTP Web Projects generated for our Webapp samples you can simply pass a -Dwtpversion=1.5 option to the usual mvn eclipse:eclipse command, like this: mvn -Dwtpversion=1.5 -Peclipse eclipse:eclipse The magic -Dwtpversion=1.5 option will add the WTP Web project nature to all the Eclipse projects with packagingwar/packaging in their Maven pom.xml. You'll then be able to add these projects to a WTP Tomcat or Geronimo Server configuration, to publish and run them straight from your Eclipse workspace. Hope this helps. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1550) InitialContextCreatorHelper Javadoc
InitialContextCreatorHelper Javadoc --- Key: TUSCANY-1550 URL: https://issues.apache.org/jira/browse/TUSCANY-1550 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Priority: Trivial Javadoc Update to the InitialContextCreatorHelper -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1550) InitialContextCreatorHelper Javadoc
[ https://issues.apache.org/jira/browse/TUSCANY-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Ersoy updated TUSCANY-1550: --- Attachment: InitialContextCreatorHelperPatch.txt InitialContextCreatorHelper Javadoc --- Key: TUSCANY-1550 URL: https://issues.apache.org/jira/browse/TUSCANY-1550 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Priority: Trivial Attachments: InitialContextCreatorHelperPatch.txt Javadoc Update to the InitialContextCreatorHelper -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1551) MetaContextCreator.java Patch
MetaContextCreator.java Patch - Key: TUSCANY-1551 URL: https://issues.apache.org/jira/browse/TUSCANY-1551 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Priority: Trivial Attachments: MetaContextCreatorPatch.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1551) MetaContextCreator.java Patch
[ https://issues.apache.org/jira/browse/TUSCANY-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Ersoy updated TUSCANY-1551: --- Attachment: MetaContextCreatorPatch.txt MetaContextCreator.java Patch - Key: TUSCANY-1551 URL: https://issues.apache.org/jira/browse/TUSCANY-1551 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Priority: Trivial Attachments: MetaContextCreatorPatch.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1538) InitialContextCreator Patches
InitialContextCreator Patches - Key: TUSCANY-1538 URL: https://issues.apache.org/jira/browse/TUSCANY-1538 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Attachments: InitialContextCreatorPatch.txt, InitialContextCreatorTestPatch.txt InitialContextCreator javadoc and test patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1538) InitialContextCreator Patches
[ https://issues.apache.org/jira/browse/TUSCANY-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Ersoy updated TUSCANY-1538: --- Attachment: InitialContextCreatorTestPatch.txt InitialContextCreator Patches - Key: TUSCANY-1538 URL: https://issues.apache.org/jira/browse/TUSCANY-1538 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Attachments: InitialContextCreatorPatch.txt, InitialContextCreatorTestPatch.txt InitialContextCreator javadoc and test patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1538) InitialContextCreator Patches
[ https://issues.apache.org/jira/browse/TUSCANY-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Ersoy updated TUSCANY-1538: --- Attachment: InitialContextCreatorPatch.txt InitialContextCreator Patches - Key: TUSCANY-1538 URL: https://issues.apache.org/jira/browse/TUSCANY-1538 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Attachments: InitialContextCreatorPatch.txt, InitialContextCreatorTestPatch.txt InitialContextCreator javadoc and test patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
Hi Luciano, Simon, I ran it like this: mvn -U -fn clean install And it runs fine (Some test errors, but build completes) with maven 2.0.5 and java 1.5.12. Thanks for all the feedback, - Ole Simon Laws wrote: On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Ole Here is what I tried, and all went OK 1.Removed .m2\repository\org\apache\tuscany 2.svn update to revision #565235 3.cd %tuscany_home%\java 4.mvn -U -fn clean install java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Maven version: 2.0.5 -- If you have a higher version, I'd recommend trying with 2.0.5 [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 48 minutes 3 seconds [INFO] Finished at: Sun Aug 12 22:28:52 PDT 2007 [INFO] Final Memory: 61M/63M [INFO] On 8/12/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi Simon, Simon Laws wrote: I note from your other post that you are having problems with the full build with JDK1.6. Is it possible for you to try with 1.5 as this is known to work? We can then isolate JDK issues from these more general build issues. Oh Man - It almost made it - I gave 1.5.12 a go for the whole build and it made it this far (I also disabled SELinux to make sure nothing funky was happening): --- T E S T S --- Running supplychain.SupplyChainClientTestCase In SupplyChainClientTestCase.test: Calling customer.purchaseGoods, customer is [Proxy - f6438d] java.lang.ClassNotFoundException: supplychain.retailer.Retailer at org.apache.felix.framework.Felix.loadBundleClass(Felix.java :1422) at org.apache.felix.framework.BundleImpl.loadClass( BundleImpl.java:335) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveWireRegisterProxyService (OSGiImplementationProvider.java:773) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveBundle (OSGiImplementationProvider.java:873) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle (OSGiImplementationProvider.java:326) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance (OSGiInstanceWrapper.java:70) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget (OSGiTargetInvoker.java:121) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke (OSGiTargetInvoker.java:172) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke( RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke( AbstractInvocationHandler.java:145) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:75) at $Proxy7.purchaseGoods(Unknown Source) at supplychain.SupplyChainClientTestCase.test( SupplyChainClientTestCase.java:52) 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 junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run( OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute( JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet( AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute( AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39
Re: mvn eclipse:eclipse fails on java
Hi Simon, Simon Laws wrote: I note from your other post that you are having problems with the full build with JDK1.6. Is it possible for you to try with 1.5 as this is known to work? We can then isolate JDK issues from these more general build issues. Oh Man - It almost made it - I gave 1.5.12 a go for the whole build and it made it this far (I also disabled SELinux to make sure nothing funky was happening): --- T E S T S --- Running supplychain.SupplyChainClientTestCase In SupplyChainClientTestCase.test: Calling customer.purchaseGoods, customer is [Proxy - f6438d] java.lang.ClassNotFoundException: supplychain.retailer.Retailer at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1422) at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:335) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveWireRegisterProxyService(OSGiImplementationProvider.java:773) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveBundle(OSGiImplementationProvider.java:873) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle(OSGiImplementationProvider.java:326) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance(OSGiInstanceWrapper.java:70) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget(OSGiTargetInvoker.java:121) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke(OSGiTargetInvoker.java:172) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:145) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:75) at $Proxy7.purchaseGoods(Unknown Source) at supplychain.SupplyChainClientTestCase.test(SupplyChainClientTestCase.java:52) 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 junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) 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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.12 sec FAILURE! test(supplychain.SupplyChainClientTestCase) Time elapsed: 1.995 sec ERROR! org.apache.tuscany.sca.factory.ObjectCreationException: org.apache.tuscany.sca.factory.ObjectCreationException: java.lang.ClassNotFoundException: supplychain.retailer.Retailer at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle(OSGiImplementationProvider.java:360) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance(OSGiInstanceWrapper.java:70) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget(OSGiTargetInvoker.java:121) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke(OSGiTargetInvoker.java:172) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at
Re: mvn eclipse:eclipse fails on java
SNIP i.e. sca/modules/binding-sca-xml Thanks for pointing this out Jean-Sebastien. OK - I tried building the module by itself. I'm running jdk 1.6, but that should be ok right? I get the following: [INFO] Compiling 2 source files to /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/target/test-classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/WriteTestCase.java:[37,46] package org.apache.tuscany.sca.binding.sca.impl does not exist /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/ReadTestCase.java:[40,46] package org.apache.tuscany.sca.binding.sca.impl does not exist /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/WriteTestCase.java:[75,8] cannot find symbol symbol : class SCABindingFactoryImpl location: class org.apace.tuscany.sca.binding.sca.xml.WriteTestCase /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/WriteTestCase.java:[75,47] cannot find symbol symbol : class SCABindingFactoryImpl location: class org.apace.tuscany.sca.binding.sca.xml.WriteTestCase /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/ReadTestCase.java:[71,32] cannot find symbol symbol : class SCABindingFactoryImpl location: class org.apace.tuscany.sca.binding.sca.xml.ReadTestCase /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/ReadTestCase.java:[80,43] cannot find symbol symbol : class SCABindingFactoryImpl location: class org.apace.tuscany.sca.binding.sca.xml.ReadTestCase [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 28 seconds [INFO] Finished at: Sat Aug 11 20:18:30 CDT 2007 [INFO] Final Memory: 9M/25M [INFO] I could probably work around these issues for updating the LDAP DAS code, but will be glad to keep trying things if we want to try to get to the bottom of this. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build Failure on java trunk
Jean-Sebastien Delfino wrote: This is weird, the build works for me with Sun JDK 1.5.0_10 on Linux. The latest nightly confluence build [1] is successful too. Hmmm...Maybe it's my jdk... Which JDK are you using? Sun JDK 1.6.0 on Linux Can you try to run a simple program with a main() method calling XMLInputFactory.newInstance() and see what you get? Which maven dependency would I specify for this? Do I need to configure a custom repository? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
I also tried looking for this manually: org.apache.tuscany.sca:tuscany-binding-sca-xml:jar:1.0-incubating-SNAPSHOT Here's what I find in the repository under: http://people.apache.org/repo/m2-snapshot-repository/org/apache/tuscany/sca/ [DIR] tuscany-binding-notification/27-Jul-2007 22:06- [DIR] tuscany-binding-rmi/ 23-May-2007 15:32- [DIR] tuscany-binding-sca/ 27-Jul-2007 17:17- [DIR] tuscany-binding-ws-axis2/23-May-2007 15:35- [DIR] tuscany-binding-ws-xml/ Should there be a directory corresponding to the groupid: tuscany-binding-sca-xml Here? Thanks, - Ole Luciano Resende wrote: What version of maven are you using ? Does it work with maven 2.0.5 ? See more info here [1] [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21031.html On 8/9/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I tried checking out java and eclipseefying the build, but I get this error: 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT Thoughts? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
I tried it with 2.0.5: [EMAIL PROTECTED] java]$ /home/ole/Desktop/maven-2.0.5/bin/mvn eclipse:eclipse I still get the same error... Missing: -- 1) org.apache.tuscany.sca:tuscany-binding-sca-xml:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Luciano Resende wrote: What version of maven are you using ? Does it work with maven 2.0.5 ? See more info here [1] [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21031.html On 8/9/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I tried checking out java and eclipseefying the build, but I get this error: 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT Thoughts? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Build Failure on java trunk
Hi, I just tried building the entire java trunk, and I get the following build failure: --- T E S T S --- Running org.apache.tuscany.sca.contribution.services.ContributionMetadataDocumentProcessorTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.146 sec Running org.apache.tuscany.sca.contribution.processor.FolderContributionPackageProcessorTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 sec Running org.apache.tuscany.sca.contribution.services.PackageTypeDescriberImplTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.152 sec Running org.apache.tuscany.sca.contribution.resolver.ExtensibleArtifactResolverTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.11 sec Running org.apache.tuscany.sca.contribution.resolver.ArtifactResolverTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.095 sec Running org.apache.tuscany.sca.contribution.processor.JarContributionPackageProcessorTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.098 sec Running org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.107 sec FAILURE! testStore(org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase) Time elapsed: 0.094 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:158) at org.apache.tuscany.sca.contribution.service.impl.ContributionRepositoryImpl.init(ContributionRepositoryImpl.java:93) at org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase.setUp(ContributionRepositoryTestCase.java:37) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) 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:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) testRemove(org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase) Time elapsed: 0.001 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:158) at org.apache.tuscany.sca.contribution.service.impl.ContributionRepositoryImpl.init(ContributionRepositoryImpl.java:93) at org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase.setUp(ContributionRepositoryTestCase.java:37) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at
Re: mvn eclipse:eclipse fails on java
Hi Simon, SNIP assuming you have the source tree checked out of svn. Yes Can you try building that module before you run the eclipse generation? Sure - I'll give it a shot. If I'm in ./java how do I find the module? Having said that I just knocked it out of my local repo and the eclipse generation ran fine. This is what I see for the project in question. SNIP Can you post the output block you get? Here's a partial block (The entire out is pretty long - I can post the rest if we need it though): [INFO] Building Apache Tuscany Dojo Sample WebApp [INFO]task-segment: [eclipse:eclipse] [INFO] [INFO] Preparing eclipse:eclipse Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/sca/tuscany-binding-sca-xml/1.0-incubating-SNAPSHOT/tuscany-binding-sca-xml-1.0-incubating-SNAPSHOT.jar Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/tuscany/sca/tuscany-binding-sca-xml/1.0-incubating-SNAPSHOT/tuscany-binding-sca-xml-1.0-incubating-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.tuscany.sca:tuscany-binding-sca-xml:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany-binding-sca-xml \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany-binding-sca-xml \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-host-webapp:jar:1.0-incubating-SNAPSHOT 3) org.apache.tuscany.sca:tuscany-host-embedded:jar:1.0-incub ating-SNAPSHOT 4) org.apache.tuscany.sca:tuscany-binding-sca-xml:jar:1.0-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 28 seconds [INFO] Finished at: Fri Aug 10 18:48:57 CDT 2007 [INFO] Final Memory: 36M/63M [INFO] Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mvn eclipse:eclipse fails on java
Hi, I tried checking out java and eclipseefying the build, but I get this error: 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT Thoughts? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Resolved: (TUSCANY-1495) LDAP DAS Contribution
Terrific - Thanks! Luciano Resende (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1495. -- Resolution: Fixed Patch applied under revision #562520 LDAP DAS Contribution - Key: TUSCANY-1495 URL: https://issues.apache.org/jira/browse/TUSCANY-1495 Project: Tuscany Issue Type: New Feature Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Ole Ersoy Assignee: Luciano Resende Priority: Minor Fix For: Java-DAS-Next Attachments: das.ldap.parent.zip Hi, The attached zip contains the LDAP DAS Contribution. The current implementation uses EMF (EDataGraph, EDataObject/EObject, EClass), but the plan is to make the LDAP DAS implementation independent. In order to compile and run the tests, the lastest snapshot of ApacheDS must be installed in the maven repository. http://directory.apache.org/community%26resources/sources.html The LdapDASTest.java contains the tests that test the DAS interface. The current LdapDAS interface throws LDAP specific exceptions, but we'll figure out some elegant ways of handling these, while wrapping it in the Tuscany DAS interface . Emmanuel Lecharny, Alex Karasulu, and the rest of the Apache Directory Team have been super helpful and supportive in getting this DAS implementation done and this implementation owes a lot to their hard work on the directory server, particularly the dynamic schema capability. Also, Ed Merks (EMF) was very helpful in finding the relevant components of the EMF API. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (TUSCANY-1506) Fix RAT issues in DAS LDAP
Hi Luciano, I looked at the RAT log and noticed that I ended up including the server-work directory in the zip. Could you please delete this from subversion. The server-work directory is created when ApacheDS is started in embedded mode by the tests. I'll start patching the non-licensed java files, as well as adding more detailed javadocs. Thanks, - Ole Luciano Resende (JIRA) wrote: Fix RAT issues in DAS LDAP -- Key: TUSCANY-1506 URL: https://issues.apache.org/jira/browse/TUSCANY-1506 Project: Tuscany Issue Type: Bug Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Luciano Resende Fix For: Java-DAS-Next Attachments: ldap-rat.log Running rat on the LDAP source flaged couple issues that we should look at. I'll attach the rat.log to this JIRA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1495) LDAP DAS Contribution
LDAP DAS Contribution - Key: TUSCANY-1495 URL: https://issues.apache.org/jira/browse/TUSCANY-1495 Project: Tuscany Issue Type: New Feature Reporter: Ole Ersoy Priority: Minor Hi, The attached zip contains the LDAP DAS Contribution. The current implementation uses EMF (EDataGraph, EDataObject/EObject, EClass), but the plan is to make the LDAP DAS implementation independent. In order to compile and run the tests, the lastest snapshot of ApacheDS must be installed in the maven repository. http://directory.apache.org/community%26resources/sources.html The LdapDASTest.java contains the tests that test the DAS interface. The current LdapDAS interface throws LDAP specific exceptions, but we'll figure out some elegant ways of handling these, while wrapping it in the Tuscany DAS interface . Emmanuel Lecharny, Alex Karasulu, and the rest of the Apache Directory Team have been super helpful and supportive in getting this DAS implementation done and this implementation owes a lot to their hard work on the directory server, particularly the dynamic schema capability. Also, Ed Merks (EMF) was very helpful in finding the relevant components of the EMF API. Cheers, - Ole -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1495) LDAP DAS Contribution
[ https://issues.apache.org/jira/browse/TUSCANY-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Ersoy updated TUSCANY-1495: --- Attachment: das.ldap.parent.zip LDAP DAS Contribution - Key: TUSCANY-1495 URL: https://issues.apache.org/jira/browse/TUSCANY-1495 Project: Tuscany Issue Type: New Feature Reporter: Ole Ersoy Priority: Minor Attachments: das.ldap.parent.zip Hi, The attached zip contains the LDAP DAS Contribution. The current implementation uses EMF (EDataGraph, EDataObject/EObject, EClass), but the plan is to make the LDAP DAS implementation independent. In order to compile and run the tests, the lastest snapshot of ApacheDS must be installed in the maven repository. http://directory.apache.org/community%26resources/sources.html The LdapDASTest.java contains the tests that test the DAS interface. The current LdapDAS interface throws LDAP specific exceptions, but we'll figure out some elegant ways of handling these, while wrapping it in the Tuscany DAS interface . Emmanuel Lecharny, Alex Karasulu, and the rest of the Apache Directory Team have been super helpful and supportive in getting this DAS implementation done and this implementation owes a lot to their hard work on the directory server, particularly the dynamic schema capability. Also, Ed Merks (EMF) was very helpful in finding the relevant components of the EMF API. Cheers, - Ole -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] Current API and EMF dependencies...
SNIP Good, I'll wait for your updates to take a further look. Please let me know when you committ these updates. Cool - I'll check in and update in a few days. SNIP I have no idea of when SDO 3.0 will be available, and we are not sure that we will have all the necessary APIs you think is missing on that release, right ? Sure - I'm sure 3.0 vs. 2.1 will be a minor thing overall. Once I'm done with the design document, we can review and consider an approach for the gaps that we see between the APIs. There are something like 12 classes that use EMF, of which 6 are core classes, so I think solutions to make the LDAP DAS SDO 2.1 compliant can be implemented quickly. SNIP We should also involve the SDO folks here, and get their input on this subject, but, having RDB DAS and LDAP DAS returning incompatible SDO would be a issue to really take in consideration when making the final decision here. Sure - I think once we understand the gaps, we'll quickly come up with solutions, and then we can put them all in a road map, and start making the LDAP DAS work with the SDO Spec. SNIP This is not really around SDO, but making usage of DAS Interfaces. I'd expect that the LDAP DASImpl [1] would implement a variation of Tuscany DAS Interface [2], and all other Tuscany DAS implementations would do the same (e.g RDB, XQuery, or any other that comes in the future). A similar interface is being used for DAS C++. This allows for a common programming model and api on the DAS level. Any plans for this ? Yes - That's the plan. [1] https://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.ldap.parent/das.ldap/src/main/java/org/apache/tuscany/das/ldap/impl/DASImpl.java [2] https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/api/src/main/java/org/apache/tuscany/das/DAS.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] 1.0.0 Just about Done + Question
Luciano Resende wrote: Are we trying to make it much more complex ? :-) I'm a big believer in as simple as possible, but no simpler. Are users going to get confused to think they have a local copy of the XML config file, but the LDAP DAS is really using the one stored on the server ? You are right. Having the whole configuration file in the DIT does not make much sense. Initially I was thinking that the config file would contain a list of all the xsd namespaces representing the schemas that are written to the server. But now I'm thinking that this list should be contained on the server, but will remain independent of the config file. The DAS then goes through the following sequence before writing a graph: - Lookup the supported schemas (List of xsd namespaces) in the DIT (Just creates a ListString of xsd namespaces) - See whether the list contains the xsd namespace for the graph that is about to be written - If it does, write the graph - If it does not, write the schema - Add the xsd namespace string to the supported schema list - Update this list on the server Sound OK? SNIP BTW, it would be great if you could add some overview design doc on the Wiki, also some sample code, or pointers to sample code, etc... Sure - I'm just implementing the things we are going over right now, and then I'm going to write a users guide, followed by updates to the design guide. The remaining (For a working LDAP DAS) task list looks approximately like this: - Finish the DAS Interface / object (Main CRUD Interface (LdapDAS.write(EDataGraph), ) - Test the DAS Interface / object - Finish and test JNDI Connection pooling configuration (Low priority) - Update the EDataGraphCreator to ignore Transient properties (Right now it will write all the properties) - Add support for multiplicity many EAttributes (Right now it just assumes that they are singular) - Complete users guide - Complete design guide - Formal Apache review Thoughts? SNIP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] Current API and EMF dependencies...
Hey Luciano, Luciano Resende wrote: Hi Ole After you mentioned you are almost done with a initial version of LDAP DAS that provides CRUD operations [1] I went to your sandbox [2] to take a quick look at the current implementation and have couple questions : - Where is the latest implementation of LDAP DAS available ? Is the code you have in your sandbox current and the most update one ? As soon as I have finished up the DAS interface code, commented everything, and removed left over scraps I'll do another check in the Working version. The sandbox is still the old stuff from when I first got reading and writing graphs working. - Your sandbox looks like still using a lot of EMF dependencies. Do you have any plans to base the LDAP DAS implementation on current Tuscany SDO (SDO 2.1 specification implementation)? I think we might want to shoot for having it compliant with the SDO 3.0 spec. 2.1 seems to be missing some key API features such as something equivalent to getEIDAttributes() which returns the EAttribute where id is true. Also another thing that both EMF and SDO 2.1 are missing is getEAllCrossReferences (which is the opposite of getEAllContainmentReferences()...EMF does provide an implementation specific way of doing this though, although it's not part of the API). Having these in the SDO spec would give us a head start of having a consistent programming model across DASs. - The beauty of Heterogenous DAS is to have a consistent programming model and a single set of APIs to access data from heterogeneous data sources, such as RDB and LDAP. Looks like the current implementation of LDAP DAS is using a different set of APIs for it's implementation, thus introducing a new programming model and a new set of APIs. What are your plans here ? I totally agree with you. The LDAP DAS should work with the standard SDO API asap. So we need to identify the gaps between the EMF API parts used currently and the SDO API and bridge them. Meanwhile, those users needing a common interface for both the LDAP DAS and RDB DAS would have to use the EMF SDO implementation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] 1.0.0 Just about Done + Question
Great tip Adriano. I modeled the configuration file using ecore, so I just made it a multiplicity many EAttribute with type EString. I'll make a note in my todo list make it a TreeSet instead. Thanks, - Ole Adriano Crestani wrote: This list of xsd namespaces, instead of using ListString, wouldn't be better to user TreeSetString? Once you need to look up for namespaces on the list frequently, unless if there are another reason to use List that I'm not aware about : ) Regards, Adriano Crestani On 7/24/07, Ole Ersoy [EMAIL PROTECTED] wrote: Luciano Resende wrote: Are we trying to make it much more complex ? :-) I'm a big believer in as simple as possible, but no simpler. Are users going to get confused to think they have a local copy of the XML config file, but the LDAP DAS is really using the one stored on the server ? You are right. Having the whole configuration file in the DIT does not make much sense. Initially I was thinking that the config file would contain a list of all the xsd namespaces representing the schemas that are written to the server. But now I'm thinking that this list should be contained on the server, but will remain independent of the config file. The DAS then goes through the following sequence before writing a graph: - Lookup the supported schemas (List of xsd namespaces) in the DIT (Just creates a ListString of xsd namespaces) - See whether the list contains the xsd namespace for the graph that is about to be written - If it does, write the graph - If it does not, write the schema - Add the xsd namespace string to the supported schema list - Update this list on the server Sound OK? SNIP BTW, it would be great if you could add some overview design doc on the Wiki, also some sample code, or pointers to sample code, etc... Sure - I'm just implementing the things we are going over right now, and then I'm going to write a users guide, followed by updates to the design guide. The remaining (For a working LDAP DAS) task list looks approximately like this: - Finish the DAS Interface / object (Main CRUD Interface (LdapDAS.write(EDataGraph), ) - Test the DAS Interface / object - Finish and test JNDI Connection pooling configuration (Low priority) - Update the EDataGraphCreator to ignore Transient properties (Right now it will write all the properties) - Add support for multiplicity many EAttributes (Right now it just assumes that they are singular) - Complete users guide - Complete design guide - Formal Apache review Thoughts? SNIP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[LDAP DAS] 1.0.0 Just about Done + Question
Howdy, UPDATE: The LDAP DAS is reading and writing graphs and it can process the change summary. I still have a few more tests to write, but I think it's pretty solid. QUESTION: Right now I default the isTypeSystemCreated configuration parameters (Keyed by model namespaceURI) to false. If the DAS runs with it set this way, it will always attempt to create the LDAP type system, but will still check to see if it exists first. I'd like to automate setting it to true, after the DAS has run for the first time. One way would be to just rewrite the configuration file, and then read it again in order to validate the rewrite. Does this sound OK? Are there better ways? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] 1.0.0 Just about Done + Question
Hi Luciano, Luciano Resende wrote: Very good to hear these news Ole. Regarding your question, does create the LDAP type system means creating the LDAP schema on the LDAP server ? Yes Do you also have the scenario of updating the schema ? Yes as long as the Schema update is versioned using the xsd namespace, as in http://maven.apache.org/pom/3.0.0 vs. http://maven.apache.org/pom/4.0.0 What about pre-populating like in sample applications ? The tests populate, so for stress testing and so on it's just a matter of building on these. Well, if you have these scenarios, maybe it would be better to use an utility to allow applications to do that, we have a similar thing in RDB DAS (dbConfig). When I woke up this morning it occurred to me that I can just store the DAS's config in the LDAP Directory Information Tree (DIT LDAP Storage Structure). That's a typical LDAP usage scenario anyways. What we could do is on first startup, store the configuration in the DIT, then on subsequent starts the minimal connection information is read from the config file, and the rest comes from the DIT. When the user wants an updated configuration file, she just loads the configuration in the DIT and serializes it to XML. Sound OK? As for the other option, that you mentioned, are you always going to have access to the configFile? In the case of RDB DAS, we allow for configuring only by passing a Stream, and in this case I guess you solution would fail. I think this scenario would be covered by storing the configuration in the DIT. Thoughts? Thanks, - Ole SNIP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Programming model for multiple implementations Fwd: [jira] Updated: (TUSCANY-1431) DAS with XQuery based data access support
Hi, I reviewed Luciano's sandbox code a while back, and will integrate it once I have tested all the CRUD operations / the classes that are the workhorses..., so any changes will have minimal impact on the LDAP DAS at them moment. Cheers, - Ole Luciano Resende wrote: Hi Amita I was taking a quick look in your proposed changes in the DAS API that is in my sandbox, could you please elaborate your thoughts around the programming model proposed here [1] ? Have you looked at the implications of these changes on other DAS implementations, such as LDAP DAS ? [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.html -- Forwarded message -- From: Amita Vadhavkar (JIRA) tuscany-dev@ws.apache.org Date: Jul 15, 2007 10:56 AM Subject: [jira] Updated: (TUSCANY-1431) DAS with XQuery based data access support To: tuscany-dev@ws.apache.org [ https://issues.apache.org/jira/browse/TUSCANY-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1431: - Attachment: 1431_xquery.patch 1431_api.patch this is just a work in progress, where config (xquery specific) is created and some basic classes are in progress. trying and checking different XQuery implementations available - like Saxon, DB2 Express etc. Next patch will have some work on that. Please give suggestions based on patch and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19983.html Thanks, Amita DAS with XQuery based data access support - Key: TUSCANY-1431 URL: https://issues.apache.org/jira/browse/TUSCANY-1431 Project: Tuscany Issue Type: New Feature Components: Java DAS XQuery Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Attachments: 1431_api.patch, 1431_xquery.patch place for submitting incremental patches for the ground work of XQuery DAS -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] Restoring non-containment references?
Hi Adriano, Super - Thanks for the feedback. During the first pass I'll just add annotations keyed by reference name to each DataObject instance and then I'll look up the xpath by the non-containment reference name on the second pass. Thanks again, - Ole Adriano Crestani wrote: Hi Ole, Yes, I think this is the best way to do this. I would probably use Hashtable on this case. Regards, Adriano Crestani On 7/13/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hey Guys, I'm working on the approach for restoring the non-containment references. I'm thinking I should do it like this: First restore the entire graph with all containment references. For each object restored add it and it's xpath fragment to a map. Then during a second pass process each object's non-containment reference by looking up the object being referenced by fragment path using the map, and setting the reference that way. (So during the first pass, I just create annotations containing the xpath to the non-containment reference's object keyed by the name of the reference.) Does anyone know of a better way to handle this? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[LDAP DAS] Restoring non-containment references?
Hey Guys, I'm working on the approach for restoring the non-containment references. I'm thinking I should do it like this: First restore the entire graph with all containment references. For each object restored add it and it's xpath fragment to a map. Then during a second pass process each object's non-containment reference by looking up the object being referenced by fragment path using the map, and setting the reference that way. (So during the first pass, I just create annotations containing the xpath to the non-containment reference's object keyed by the name of the reference.) Does anyone know of a better way to handle this? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] Can Read and Write EDataGraph Instances
Thanks Luciano, Here's the Sandbox location: svn checkout https://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.ldap.parent Just check it out and run: mvn eclipse:clean eclipse:eclipse The tests run against ApacheDS embedded, so all that is needed is to checkout and build the latest ApacheDS build. svn checkout http://svn.apache.org/repos/asf/directory/apacheds/trunk-with-dependencies Cheers, - Ole P.S. It reads DataGraphs, but I still need to update the cross references, thus the only thing tested so far is restoring containment references. Luciano Resende wrote: Very great news, Is this available in your sandbox ? Could you share the link again, for the ones interested on taking a quick look at it ? For the LDAP Server dependencies/requirements, are there any instructions on running the DAS and connecting to the LDAP server ? On 6/25/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hey Guys, The LDAP DAS can now read and write EDataGraph instances to ApacheDS. Now I need to start working on handling updates and deletions. If anyone wants to see the code so far, please let me know and I'll check it in. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Release - Issue with SDO EMF Dependencies
Hey Luciano, I'm glad you asked :-) I'm going to check with the EMF team on the ideal solution mentioned below. I think that it's a much better request now that there's a lot of people interested in it. Also I believe there's already something in the EMF build for creating maven artifacts. Also, I think the ALTERNATIVE SOLUTION would be the quickest to implement for now to get the RC released. IDEAL SOLUTION I think the ideal solution would be to have the EMF team create emf artifacts with each build, and publish those as well. I'll see what I can do to help make this happen. I think the only thing left to do at that point is to create a JIRA for the maven project to upload the dependencies to Ibiblio. I think they get mirrored from there. ALTERNATIVE SOLUTION We just grab the standalone distribution, create maven repository artifacts out of each jar, and create a JIRA for maven to upload the artifacts to ibiblio. So I'll verify the process for the alternative solution first, and see whether we can get that going real quick. Then I'll check with the EMF team to see whether the ideal solution is a possibility. Cheers, - Ole Luciano Resende wrote: Hi Ole This EMF dependency is the unique remaining issue in order to go ahead with a DAS RC. Would you like to help us with this ? SDO Guys, any other ideas/options ? I think this would be the same issue for anyone trying to build SDO beta1 (or probably trunk as well) from scratch today. On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I would personally love to see the EMF dependencies committed to Ibiblio. I need to get more familiar with the process though. I know the ApacheDS artifacts get pushed to Ibiblio with each release. Another option is to just make a local Tuscany repo for the EMF dependencies. We could run a shell script (I think the EMF build has such a script) that downloads the EMF jars, creates Maven repository artifacts out of them, and then puts them in subversion or some other http accessible location Thoughts? Luciano Resende wrote: Thanks Ole, got me further, but still missing some dependencies... Is there any chance we can make these dependencies available in one of our Apache maven repos ? On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I think this will have them: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Cheers, - Ole Luciano Resende wrote: So, I saw Brian created a JIRA to increment EMF dependencies, but any ideas of what could be done for our current dependencies ? On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, I too can't find a 2.2 EMF artifacts maven repository at the moment. When Ole asked a similar question [1] on the EMF mailing list they said they just don't offer EMF archives from a maven repo. I will keep looking. Regards, Kelvin. On 22/06/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to build a DAS release candidate, but I can't find a maven repository that would have EMF 2.2.2 dependencies available. The one being used today by SDO, looks like they don't have these dependencies anymore. repository idindiana/id urlhttp://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//url snapshots enabledtrue/enabled /snapshots /repository Ideas ? Other repos to try ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Release - Issue with SDO EMF Dependencies
Here's an example of how to go about doing a JIRA request for artifact uploads. I'm going to look at the artifact requirements on the maven site next. There are metadata files that need to be updated as well: http://jira.codehaus.org/browse/MAVENUPLOAD-1431 Cheers, - Ole Luciano Resende wrote: Hi Ole This EMF dependency is the unique remaining issue in order to go ahead with a DAS RC. Would you like to help us with this ? SDO Guys, any other ideas/options ? I think this would be the same issue for anyone trying to build SDO beta1 (or probably trunk as well) from scratch today. On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I would personally love to see the EMF dependencies committed to Ibiblio. I need to get more familiar with the process though. I know the ApacheDS artifacts get pushed to Ibiblio with each release. Another option is to just make a local Tuscany repo for the EMF dependencies. We could run a shell script (I think the EMF build has such a script) that downloads the EMF jars, creates Maven repository artifacts out of them, and then puts them in subversion or some other http accessible location Thoughts? Luciano Resende wrote: Thanks Ole, got me further, but still missing some dependencies... Is there any chance we can make these dependencies available in one of our Apache maven repos ? On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I think this will have them: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Cheers, - Ole Luciano Resende wrote: So, I saw Brian created a JIRA to increment EMF dependencies, but any ideas of what could be done for our current dependencies ? On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, I too can't find a 2.2 EMF artifacts maven repository at the moment. When Ole asked a similar question [1] on the EMF mailing list they said they just don't offer EMF archives from a maven repo. I will keep looking. Regards, Kelvin. On 22/06/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to build a DAS release candidate, but I can't find a maven repository that would have EMF 2.2.2 dependencies available. The one being used today by SDO, looks like they don't have these dependencies anymore. repository idindiana/id urlhttp://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//url snapshots enabledtrue/enabled /snapshots /repository Ideas ? Other repos to try ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Release - Issue with SDO EMF Dependencies
Actually - I'm going to back track on the below idea. I've been reading this: http://maven.apache.org/guides/mini/guide-central-repository-upload.html And it says the preferred way it to provide a script that enables the maven repo to sync the artifacts from another public repo (I think, I'd need to do a test project so that I understand what is being said more precisely). So if the EMF project could establish such a repo, we just need to provide a script like this, and the artifacts would be automatically synced to the Ibiblio repository. EMF is built using shell scripts, so the next step is to figure out how to get such a repository going. Cheers, - Ole Ole Ersoy wrote: Here's an example of how to go about doing a JIRA request for artifact uploads. I'm going to look at the artifact requirements on the maven site next. There are metadata files that need to be updated as well: http://jira.codehaus.org/browse/MAVENUPLOAD-1431 Cheers, - Ole Luciano Resende wrote: Hi Ole This EMF dependency is the unique remaining issue in order to go ahead with a DAS RC. Would you like to help us with this ? SDO Guys, any other ideas/options ? I think this would be the same issue for anyone trying to build SDO beta1 (or probably trunk as well) from scratch today. On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I would personally love to see the EMF dependencies committed to Ibiblio. I need to get more familiar with the process though. I know the ApacheDS artifacts get pushed to Ibiblio with each release. Another option is to just make a local Tuscany repo for the EMF dependencies. We could run a shell script (I think the EMF build has such a script) that downloads the EMF jars, creates Maven repository artifacts out of them, and then puts them in subversion or some other http accessible location Thoughts? Luciano Resende wrote: Thanks Ole, got me further, but still missing some dependencies... Is there any chance we can make these dependencies available in one of our Apache maven repos ? On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I think this will have them: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Cheers, - Ole Luciano Resende wrote: So, I saw Brian created a JIRA to increment EMF dependencies, but any ideas of what could be done for our current dependencies ? On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, I too can't find a 2.2 EMF artifacts maven repository at the moment. When Ole asked a similar question [1] on the EMF mailing list they said they just don't offer EMF archives from a maven repo. I will keep looking. Regards, Kelvin. On 22/06/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to build a DAS release candidate, but I can't find a maven repository that would have EMF 2.2.2 dependencies available. The one being used today by SDO, looks like they don't have these dependencies anymore. repository idindiana/id urlhttp://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//url snapshots enabledtrue/enabled /snapshots /repository Ideas ? Other repos to try ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMF Artifacts] Working with cat.pdx.edu
Hi, I sent an email to [EMAIL PROTECTED] to see whether we can work with them to get the additional artifacts needed by Tuscany uploaded. After that I think we just need to get the Maven project a shell script to sync Ibiblio with this repository. I also asked if they could share the process they have for creating this repository with us. Luciano, do you know which additional artifacts are needed, apart from the ones already in: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ ? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMF Artifacts] Working with cat.pdx.edu
I have not heard back from them yet either. How about this: We rsync this repository to a tuscany server. Make the repository web accessible. Add the additional artifacts manually. We just need to add the pom.xml and the jar as shown here: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0-RC2a/ Which contains: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0-RC2a/codegen-2.2.0-RC2a.jar http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0-RC2a/codegen-2.2.0-RC2a.pom So to add the codegen dependency needed we would just have make following URLs work as well: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0/codegen-2.2.0.jar http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0/codegen-2.2.0.pom So we if had the artifacts on a Tuscany server then we just add the following files below the /emf directory: codegen/2.2.0/codegen-2.2.0.jar codegen/2.2.0/codegen-2.2.0.pom Then we could also request that this repository be synced with IBiblio. Thoughts? Cheers, - Ole Luciano Resende wrote: Just tried (already including cat.pdx.edu), and these are the missing dependencies : Missing: -- 1) org.eclipse.emf:codegen:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=codegen \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.eclipse.emf:codegen:jar:2.2.2 2) org.eclipse.emf:codegen-ecore:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=codegen-ecore \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.eclipse.emf:codegen-ecore:jar:2.2.2 3) org.eclipse.emf:ecore-xmi:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=ecore-xmi \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1 4) org.eclipse.emf:ecore-xmi:jar:2.2.2 4) org.eclipse.emf:ecore-change:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=ecore-change \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1 4) org.eclipse.emf:ecore-change:jar:2.2.2 5) org.eclipse.emf:common:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=common \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1 4) org.eclipse.emf:common:jar:2.2.2 -- 5 required artifacts are missing. for artifact: org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 from the specified remote repositories: Geotools project (http://maven.geotools.fr/repository/), central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshot (http://snapshots.repository.codehaus.org), eclipse.emf (http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/), indiana (http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/) On 6/25/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I sent an email to [EMAIL PROTECTED] to see whether we can work with them to get the additional artifacts needed by Tuscany uploaded. After that I think we just need to get the Maven project a shell script to sync
[LDAP DAS] Can Read and Write EDataGraph Instances
Hey Guys, The LDAP DAS can now read and write EDataGraph instances to ApacheDS. Now I need to start working on handling updates and deletions. If anyone wants to see the code so far, please let me know and I'll check it in. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[LDAP DAS] Efficient Determination of the Type's member that represents its ID
Hey Guys, I'm in the process of coding the EDataObjectReader. It first looks up a LDAP context containing a DataObject instances property values. In order to do this, it needs to know which Type member represents the Type's ID. Does Tuscany have an efficient way of determining this ID? With the EMF API it looks like I have to preprocess all the EClass instances, and store each EClass's ID (isID() returns true) EAttribute on a Map for more efficient retrieval. Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Release - Issue with SDO EMF Dependencies
I think this will have them: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Cheers, - Ole Luciano Resende wrote: So, I saw Brian created a JIRA to increment EMF dependencies, but any ideas of what could be done for our current dependencies ? On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, I too can't find a 2.2 EMF artifacts maven repository at the moment. When Ole asked a similar question [1] on the EMF mailing list they said they just don't offer EMF archives from a maven repo. I will keep looking. Regards, Kelvin. On 22/06/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to build a DAS release candidate, but I can't find a maven repository that would have EMF 2.2.2 dependencies available. The one being used today by SDO, looks like they don't have these dependencies anymore. repository idindiana/id urlhttp://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//url snapshots enabledtrue/enabled /snapshots /repository Ideas ? Other repos to try ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Release - Issue with SDO EMF Dependencies
I would personally love to see the EMF dependencies committed to Ibiblio. I need to get more familiar with the process though. I know the ApacheDS artifacts get pushed to Ibiblio with each release. Another option is to just make a local Tuscany repo for the EMF dependencies. We could run a shell script (I think the EMF build has such a script) that downloads the EMF jars, creates Maven repository artifacts out of them, and then puts them in subversion or some other http accessible location Thoughts? Luciano Resende wrote: Thanks Ole, got me further, but still missing some dependencies... Is there any chance we can make these dependencies available in one of our Apache maven repos ? On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I think this will have them: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Cheers, - Ole Luciano Resende wrote: So, I saw Brian created a JIRA to increment EMF dependencies, but any ideas of what could be done for our current dependencies ? On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, I too can't find a 2.2 EMF artifacts maven repository at the moment. When Ole asked a similar question [1] on the EMF mailing list they said they just don't offer EMF archives from a maven repo. I will keep looking. Regards, Kelvin. On 22/06/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to build a DAS release candidate, but I can't find a maven repository that would have EMF 2.2.2 dependencies available. The one being used today by SDO, looks like they don't have these dependencies anymore. repository idindiana/id urlhttp://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//url snapshots enabledtrue/enabled /snapshots /repository Ideas ? Other repos to try ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMF Maven Repository] EMF 2.3 Repository?
Hi, Does anyone know if there is a maven repository for the EMF 2.3 artifacts? I used to use the one below for the M4 release, but it looks like it has been Deprecated. http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Thanks - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMF 2.3 Maven Repository] Never Mind
Hi, Sorry about starting a new thread. GMail hides the copy of the original thread from me... Looks like the emf artifact are pushed to ibiblio. Sorry for the noise. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMF Maven Repository] EMF 2.3 Repository?
Hi Frank, Thanks - I'll check it out. Incidentally - The artifacts are missing from Ibiblio after all. I saw Maven print Downloading and jump to conclusions. Later in the log, it says Unable Hopefully they will be in the pdx mirror, once it comes back up. Thanks again, - Ole Frank Budinsky wrote: Hi Ole, I'm not sure exactly where it is, but I know that the EMF project has been moved from the tools project to a new top level modeling project at Eclipse. So maybe the location is something like this now: http://mirrors.cat.pdx.edu/eclipse/modeling/emf/maven2/ If that doesn't work, I'd ask on the EMF newsgroup. Frank. Ole Ersoy [EMAIL PROTECTED] wrote on 06/14/2007 04:19:47 PM: Hi, Does anyone know if there is a maven repository for the EMF 2.3 artifacts? I used to use the one below for the M4 release, but it looks like it has been Deprecated. http://mirrors.cat.pdx. edu/eclipse/tools/emf/maven2/ Thanks - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMF Maven Repository] EMF 2.3 Repository?
Hi Frank, Good guess :-). All the dependencies download fine. Thanks again, - Ole Frank Budinsky wrote: Hi Ole, I'm not sure exactly where it is, but I know that the EMF project has been moved from the tools project to a new top level modeling project at Eclipse. So maybe the location is something like this now: http://mirrors.cat.pdx.edu/eclipse/modeling/emf/maven2/ If that doesn't work, I'd ask on the EMF newsgroup. Frank. Ole Ersoy [EMAIL PROTECTED] wrote on 06/14/2007 04:19:47 PM: Hi, Does anyone know if there is a maven repository for the EMF 2.3 artifacts? I used to use the one below for the M4 release, but it looks like it has been Deprecated. http://mirrors.cat.pdx. edu/eclipse/tools/emf/maven2/ Thanks - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[LDAP DAS] Quick Update
Hey Guys, I thought and really wanted to have the reading of writing of DataGraph instances wrapped up today, but I hit a bug in ApacheDS that's a blocker, so it will be a little while longer. Hope to have it done very soon though. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[LDAP DAS] Quick Update
Hey Guys, I'm a few days away from showing a demo that reads and writes DataGraph instances. I started getting my Groove On so I've just been doing Go coding, and will finish the design guide after, although I did add a lot more content to in order to to provide visibility wrt end game. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[LDAP DAS] New Tuscany PEN Branch
Hey Guys, We have a new PEN Branch for the Tuscany project (Courtesy of Emmanuel Lecharny - Directory PMC). Thank Alex Karasulu (Directory Project Lead) for getting the PEN for the Apache Software Foundation. All OIDs for LDAP DAS Schema Entries (The Equivalent of the SDO Types defined in LDAP Schema terms) will now use this number as a prefix for the unique ID. Here's is the page: http://cwiki.apache.org/confluence/display/DIRxPMGT/OID+Assignment+Scheme Here is the number: 1.3.6.1.4.1.18060.4 Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Type System Comment
Hi Frank, Frank Budinsky wrote: Hi Ole, Your point about the benefits of separating properties into two lists, references and attributes, is well taken. Super :-) The SDO spec does say this in section 3.6: A Property whose Type is for DataObjects is sometimes called a reference; otherwise it is called an attribute. So, in documentation anyway, you can call DataObject typed properties references, if you like. Calling DataType properties attributes is a little ambiguous, however, because it's overloaded with the concept of an XML attribute. Sure - Absolutely. I was hoping for something like EAttribute or EReference, that we can draw on a Class Diagram. I like these because they have clear mappings to XSD already, so there's there's minimal chance of confusion when talking about the mapping. Right now I have two choices for the equivalent of an EReference in SDO. I can call it a reference or I can call it a member/property that is a SDO DataObject type. So if SDO had an EReference (SReference) equivalent class, we could just say SReference. I love EMF because it's so elegant in this sense. It's really easy to know precisely what something is. Notice that XML/XSD split between element and attribute properties is different from the split between reference and attribute properties (as in EMF). An EAttribute can map to an attribute or element in XML. Same for EReference. Indeed. So I think this is saying that SDO further restricts the typing that EMF allows, or at least the mapping to XML Schema instances (I need to read some more SDO 2 stuff). The part I'm hanging on is whether when loading the SDO type system we loose some information so we have to recalculate it at runtime. And if we have to recalculate it, do we loose efficiency? When we load an ecore instance we can examine the EClass and know what members are EAttributes and what members are EReferences, the proceeds to process these lists separately. If I examine and SDO Type reflectively I think I'd have to first iterate through all the member types and separate the two into the equivalent of EReferences and EAttributes. (SOAP BOX: Personally I feel like this is a little bit of a typing black hole, but that could be it's just because I'm EMF biased. I think I just like knowing that an EAttribute is an EAttribute and an EReference is an EReference). Then I can go ahead an process the DataGraph efficiently. So I'm really wondering whether the processing that separates the simple from the complex types is best handled during type system loading. Maybe the end result is the same. It sounds like there are two possible end games. One is that SDO types stay the way they are and are augmented by utilities that separate simple from complex types in the type system, so that DataGraphs can be efficiently processed. The other is to build in the equivalent of XSD Simple and Complex Types into the SDO Typing system. I think the criteria for which one is best are Type system efficiency and developer preference. It could be neat to have some sort of scoring system for it on OSOA. Although this of coarse depends on whether I'm making any sense. :-) Cheers, - Ole SNIP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[LDAP DAS] Update was [LDAP DAS] New Tuscany PEN Branch
Sure. OK - Here's the Scoop. LDAP DAS HOME: We are hoping the LDAP DAS will have a home somewhere in the Tuscany Subversion repository soon. I we want to make one I'll be glad to check everything in. TIMELINE I'm hoping to have an implementation that can read and write DataGraphs in about 10 days. PROCESS The way I'm going about this is writing a design guide consisting of lots of little recipes that are sequenced in roughly the order of the challenges that need solutions, such that the DAS can do it's thing. In other words it breaks the design down into little challenges that are easy to understand and code. So thats what the LDAP DAS Design Guide is. The recipes are written in an XML document and this is used to generate an Eclipse Documentation plugin via a maven mojo if anyone is interested in trying to process out. All apache licensed of coarse. I'm thinking I'll republish the guide s in about two-three days, which should give me plenty of time to solidify my thoughts on the DAS's process. Then I just need to finish up the implementation, so I'm giving myself a week for that. Cheers, - Ole SNIP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Type System Comment
Hi Frank, I think I may have figured out what I'm talking about :-) Suppose I'm loading Ecore from its XMI Document. So I'm loading several XMI elements that are either of the type EDataType or EClassifier. So this could be viewed as iterating through the document's elements. I have to do this iteration in order to load the Ecore Type System. So I have an opportunity here to check each element I'm loading and add it to either an EDataType list or an EClassifier list. If I choose skip creating the lists, and later I need a list of all the EDataTypes, then I have to iterate through something like EcorePackage.eContents() and sift out the EDataType instances. So now I'm doing additional work that could have been avoided had I just created the lists when the model was loaded. The reason this crossed my mind, is because I need a list of all the EDataType instances in Ecore. It looks as if I have to filter them out from eContents(). Do you know by chance whether SDO 2 has such a list. The reason I need it is because I need to write the equivalent of the SDO base type system to ApacheDS. So if such a list were just available through the API it would make life a little simpler :-) So to summarize for me it seems like opportunities to create generic lists like eDataTypes(): EListEDataType or eClassifiers() : EListEClass makes the API more friendly and efficient to work with. If SDO had something like ClassType, SimpleType, and ComplexType the generic lists like: EListSDOSimpleType EListSDOComplexType could be created during Type system loading. because SDO would now have the semantics for generically specifying a list of simple types and complex types. Cheers, - Ole Frank Budinsky wrote: Hi Ole, Your point about the benefits of separating properties into two lists, references and attributes, is well taken. The SDO spec does say this in section 3.6: A Property whose Type is for DataObjects is sometimes called a reference; otherwise it is called an attribute. So, in documentation anyway, you can call DataObject typed properties references, if you like. Calling DataType properties attributes is a little ambiguous, however, because it's overloaded with the concept of an XML attribute. Notice that XML/XSD split between element and attribute properties is different from the split between reference and attribute properties (as in EMF). An EAttribute can map to an attribute or element in XML. Same for EReference. Frank Ole Ersoy [EMAIL PROTECTED] wrote on 05/17/2007 10:17:42 AM: Hi Frank, Frank Budinsky wrote: Ole, Type.isDataType() is the way to distinguish between complex and simple types. Thanks for the tip. I have several other comments below. I'll just preface these by saying that this is just my initial impression / hunch. I figured I'd point these out while they are fresh in case they end up being useful, and might make it onto an SDO FAQ or something. Since EMF has been around for some time, I imagine their could be other EMFers with a similar questions/concerns. OK - Here goes: Ideally for me at least I would love it if SDO had EReferences, EDataTypes, and EAttributes. One benefit is that when documenting I can just say EReference. Currently I have to say something like When Type.isDataType() returns true. Minor point, but when writing a lot of documentation and comparing type systems, it adds up. (SIDE NOTE: I got to the bottom and noticed you pointed out the DataObject Types and DataTypes labeling - Thanks). Also, (As I'm sure you know given that you co-authored the very excellent Eclipse Modeling Framework Book :-) ) with EMF EReferences are ready to go on their own list, and the same goes for EAttributes. Now it seems like the first natural step when processing a DataGraph is to always check the Type of a Type... This is just my initial impression though, but it does seem like this whole step could be skipped if something similar to EReferences and EAttributes were used. I think Tuscany may already have a utility for this, but the EMF way still seems cleaner, faster, and better organized to me. I a utility handled the separation in Tuscany in order to avoid the isDataType check when processing the DataGraph separating the DataTypes from the DataObjectTypes does that lead to additional overhead? Seems like EMFs approach is more efficient. Looking at the scenario backwards with the Fastest and simplest API in mind it seems like XSD and EMF have it nailed. I guess the only way I can prove it is by showing a use case where the additional semantics of XSD and EMF lead to less calls. If I end up Unproving it I think I'll be more at ease with the isDataType() call :-) Simple types map to a type with isDataType=true, complex types map to types with isDataType=false. They are often referred to as Data types and DataObject types, respectively. Ah - Thanks - That should definitely help with the documentation part. I'll make sure I put
SDO Type System Comment
Hi, This really belongs in something like a osoa.org sdo design spec discussion, but it's not up yet, so I hope it's ok to post here. As I'm fine tuning the LDAP DAS Design Guide I find myself saying this alot: an SDO Type that is the semantic equivalent of an XSD Complex Type If I were discussing EMF and XSD I would just say EClass. Just seems like SDO would map a lot cleaner to other typing systems if it included the semantics of Complex and Simple types. Seems like it makes the API more efficient too, since it becomes natural to keep simple and complex types in separate lists. I'm guessing that doing this upfront within the core SDO API would make most products derived from the SDO API more efficient since developers would become accustomed to dealing with the distinction. Anyways - just my two cents. I figured I'd throw it out there for general awareness in case others were interested. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[LDAP DAS] Obtaining a PEN for Tuscany
Hi, The LDAP DAS uses the Apache Directory PEN (Private Enterprise Number) to prefix OID (Object Identifier) numbers that are unique ids for types defined in the LDAP server. It might make sense for Tuscany to get an ID from the Apache Software Foundation. The Foundation owns ID 1.3.6.1.4.1.18060 It has given the directory project the branch: 1.3.6.1.4.1.18060.0 Maybe Tuscany could get the branch 1.3.6.1.4.1.18060.1 This way this branch could be used as the OID prefix for all LDAP types created by the LDAP DAS. I'll check with the directory project on the process for getting a Tuscany PEN Branch. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Testing] Open Source Automated Testing for SOA
Hey Guys, This just came across the wire on the JUnit mailing list. http://gtcgroup.com/soaj/Road.to.SOAj.html#AMT Here's a little excerpt: == Hey, did you read that last bullet? It is a significant differentiator between a “framework” and a “platform abstraction”. Many frameworks attempt to provide 100% functionality in a problem space. SOAj seeks to support typical SOA capabilities. == The documentation has impressive depth. Might be worth it for us to keep a close eye on this. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Testing] Open Source Automated Testing for SOA
Indeed :-) I need to read over it a few more times, but it seems like the prototype might be a good testing fit for the RDB DAS as a real validation / trial of the concept. Cheers, - Ole Kevin Williams wrote: This looks interesting and I notice that they are addressing persistence from the start. On 4/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hey Guys, This just came across the wire on the JUnit mailing list. http://gtcgroup.com/soaj/Road.to.SOAj.html#AMT Here's a little excerpt: == Hey, did you read that last bullet? It is a significant differentiator between a framework and a platform abstraction. Many frameworks attempt to provide 100% functionality in a problem space. SOAj seeks to support typical SOA capabilities. == The documentation has impressive depth. Might be worth it for us to keep a close eye on this. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Performance / API / Spec
Hi Frank,
I looked around osoa.org to sign up for a account,
but could not find a signup
page. Do you know if it's up yet?
Also, I noticed that there is no
setRootDataObject() method on the
DataGraph interface, but there is one on the
implementation.
It seems like it should be in the interface as well.
Do you know whether there is a Whiteboard somewhere,
where we can post SDO API suggestions? Should I perhaps
JIRA these in the Java Spec API section?
Thanks,
- Ole
Frank Budinsky wrote:
Hi Ole,
I'm not sure what reasoning was to justify the ChangeSummary API which
requires you to iterate over the one list returned by
getChangedDataObjects() and then call isCreated(), isModified(), or
isDeleted() to see if it was a C, U, or D.
If you look at class ChangeSummaryImpl, you'll notice that in Tuscany we
actually implement this with three separate lists under the covers. The
isDeleted() method, for example, looks like this:
public boolean isDeleted(DataObject dataObject)
{
return getCachedDeletedObjects().contains(dataObject);
}
I know that there is a proposed SDO 3 work item to revisit ChangeSummary
to see if the API could be improved. Perhaps you'd like to get involved in
the spec discussion on this issue, when it begins? Now that it's moving to
OASIS (http://osoa.org/display/Main/News+about+SCA+and+SDO), SDO design
discussions will be open to everyone.
Frank.
Ole Ersoy [EMAIL PROTECTED] wrote on 04/17/2007 12:27:58 PM:
Hi Guys,
I have a few performance related
questions with respect to change
summary processing (Really spec related - hope it's ok that I float it
here).
I just looked at the Change
summary API and it looks like
the DataGraph sets the
isDeleted and isCreated
flags on each DataObject instance
that it creates or deletes, and
then it adds them to the change summary.
It seems like change summary
processing would perform better
if the Change summary had CUD lists.
So one list for:
- Created DataObjects
- Deleted DataObjects
- Update DataObjects
Then these lists could be processed directly by the
DAS and it would not have to check what type CUD
was done for each object.
Then the DataGraph only adds objects to these lists
and does not need to set any flags, which means that
during processing the flags don't need to be checked
in order to perform the right type of processing.
I'm still getting my feet wet here, but I thought I'd throw this out
there, since to me it seems like it's simpler and more light weight.
Thoughts?
Thanks,
- Ole
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Performance / API / Spec
Hey Frank,
Frank Budinsky wrote:
Hi Ole,
I found out today that it will take 2-3 months before the OASIS SDO
charter will be finalized and the discussions can begin. I'm involved with
the charter, so I can tell you that both of the issues you mentioned are
in scope for SDO 3, so they will be discussed once things get started.
Great.
For DataGraph.setRootObject(), the proposal is to either deprecate the
DataGraph interface entirely or to make DataGraph also be a DataObject.
Either way, you would set the root object using DataObject.set(). The root
object would be an open content property so you could set it by simply
calling something like this: dataGraph.set(company, myCompany).
Ah - I see.
DataGraph and DataObject do seem very closely related, like one is not
really needed.
I really like the EMF API here and wish the SDO API would do the same,
with a Resource (Which seems like a really good metaphor) containing a
graph of objects, and a ResourceSet containing many Resources. Then
start and stop logging could be called at the ResourceSet, Resource, and
DataObject levels, which seems like a clean way to cut it.
Anyways I'm jumping ahead :-)
I'll just collect ideas, and wait until the Charter gets finalized.
Thanks,
- Ole
Frank.
Ole Ersoy [EMAIL PROTECTED] wrote on 04/18/2007 01:41:53 PM:
Hi Frank,
I looked around osoa.org to sign up for a account,
but could not find a signup
page. Do you know if it's up yet?
Also, I noticed that there is no
setRootDataObject() method on the
DataGraph interface, but there is one on the
implementation.
It seems like it should be in the interface as well.
Do you know whether there is a Whiteboard somewhere,
where we can post SDO API suggestions? Should I perhaps
JIRA these in the Java Spec API section?
Thanks,
- Ole
Frank Budinsky wrote:
Hi Ole,
I'm not sure what reasoning was to justify the ChangeSummary API which
requires you to iterate over the one list returned by
getChangedDataObjects() and then call isCreated(), isModified(), or
isDeleted() to see if it was a C, U, or D.
If you look at class ChangeSummaryImpl, you'll notice that in Tuscany
we
actually implement this with three separate lists under the covers.
The
isDeleted() method, for example, looks like this:
public boolean isDeleted(DataObject dataObject)
{
return getCachedDeletedObjects().contains(dataObject);
}
I know that there is a proposed SDO 3 work item to revisit
ChangeSummary
to see if the API could be improved. Perhaps you'd like to get
involved in
the spec discussion on this issue, when it begins? Now that it's
moving to
OASIS (http://osoa.org/display/Main/News+about+SCA+and+SDO), SDO
design
discussions will be open to everyone.
Frank.
Ole Ersoy [EMAIL PROTECTED] wrote on 04/17/2007 12:27:58 PM:
Hi Guys,
I have a few performance related
questions with respect to change
summary processing (Really spec related - hope it's ok that I float
it
here).
I just looked at the Change
summary API and it looks like
the DataGraph sets the
isDeleted and isCreated
flags on each DataObject instance
that it creates or deletes, and
then it adds them to the change summary.
It seems like change summary
processing would perform better
if the Change summary had CUD lists.
So one list for:
- Created DataObjects
- Deleted DataObjects
- Update DataObjects
Then these lists could be processed directly by the
DAS and it would not have to check what type CUD
was done for each object.
Then the DataGraph only adds objects to these lists
and does not need to set any flags, which means that
during processing the flags don't need to be checked
in order to perform the right type of processing.
I'm still getting my feet wet here, but I thought I'd throw this out
there, since to me it seems like it's simpler and more light weight.
Thoughts?
Thanks,
- Ole
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] Performance / API / Spec
Hi Guys, I have a few performance related questions with respect to change summary processing (Really spec related - hope it's ok that I float it here). I just looked at the Change summary API and it looks like the DataGraph sets the isDeleted and isCreated flags on each DataObject instance that it creates or deletes, and then it adds them to the change summary. It seems like change summary processing would perform better if the Change summary had CUD lists. So one list for: - Created DataObjects - Deleted DataObjects - Update DataObjects Then these lists could be processed directly by the DAS and it would not have to check what type CUD was done for each object. Then the DataGraph only adds objects to these lists and does not need to set any flags, which means that during processing the flags don't need to be checked in order to perform the right type of processing. I'm still getting my feet wet here, but I thought I'd throw this out there, since to me it seems like it's simpler and more light weight. Thoughts? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[XPATH] Getting a DataObject's Path?
Hi, I've been looking at the SDO Specification and Javadocs trying to figure out how to get a dataobject's path (Relative to it's root). Something like: String path = DataGraph.getPath(dataObject); Which would return something like: //company/employees[2]/ Thoughts? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [XPATH] Getting a DataObject's Path?
Frank, Kelvin, Thanks - That's exactly what I'm looking for. Cheers, - Ole Frank Budinsky wrote: There's no standard SDO API, but we have a Tuscany utility method which is used in the implementation of Java serialization: DataObjectUtil.getXPath(DataObject dataObject) Frank. Ole Ersoy [EMAIL PROTECTED] 04/17/2007 02:50 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject [XPATH] Getting a DataObject's Path? Hi, I've been looking at the SDO Specification and Javadocs trying to figure out how to get a dataobject's path (Relative to it's root). Something like: String path = DataGraph.getPath(dataObject); Which would return something like: //company/employees[2]/ Thoughts? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Performance / API / Spec
Hi Frank,
SNIP
If you look at class ChangeSummaryImpl, you'll notice that in Tuscany we
actually implement this with three separate lists under the covers. The
isDeleted() method, for example, looks like this:
public boolean isDeleted(DataObject dataObject)
{
return getCachedDeletedObjects().contains(dataObject);
}
Oh - Great - I like that :-).
I know that there is a proposed SDO 3 work item to revisit ChangeSummary
to see if the API could be improved. Perhaps you'd like to get involved in
the spec discussion on this issue, when it begins?
Absolutely and thank you for the detailed explanation and OSOA link.
Cheers,
- Ole
SNIP
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic SDO question: no built-in types?
Kelvin, Frank, Great - Thanks for all the insight. I wrote most of the DAS LDAP Design Guide using references to EMF concepts, so I'll start using this to convert over. Thanks again, - Ole kelvin goodson wrote: Ole, the HelperContext acts as a high level scope for types. To create types dynamically using the SDO 2.1 API you would get the TypeHelper instance from a HelperContext instance and use one of the TypeHelper.define methods to create types within the scope of the HelperContext. There is also Tuscany specific interface on the SDOUtil class that allows creation of types more in the style you show above, using a TypeHelper instance to control the scope of the new types. In this case the new types are available to the HelperContext to which the TypeHelper instance belongs, and all its associated helpers. The SDO API variant method offers solutions to the issues encountered when creating type systems which have cross references, which can't be achieved with the Tuscany interface. It also deals with achieving a state whereby a newly created type is known to be finalized. The Tuscany API is a quick method for defining types when these considerations are not important. Regards, Kelvin. On 09/04/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hope it's ok that I piggy back with a somewhat related question. Does SDO a container for Type instances (the equivalent to an EMF EPackage)? In the EMF API I would do something like DataType dataType = EcoreFactory.eINSTANCE.createDataType(); //Initialize the dataType //Add it to an ePackage containing all the model's Types ePackage.eClassifiers.add(dataType); Thanks, - Ole Scott Kurz wrote: Thanks Fuhwei, Frank that helps me under the SDO view of the built-in types. I wonder how useful it would be to allow WSDL2Java to generate a Type, then, instead of an int or String, when the -dynamicSDO option is chosen. There would need to be some runtime databinding-sdo support for this option too, I'd think. Interesting but I'm probably going to drop this train of thought for now... Scott On 4/9/07, Fuhwei Lwo [EMAIL PROTECTED] wrote: Scott, SDO built-in types were defined in the sdoModel.xsd under tuscany/java/spec/sdo-api/src/main/resources/xml directory. The mapping from XSD to Java is described in the spec section 9.4. The instances of SDO built-in types will be instances of commonj.sdo.Type. So if you have a SDO type for xsd:int, the name of the commonj.sdo.Typeinstance will be Int. Hope this helps. Scott Kurz [EMAIL PROTECTED] wrote: This is maybe an SDO for dummies question. Are there any built-in SDO types, say, corresponding to int which I can work with as a generic DataObject in the manner that java.lang.Integeris a java.lang.Object corresponding to int? (I'm not seeing anything from a quick scan of the source or spec to suggest that there is.) Or is the simplest DataObject one can create a user-defined, complexType wrappering a single int? Thanks, Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic SDO question: no built-in types?
Kelvin, Brilliant article. Just in time too :-). It will really come in handy when I start coding the Restore DataObject MetaData part of the LDAP DAS. Thanks again, - Ole kelvin goodson wrote: Ole, glad to be of help. I was a bit worried that the different perspectives from which Frank and I responded might cause confusion, but you seem to be happy marrying the two responses together. Just to be clear, from the SDO perspective, in the context we are discussing the EPackage does 2 orthogonal things that are handled separately in SDO. One is to aggregate and provide access to the type system, and the other to bestow the namespace uri upon the types it contains. I answered from the perspective of the first and Frank from the second. BTW, page 2 of the recently published What is SDO? Part 2 paper has a description of how to create types dynamically using the SDO API. http://java.sys-con.com/read/358059_2.htm Regards, Kelvin. On 10/04/07, Ole Ersoy [EMAIL PROTECTED] wrote: Kelvin, Frank, Great - Thanks for all the insight. I wrote most of the DAS LDAP Design Guide using references to EMF concepts, so I'll start using this to convert over. Thanks again, - Ole kelvin goodson wrote: Ole, the HelperContext acts as a high level scope for types. To create types dynamically using the SDO 2.1 API you would get the TypeHelper instance from a HelperContext instance and use one of the TypeHelper.define methods to create types within the scope of the HelperContext. There is also Tuscany specific interface on the SDOUtil class that allows creation of types more in the style you show above, using a TypeHelper instance to control the scope of the new types. In this case the new types are available to the HelperContext to which the TypeHelper instance belongs, and all its associated helpers. The SDO API variant method offers solutions to the issues encountered when creating type systems which have cross references, which can't be achieved with the Tuscany interface. It also deals with achieving a state whereby a newly created type is known to be finalized. The Tuscany API is a quick method for defining types when these considerations are not important. Regards, Kelvin. On 09/04/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hope it's ok that I piggy back with a somewhat related question. Does SDO a container for Type instances (the equivalent to an EMF EPackage)? In the EMF API I would do something like DataType dataType = EcoreFactory.eINSTANCE.createDataType(); //Initialize the dataType //Add it to an ePackage containing all the model's Types ePackage.eClassifiers.add(dataType); Thanks, - Ole Scott Kurz wrote: Thanks Fuhwei, Frank that helps me under the SDO view of the built-in types. I wonder how useful it would be to allow WSDL2Java to generate a Type, then, instead of an int or String, when the -dynamicSDO option is chosen. There would need to be some runtime databinding-sdo support for this option too, I'd think. Interesting but I'm probably going to drop this train of thought for now... Scott On 4/9/07, Fuhwei Lwo [EMAIL PROTECTED] wrote: Scott, SDO built-in types were defined in the sdoModel.xsd under tuscany/java/spec/sdo-api/src/main/resources/xml directory. The mapping from XSD to Java is described in the spec section 9.4. The instances of SDO built-in types will be instances of commonj.sdo.Type. So if you have a SDO type for xsd:int, the name of the commonj.sdo.Typeinstance will be Int. Hope this helps. Scott Kurz [EMAIL PROTECTED] wrote: This is maybe an SDO for dummies question. Are there any built-in SDO types, say, corresponding to int which I can work with as a generic DataObject in the manner that java.lang.Integeris a java.lang.Object corresponding to int? (I'm not seeing anything from a quick scan of the source or spec to suggest that there is.) Or is the simplest DataObject one can create a user-defined, complexType wrappering a single int? Thanks, Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working with Tuscany SDOs reflectively
Super. We'll stick with that convention, since LDAP ObjectClasses also have attributes. Thanks, - Ole Frank Budinsky wrote: Well in the XML to SDO mapping, isDataType=true for properties where the type is an xsd:simpleType, while isDataType=false if the type is an xsd:complexType. So calling them simple or complex properties (or more specifically properties of simple type and properties of complex type) seems reasonable. The SDO spec does also mention that dataType properties are sometimes referred to as attributes, and dataObject properties as references, so using that terminology would also be OK. I guess my personal preference would be simple/complex, since the term attribute is overloaded in SDO (attribute vs reference, and also attribute vs element in the XML). Frank. Ole Ersoy [EMAIL PROTECTED] wrote on 03/29/2007 06:44:05 PM: Hey Frank, Yes - I can see how trying to change the specification, at least in the next couple of days, might be a long shot :-) I guess I'll just put a SDOUtil method in to separate the EAttributes from the EReferences. That way when the SDOs are stored in ApacheDS, the DAS is not calling isDataType every time it processes a SDO property. Incidentally, terminology wise, would it be correct for me to call EAttributes simple properties and EReferences complex properties? Thanks, - Ole Frank Budinsky wrote: Hi Ole, It will probably be hard to convince people to add the extra lists to the SDO specification. It was intentionally designed to have one simple list. Adding some methods in Tuscany (in class SDOUtil) to return just the dataType or non-dataType properties is possible, but as SDO is now being standardized and there are multiple implementations of it, it's really best to avoid using implementation-specific APIs, if possible. getType().getProperties() returns all the properties (including from the base types) - it's like EMF's getEAllStructuralFeatures(). getType().getDeclaredProperties() returns just the locally defined properties - like EMF's getEStructuralFeatures(). Frank. Ole Ersoy [EMAIL PROTECTED] wrote on 03/29/2007 03:04:52 PM: Super - Thanks Frank. This may be something I should be brining up to the SDO Specification guys, but it seems like Ecore's way of separating the EAttributes and the EReferences into separate lists will be more efficient from the perspective of of looking for various class members. For instance sometimes I'm only interested in the EAttributes, and with the EMF API I have access to only the List containing the EAttributes, so the time it takes to iterate through this list is shorter than the time it takes to iterate through all the EStructuralFeatures, which it seems like what I would be doing with the SDO API... Any thoughts? Could we perhaps add something to the Tuscany SDO implementation that gives us the ability to iterate through the isDataType() members of the SDO object and also the non isDataType() members. In addition, Ecore has the eObject.eClass().getEAllEReferences or EAttributes... giving us the inherited members as well. Is this what the SDO object returns when calling getType().getProperties() except in return in effect all the EStructuralFeatures? Thanks, - Ole Frank Budinsky wrote: In SDO there's a list of properties (simple and complex combined) that you can get like this: ListProperty properties = userSDO.getType().getProperties(); If you are interested in the simple ones, you need to do something like this when iterating through the list: if (property.getType().isDataType()) ... Frank. Ole Ersoy [EMAIL PROTECTED] wrote on 03/29/2007 01:59:05 PM: Hi, I asked this question a little differently before referring to EMF's ecore, and I'll try again by restating what I wish to do. Suppose I have an SDO instance Class name UserSDO, instance userSDO I would like to get a list of all the non-complex object members of userSDO So for instance if userSDO has some String members like userName and userPassword I would like a list of these. Do I just use regular java reflection or does the Tuscany SDO API have something similar to EMF's EClass. If I were using EMF I could do EClass eClass = userSDO.eClass(); Then to get the members I would do EListEAttribute attributes = eClass.getEAttributes(); If I wanted the complext object references I would do EListEReference references eClass.getEReferences(); Does the Tuscany SDO API have something similar? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED
[Fwd: [DAS] Initial Design Guide Draft]
Hi, I just sent this out on the directory developers list, but thought the Tuscany might be interested as well. Some like to see the material as it evolves and some like to see the clean version. For those of you in the first group, this is a very early stage draft. I'm starting to do test experiments now, and will update it with real code :-) and more design recipes shortly. Comments are always welcome. Cheers, - Ole ---BeginMessage--- Hey Guys, I just versioned the first draft of the DAS Design Guide. https://svn.apache.org/repos/asf/directory/sandbox/oersoy/guides/das.ldap.design.documentation It's an eclipse documentation plugin (Suprise), so just drop it into the plugins folder and look for LDAP DAS Design Guide in the books. It's a little rough, and some of the code I just made up as placeholders. I'm going to start experimenting with real code now. Luciano, I used the EMF API to illustrate some of the concepts and would appreciate any assistance you can give with converting over to the SDO API. In general an EMF EObject corresponds to a SDO DataObject. EAttribute is a simple SDO type (isDataType returns true); EReference is a complex SDO type (isDataType returns false) getEAllAttributes() returns an EObject's simple types including those inherited. getEAllReferences return an EObjects's complex types, including those inherited. Cheers, - Ole ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [DAS] Initial Design Guide Draft]
Cool - Thanks Luciano - Ole Luciano Resende wrote: Sure, I saw your post on the directory list, but didn't have a chance to go over that yet... I'll try to send some feedback over the weekend. On 3/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I just sent this out on the directory developers list, but thought the Tuscany might be interested as well. Some like to see the material as it evolves and some like to see the clean version. For those of you in the first group, this is a very early stage draft. I'm starting to do test experiments now, and will update it with real code :-) and more design recipes shortly. Comments are always welcome. Cheers, - Ole -- Forwarded message -- From: Ole Ersoy [EMAIL PROTECTED] To: Apache Directory Developers List dev@directory.apache.org, Luciano Resende [EMAIL PROTECTED] Date: Fri, 30 Mar 2007 10:48:05 -0500 Subject: [DAS] Initial Design Guide Draft Hey Guys, I just versioned the first draft of the DAS Design Guide. https://svn.apache.org/repos/asf/directory/sandbox/oersoy/guides/das.ldap.design.documentation It's an eclipse documentation plugin (Suprise), so just drop it into the plugins folder and look for LDAP DAS Design Guide in the books. It's a little rough, and some of the code I just made up as placeholders. I'm going to start experimenting with real code now. Luciano, I used the EMF API to illustrate some of the concepts and would appreciate any assistance you can give with converting over to the SDO API. In general an EMF EObject corresponds to a SDO DataObject. EAttribute is a simple SDO type (isDataType returns true); EReference is a complex SDO type (isDataType returns false) getEAllAttributes() returns an EObject's simple types including those inherited. getEAllReferences return an EObjects's complex types, including those inherited. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Working with Tuscany SDOs reflectively
Hi, I asked this question a little differently before referring to EMF's ecore, and I'll try again by restating what I wish to do. Suppose I have an SDO instance Class name UserSDO, instance userSDO I would like to get a list of all the non-complex object members of userSDO So for instance if userSDO has some String members like userName and userPassword I would like a list of these. Do I just use regular java reflection or does the Tuscany SDO API have something similar to EMF's EClass. If I were using EMF I could do EClass eClass = userSDO.eClass(); Then to get the members I would do EListEAttribute attributes = eClass.getEAttributes(); If I wanted the complext object references I would do EListEReference references eClass.getEReferences(); Does the Tuscany SDO API have something similar? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working with Tuscany SDOs reflectively
Super - Thanks Frank. This may be something I should be brining up to the SDO Specification guys, but it seems like Ecore's way of separating the EAttributes and the EReferences into separate lists will be more efficient from the perspective of of looking for various class members. For instance sometimes I'm only interested in the EAttributes, and with the EMF API I have access to only the List containing the EAttributes, so the time it takes to iterate through this list is shorter than the time it takes to iterate through all the EStructuralFeatures, which it seems like what I would be doing with the SDO API... Any thoughts? Could we perhaps add something to the Tuscany SDO implementation that gives us the ability to iterate through the isDataType() members of the SDO object and also the non isDataType() members. In addition, Ecore has the eObject.eClass().getEAllEReferences or EAttributes... giving us the inherited members as well. Is this what the SDO object returns when calling getType().getProperties() except in return in effect all the EStructuralFeatures? Thanks, - Ole Frank Budinsky wrote: In SDO there's a list of properties (simple and complex combined) that you can get like this: ListProperty properties = userSDO.getType().getProperties(); If you are interested in the simple ones, you need to do something like this when iterating through the list: if (property.getType().isDataType()) ... Frank. Ole Ersoy [EMAIL PROTECTED] wrote on 03/29/2007 01:59:05 PM: Hi, I asked this question a little differently before referring to EMF's ecore, and I'll try again by restating what I wish to do. Suppose I have an SDO instance Class name UserSDO, instance userSDO I would like to get a list of all the non-complex object members of userSDO So for instance if userSDO has some String members like userName and userPassword I would like a list of these. Do I just use regular java reflection or does the Tuscany SDO API have something similar to EMF's EClass. If I were using EMF I could do EClass eClass = userSDO.eClass(); Then to get the members I would do EListEAttribute attributes = eClass.getEAttributes(); If I wanted the complext object references I would do EListEReference references eClass.getEReferences(); Does the Tuscany SDO API have something similar? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working with Tuscany SDOs reflectively
Hey Frank, Yes - I can see how trying to change the specification, at least in the next couple of days, might be a long shot :-) I guess I'll just put a SDOUtil method in to separate the EAttributes from the EReferences. That way when the SDOs are stored in ApacheDS, the DAS is not calling isDataType every time it processes a SDO property. Incidentally, terminology wise, would it be correct for me to call EAttributes simple properties and EReferences complex properties? Thanks, - Ole Frank Budinsky wrote: Hi Ole, It will probably be hard to convince people to add the extra lists to the SDO specification. It was intentionally designed to have one simple list. Adding some methods in Tuscany (in class SDOUtil) to return just the dataType or non-dataType properties is possible, but as SDO is now being standardized and there are multiple implementations of it, it's really best to avoid using implementation-specific APIs, if possible. getType().getProperties() returns all the properties (including from the base types) - it's like EMF's getEAllStructuralFeatures(). getType().getDeclaredProperties() returns just the locally defined properties - like EMF's getEStructuralFeatures(). Frank. Ole Ersoy [EMAIL PROTECTED] wrote on 03/29/2007 03:04:52 PM: Super - Thanks Frank. This may be something I should be brining up to the SDO Specification guys, but it seems like Ecore's way of separating the EAttributes and the EReferences into separate lists will be more efficient from the perspective of of looking for various class members. For instance sometimes I'm only interested in the EAttributes, and with the EMF API I have access to only the List containing the EAttributes, so the time it takes to iterate through this list is shorter than the time it takes to iterate through all the EStructuralFeatures, which it seems like what I would be doing with the SDO API... Any thoughts? Could we perhaps add something to the Tuscany SDO implementation that gives us the ability to iterate through the isDataType() members of the SDO object and also the non isDataType() members. In addition, Ecore has the eObject.eClass().getEAllEReferences or EAttributes... giving us the inherited members as well. Is this what the SDO object returns when calling getType().getProperties() except in return in effect all the EStructuralFeatures? Thanks, - Ole Frank Budinsky wrote: In SDO there's a list of properties (simple and complex combined) that you can get like this: ListProperty properties = userSDO.getType().getProperties(); If you are interested in the simple ones, you need to do something like this when iterating through the list: if (property.getType().isDataType()) ... Frank. Ole Ersoy [EMAIL PROTECTED] wrote on 03/29/2007 01:59:05 PM: Hi, I asked this question a little differently before referring to EMF's ecore, and I'll try again by restating what I wish to do. Suppose I have an SDO instance Class name UserSDO, instance userSDO I would like to get a list of all the non-complex object members of userSDO So for instance if userSDO has some String members like userName and userPassword I would like a list of these. Do I just use regular java reflection or does the Tuscany SDO API have something similar to EMF's EClass. If I were using EMF I could do EClass eClass = userSDO.eClass(); Then to get the members I would do EListEAttribute attributes = eClass.getEAttributes(); If I wanted the complext object references I would do EListEReference references eClass.getEReferences(); Does the Tuscany SDO API have something similar? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Ecore Terminology / Concepts] Usage WRT Tuscany SDO API
Hi, I've started work on the design of the Tuscany LDAP DAS, and I find myself using Ecore concepts/models like EStructuralFeature, etc. quite a bit, when referring to members of EClassifiers (SDO Classes), etc. Does Tuscany have something similar/equivalent to Ecore that I should be using instead? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SAP R/3 Connector
Hi, Is there interest in having an SAP R/3 Connector project within Tuscany. It's a little tricky to test, but maybe someone here might know someone who knows someone who has access to an R/3 instance. I think Intalio already has a connector like this: http://www.intalio.com/news/intaliobpms-for-sap/ Could be that they would be willing to share. I'll find out more. Cheers, - Ole
Re: Ecore2Ecore Model and Processor Donation
Hi Fuhwei, Sure. The ecore2ecore model maps one ecore model to another. Here's a real world scenario that I'm using it for that will hopefully make it clearer. 1) I generate an ecore model from the maven pom v400 xml schema. 2) I map this model using ecore2ecore to another model I created (LibrarySpecDescriptor) 3) I load maven pom.xml instances and use the ecore2ecore processor to create corresponding LibrarySpecDescriptor instances (That are passed to a JET template for generating RPM Spec files). So the Ecore2Ecore model describes how EClassifiers of two different models relate, as well as howthe EStructuralFeatures of the two models map. The processor will create a target model instance, given a source model instance. SDO Scenario: Suppose you had an SDO model: PurchaseOrderVersion1 Later you create a newer version: PurchaseOrderVersion2 PurchaseOrderVersion2 has features and classes that map to PurchaseOrderVersion1 In addition PurchaseOrderVersion2 has additional features and classes that map to SupplierVersion1 So you wish to create PurchaseOrderVersion2 instances from PurchaseOrderVersion1 instances, along with SupplierVersion1 instances. You could use Ecore2Ecore to map the models and then the Ecore2EcoreProcessor to create the PurchaseOrderVersion2 instances. Does that help? Please let me know if need to elaborate on certain areas. Thanks, - Ole Fuhwei Lwo wrote: Hi Ole, I am no EMF expert. Can you help me understand what this Ecore2Ecore Model and Processor is used for? Thanks. Sincerely, Fuhwei Lwo Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created an Ecore2Ecore Model and Processor. I was wondering if this might find a home in Tuscany? The model maps one ecore model to another. It's different from the Eclipse implementation (Thought it was tricky to use), but I tried to reuse the naming of objects as much as possible. The processor will take a source model instance and create the corresponding target model. Here is the URL: https://svn.apache.org/repos/asf/directory/sandbox/oersoy/rpm.factory.all/ecore2ecore.model.parent Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ecore2Ecore Model and Processor Donation
Hi Frank, OK - Sounds good - I'll study up on my SDO concepts a little more - and look at how we can make it work. I did donate it to EMF on bugzilla already as well https://bugs.eclipse.org/bugs/show_bug.cgi?id=173226 Cheers, - Ole Frank Budinsky wrote: Hi Ole, Sounds interesting, but unless you want to reimplement the idea as an SDOType2SDOType model (independent of EMF), Tuscany is not the right home. Tuscany is an SDO implementation, which currently happens to have a dependency on EMF. It uses Ecore in restrictred and specialized ways, and the goal, over time, is to decrease the dependence on EMF. An EMF-specific (Ecore) mapping model would not be appropriate at Tuscany. Have you considered contributing it to the EMFT (EMF Technology) project at Eclipse? EMFT is the intended home for new EMF-based technologies. Frank Ole Ersoy [EMAIL PROTECTED] wrote on 03/17/2007 07:15:38 PM: Hi, I've created an Ecore2Ecore Model and Processor. I was wondering if this might find a home in Tuscany? The model maps one ecore model to another. It's different from the Eclipse implementation (Thought it was tricky to use), but I tried to reuse the naming of objects as much as possible. The processor will take a source model instance and create the corresponding target model. Here is the URL: https://svn.apache.org/repos/asf/directory/sandbox/oersoy/rpm. factory.all/ecore2ecore.model.parent Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ecore2Ecore Model and Processor Donation
Hi, I've created an Ecore2Ecore Model and Processor. I was wondering if this might find a home in Tuscany? The model maps one ecore model to another. It's different from the Eclipse implementation (Thought it was tricky to use), but I tried to reuse the naming of objects as much as possible. The processor will take a source model instance and create the corresponding target model. Here is the URL: https://svn.apache.org/repos/asf/directory/sandbox/oersoy/rpm.factory.all/ecore2ecore.model.parent Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestions for Tuscany SCA documenation?
Hi, I'm working one some Maven plugins for automatically producing Eclipse Documentation Plugins that have an EMF (Could be pure documentation model) as a source. The first guide I will be automating the production of is this Apache Directory Contributor Guide: https://svn.apache.org/repos/asf/directory/sandbox/oersoy/guides/org.apache.directory.contributor.guide/org.apache.directory.doc.contributor.1.0.0.v200701091241.zip This enables us to go between the Eclipse info center and website documentation transparently. I should have the first plugin done today, in case anyone is interested. The Apache Directory Contributor Guide should also be suitable for Tusancy I would think, with a few changes to the source xml content. Cheers, - Ole --- haleh mahbod [EMAIL PROTECTED] wrote: Tom, Thanks for helping to move Tuscany website content to CWIKI. I like the the left navigation bar. We could use this opportunity to simplify the site and make it more user friendly. For example, we might want to re-think the way we handle languages and put some thought into how to highlight scripting languages. First step will be to move the data and then we can re-arrange a lot of this to make it more readable. I'll work on the simplification of the presentation in parallel with what you are doing. I'll probably do a mock up on another page and move it once everyone agrees to it. Haleh On 2/14/07, Dan Murphy [EMAIL PROTECTED] wrote: I like the idea of having a side navigator; a little concerned of the potential maintenance overhead of this on each wiki page that needs a navigator (although I guess it isn't needed on every page ?), but we'll only find out once we have a reasonable body of work, so I'll go with Simon's give it a spin and see how it goes There is/was also a thread about wiki versus web site @ http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12431.html which I'm not sure reached any conclusion about what content (if any) should remain on the web site and what should move to the wiki It seems a shame to loose the Tuscany LF; perhaps the number of people who have offered to help with the wiki based documentation outweighs the value of the Tuscany LF - it's not like the cwiki is ugly :) On 14/02/07, Simon Laws [EMAIL PROTECTED] wrote: On 2/13/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Tom Seelbach wrote: If the wiki was switched to a left menu theme it would probably apply to the whole space. That would not work well for Tuscany since it has 3 separate projects (sca, sdo, das) as well as 2 implementations (java, cpp). i.e. the site is very complicated and it wouldn't be worth it to carry that left menu everywhere. There is always the horizontal link navigation at the top of every page anyway so a user is only one click from the top page. I just added a left-hand-nav to the wiki homepage to serve as a TOC. It's pretty simple. I tried to follow the existing Tuscany home as much as possible, and link to new information on the wiki as well. If the team agrees with this approach, we can migrate useful information off of the existing homepage and onto the wiki. If the team doesn't think this is the way to go, its a simple undo. +1, I like it. I'm willing to port some of the existing pages over and update them in the process if this helps. Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Tom Sidebar looks good to me. Lets give it a spin and see how it goes. +1 Simon No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LDAP DAS
Perfect. Full speed ahead :-) --- Luciano Resende [EMAIL PROTECTED] wrote: My comments groupId: org.apache.tuscany artifactId:das This is already taken by the DAS subproject /java/das... What do you think about something like : groupId: org.apache.tuscany.das artifactId:das.api artifactId:das.rdb artifactId:das.ldap artifactId:distribution artifactId:samples In the future, we might need to have samples moved to each impl, so das.rdbwould have it's own samples, and das.ldap would have it's own samples. Toughts ? On 1/31/07, Ole Ersoy [EMAIL PROTECTED] wrote: I'm looking at creating the maven project for the das interfaces right now. I think groupId: org.apache.tuscany artifactId:das makes sense for the interfaces project. Then groupId: org.apache.tuscany artifactId:das.rdb artifactId:das.ldap for the datasource specific implementations. Thoughts? Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, this would be the first step and you are on the right track, if we identify others, we could continue moving them gradatively... Another think to have in mind, and I don't think I have an answer right now, is around the config model, and where is the best place for it : API project, a common impl project , or each particular backend impl. Probably API, if the models don't defer much. Any Toughts ? -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: OK - I think this is the trunk: https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb And I think these are the interfaces: -rw-r--r-- 1 ole ole 1999 Sep 29 16:36 Command.java -rw-r--r-- 1 ole ole 3914 Dec 4 14:40 ConfigHelper.java -rw-r--r-- 1 ole ole 2092 Oct 5 15:03 Converter.java -rw-r--r-- 1 ole ole 2103 Oct 5 15:03 DASFactory.java -rw-r--r-- 1 ole ole 2076 Sep 29 16:36 DAS.java -rw-r--r-- 1 ole ole 2154 Oct 5 15:03 Pager.java Am I on the righ track? If so, I'll move the package containing the interfaces to another maven project and submit it via JIRA? Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Trunk DAS is pretty stable, unless you find any problems with it, I'd recommend staying with trunk. On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: Should I be grabbing das-java-M2? --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, your CLA should be fine... One of the first things that we will need on DAS to easily accommodate new implementations would be to refactor the DAS Interfaces to it's own project (e.g DAS API) and have the current DAS RDB having that as a dependency, and then DAS LDAP would also use DAS API as dependency. We would also need to enhance the API to allow instantiation of an specific DAS impl. As for design topics, some of the things that come to mind : - Command syntax - mapping filters to ldap searches - is there a standard syntax for CRUD operations in ldap ? - Support for change summary -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: I have a CLA on file with the apache directory project, so that probably applies for Apache in general right? OK - Cool - I'll gather up some of my design notes, go through the RDB DAS info, so I understand how that was done better, and try to come up with something inline with that for an LDAP DAS. If anyone has specific ideas I'll be glad to incorporate them into whatever design documentation produced. Cheers, - Ole === message truncated === Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-1088) SDO should tolerate malformed XML
Hi, Ed Merks and I did some work on this (Mostly Ed :-) ). I skimmed the JIRA briefly, and I think this applies here: See https://bugs.eclipse.org/bugs/show_bug.cgi?id=166127 Here's a brief summary: Case1: The element is supposed to be namespaced, but is not. Case2: The element is namespaced, but should not be. Case3: The element is namespaced, but the namespace is different from the namespace that the element is supposed to have per the schema definition. The redesigne of BasicExtendedMetaData supports cases 1 2 with a single switch. Hopefully the new design of the BasicExtendedMetaData applies to this TUSCANY-1088 Cheers, - Ole --- Kevin Williams (JIRA) tuscany-dev@ws.apache.org wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Williams updated TUSCANY-1088: Description: I had some off-line discussion with Frank and Yang. Here is the summary: As an improvement to consumability, SDO should tolerate some malformed XML. XML documents are often less than well-formed. Rather than failing on deserialization when a document does not completely conform to its schema, we should consider making some assumptions and continuing on. Some competitor technologies do this today. Here's an example. Say we have this schema: ?xml version=1.0 encoding=UTF-8? xsd:schema targetNamespace=http://QuickTest/HelloWorld; xmlns:tns=http://QuickTest/HelloWorld; xmlns:xsd=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified xsd:element name=sayHello xsd:complexType xsd:sequence xsd:element name=input1 nillable=true type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:schema If we get an xml that looks like this: ?xml version=1.0 encoding=UTF-8? tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://QuickTest/HelloWorld HelloWorldMessage.xsd input1input1/input1 /tns:sayHello then we will fail validating this since input1 isn't fully qualified. Here's the xml that would work: ?xml version=1.0 encoding=UTF-8? tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://QuickTest/HelloWorld HelloWorldMessage.xsd tns:input1tns:input1/tns:input1 /tns:sayHello Frank mentioned 2 potential approaches: 1. Read the element in as if it was an open content property. If you reserialize it would be the same (still invalid). 2. If a property with the same name (but different namespace) exists, then associate it with that. When you reserialize it will be then be correct. The later seems the best approach. Yang also contributed the following: It's friendly to tolerate if a user forgets to qualify a local element. There're 3 scenarios may not have the same elementFormDefault=qualified enforcement policy. What do you think? 3-1. tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; input1input1/input1 /tns:sayHello The author may have forgot to qualify input1 element, although input1 may also be a global element without NameSpace. It's friendly to tolerate. 3-2. tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns:onPurpose=differentNameSpace onPurpose:input1input1/onPurpose:input1 /tns:sayHello The author has qualified input1 element; I'm not confident we should tolerate. 3-3. tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns=differentNameSpace !-- xmlns= declares all unqualified elements/attributes under differentNameSpace -- input1input1/input1 /tns:sayHello It's hard to tell if the author may have forgot to qualify input1 element or not. I bet on not. Should we tolerate? was: I had some off-line discussion with Frank and Yang. Here is the summary: As an improvement to consumability, SDO should tolerate some malformed XML. It is not uncommon for XML documents to not be less than well-formed. Rather than failing on deserialization when a document does not completely conform to its schema, we should consider making some assumptions and continuing on. Some competitor technologies do this today. Here's an example. Say we have this schema: ?xml version=1.0 encoding=UTF-8? xsd:schema targetNamespace=http://QuickTest/HelloWorld; xmlns:tns=http://QuickTest/HelloWorld; xmlns:xsd=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified xsd:element name=sayHello xsd:complexType xsd:sequence
Re: LDAP DAS
I'm looking at creating the maven project for the das interfaces right now. I think groupId: org.apache.tuscany artifactId:das makes sense for the interfaces project. Then groupId: org.apache.tuscany artifactId:das.rdb artifactId:das.ldap for the datasource specific implementations. Thoughts? Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, this would be the first step and you are on the right track, if we identify others, we could continue moving them gradatively... Another think to have in mind, and I don't think I have an answer right now, is around the config model, and where is the best place for it : API project, a common impl project , or each particular backend impl. Probably API, if the models don't defer much. Any Toughts ? -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: OK - I think this is the trunk: https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb And I think these are the interfaces: -rw-r--r-- 1 ole ole 1999 Sep 29 16:36 Command.java -rw-r--r-- 1 ole ole 3914 Dec 4 14:40 ConfigHelper.java -rw-r--r-- 1 ole ole 2092 Oct 5 15:03 Converter.java -rw-r--r-- 1 ole ole 2103 Oct 5 15:03 DASFactory.java -rw-r--r-- 1 ole ole 2076 Sep 29 16:36 DAS.java -rw-r--r-- 1 ole ole 2154 Oct 5 15:03 Pager.java Am I on the righ track? If so, I'll move the package containing the interfaces to another maven project and submit it via JIRA? Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Trunk DAS is pretty stable, unless you find any problems with it, I'd recommend staying with trunk. On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: Should I be grabbing das-java-M2? --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, your CLA should be fine... One of the first things that we will need on DAS to easily accommodate new implementations would be to refactor the DAS Interfaces to it's own project (e.g DAS API) and have the current DAS RDB having that as a dependency, and then DAS LDAP would also use DAS API as dependency. We would also need to enhance the API to allow instantiation of an specific DAS impl. As for design topics, some of the things that come to mind : - Command syntax - mapping filters to ldap searches - is there a standard syntax for CRUD operations in ldap ? - Support for change summary -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: I have a CLA on file with the apache directory project, so that probably applies for Apache in general right? OK - Cool - I'll gather up some of my design notes, go through the RDB DAS info, so I understand how that was done better, and try to come up with something inline with that for an LDAP DAS. If anyone has specific ideas I'll be glad to incorporate them into whatever design documentation produced. Cheers, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Probably starting some design discussions on the dev-list, and later on summarazing it on the wiki would be a good way of doing this. Not sure if others have any more special handling for this... On the legal side, I think contributions via patches should work just fine. On 1/29/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, Yes - Very much interested. We've been having discussions around doing one over at the directory project for triplesec, and I have experimented a little using EMF reflection to produce jndi updates, etc. I'll gather up my old design notes. Let me know if there is some formal protocol I should be following for this wrt Tuscany. Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: I don't recall any previous discussions around an LDAP DAS. If you are interested in contributing an LDAP DAS implementation to Tuscany, we could start some design discussions and how we would go about getting it done. Thanks for Volunteering !!! === message truncated === 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
Re: LDAP DAS
OK - Cool. I'll checkout the DAS project and have a go at the refactoring. Then I'll read some of the DAS example doco (I think there is some) and try to come up with similar examples for LDAP that can be used as a guide to starting the DAS implentation. I'll do it Cookbook style like: Challenge: Updating ApacheDS using an SDO Change Summary Solution: Short Blah Blah Blah Description... Discussion: Longer Blah Blah Blah Related Items: Blah Blah These can then be used to provide context for further design discussions. Sound ok? Cheers, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, your CLA should be fine... One of the first things that we will need on DAS to easily accommodate new implementations would be to refactor the DAS Interfaces to it's own project (e.g DAS API) and have the current DAS RDB having that as a dependency, and then DAS LDAP would also use DAS API as dependency. We would also need to enhance the API to allow instantiation of an specific DAS impl. As for design topics, some of the things that come to mind : - Command syntax - mapping filters to ldap searches - is there a standard syntax for CRUD operations in ldap ? - Support for change summary -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: I have a CLA on file with the apache directory project, so that probably applies for Apache in general right? OK - Cool - I'll gather up some of my design notes, go through the RDB DAS info, so I understand how that was done better, and try to come up with something inline with that for an LDAP DAS. If anyone has specific ideas I'll be glad to incorporate them into whatever design documentation produced. Cheers, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Probably starting some design discussions on the dev-list, and later on summarazing it on the wiki would be a good way of doing this. Not sure if others have any more special handling for this... On the legal side, I think contributions via patches should work just fine. On 1/29/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, Yes - Very much interested. We've been having discussions around doing one over at the directory project for triplesec, and I have experimented a little using EMF reflection to produce jndi updates, etc. I'll gather up my old design notes. Let me know if there is some formal protocol I should be following for this wrt Tuscany. Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: I don't recall any previous discussions around an LDAP DAS. If you are interested in contributing an LDAP DAS implementation to Tuscany, we could start some design discussions and how we would go about getting it done. Thanks for Volunteering !!! -- Luciano Resende http://people.apache.org/~lresende On 1/26/07, Ole Ersoy [EMAIL PROTECTED] wrote: Anyone know whether there is a LDAP DAS planned for Tuscany? Thanks, - Ole Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende http://people.apache.org/~lresende Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL - === message truncated === Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
Re: LDAP DAS
Should I be grabbing das-java-M2? --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, your CLA should be fine... One of the first things that we will need on DAS to easily accommodate new implementations would be to refactor the DAS Interfaces to it's own project (e.g DAS API) and have the current DAS RDB having that as a dependency, and then DAS LDAP would also use DAS API as dependency. We would also need to enhance the API to allow instantiation of an specific DAS impl. As for design topics, some of the things that come to mind : - Command syntax - mapping filters to ldap searches - is there a standard syntax for CRUD operations in ldap ? - Support for change summary -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: I have a CLA on file with the apache directory project, so that probably applies for Apache in general right? OK - Cool - I'll gather up some of my design notes, go through the RDB DAS info, so I understand how that was done better, and try to come up with something inline with that for an LDAP DAS. If anyone has specific ideas I'll be glad to incorporate them into whatever design documentation produced. Cheers, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Probably starting some design discussions on the dev-list, and later on summarazing it on the wiki would be a good way of doing this. Not sure if others have any more special handling for this... On the legal side, I think contributions via patches should work just fine. On 1/29/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, Yes - Very much interested. We've been having discussions around doing one over at the directory project for triplesec, and I have experimented a little using EMF reflection to produce jndi updates, etc. I'll gather up my old design notes. Let me know if there is some formal protocol I should be following for this wrt Tuscany. Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: I don't recall any previous discussions around an LDAP DAS. If you are interested in contributing an LDAP DAS implementation to Tuscany, we could start some design discussions and how we would go about getting it done. Thanks for Volunteering !!! -- Luciano Resende http://people.apache.org/~lresende On 1/26/07, Ole Ersoy [EMAIL PROTECTED] wrote: Anyone know whether there is a LDAP DAS planned for Tuscany? Thanks, - Ole Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende http://people.apache.org/~lresende Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL - === message truncated === Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LDAP DAS
OK - I think this is the trunk: https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb And I think these are the interfaces: -rw-r--r-- 1 ole ole 1999 Sep 29 16:36 Command.java -rw-r--r-- 1 ole ole 3914 Dec 4 14:40 ConfigHelper.java -rw-r--r-- 1 ole ole 2092 Oct 5 15:03 Converter.java -rw-r--r-- 1 ole ole 2103 Oct 5 15:03 DASFactory.java -rw-r--r-- 1 ole ole 2076 Sep 29 16:36 DAS.java -rw-r--r-- 1 ole ole 2154 Oct 5 15:03 Pager.java Am I on the righ track? If so, I'll move the package containing the interfaces to another maven project and submit it via JIRA? Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Trunk DAS is pretty stable, unless you find any problems with it, I'd recommend staying with trunk. On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: Should I be grabbing das-java-M2? --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, your CLA should be fine... One of the first things that we will need on DAS to easily accommodate new implementations would be to refactor the DAS Interfaces to it's own project (e.g DAS API) and have the current DAS RDB having that as a dependency, and then DAS LDAP would also use DAS API as dependency. We would also need to enhance the API to allow instantiation of an specific DAS impl. As for design topics, some of the things that come to mind : - Command syntax - mapping filters to ldap searches - is there a standard syntax for CRUD operations in ldap ? - Support for change summary -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: I have a CLA on file with the apache directory project, so that probably applies for Apache in general right? OK - Cool - I'll gather up some of my design notes, go through the RDB DAS info, so I understand how that was done better, and try to come up with something inline with that for an LDAP DAS. If anyone has specific ideas I'll be glad to incorporate them into whatever design documentation produced. Cheers, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Probably starting some design discussions on the dev-list, and later on summarazing it on the wiki would be a good way of doing this. Not sure if others have any more special handling for this... On the legal side, I think contributions via patches should work just fine. On 1/29/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, Yes - Very much interested. We've been having discussions around doing one over at the directory project for triplesec, and I have experimented a little using EMF reflection to produce jndi updates, etc. I'll gather up my old design notes. Let me know if there is some formal protocol I should be following for this wrt Tuscany. Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: I don't recall any previous discussions around an LDAP DAS. If you are interested in contributing an LDAP DAS implementation to Tuscany, we could start some design discussions and how we would go about getting it done. Thanks for Volunteering !!! -- Luciano Resende http://people.apache.org/~lresende On 1/26/07, Ole Ersoy [EMAIL PROTECTED] wrote: Anyone know whether there is a LDAP DAS planned for Tuscany? Thanks, - Ole Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] === message truncated === Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LDAP DAS
Great - Thanks - Good to know I'm on the right track. Just taking a quick shot: I think there should be a org.apache.tuscany.das.config.model.rdb + some other implementation packages in it's own project. And the same for ldap. So: org.apache.tuscany.das.config.model.ldap + implementation packages. Cheers, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, this would be the first step and you are on the right track, if we identify others, we could continue moving them gradatively... Another think to have in mind, and I don't think I have an answer right now, is around the config model, and where is the best place for it : API project, a common impl project , or each particular backend impl. Probably API, if the models don't defer much. Any Toughts ? -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: OK - I think this is the trunk: https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb And I think these are the interfaces: -rw-r--r-- 1 ole ole 1999 Sep 29 16:36 Command.java -rw-r--r-- 1 ole ole 3914 Dec 4 14:40 ConfigHelper.java -rw-r--r-- 1 ole ole 2092 Oct 5 15:03 Converter.java -rw-r--r-- 1 ole ole 2103 Oct 5 15:03 DASFactory.java -rw-r--r-- 1 ole ole 2076 Sep 29 16:36 DAS.java -rw-r--r-- 1 ole ole 2154 Oct 5 15:03 Pager.java Am I on the righ track? If so, I'll move the package containing the interfaces to another maven project and submit it via JIRA? Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Trunk DAS is pretty stable, unless you find any problems with it, I'd recommend staying with trunk. On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: Should I be grabbing das-java-M2? --- Luciano Resende [EMAIL PROTECTED] wrote: Yes, your CLA should be fine... One of the first things that we will need on DAS to easily accommodate new implementations would be to refactor the DAS Interfaces to it's own project (e.g DAS API) and have the current DAS RDB having that as a dependency, and then DAS LDAP would also use DAS API as dependency. We would also need to enhance the API to allow instantiation of an specific DAS impl. As for design topics, some of the things that come to mind : - Command syntax - mapping filters to ldap searches - is there a standard syntax for CRUD operations in ldap ? - Support for change summary -- Luciano Resende http://people.apache.org/~lresende On 1/30/07, Ole Ersoy [EMAIL PROTECTED] wrote: I have a CLA on file with the apache directory project, so that probably applies for Apache in general right? OK - Cool - I'll gather up some of my design notes, go through the RDB DAS info, so I understand how that was done better, and try to come up with something inline with that for an LDAP DAS. If anyone has specific ideas I'll be glad to incorporate them into whatever design documentation produced. Cheers, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: Probably starting some design discussions on the dev-list, and later on summarazing it on the wiki would be a good way of doing this. Not sure if others have any more special handling for this... On the legal side, I think contributions via patches should work just fine. On 1/29/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, Yes - Very much interested. We've been having discussions around doing one over at the directory project for triplesec, and I have experimented a little using EMF reflection to produce jndi updates, etc. I'll gather up my old design notes. Let me know if there is some formal protocol I should be following for this wrt Tuscany. Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: I don't recall any previous discussions around an LDAP DAS. If you are interested in contributing an LDAP DAS implementation to Tuscany, we could start some design discussions and how we would go about getting it done. Thanks for Volunteering !!! === message truncated === Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform
Re: LDAP DAS
Hi, Yes - Very much interested. We've been having discussions around doing one over at the directory project for triplesec, and I have experimented a little using EMF reflection to produce jndi updates, etc. I'll gather up my old design notes. Let me know if there is some formal protocol I should be following for this wrt Tuscany. Thanks, - Ole --- Luciano Resende [EMAIL PROTECTED] wrote: I don't recall any previous discussions around an LDAP DAS. If you are interested in contributing an LDAP DAS implementation to Tuscany, we could start some design discussions and how we would go about getting it done. Thanks for Volunteering !!! -- Luciano Resende http://people.apache.org/~lresende On 1/26/07, Ole Ersoy [EMAIL PROTECTED] wrote: Anyone know whether there is a LDAP DAS planned for Tuscany? Thanks, - Ole Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven profile to generate correct Eclipse projects?
Hi, I just skimmed this so sorry if someone may have answered your original question. If you run mvn eclipse:clean eclipse:eclipse, it will restore the Maven project to it's original pre-eclipse project state, and then recreate the eclipse project files. This guarantees that the files are up to date. If you do the same on a parent project, it cleans and updates all the child projects. Then if you run mvn clean install on the parent it will update the entire build. You now have to F5 each project to make sure it sees the latest recompiled and deployed dependencies in the maven repository. With Eclipse 3.2 some test files occasionally pretend that they don't see the dependencies after running the eclipse plugin. Then when I run the test in eclipse, the dependencies are resolved. Cheers, - Ole --- Dan Murphy [EMAIL PROTECTED] wrote: Hi, I think the cause of the problem is both Sebastien and I are going into specific component / sub components of Tuscany and running mvn -Peclipse from there from the sounds of it if you run it at the top level then you should get all the subs build such that any dependecies are resolved to other compoenents in the same source hierarchy (as opposed to the repository). Seems like this could be a good point to document in the wiki, 'cos the last time I read the docs it advised you to go into each part seperatly and run mvn -Peclipse Regards, Dan On 10/01/07, Rick [EMAIL PROTECTED] wrote: Sebastien, I don't quite get the issue you are seeing. I'll just add what I've been doing: In top folder (java) run mvn -Pall,eclipse eclipse:eclipse I'm still a hold out I guess in that I like building the whole tuscany package. For debugging, I add source of projects I know I need. So far this has been working for me. Cheers. Jean-Sebastien Delfino wrote: I'm trying to do some simple refactoring of the spec APIs to fix JIRA 909, and running into the following issues: I am using Eclipse and running mvn -Peclipse eclipse:eclipse in the spec and sca folders to generate Eclipse projects. If I remember correctly this used to generate correct Eclipse project dependencies, for example the core project had a dependency on the sca-api project. Now project core depends on the sca-api-r0.95 jar instead. Code changes that I make in the sca-api project are not seen by core. Refactoring methods in sca-api does not adjust any of the code in core. The jars do not have associated source code so this makes debugging tough (and there's way too many projects for me to associate the source code to each jar manually). I have probably forgotten to do something or not run mvn -Peclipse correctly. Could somebody point me to the magic Maven commands that will generate a usable Eclipse workspace? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
EMF Maven Dependencies
Hi, Hope it's ok that I ask this question of the Dev list...It's sort of devvish. I noticed in the eclipse cvs emf-build folder that there is a maven script for creating mavenized emf builds. Does the Tuscany team use this to put the Maven dependencies on a public repository anywhere? Thanks, - Ole __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
