Re: [SDO Java DISCUSS] Contents of the next SDO release
[I inadvertently sent a reply to tuscany-dev when this thread belongs on tuscany-user, so copying my response here ...] Good suggestion Steffen. If you were able to open a Jira and dump into it any thoughts you may have had about the details of how you see this working that would be great. The more detail you put there, the more likely it is that someone who wants to get their hands dirty would be likely to pick it up; unless of course you have plans for doing it yourself. As an aside, it's always interesting to know the background to why a particular feature is important to someone, so if you felt like commenting on your scenarios that would benefit from this too, whether in the JIRA on or the list, that would be great. For my part here are the things that I'd like to see done ... - reorganisation of the build to create release distributions in line with the SCA release format - review and improvement of the samples and implementation of an alternative simple approach to running the samples that does not involve running a maven build - review and improvement of the website documentation In addition, some things I'd like to see being done, but I don't see as absolute prerequisites for a release are ... - creation of a further sdo sub-project that permits automated exercising of the sdo plugin and java generator - more test cases In terms of JIRA's, we currently have 3 marked for the specific release [1], rather then the generic Java-SDO-Next bucket [2] that is the placeholder for Jiras not assigned to a release. TUSCANY-1317 http://issues.apache.org/jira/browse/TUSCANY-1317, TUSCANY-1143 http://issues.apache.org/jira/browse/TUSCANY-1143 , TUSCANY-513 http://issues.apache.org/jira/browse/TUSCANY-513 The first is there because the originator marked it for the beta1, which it didn't make, but it looks well defined, so after the beta1 I changed the fix release to the 1.0 release, but I don't think I'll have the bandwidth to cover this. The second is there because I want it to be, and plan to tackle it. The third is there because the originator has provided a patch and I'm in the process of committing it. In the light of my priorities above, having taken a scan through [2] in addition to 1143, I plan to look at ... TUSCANY-1122TypeConversionTestCase fails for JDK 1.4.2 TUSCANY-1127ObtainingDataGraphFromXml, and maybe other samples, incorrectly accessing xsd:any content TUSCANY-1284Manifest version number in Java SDO Impl and Tools jars TUSCANY-257recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 and there are a few others I have my eye on, e.g. 303, if all the above goes well. Regards, Kelvin. [1] http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=1status=3status=4component=12311542component=12310660component=12310973component=12310802fixfor=12312521sorter/field=issuekeysorter/order=DESC [2] http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=1status=3status=4component=12310660component=12310973component=12310802fixfor=12312262sorter/field=issuekeysorter/order=DESC On 09/06/07, Steffen Glomb [EMAIL PROTECTED] wrote: i would like to see support for typesafe collections in the xsd2java generator. regards Steffen On 6/8/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd like to draw the communities attention to this issue again please. Thanks to David for responding with his requirements and with the fix for 1223. I have some thoughts that I'm structuring at the moment on what's important for a next release from my perspective that I'll post soon, but in general I'm just keen to get the good stuff that we have added recently out in a release that, as I said before from my perspective, warrants the title of 1.0. With the Summer holiday season coming up, I'd like to do this soon so that I can sun myself on a beach without that niggling feeling of things that ought to have been done ;-) What say you we put a stake in the ground of aiming for a SDO 1.0release to be at the IPMC ratification stage by mid-July? So to that end I ask again, if you have requirements that you feel are fundamental to the next release please raise them now; with the caveat of course that the only way to be sure of getting your requirements into the release is to step forward and supply the fixes. -- Kelvin. On 23/05/07, David Adcox [EMAIL PROTECTED] wrote: Kelvin, I would like to see the multiple namepace issue resolved in the XSD2JavaGenerator tool. This issue is covered in JIRA 1223. Optionally, making it available to the plugin (JIRA 303) would be nice. JIRA 1143 is something that I need fixed, as well. So any focus that can be given to that prior to this release would be appreciated. In the spirit of cooperation, I'll be posting a first pass on 1223 a bit later in the week. Thanks, David On 5/21/07, kelvin goodson [EMAIL
[SDO Java] discuss the next SDO release on the IRC chat today
I've posted a couple of notes about the next SDO release recently. It would seem timely to use part of the IRC chat slot to discuss this. Regards, Kelvin.
RE: Adding Multiple Contributions, was:Re: Simple use case problem
Luciano,
Thanks. Works fine with these corrections.
-Message d'origine-
De : Luciano Resende [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 8 juin 2007 7:31
À : tuscany-user@ws.apache.org; tuscany-dev
Objet : Adding Multiple Contributions, was:Re: Simple use case problem
Patrick
Thanks for helping on this, looks like while trying the scenario where
we have multiple contributions, we uncovered the following bugs :
- Class loader issue with contribution metadata loader [1]
- Wiring of multiple contributions [2]
This scenario should now be working, after couple fixes that I
committed under revision # 545411. Note that your sample application
will need some small modifications, but you could use the
EmbeddedSCADomainTestCase as an example to what needs to be changed,
basically you will need to add a call to helper.activateDomain and
then helper.startComponent.
There is also a sample application exercising this scenario in my
sandbox [3] for those interested. I'll work little more on this sample
and probably move it to trunk under a sample or test case.
While working on these issues, I also found the programming model to
work with multiple contributions using EmbeddedSCADomain more complex
then it should be. I'll take a deeper look into this area and send
some proposals on how we could improve the programming model when
using multiple contributions.
[1] https://issues.apache.org/jira/browse/TUSCANY-1329
[2] http://issues.apache.org/jira/browse/TUSCANY-1332
[3]
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresend
e/sca/samples/
On 6/7/07, Patrick Vanhuyse [EMAIL PROTECTED] wrote:
Hi Luciano,
I have attached the full code of my sample to the jira issue.
All is in it !
I now use 2 different resolvers. But it doesn't help !
Regards.
Patrick
-Message d'origine-
De : Luciano Resende [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 6 juin 2007 23:44
À : tuscany-user@ws.apache.org
Objet : Re: Simple use case problem
Hi Patrick
Thanks for finding a workaround for a bug in the code that process
the contribution metadata side file, I have created a jira for it [1].
Looking into the code you provided, I noticed you are using the
same resolver while contributing both contributions, and you should be
using two different ones
Could you also provide us with the full stack trace and the
composite files you are using ? In the mean time, I'll try to simulate
what I think you are doing in a test case and made it available in
Tuscany.
[1] https://issues.apache.org/jira/browse/TUSCANY-1329
On 6/6/07, Patrick Vanhuyse [EMAIL PROTECTED] wrote:
Luciano,
First try with url = file://.../provider.jar doesn't work
because :
In ContributionServiceImpl.java, initializeContributionMetadata
(line 134) :
URL[] clUrls = {sourceURL};
URLClassLoader cl = new URLClassLoader(clUrls);
contributionMetadataURL =
cl.getResource(Contribution.SCA_CONTRIBUTION_META);
sourceURL = file://.../provider.jar
contributionMetadataURL =
file://.../consumer/target/classes/META-INF/sca-contribution.xml
because of the parent class loader in cl.
If I put a null parent class loader in the creation of cl :
URL[] clUrls = {sourceURL};
URLClassLoader cl = new URLClassLoader(clUrls, null);
contributionMetadataURL =
cl.getResource(Contribution.SCA_CONTRIBUTION_META);
it finds the good sca-contribution :
contributionMetadataURL =
jar:file://.../provider.jar!/META-INF/sca-contribution.xml
and it loads the ProviderComposite and the ProviderComponent in it.
But in my test :
// Determine my class loader and my test SCA
contribution location
String url =
file:///h:/it/logiciel_gi/sca/provider/target/provider.jar;
ContributionService contributionService =
domain.getContributionService();
DomainCompositeHelper helper =
domain.getDomainCompositeHelper();
ModelResolver myResolver = new
ModelResolverImpl(getClass().getClassLoader());
// Contribute the SCA contribution
ListContribution contributions = new
ArrayListContribution(2);
Contribution contribution = contributionService
.contribute(http://www.greisch.com/provider;, new URL(url),
myResolver, false);
assertNotNull(contribution);
contributions.add(contribution);
url = file:///h:/it/logiciel_gi/sca/consumer/target/classes/;
contribution = contributionService
.contribute(http://www.greisch.com/consumer;, new URL(url),
myResolver, false);
assertNotNull(contribution);
contributions.add(contribution);
for (Contribution contrib : contributions) {
for (Composite composite :
RE: [SDO Java DISCUSS] Contents of the next SDO release
Hi
I have a couple of places where I go beyond the SDO classes and into
EMF, that I would to see included into some of the SDO utilities:
1. Upper and lower bound on properties where 'isMany' is true:
I have implemented it like this
public static int getUpperBound(Property property) {
return ((EStructuralFeature) property).getUpperBound();
}
public static int getLowerBound(Property property) {
return ((EStructuralFeature) property).getLowerBound();
}
The SDOUtil class seems a perfect place to put these.
2. The enumeration facet
I need to know whether a type has enumerated restrictions:
public static ListString getEnumerationFacet(Type type) {
return
ExtendedMetaData.INSTANCE.getEnumerationFacet((EDataType)type);
}
3. Validation
I do validation using Diagnostic:
Diagnostic diagnostic = Diagnostician.INSTANCE.validate((EObject)
dataObject);
if (diagnostic.getSeverity() == Diagnostic.ERROR) {
.
I haven't seen if SDO 2.1 has introduced other kind of validation of if
a funtionality is in the making...
/Chr
-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: 8. juni 2007 19:02
To: tuscany-user@ws.apache.org
Subject: Re: [SDO Java DISCUSS] Contents of the next SDO release
I'd like to draw the communities attention to this issue again please.
Thanks to David for responding with his requirements and with the fix
for
1223. I have some thoughts that I'm structuring at the moment on what's
important for a next release from my perspective that I'll post soon,
but
in general I'm just keen to get the good stuff that we have added
recently
out in a release that, as I said before from my perspective, warrants
the
title of 1.0. With the Summer holiday season coming up, I'd like to
do
this soon so that I can sun myself on a beach without that niggling
feeling
of things that ought to have been done ;-)
What say you we put a stake in the ground of aiming for a SDO 1.0
release to
be at the IPMC ratification stage by mid-July?
So to that end I ask again, if you have requirements that you feel are
fundamental to the next release please raise them now; with the caveat
of
course that the only way to be sure of getting your requirements into
the
release is to step forward and supply the fixes.
--
Kelvin.
On 23/05/07, David Adcox [EMAIL PROTECTED] wrote:
Kelvin,
I would like to see the multiple namepace issue resolved in the
XSD2JavaGenerator tool. This issue is covered in JIRA 1223.
Optionally, making it available to the plugin (JIRA 303) would be
nice. JIRA 1143 is something that I need fixed, as well. So any
focus that can be given to that prior to this release would be
appreciated.
In the spirit of cooperation, I'll be posting a first pass on 1223 a
bit later in the week.
Thanks,
David
On 5/21/07, kelvin goodson [EMAIL PROTECTED] wrote:
With the beta1 release of SDO Java announced, I have begun thinking
about
a
next release which I believe can be given the version tag
1.0-incubator
. We
have full coverage of the 2.1 SDO spec in the trunk now, and we
currently
have 33 open JIRAs.
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid
=12310210status=1status=3status=4component=12310660component=123109
73component=12310802sorter/field=issuekeysorter/order=DESCsorter/fie
ld=componentssorter/order=ASCsorter/field=prioritysorter/order=DESC
Please give feedback on those issues which are important to you and,
if
possible, step up to provide fixes for those issues.
If we are to call this the 1.0 release then it ought to provide a
really
good experience for the user. Please share your experiences about
using
the
beta1 release and make suggestions or contributions to improve the
next
one.
Aside from fixes to the code, key contributions would be to improve
the
instructions, the samples and the documentation (we already have
discussions going on about the shape of the release distributions on
another
thread).
Kelvin.
-
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: why does extension-helper deprecate definition of ExtentionPoints in Implementation/Binding activators
On 6/11/07, lee zhenghui [EMAIL PROTECTED] wrote: Hi, extension-helper module is simplifying implementation/binding extention development. But Why it deprecate definition of ExtentionPoints in Implementation/Binding activators. Java implementation have defined a class visitors extention points in the activator, do you want to replace org.apache.tuscany.sca.core.ModuleActivator with org.apache.tuscany.sca.spi.ImplementationActivator for java implementation? If yes, Where is the pretty runtime point to registry these extension points? If no, Java implementation looks a little different than other implementations. maybe a little confused to new comer(java implementation is a good entry point to learn sca implementation extension) Maybe I missed something here, pls correct me. Just to be clear, extension-helper is not deprecating the existing runtime SPI. The existing runtime SPI continues to be perfectly fine to write implementation extensions with. The extension-helper module is the start of a simpler SPI for binding and implementation extensions as those type of extension will not usually need the full power and flexibility of the full Tuscany runtime SPI. Be interesting to hear other opinions, but I'm not sure that implementation.java really needs to or should be using the ExtensionPoint mechanism (getExtensionPoints) to add its classVisitors. This ends up making the class visitors available to everything in the runtime which doesn't seem ideal. I think its just done like this as a hang over from the old runtime code. The extension-helper module is still being worked out, if you've suggestions (or patches :) ) on how to improve it or use cases showing its deficiency's that would be really helpful. If you'd really find the getExtensionPoints facility useful say and we can look at adding it. ...ant
Re: Databinding, dataobject - UI Component
Steffen, there's no provision in the SDO API for receiving direct notification of changes to values. It would be an unportable and fragile thing to do to rely on the EMF underpinnings of the Tuscany SDO implementation. I don't think there is anything to offer here from the pure SDO API level. Regards, Kelvin. On 10/06/07, Steffen Glomb [EMAIL PROTECTED] wrote: hopefully common Scenario: Using SDO in a Swing Rich Client application, pulling the datagraph to the client. Fields from in the User Interface are bound to properties of the dataobjects in the graph. Client side business logic causes changes in the dataobjects. One might want to have these changes automatically synchronized to the UI Components. Problem: I am having difficulties finding a simple way to implement the data binding. Question: How can i get the change notification from the dataobject? ( dataobject.eAdapters() returns an umodifieable list) Solution? The only way i found to accomplish this is through adding an adapter to the changesummary and unscrambling the changeentries as they are added. Is this the intended way? why is the changenotification of EObjectImpl cut off ? Thanks for sharing your expertise Steffen
