-impl really means
sdo-impl + sdo-tools + sdo-plugin. In order to avoid such confusion, I
would suggest you provide one source zip file containing source for
sdo-spec, sdo-impl, sdo-tools, and sdo-plugin. I think this is clearer
and more consistent.
Thanks again,
- Ron
kelvin goodson wrote:
I posted
I have made available an RC2 release candidate for SDO for Java at
http://people.apache.org/~kelvingoodson/sdo_java/RC2/
The main differences from RC1a are
Tuscany JIRAs 115 and 755 are fixed
The source distribution has been split (re-split) into specification and
implementation archives after
Brandon,
yes, thanks for catching that. I have been rearranging directories last
week to make the M2 distribution, and this problem has arisen becuase of
that. Apologies.
Regards, Kevlin.
On 07/10/06, Brandon Werner [EMAIL PROTECTED] wrote:
All:
On the website URL:
Correction -- The new DAS release candidate is at ...
http://people.apache.org/~kelvingoodson/das_java/RC4a/
Regards, Kelvin.
On 20/10/06, Luciano Resende [EMAIL PROTECTED] wrote:
The DAS Java M2 Release Candidate 4a is available at :
Hi Dan,
Welcome to Tuscany! Working on the test compliance kit (TCK -- at least
that's what I've always assumed the acronym to mean) for Java would be a
real help. In particular there's some work going on exploring integration
of tests from RogueWave into Tuscany under JIRA 829 (
The Apache Tuscany community is pleased to announce its Milestone 2 release
of SDO (Service Data Objects).
You can download binary and source distributions from:
http://incubator.apache.org/tuscany/downloads.html
For further information, visit our web site at:
Hello Raghu
I think you have the Eclipse EMF SDO 1 implementation on your classpath.
Regards, Kelvin.
On 22/11/06, Raghu Ram Sripada [EMAIL PROTECTED] wrote:
Hi Kelvin,
I was trying to write my first app using DAS and while using the M2 drop I
found the following:
in SDOUtil.java in the
Hi Sue,
providing a solution to lazy instantiation of data graphs is a subject
that's on the SDO spec group's agenda. Currently the SDO spec JIRA that's
tracking this issue proposes a DataObjectResolver which looks not too
dissimilar to the current Store stuff that's in SDO1/EMF, and resolving
Hi Erich,
it sounds to me like you have managed to register the types dynamically
(perhaps as well as statically);
i.e. in addition to a call to
SDOUtil.registerStaticTypes(FactoryThatCreatesPersonClassesEtc.class);
I think you must have a call to something like
forwarding email exchange (2 of 3)
-- Forwarded message --
From: kelvin goodson [EMAIL PROTECTED]
Date: 05-Jan-2007 11:03
Subject: Re: Build problem (Tuscany M2 SDO) (Linux)
To: Stanislaw T. Findeisen [EMAIL PROTECTED]
Hi Stanislaw,
yes, I'm a Tuscany developer. I have
Forwarding email exchange to tuscany-user (3 of 3)
-- Forwarded message --
From: Stanislaw T. Findeisen [EMAIL PROTECTED]
Date: 05-Jan-2007 12:52
Subject: Re: Build problem (Tuscany M2 SDO) (Linux)
To: [EMAIL PROTECTED]
The resource seems to be found.
I added some debugging to
Stanislaw,
I have tried unsuccessfully to reproduce the symptom you are describing.
However, I see from the documentation at
http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html that
the maven javadoc plugin can be influenced to handle assert statements by
the inclusion of
]
[ERROR] BUILD FAILURE
[INFO]
...
kelvin goodson wrote:
Stanislaw,
I have tried unsuccessfully to reproduce the symptom you are
describing.
However, I see from
]
[ERROR] BUILD FAILURE
[INFO]
...
kelvin goodson wrote:
Stanislaw,
I have tried unsuccessfully to reproduce the symptom you are
describing.
However, I see from the documentation at
http
Hi Sam,
have you registered your static classes to make them available to the
DataFactory?
If you are using our M2 download version of SDO then the way to do this is
to call
SDOUtil.registerStaticTypes(XXXFactory.class);
where XXXFactory is the generated class that knows how to create one of
Angel,
this symptom is showing up in a number of places, for different
dependencies, and I don't know what's causing it. I have an inkling from a
comment on the tuscany-dev list (17th Jan, Build failure in tools), that
it is caused by people posting their artefacts to maven repositories
, kelvin goodson [EMAIL PROTECTED] wrote:
Ron,
apologies, I was applying a mistaken assumption, I have written a test
program and verified that neither the createDateTimeFromString of
ModelFactoryImpl nor of XMLTypeFactoryImpl are invoked during XML
deserialization of an element of type
;
tuscany-sdo-impl-1.0-incubator-M2.jar;common-2.2.1.jar;ecore-2.2.1.jar
;e
core-change-2.2.1.jar ;ecore-xmi-2.2.1.jar;xsd-2.2.1.jar;.
sandbox.Deconstructor
/Chr
-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: 26. januar 2007 13:04
To: tuscany-user
I've spent a while updating the SDO Java wiki pages under
http://cwiki.apache.org/confluence/display/TUSCANY/Home. I'd be grateful for
any review/feedback, thanks.
Kelvin.
I'd like to see it done as soon as possible, and I'm working towards
getting a release candidate together in the very short term. There hasn't
been any response to my postings about managing this release or the content
of it. I'm assuming lazy consensus on my proposal of me managing this
-1113?page=com.atlassian.jira.plugin.system
.issuetabpanels:comment-tabpanel%23action_12473251
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: Fri 3/16/2007 9:14 AM
To: tuscany-user@ws.apache.org
Subject: Re: SDO Java M3 Release Candidate RC1
Christian
?URL=https://issues.a
pache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system
.issuetabpanels:comment-tabpanel%23action_12473251
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: Fri 3/16/2007 9:14 AM
To: tuscany-user
Part 2 of Geoff's and my article on What is SDO? has just appeared on the
JDJ website.
http://java.sys-con.com/read/358059.htm (if in an quiet space you might
like to hit your mute button before following the link)
It was a while ago that we put this together, and its taken a bit of a
while
Haleh,
thanks for addressing these issues. One concern I have after a quick look
is that on arriving at a pages such as
http://cwiki.apache.org/TUSCANY/sdo-java.html some of the links on the left
under a given heading go off to a scope that is not intuitive from the page
that you were on.
I think you just need to send a note to tuscany-user-unsubscribe AT
ws.apache.org from the email address you get the notes in doing the obvious
substitution on the AT.
On 03/05/07, Robert Temple [EMAIL PROTECTED] wrote:
I'd like information about how to unsubscribe to the newsletter. I am
not
Unfortunately not, at least not through the SDO API as it stands. I think
this is part of the discussion discussion in the spec group under the XSD
fidelity heading in http://www.xcalia.com/support/browse/SDO-197. However,
I'm pretty sure this could be dug out from the underlying EMF metadata
Daniel,
You can specify the java package with the -javaPackage argument, and the
Factory class name is derived from the prefix, so you can use something
like
-javaPackage a.b -prefix Foo
to create a factory a.b.FooFacotry
Kelvin.
On 10/05/07, Daniel Peter [EMAIL PROTECTED] wrote:
Hi
Bryan,
can you post some details of the errors please. I just did a full
extract, built SDO from the trunk and ran mvn from the top level DAS folder.
I got this, but the build didn't seem to run any tests!
C:\Development\JiraDev\fullJava\dasmvn
[INFO] Scanning for projects...
[INFO] Reactor
Bert,
I think the file at
https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/tools/src/test/resources/subgroup.xsddemonstrates
what you want.
Regards, Kelvin.
On 15/05/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi all,
I've a general question concerning polymorphism and SDO.
Tuscany users,
there's been a some discussion on the SDO Java Community Test Suite over
on the tuscany-dev list. Things such as discussions about a release[1] and
working towards full coverage [2]. There has been a recent update to the
wiki page to show how to run the test suite in Eclipse
On the basis of my recent note, this would have been more appropriate on
the users list ...
-- Forwarded message --
From: kelvin goodson [EMAIL PROTECTED]
Date: 15-May-2007 13:21
Subject: [SDO Java CTS] adopting ContainmentTest
To: tuscany-dev [EMAIL PROTECTED]
I propose
The change seems to have been introduced by commit 536241 as the first part
of a fix for TUSCANY-1197, which was a change to only the tuscany impl
project.
Kelvin.
On 14/05/07, Luciano Resende [EMAIL PROTECTED] wrote:
Thanks for trying this ant, looks like the issue we currently have is the
16th May 2007:
The Apache Tuscany community is pleased to announce its
1.0-incubating-beta1 release
of SDO (Service Data Objects) Java.
You can download binary and source distributions from:
http://people.apache.org/dist/incubator/tuscany/java/sdo/1.0-incubating-beta1/
Maven artifacts for this
I've been working my way through some changes to the Java CTS that I posted
about yesterday, and have now created a new staging point for referencing
tests that people want to propose for adoption into the CTS proper.
Switching this to tuscany-users to solicit user community input.
I think I need some clarification of what it means to ship the samples
with the binary distribution. One of the key things a user is going to
want to do is to modify and rebuild the samples, so how do we make
that easy for them?
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.
Ryan,
there are unsubscribe links from this page
http://cwiki.apache.org/confluence/display/TUSCANY/Mailing+Lists
Sorry to see you go.
Kelvin.
On 21/05/07, Ryan Auclair [EMAIL PROTECTED] wrote:
Hi I don't know if this is the right email but I'd love to unsubscribe
from the apache mailing list.
On 09/05/07, Frank Budinsky [EMAIL PROTECTED] wrote:
Hi SDO developers and users,
snip/
It would be great if
we can put together a first release of the CTS in June along with the 1.0
implementation.
+1 to that. Does anyone want to volunteer to be the release manager for the
CTS?
snip/
David,
to be able to get a ChangeSummary from a DataObject it must either
a) be in a data graph that is contained in an instance of DataGraph
b) be of a Type which has a property of type sdo:ChangeSummaryType
c) be contained, either directly or indirectly by a DataObject which has a
property of
Hi Daniel,
these two libraries provide the stax support required by
org.apache.tuscany.sdo.util.resource.XMLStreamSerializer
which underpins function in the Tuscany specific XMLStreamSerializer API to
allow DataObject's to be read from and written to XML streams. For
example, see
Daniel,
the short answer is yes it can. How? Well, the Java generator code
specifically for generating the classes that represent types can be seen in
[1], but note that it itself is generated from the javajet template at [2]
(a JSP like syntax).
To generate [1] from[2] you need to add a
Hi Chris
I couldn't find an example of this so I had a play and added a new test
case at [1].
Regards, Kelvin.
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/tools/src/test/java/org/apache/tuscany/sdo/test/OpenContentTestCase.java
On 23/05/07, Chris Mildebrandt [EMAIL
Hi Daniel,
could you open a new feature Jira for this please? I have created a
new version tag, SDO-Java-1.0. If you set the fix version to that then it's
clear that there is community interest in getting this into the next
release. You seem to have a good grasp of the code in this area;
Chris,
we seem to have 3 places where prefixes are generated, and not using the
same algorithm.
1) BaseSDOXSDEcoreBuilder.getEPackage()
2) SDOXSDEcoreBuilder.lookupPrefix
3) EMFs BasicExtendedMetadata.computePrefix()
The difference in behaviour here is explained by the fact that when the two
I'm applying a patch attached to [1] to the java generator which allows it
to generate classes for multiple namespaces in a single run. The current fix
is adopting the safe policy of not changing the default behaviour, which
only exports classes for a single namespace.
So as it stands, one new
Mail
Von: kelvin goodson [EMAIL PROTECTED]
An: Tuscany Users tuscany-user@ws.apache.org
Gesendet: Mittwoch, den 30. Mai 2007, 18:23:05 Uhr
Betreff: [SDO Java] behaviour of generator with multiple namespaces
I'm applying a patch attached to [1] to the java generator which allows it
to generate
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
.
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
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.
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.
I made a rather late attempt yesterday to use the regular IRC chat for the
purposes of discussing the SDO release content, which, no surprises, didn't
work out. Is there interest in scheduling a time slot particularly for this
purpose?
This would be an opportunity for SDO Java users and
Ron,
this sounds just the sort of thing I'd like to see beginning to happen,
and I'd like to be involved in doing it too. Currently I'm finding little
time to raise my head above the fundamentals of getting a spec compliant
release out there. But we should be looking outward and thinking about
:
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
else in my setup? I am
trying to get started on Tuscany SDO and would like to help with some JIRA
fixes, content...
Regards,
Amita
On 6/14/07, ant elder [EMAIL PROTECTED] wrote:
On 6/14/07, kelvin goodson [EMAIL PROTECTED] wrote:
On 12/06/07, Frank Budinsky [EMAIL PROTECTED] wrote
For anyone else trying to address this issue and coming across the
apparently unanswered thread, Thomas open two threads with the same
subject. See [1]
Kelvin.
[1] http://www.mail-archive.com/tuscany-user@ws.apache.org/msg01128.html
On 18/06/07, Thomas Kuhn [EMAIL PROTECTED] wrote:
Hi,
I
The JIRA http://issues.apache.org/jira/browse/TUSCANY-1358 was raised
to help one of the community to understand how to load a schema, and
use the Types to generated a modified schema. I'm transferring the
discussion here to the users' list as I don't think this is a bug,
and the rest of the
Hi Tom,
the only generator we have in good shape to generate Tuscany SDO
classes is the XSD to Java generator. I think it would be a
significant new feature to properly support what you are trying to do.
You are correct in your understanding that you must arrange for a
specialised factory to
Following recent discussions on the mailing list I have been updating the
SDO Java sample code and I'd like to solicit some input.
My aims have been
-- to make it an informative exercise to run binary samples without
necessarily directly referencing the source code
-- categorize the samples
I just checked in another sample which I'd be happy to take feedback on --
[1] (output appended as in my previous posts)
I would like to rearrange the packages of the samples, as I think the
current arrangement is not very helpful to someone trying to explore SDO
(specCodeSnippets,
Hi Ron, thanks very much for these. I'm just exploring Erich's question on
Tuscany users list and then your patches are the next thing I plan to look
at.
Regards, Kelvin.
On 02/07/07, Ron Gavlin [EMAIL PROTECTED] wrote:
Hi Kelvin Luciano,
I submitted patches for TUSCANY-1393 TUSCANY-1237
Hi Erich,
I generated code from your schema and tried the following lines of code,
which executed without failure ...
*public* *void* testErichsProblem() *throws* Exception {
PublicationDataGraph pdg =
ServicesFactory.*INSTANCE*.createPublicationDataGraph();
DataObject dob =
Release Candidates?
- Original Message
From: kelvin goodson [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Monday, July 2, 2007 12:37:39 PM
Subject: Re: Patches for TUSCANY-1393 TUSCANY-123
Hi Ron, thanks very much for these. I'm just exploring Erich's question
on
Tuscany users list
The list is archived in about 3 places that I have found, but the one I
find best from a thread view perspective is ...
http://www.mail-archive.com/tuscany-user@ws.apache.org/index.html
Regards, Kelvin.
On 02/07/07, Enric Staromiejski Torregrosa [EMAIL PROTECTED]
wrote:
hi,
I just got
Jeff,
welcome! this is great news. I look forward to understanding your
scenario and working together to ensure SDO does what you need.
Kelvin.
On 03/07/07, Anderson, Jeff T (CA - Toronto) [EMAIL PROTECTED]
wrote:
I am currently architecting a SOA platform for a major Canadian financial
[EMAIL PROTECTED] wrote:
Kelvin,
I think basic may read better than novice, but otherwise this is a
good idea.
Yours, Mike.
kelvin goodson wrote:
I just checked in another sample which I'd be happy to take feedback
on
--
[1] (output appended as in my previous posts)
I would like
There's a sample that shows the two approaches at [1]. This sample has
changed a lot since the beta1 release, so I include the output of the
sample below in case its not so easy for you to build from the trunk.
Kelvin
[1]
I think you have hit the same problem as another user reported today. I
guess your root is embedded in a DataGraph, yes? If so then you have hit
the issue described in https://issues.apache.org/jira/browse/TUSCANY-1421.
Regards, Kelvin.
On 04/07/07, litaojian [EMAIL PROTECTED] wrote:
Hi All
Thanks for looking at this ant ...
snip/
NOTICE file still contains the incubating disclaimer
will fix
RELEASE_NOTES should have a sentence or 2 at the top saying, in a nutshell,
what is SDO. maybe also rather than saying just '...is a superset of
previous release... make it sound a bit
JIRAs fixed before the 1.0 release.
https://issues.apache.org/jira/browse/TUSCANY-1110
https://issues.apache.org/jira/browse/TUSCANY-1436
Thanks,
Raymond
- Original Message -
From: kelvin goodson [EMAIL PROTECTED]
To: Tuscany Users tuscany-user@ws.apache.org
Sent: Tuesday, July 10, 2007
:
Kelvin,
I'm going to take a run at Tuscany-1143. I've started looking into
this issue and hope to have something by middle to end of next week.
Let me know if this will work for your timetable.
Thanks,
David
On 6/26/07, kelvin goodson [EMAIL PROTECTED] wrote:
I'd like to take a quick
You could download the source distro from
http://people.apache.org/~kelvingoodson/sdo_java/1.0-incubating/RC1/
or look in
http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sdo-api/
Regards, Kelvin.
On 16/07/07, Robert Young [EMAIL PROTECTED] wrote:
Hi,
Where can I find the source
Robert,
I replied too fast without absorbing the precise detail of your request,
the true source of the beta1 is available at
http://people.apache.org/~kelvingoodson/sdo_java/beta1/RC1/api/
and the location of the beta1 source in svn is at
either way with the naming; both scan OK to me.
9. Nice detail in the index file. :)
thanks
On 7/16/07, kelvin goodson [EMAIL PROTECTED] wrote:
Raymond,
I'm going to reference your request in thread that is determining
release
contents. I added a comment to 1436. Will you be able
This release is running later than I had hoped due to extra jiras being
added to the plan, and a few issues that have come up after recent fixe, so
we are a bit behind where I'd proposed we should be in terms of getting this
release out. Please help with some of these TODOs if you can. If you
/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
This release is running later than I had hoped due to extra jiras being
added to the plan, and a few issues that have come up after recent fixe, so
we are a bit behind where I'd proposed we should be in terms of getting this
release out. Please help
the change summary aspects of the medical scenario sample
I'm going to tackle 3 now
Kelvin.
On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
I'm going to number off the non jira related tasks so that its easy to
reference them
I just did 1 and now plan to do 4,5,7,8,9
1 the pom has
Oops, I copied 3 across unnecessarily-- it's done. I'm back looking at 12
now.
Kelvin.
On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
11 seemed to be a no-op
13 is done
14 is done
leaving ...
2 use rat results to fix license header issues and post rat results
3 check that all recent
The class is in the sdo-api-r2.1-1.0-incubating-beta1.jar file. I just
re-downloaded the zip file from the website download page
C:\Dev\apache-
tuscany-sdo-1.0-incubating-beta1-bin\tuscany-sdo-1.0-incubating-beta1\libjar
-tvf sdo-api-r2.1-1.0-incubating-beta1.jar
snip/
573 Wed Apr 25
You have a typo in your script, you have an extra .1 in the naming of the
SDO API jar.
Kelvin.
On 18/07/07, Sam Griffith [EMAIL PROTECTED] wrote:
Hello,
I'm new to this, but am porting a preexisting code base that worked with
the M2 release, so have working code to go from.
Anyway, I've
a quick update on my previous response, where I said any path resolves to
zero or one value only, I really meant that it resolves to zero or one
location in the data graph (that location may of course correspond to a
multi-valued property) .
Kelvin.
On 26/07/07, kelvin goodson [EMAIL
The SDO 2.1 spec has left the way open for implementations to provide
alternative, scheme based means of handling path expressions in SDO calls
that operate on paths paths.
From the spec perspective, each path supplied to such a call belongs to a
scheme, the default scheme being sdo. To
The Apache Tuscany team are pleased to announce the 1.0-incubating release
of the Java SDO project.
This project provides an implementation of the SDO 2.1 specification
[1] and this is our first release to provide full coverage of the
specification. In addition to completing the few remaining SDO
Having released 1.0-incubating, what are the priorities for SDO Java now.
I'm just catching up on reading the lists having taken a break. The
major things I had in mind before going away were to
- rearrange the project structure to permit generation of java classes
during maven tests
You need to create a HelperContext that has the extensible namespaces
set to true. so instead of using XMLHelper.INSTANCE you must do
HelperContext scope = SDOUtil.createHelperContext(true);
then use the XSDHelper from
XSDHelper xsdHelper = scope.getXSDHelper()
if you use this instance of
I don't think I can see the reasons for this without seeing the
schemas. Here's a test case that passes for me ...
public void test2SchemasWithSameNamespace() throws Exception
{
HelperContext scope = SDOUtil.createHelperContext(true);
URL url =
Eric,
the missing ModelPackageImpl issue is more than likely related to
old generated java classes that need to be regenerated. The XSD to
Java generator now just produces a Factory interface and
implementation per schema rather than the Factory and Package that it
used to produce.
Hi Johan,
Having looked back at the minimal changes between 1.0 RC2 and the
final release I spotted that you said May 2007, which was the RC2 for
the beta1 release, so if it is these two distros you have been using
then there are a large number of changes between them, see [1]. I'm
not an
Hi Frank,
thanks for drawing this to our attention, I was just looking back
at this. I followed the first link in your note and came to a generic
BoF page. Can you provide any more info on this please? Is there a
title for the BoF? Are you the BoF lead?
Tuscany Community --- Do we have
Umesh,
you have hit the known issue
https://issues.apache.org/jira/browse/TUSCANY-1021. The original
proposition was to implement copying of the ChangeSummary using
serialization/deserialization, but Frank's comment shows that
attempts to do this didn't work out. Is this a blocker for you;
Hi Ron,
Ron, sorry not to get to this earlier. I just took a look at this,
expecting to have to dig quite deep into an area I'm not very familiar
with, but debugging through a test case I spotted an anomaly [1]
which strikes a chord with your description. I'll commit a fix. Can
you let me
Please ignore the 2nd part of my previous note -- It was part of an
earlier composition that I meant to delete.
Kelvin.
On 09/10/2007, kelvin goodson [EMAIL PROTECTED] wrote:
Hi Ron,
Ron, sorry not to get to this earlier. I just took a look at this,
expecting to have to dig quite deep
I'm looking through the mounting number of JIRAs in SDO Java and hope
to knock a few down. It would be good to get another release in plan.
What do people want in it? I'm going to be doing a full pass through
the open JIRAs in the near term and flag up my own priorities.
Regards, Kelvin.
this is (intentionally?) omitted.
Its a small step to some form of JavaBean PropertyChangeSupport.
Maybe anyone has a link to where this might have been discussed?
Thanks
Steffen
On 6/11/07, kelvin goodson [EMAIL PROTECTED] wrote:
Steffen,
there's no provision
Hi,
SDO Itself doesn't have a way to handle this at the moment, but
Tuscany has a method in the SDOHelper interface
public ObjectInputStream createObjectInputStream(InputStream
inputStream, HelperContext helperContext) throws IOException;
that allows you to associate a selected
Hello again,
thanks for your questions. With regards to your first question, I
think it's basically the same answer as I posted earlier today, that
you can create an ObjectInputStream associated with an arbitrary
HelperContext.
However, as an aside, I realised in my earlier response that I
The SDO spec will be addressing standard instance properties that allow
values of facets to be retrieved from types and properties. Until that time
it allows implementations to define their own, adn we do that in Tuscany.
See
Looking at this again, I see I have answered it from the perspective of XSD
generation of types and you are using the dynamic API. You are free to
create open content properties of your own using
TypeHelper.defineOpenContentProperty and use them to annotate your types, so
that you can retrieve
Hi Andrej,
Thanks for your notes. I think from your other thread you are sorted with
regards to this issue now. Is that right?
Regards, Kelvin.
On 31/12/2007, Andrej Koelewijn [EMAIL PROTECTED] wrote:
Hi,
I'm trying to create some test programs with sdo, and one of the tests is
that i
Hi Ron,
the SDO code never touches ConfigurationCache directly, and the EMF
JavaDoc says it is an internal API [1]. I guess this is one to raise with
EMF. A google on ConfigurationCache reveals very little in terms of anyone
having hit this issue before. Are you happy to raise this on the
Ron,
I talked to Ed Merks about this, and here's a summary of what he said.
He was referencing the EMF 2.4 code, but aside from the generics he thought
it was the same as 2.2.3. The key diagnostic would be to see whether calls
to getPrinter() and releasePrinter(XMLString) are made in pairs.
1 - 100 of 128 matches
Mail list logo
