Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)
+1 Frank. Jean-Sebastien Delfino [EMAIL PROTECTED] wrote on 05/12/2008 04:37:21 PM: ant elder wrote: Restarting the graduation vote with the updated proposal words, please vote on the proposal below to graduate Tuscany to a TLP. +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the Service Component Architecture standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: * Adriano Crestani adrianocrestani at apache dot org * ant elder antelder at apache dot org * Brady Johnson bjohnson at apache dot org * Frank Budinsky frankb at apache dot org * Ignacio Silva-Lepe isilval at apache dot org * Jean-Sebastien Delfino jsdelfino at apache dot org * kelvin goodson kelvingoodson at apache dot org * Luciano Resende lresende at apache dot org * Mark Combellack mcombellack at apache dot org * Matthieu Riou mriou at apache dot org * Mike Edwards edwardsmj at apache dot org * Paul Fremantle pzf at apache dot org * Pete Robbins robbinspg at apache dot org * Raymond Feng rfeng at apache dot org * Simon Laws slaws at apache dot org * Simon Nash nash at apache dot org * Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged. +1 from me -- Jean-Sebastien
Re: SDO Date format
Adriano,
All these formats are only allowed for convenience of entry. When a date
is serialized it is converted to the canonical format. Take a look at
class ModelFactoryImpl:
public String convertDateToString(Object instanceValue)
{
if (instanceValue == null)
{
return null;
}
SimpleDateFormat f = new SimpleDateFormat(
-MM-dd'T'HH:mm:ss'.'SSS'Z');
f.setTimeZone(TimeZone.getTimeZone(GMT));
return f.format((Date)instanceValue);
}
Frank.
[EMAIL PROTECTED] wrote on 03/30/2008 03:27:33 AM:
Surfing on net I found this:
Time zones
...
More recent (post 1.5.0) versions of openadaptor use Java TimeZone
objects,
so the string must be understood by that class (either GMT±hh:mm
Europe/London - note that three letter abbreviations such as CST are
frowned
upon, as there are no standards and many ambiguities - is that US
Central
Standard Time or China Standard Time?). If the timezone is not
recognised,
then the JVM local timezone is assumed. or descriptive:
This text is located at the bottom of [1]. Relying on this text, should
SDO
use time zone abbreviations instead of GMT +-HH:mm format?
[1] https://openadaptor.openadaptor.org/pg/dates_times_and_timezones.htm
Adriano Crestani
On Sat, Mar 29, 2008 at 10:39 PM, Adriano Crestani
[EMAIL PROTECTED] wrote:
I have some doubts about if it's acceptable or not, because the Java
SDO
specs defines the following format: -MM-dd'T'HH:mm:ss'.'SSS'Z'
. But
when I look at the testcases, it test many date strings that are not
exactly
in this format:
// Ensure that strings that should be recognized by toDate do not
// result in a null Date value.
public void testToDateFormats() throws Exception
{
String[] validStrings =
{
2006-03-31T03:30:45.123Z,
-2006-03-31T03:30:45.1Z,
2006-03-31T03:30:45Z,
2006-03-31T03:30:45.123,
2006-03-31T03:30:45.1,
-2006-03-31T03:30:45,
2006-03-31T03:30:45.123 EDT,
2006-03-31T03:30:45.1 EDT,
2006-03-31T03:30:45 EDT,
---05 PST,
---04,
--12 GMT,
--12,
--08-08 EST,
--08-08,
1976-08-08 PDT,
1976-08-08,
88-12 CST,
1988-12,
2005 CDT,
1999,
P2006Y 08M 10D T 12H 24M 07S,
P2006Y 10D T 12H,
-P2006Y 08M 10D T 07S.2,
P08M 10D T 07H,
-P 04M 10DT12H 24S.88,
PT12H
};
for (int i = 0; i validStrings.length; i++)
{
assertNotNull(DataHelper.toData() should not return null
for
' + validStrings[i] + '.,
data_helper.toDate(validStrings[i]));
}
}
Am I missing something?
Thanks in advance,
Adriano Crestani
On Sat, Mar 29, 2008 at 5:55 PM, Adriano Crestani
[EMAIL PROTECTED] wrote:
Hi,
What is the time zone format used in datetime SDO string? Only the
time
zone abbreviation, like for example: PST, or it also accepts
GTM, like for
example: GMT -04:00?
Thanks in advance,
Adriano Crestani
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alias Name Support in Tuscany SDO
It's not sufficient just to add a new aliasName to the list. You'd also
need to push the change back down to the EAnnotation, from which the list
contents is derived:
public List getAliasNames(EModelElement modelElement) {
EAnnotation eAnnotation = getAnnotation(modelElement, false);
List list = null;
if (eAnnotation != null) {
String aliasNames = (String)eAnnotation.getDetails().get(
aliasNames);
if (aliasNames != null) {
list = new ArrayList();
StringTokenizer st = new StringTokenizer(aliasNames, );
while (st.hasMoreTokens()) {
String t = st.nextToken();
list.add(t);
}
}
}
return list;
}
Frank.
David Adcox [EMAIL PROTECTED]
03/20/2008 08:22 AM
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Alias Name Support in Tuscany SDO
Currently, alias name support is disabled in SDO, intentionally. The
SDOHelperImpl.addAliasName(Type,String) and
SDOHelperImpl.addAliasName(Property,String) throw an
UnsupportedOperationException when called. Does this function still
need to be disabled? When I remove these guards, my test cases seem
to function properly.
-
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]
Frank Budinsky/Toronto/IBM is out of the office.
I will be out of the office starting 01/26/2008 and will not return until 02/04/2008. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Frank Budinsky/Toronto/IBM is out of the office.
I will be out of the office starting 01/08/2008 and will not return until 01/14/2008. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Type Conversion Unit Test
I think it makes sense for TypeConversionTestCase to test both get and set. The DataHelper.convert() methods also test type conversion, but maybe those would be better to test in a DataHelper test case. Frank. David Adcox [EMAIL PROTECTED] wrote on 12/19/2007 11:13:56 AM: The unit test case org.apache.tuscany.sdo.test.TypeConversionTestCase exercises the get() methods on a DataObject, validating type conversion functions. What is missing from this test, though, is any conversion testing of the set() methods. This test suite uses the set method to seed the primary type, but it doesn't attempt to set the property using an alternative type. I was looking to add the test case I created for Tuscany-1935 and found this test hole. Does it make sense to go ahead and augment TypeConversionTestCase to validate the setX() methods as well? - 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: [SDO] Static SDO Generator problem: elements named internal*
oppositeProperty is in the namespace commonj.sdo/xml, so it should be: xmlns:sdox=commonj.sdo/xml and then: sdox:oppositeProperty=... Frank. Amita Vadhavkar [EMAIL PROTECTED] wrote on 12/11/2007 08:37:52 AM: SDO Spec talks about BiDi support and BiDirectional in EMF is same as Opposite in SDO terms. SDOHelperImpl has implementation for setOpposite() and RDB-DAS relies on it when defining Dynamic DO Properties - using SDOUtil.setOpposite(parentProp, childProp); SDOUtil.setOpposite(childProp, parentProp); I took the dump of DAS formed DO using XSDHelperImpl.generate(Listtypes). As the above DAS code specifically sets the opposites, the XSDHelperImpl dumps the xsd as below:- this can be used for the TUSCANY-1483 to see the effect. I further found that sdo-impl is failing to detect getOpposite() on it (: DasOpposite.xsd --- xs:schema xmlns:sdo=commonj.sdo xmlns:sdoJava=commonj.sdo/java xmlns:stn_1=http:///org.apache.tuscany.das.rdb/das; xmlns:xs=http://www.w3.org/2001/XMLSchema; attributeFormDefault=qualified elementFormDefault=qualified targetNamespace=http:///org.apache.tuscany.das.rdb/das; xs:complexType abstract=false name=ORDERDETAILS xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=orderDetailsDesc sdo:oppositeProperty=orderDetailsDesc_opposite sdo:propertyType=stn_1:ORDERDETAILSDESC type=xs:anyURI/ /xs:sequence xs:attribute name=ORDERID type=xs:int/ xs:attribute name=PRODUCTID type=xs:int/ xs:attribute default=0.0 name=PRICE type=xs:double/ /xs:complexType xs:complexType abstract=false name=ORDERDETAILSDESC xs:sequence xs:element name=orderDetailsDesc_opposite sdo:oppositeProperty=orderDetailsDesc sdo:propertyType=stn_1:ORDERDETAILS type=xs:anyURI/ /xs:sequence xs:attribute name=ID type=xs:int/ xs:attribute name=ORDERID type=xs:int/ xs:attribute name=PRODUCTID type=xs:int/ xs:attribute name=DESCR type=xs:string/ /xs:complexType /xs:schema - And had a small test like - final HelperContext hc = SDOUtil.createHelperContext(); typeHelper = hc.getTypeHelper(); dataFactory = hc.getDataFactory(); xsdHelper = hc.getXSDHelper(); streamHelper = SDOUtil.createXMLStreamHelper(hc); final URL url = getClass().getResource(/DasOpposite.xsd); final InputStream inputStream = url.openStream(); xsdHelper.define(inputStream, url.toString()); inputStream.close(); DataObject dataObjectOrdDet = dataFactory.create( http:///org.apache.tuscany.das.rdb/das;, ORDERDETAILS); DataObject dataObjectOrdDetDesc = dataFactory.create( http:///org.apache.tuscany.das.rdb/das;, ORDERDETAILSDESC); System.out.println(dataObjectOrdDet.getInstanceProperty (orderDetailsDesc).getOpposite()); But seems that this returns null. Anybody any clue why this returns null, when the xsd shows use of sdo:oppositeProperty. Also, will it be useful to add a set/getOpposite() test case to current SDO test cases? Regards, Amita On Dec 10, 2007 9:02 PM, David Adcox [EMAIL PROTECTED] wrote: Amita, If I understand what you are saying, I believe you have found one additional condition related to this issue that will precipitate the problem in T-1483. Right? If so, could you post a sample schema that would demonstrate the problem? I'll take a look at it. On Dec 10, 2007 8:32 AM, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I just tried the patch from https://issues.apache.org/jira/browse/TUSCANY-1483 and it works perfect. There may be just one more case of BiDirectional feature where SDOGenUtil.getQualifiedInternalPropertyID(genFeature) will get called. For this the patch can be modified to include change in this file as well. Suggestions? 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: [SDO] questions about support for Enumeration facet
I think it should be isMany=false but of type commonj.sdo{Strings}. Then
get() or getList() would return ListString. Only getString() would
convert to the space-separated value we're returning today.
Frank.
[EMAIL PROTECTED] wrote on 12/11/2007 06:44:22 AM:
Hi Amita,
thanks for looking at this. I'm a bit surprised, on digging a little
way
in, that the enumeration Property is isMany==false. I'll dig a bit
further, but I had expected to be able to find the Property named
enumeration and get a list of entries.
Kelvin.
On 11/12/2007, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Hi,
I tried TUSCANY-1360 related to enumeration facet. Below is the
summary of
what was
discussed so far and a few questions.
-
1) One way to do this is -
public static ListString getEnumerationFacet(Type type) {
return
ExtendedMetaData.INSTANCE.getEnumerationFacet((EDataType)type);
}
which works very straight forward and gives a list of enums.
-
2) Another way is -
Do type.getInstanceProperties() and find the Property called
enumeration.
Where, getInstanceProperties() calls
DataObjectUtil.getMetaObjectInstanceProperties(EModelElement
metaObject)
in which for the given metaObject its annotations and details of each
annotations are traversed. Each
Annotation Detail is mapped to EStringToStringMapEntryImpl entry like
below
-
EStringToStringMapEntryImpl entry =
(EStringToStringMapEntryImpl)iter.next(); //iter is Iterator over
current
Annotation's Details
String propertyName = entry.getTypedKey();
Property globalProperty = getGlobalProperty(hc, propertyURI,
propertyName);
if (globalProperty != null)
{
result.add(globalProperty);
}
Result is a UniqueEList which is returned at the end.
Here, when entry.getTypedKey() is enumeration, entry.getTypedValue()
gives
a String having space separated enums
e.g. for
simpleType name=ExampleRating
restriction base=string
enumeration value=/
enumeration value=Good/
enumeration value=Bad/
/restriction
/simpleType
it gives, Good Bad
As we see in Property globalProperty = getGlobalProperty(hc,
propertyURI,
propertyName); the TypedKey information is
used when forming Property with name enumeration, but the TypedValue
information is not stored in the Property.
Same thing will be applicable for other facets like MinLenght,
MaxExclusive
--
Questions:
Thus, the question I have is, in case of following 2), what will be
the
way
to preserve the mapping (key-value)
information available about facets from EMF in the formed Property?
And
what
will be better approach for TUSCANY-1360
and as such for any other facets?
Regards,
Amita
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1918) Support for dynamic containment
[ https://issues.apache.org/jira/browse/TUSCANY-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548263 ] Frank Budinsky commented on TUSCANY-1918: - Hi Bert, Yes, please forward your comments to the OASIS list. Also please mention the charter item (10. Relaxing Containment Requirements) that they're related to. Thanks, Frank. Support for dynamic containment --- Key: TUSCANY-1918 URL: https://issues.apache.org/jira/browse/TUSCANY-1918 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: bert.robben In SDO, the boundaries of a datagraph are defined by the containment relation. Only objects which can be reached from the root object by following properties that are contained are part of the datagraph. Containment is defined at the type level. In cases where applications need to dynamically select what information they want, this fixed containment relationship is an issue. For instance, suppose in a medical context you have defined a number of types defines to represent patients together with their clinical (e.g. procedures they have taken) and administrative data (for instance their address). The type definition needs to decide on the containment of the clinical and administrative data. However it is hard to decide whether or not the administrative and clinical data should be contained because some applications might only need clinical or administrative data and others might need both. In cases where the type system is large or where there are large volumes of data involved (for instance in the example, procedures could have an associated pdf-report property) this becomes a real issue. Current solutions within the SDO framework could be (for the interested, there has been a mail thread about this a while ago in the user mailing list) - Each app shoud define its own type with an appropriate containment relation. The downside of this is a proliferation of types. - The main types should not have any containment relations. Containment is specified using a synthetic type. Think of this as a special list type that contains its elements. The root of the datagraph then would be an instance of such a list type. All instances that are needed should be put in this flat list. I would like to propose an alternative solution. In this solution, containment would not be specified at the type level. Whenever the boundary of a datagraph is needed (for instance when an xml document it be generated or a datagraph is to be exchanged between for instance a client and a server), the application should provide appropriate information that specifies exactly what is part of the graph and what not. This can be seen as a select clause for sql, or even better as a set of fetch joins in Hibernate. This would give the application control over exactly what it wants. In the example for instance, the application can easily decide at each point whether or not it would want the address information together with the patient data. This proposal would have a number of interesting implications. - What is the implication of this for cases where datagraphs are represented as xml documents that should be according to an xml schema? - How to deal with links to objects that don't belong to the datagraph? One strategy could be just to drop them. Another one to provide some kind of proxy. Interested parties can have a look at our SDO implementation (see also JIRA 1527 and 1493) where we try to support this. -- 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] Commented: (TUSCANY-1918) Support for dynamic containment
[ https://issues.apache.org/jira/browse/TUSCANY-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547879 ] Frank Budinsky commented on TUSCANY-1918: - Hi Bert, Non-members can monitor the email archives (http://www.oasis-open.org/archives/sdo/) and the document repository (http://www.oasis-open.org/committees/documents.php?wg_abbrev=sdo), and provide comments/feedback via the email list (http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=sdo). Links to all three of these resources are found on the TC Public page at: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdo Frank. Support for dynamic containment --- Key: TUSCANY-1918 URL: https://issues.apache.org/jira/browse/TUSCANY-1918 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: bert.robben In SDO, the boundaries of a datagraph are defined by the containment relation. Only objects which can be reached from the root object by following properties that are contained are part of the datagraph. Containment is defined at the type level. In cases where applications need to dynamically select what information they want, this fixed containment relationship is an issue. For instance, suppose in a medical context you have defined a number of types defines to represent patients together with their clinical (e.g. procedures they have taken) and administrative data (for instance their address). The type definition needs to decide on the containment of the clinical and administrative data. However it is hard to decide whether or not the administrative and clinical data should be contained because some applications might only need clinical or administrative data and others might need both. In cases where the type system is large or where there are large volumes of data involved (for instance in the example, procedures could have an associated pdf-report property) this becomes a real issue. Current solutions within the SDO framework could be (for the interested, there has been a mail thread about this a while ago in the user mailing list) - Each app shoud define its own type with an appropriate containment relation. The downside of this is a proliferation of types. - The main types should not have any containment relations. Containment is specified using a synthetic type. Think of this as a special list type that contains its elements. The root of the datagraph then would be an instance of such a list type. All instances that are needed should be put in this flat list. I would like to propose an alternative solution. In this solution, containment would not be specified at the type level. Whenever the boundary of a datagraph is needed (for instance when an xml document it be generated or a datagraph is to be exchanged between for instance a client and a server), the application should provide appropriate information that specifies exactly what is part of the graph and what not. This can be seen as a select clause for sql, or even better as a set of fetch joins in Hibernate. This would give the application control over exactly what it wants. In the example for instance, the application can easily decide at each point whether or not it would want the address information together with the patient data. This proposal would have a number of interesting implications. - What is the implication of this for cases where datagraphs are represented as xml documents that should be according to an xml schema? - How to deal with links to objects that don't belong to the datagraph? One strategy could be just to drop them. Another one to provide some kind of proxy. Interested parties can have a look at our SDO implementation (see also JIRA 1527 and 1493) where we try to support this. -- 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] Commented: (TUSCANY-1918) Support for dynamic containment
[ https://issues.apache.org/jira/browse/TUSCANY-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545487 ] Frank Budinsky commented on TUSCANY-1918: - Hi Bert, If you want to join the TC and attend the regular telecons, you (or your company) needs to be an OASIS member. We'd love to have you :-) Alternatively, anybody can observe what's going on and provide comments. Details can be found at: http://lists.oasis-open.org/archives/tc-announce/200710/msg00011.html Frank. Support for dynamic containment --- Key: TUSCANY-1918 URL: https://issues.apache.org/jira/browse/TUSCANY-1918 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: bert.robben In SDO, the boundaries of a datagraph are defined by the containment relation. Only objects which can be reached from the root object by following properties that are contained are part of the datagraph. Containment is defined at the type level. In cases where applications need to dynamically select what information they want, this fixed containment relationship is an issue. For instance, suppose in a medical context you have defined a number of types defines to represent patients together with their clinical (e.g. procedures they have taken) and administrative data (for instance their address). The type definition needs to decide on the containment of the clinical and administrative data. However it is hard to decide whether or not the administrative and clinical data should be contained because some applications might only need clinical or administrative data and others might need both. In cases where the type system is large or where there are large volumes of data involved (for instance in the example, procedures could have an associated pdf-report property) this becomes a real issue. Current solutions within the SDO framework could be (for the interested, there has been a mail thread about this a while ago in the user mailing list) - Each app shoud define its own type with an appropriate containment relation. The downside of this is a proliferation of types. - The main types should not have any containment relations. Containment is specified using a synthetic type. Think of this as a special list type that contains its elements. The root of the datagraph then would be an instance of such a list type. All instances that are needed should be put in this flat list. I would like to propose an alternative solution. In this solution, containment would not be specified at the type level. Whenever the boundary of a datagraph is needed (for instance when an xml document it be generated or a datagraph is to be exchanged between for instance a client and a server), the application should provide appropriate information that specifies exactly what is part of the graph and what not. This can be seen as a select clause for sql, or even better as a set of fetch joins in Hibernate. This would give the application control over exactly what it wants. In the example for instance, the application can easily decide at each point whether or not it would want the address information together with the patient data. This proposal would have a number of interesting implications. - What is the implication of this for cases where datagraphs are represented as xml documents that should be according to an xml schema? - How to deal with links to objects that don't belong to the datagraph? One strategy could be just to drop them. Another one to provide some kind of proxy. Interested parties can have a look at our SDO implementation (see also JIRA 1527 and 1493) where we try to support this. -- 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] Commented: (TUSCANY-1918) Support for dynamic containment
[ https://issues.apache.org/jira/browse/TUSCANY-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545037 ] Frank Budinsky commented on TUSCANY-1918: - There is also a related feature in the charter for SDO 3. See item 10 in the Function (V3.0) section: http://www.oasis-open.org/committees/sdo/charter.php Note that SDO 3 TC at OASIS welcomes all interested parties. Support for dynamic containment --- Key: TUSCANY-1918 URL: https://issues.apache.org/jira/browse/TUSCANY-1918 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: bert.robben In SDO, the boundaries of a datagraph are defined by the containment relation. Only objects which can be reached from the root object by following properties that are contained are part of the datagraph. Containment is defined at the type level. In cases where applications need to dynamically select what information they want, this fixed containment relationship is an issue. For instance, suppose in a medical context you have defined a number of types defines to represent patients together with their clinical (e.g. procedures they have taken) and administrative data (for instance their address). The type definition needs to decide on the containment of the clinical and administrative data. However it is hard to decide whether or not the administrative and clinical data should be contained because some applications might only need clinical or administrative data and others might need both. In cases where the type system is large or where there are large volumes of data involved (for instance in the example, procedures could have an associated pdf-report property) this becomes a real issue. Current solutions within the SDO framework could be (for the interested, there has been a mail thread about this a while ago in the user mailing list) - Each app shoud define its own type with an appropriate containment relation. The downside of this is a proliferation of types. - The main types should not have any containment relations. Containment is specified using a synthetic type. Think of this as a special list type that contains its elements. The root of the datagraph then would be an instance of such a list type. All instances that are needed should be put in this flat list. I would like to propose an alternative solution. In this solution, containment would not be specified at the type level. Whenever the boundary of a datagraph is needed (for instance when an xml document it be generated or a datagraph is to be exchanged between for instance a client and a server), the application should provide appropriate information that specifies exactly what is part of the graph and what not. This can be seen as a select clause for sql, or even better as a set of fetch joins in Hibernate. This would give the application control over exactly what it wants. In the example for instance, the application can easily decide at each point whether or not it would want the address information together with the patient data. This proposal would have a number of interesting implications. - What is the implication of this for cases where datagraphs are represented as xml documents that should be according to an xml schema? - How to deal with links to objects that don't belong to the datagraph? One strategy could be just to drop them. Another one to provide some kind of proxy. Interested parties can have a look at our SDO implementation (see also JIRA 1527 and 1493) where we try to support this. -- 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: How to write a simple SDO class for the tutorial?
Hi Sebastien, One thing to note is that the static SDO supported in Tuscany today is an EMF-style pattern that is intended to be the highest performance in-memory static DataObjects. Other less-performant patterns, that use a dynamic (DataObject) proxy, for example, are possible and probably easier achieve without a code generator. There are two features in the SDO 3 charter related to this topic: 1) standard SDO annotations on Java interfaces to define SDO metadata, and 2) unify static SDO with other static bindings like JAXB (this covers POJOs as well). If you want to experiment with some ideas in this area, that would be great. We could use it as input to the SDO 3 discussions when they start. Thanks, Frank. [EMAIL PROTECTED] wrote on 11/19/2007 05:53:25 AM: I missed you last point in my reply. getStaticType() is required to underpin fundamental EMF behaviour. Without it EMF's capacity to know the class of an EObject (which all our DataObjects are derived from) is broken for all static classes, and that would break many SDO behaviours, e.g. serialization, copying, and I'm sure lots more. Kelvin. On 17/11/2007, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: kelvin goodson wrote: If you are discounting using XSD for the source of metadata to describe the SDO types then there is the SDO API provided for dynamic metadata creation. The sample at [1] gives an introduction to this. The paper at [2] discusses the subject also, and the program underlying the discussion in the paper is at [3] (no change monitoring) and [4] (with change monitoring). You say that you want to write the minimum code. There is a quick and simple Tuscany API for simple cases that you could use instead (See the MetaDataBuilder inner class in [5]). Whilst the code to create the type system with this project specific API is simple to understand and implement it has some drawbacks. We don't have a sample program for this, but I believe the DAS uses it) I'm happy to discuss further if you want some more insight into this. Kelvin. [1] http://svn.apache. org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample. java [2] http://java.sys-con.com/read/358059_2.htm [3] http://svn.apache. org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario. java [4] http://svn.apache. org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring. java [5] http://svn.apache. org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper. java Thanks. Follow-up questions: - Is there an SDO Helper that can introspect my handwritten Item Java class and drive the calls to the TypeHelper APIs? If not, can I add one? - I see that I can associate a class with a type, does it have to be an interface or can it be a class? - If it can be a class do I really need a factory class or is the SDO runtime able to instantiate the class? - I see methods like getStaticType on generated SDOs, do I need to implement that method in my handwritten SDO and why? -- Jean-Sebastien - 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: How to write a simple SDO class for the tutorial?
Sebastien,
You're generic implementation is fine as long as TypeHelper.INSTANCE is
the right scope where the type is registered.
If you aren't interested in supporting dynamic subclasses of static
classes, then getStaticType() is always == DataObject.getType(), so you
might not even need to implement getStaticType().
Frank
Jean-Sebastien Delfino [EMAIL PROTECTED]
11/19/2007 11:25 AM
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Re: How to write a simple SDO class for the tutorial?
kelvin goodson wrote:
I missed you last point in my reply. getStaticType() is required to
underpin fundamental EMF behaviour. Without it EMF's capacity to know
the class of an EObject (which all our DataObjects are derived from)
is broken for all static classes, and that would break many SDO
behaviours, e.g. serialization, copying, and I'm sure lots more.
Kelvin.
Assuming that my DataObjects are simple classes without interfaces,
isn't the type already registered with my DataObject's class?
In other words can I implement getStaticType generically as follows:
Type getStaticType() {
TypeHelper.INSTANCE.getType(this.getClass());
}
--
Jean-Sebastien
-
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: [SDO] validations in SDOUtil.createFromString()
SDO doesn't require validation at any particular time, so it's up to the implementation. The primary use of the createFromString() and convertToString() methods is to support XML deserialization and serialization respectively. We don't want to slow down load performance if we don't need to, and since the SDO Month type's instanceClass is java.lang.String, we simply assume it's valid and return the same string in createFromString - see ModelFactoryImpl.createMonthFromString(). Frank Amita Vadhavkar [EMAIL PROTECTED] wrote on 11/06/2007 08:01:49 AM: Object convertedObj = org.apache.tuscany.sdo.util.SDOUtil.createFromString( TypeHelper.INSTANCE.getType(commonj.sdo, Month) , abcd); System.out.println(conv month +convertedObj+, +convertedObj.getClass().getName()); Is the above supposed to throw some sort of exception as abcd is not in following --mm zz? pattern? I tried it and it simply gives abcd String with no exceptions. Trying to understand what is the expected behavior. Regards, Amita - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1780) [JAVA-SDO] Incorrect generation of class with default value for a list
[ https://issues.apache.org/jira/browse/TUSCANY-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537012 ] Frank Budinsky commented on TUSCANY-1780: - I'd suggest replacing this: stringBuffer.append(genFeature.getStaticDefaultValue()); with something like this: stringBuffer.append(SDOGenUtil.getStaticDefaultValue(genFeature)); Then you can implement SDOGenUtil.getStaticDefaultValue() to produce only what is needed for SDO. [JAVA-SDO] Incorrect generation of class with default value for a list -- Key: TUSCANY-1780 URL: https://issues.apache.org/jira/browse/TUSCANY-1780 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-1.0, Java-SDO-Next Environment: Windows XP, JRE 1.4.2 and JRE 1.5 Reporter: Chris Mildebrandt Priority: Critical Fix For: Java-SDO-Next Attachments: Address.xsd, Address2.xsd, SDOClass.java Hello, There seems to be a problem when generating static classes when lists are involved. I have the following lines in my schema: xsd:attribute name=categoryType type=address:CategoryType use=required default=myCat/ simpleType name=CategoryType list itemType=category / /simpleType This generates the following line in the impl class: protected static final Object CATEGORY_TYPE_DEFAULT_ = ((EFactory)ModelFactory.INSTANCE).createFromString(ModelPackageImpl.eINSTANCE.getObject(), myCat); The class ModelPackageImpl doesn't exist. I've tried this with the 1.0 version of SDO and a version I built today. Let me know if you need any more information. Thanks, -Chris -- 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] Commented: (TUSCANY-1853) XSD2JavaGenerator generates Java identifier with dots
[
https://issues.apache.org/jira/browse/TUSCANY-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535581
]
Frank Budinsky commented on TUSCANY-1853:
-
Hi Czarek, This looks familiar, I think we may have fixed it already. Can you
try the latest from trunk and see if you still experience problems. Thanks.
XSD2JavaGenerator generates Java identifier with dots
-
Key: TUSCANY-1853
URL: https://issues.apache.org/jira/browse/TUSCANY-1853
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
Environment: Windows XP, jre 1.5
Reporter: Cezary Tkaczyk
Hello,
While I'm trying to compile generated by XSD2JavaGenerator Java classes, I've
got such an error:
[javac]
C:\projekty\eclipse-workspace-rbpl-sdo-1.0\REB-Catalog-SDO-Java\src-autogen\pl\esb\impl\EsbFactoryImpl.java:169:
';' expected
[javac] pl.esb.blm.adapter.AdapterFactory
pl.esb.blm.adapter.AdapterFactoryInstance =
pl.esb.blm.adapter.AdapterFactory.INSTANCE;
[javac]^
The problem is: variable identifier cannot contain dots.
The place, where this error appears looks like this:
public static EsbFactoryImpl init()
{
if (instance != null ) return instance;
instance = new EsbFactoryImpl();
// Initialize dependent packages
AdapterFactory AdapterFactoryInstance = AdapterFactory.INSTANCE;
RebFactory RebFactoryInstance = RebFactory.INSTANCE;
pl.raiffeisen.esb.blm.adapter.AdapterFactory
pl.raiffeisen.esb.blm.adapter.AdapterFactoryInstance =
pl.raiffeisen.esb.blm.adapter.AdapterFactory.INSTANCE;
// Create package meta-data objects
instance.createMetaData();
// Initialize created meta-data
instance.initializeMetaData();
// Mark meta-data to indicate it can't be changed
//theEsbFactoryImpl.freeze(); //FB do we need to freeze / should we
freeze
return instance;
}
I think the problem is that I have two namespaces of the same suffix:
http://www.esb.pl/blm/adapter
http://www.esb.pl/ods1/adapter
So, generator is trying to avoid the problem creating unique variable name:
pl.esb.blm.adapter.AdapterFactoryInstance
Unfortunately, this is not valid identifier.
Kind Regards,
Czarek
--
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] Commented: (TUSCANY-1842) IOException loading DataGraph containing a deleted dataObject with a property whose type extends a complexType w/simple integer content
[
https://issues.apache.org/jira/browse/TUSCANY-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534410
]
Frank Budinsky commented on TUSCANY-1842:
-
Hi Ron,
It looks like the problem is caused because DataObject.delete() calls unset()
on the special value property of a wrapper type which causes an invalid
instance to be serialized:
objectsToAttach xsi:type=sev:ValueType/
Your hack works around the issue by forcing the loader to accept the invalid
instance.
A better fix would be to prevent DataObject.delete() from calling unset() on
value properties, but there is currently no way to detect that a property is
one of these special wrapper value properties. So, I guess your hack is as good
as any for now, but we need to document the fact that this is a temporary fix.
In the future we need to ensure that unset() is not called - or it has special
behavior - for the value properties.
Frank.
IOException loading DataGraph containing a deleted dataObject with a property
whose type extends a complexType w/simple integer content
---
Key: TUSCANY-1842
URL: https://issues.apache.org/jira/browse/TUSCANY-1842
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Environment: Windows XP, Sun JDK 1.5.0_09
Reporter: Ron Gavlin
Priority: Critical
Fix For: Java-SDO-Next
In the test method, testComplexTypeWithSimpleContentExtensionChangeSummary()
listed below, a DataGraph is created with a dataObject whose property type
extends a complexType with simple integer content. After the dataObject is
deleted, an attempt is made to save and load the DataGraph. While the
DataGraph is being loaded, an unsuccessful attempt is made to convert a
zero-length string into a BigInteger.
Any suggestions on how to best fix this are most welcome.
Thanks,
- Ron
==
substitutionWithExtensionValues.xsd
==
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sev=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sev:ResultsType /
element name=result type=sev:ResultType /
element name=myResult type=sev:MyResultType
substitutionGroup=sev:result /
complexType name=ResultsType
sequence
element name=id type=sev:IdType /
element ref=sev:result minOccurs=0
maxOccurs=unbounded /
element name=comment type=sev:CommentType /
/sequence
/complexType
complexType name=ResultType
sequence
element name=id type=sev:IdType /
element name=name type=string /
element name=value type=sev:ValueType /
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sev:ResultType /
/complexContent
/complexType
simpleType name=IdType
restriction base=sev:AsciiStringType
maxLength value=32 /
pattern value=[0-9a-fA-F]* /
/restriction
/simpleType
simpleType name=AsciiStringType
restriction base=string
pattern value=\p{IsBasicLatin}* /
/restriction
/simpleType
complexType name=ValueType
simpleContent
extension base=sev:Integer32Bit
[jira] Commented: (TUSCANY-1832) Complex type w/simple content restriction facets are ignored
[ https://issues.apache.org/jira/browse/TUSCANY-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533748 ] Frank Budinsky commented on TUSCANY-1832: - Hi Ron, What you're doing here is really very EMF specific. Even the fact that there is a second type, _MyCommentType, is an EMF detail. None of that is defined in the SDO spec. All the SDO spec requires is that the type of the value property is something capable of holding the value, so AsciiStringType is as good as anything from the spec perspective. The problem is caused by the fact that EMF validation relies on the constraints being associated with an EDataType - that's why EMF defines the special _MyCommentType type with the constraints. Unfortunately, this corner case of a complexType with simple content restricing another completType with simple content is broken because of EMF limitiations described above and by Ed. So, to answer your question, I think SDO, not just Tuscany, should handle this, but I'm not sure there's a good quick fix. I think the SDO spec needs to specify this (e.g., how are simple content constraints represented in a complex type with a value property). My guess is that the correct answer is that they should appear as instanceProperties on the actual type MyCommentType. Maybe that's something we could try to implement in Tuscany ahead of time, but I'm not sure if it's easily doable - and since SDO 2.1 hasn't defined standard properties for constraints yet, it would still be Tuscany specific. How important is it that you have access to these constraints? The alternative is to simply get them by reading the XSD directly. Complex type w/simple content restriction facets are ignored Key: TUSCANY-1832 URL: https://issues.apache.org/jira/browse/TUSCANY-1832 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: Ron Gavlin Namespace http://www.example.com/substitutionEV; includes two complex type with simple content named CommentType and MyCommentType. MyCommentType restricts CommentType with facet maxLength=40. This maxLength facet does not appear to exist in the SDO metadata. The sample test case named testComplexTypeWithSimpleContentExtension() is included below. == substitutionWithExtensionValues.xsd == schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.example.com/substitutionEV; xmlns:sev=http://www.example.com/substitutionEV; !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- element name=results type=sev:ResultsType / element name=result type=sev:ResultType / element name=myResult type=sev:MyResultType substitutionGroup=sev:result / complexType name=ResultsType sequence element name=id type=sev:IdType / element ref=sev:result minOccurs=0 maxOccurs=unbounded / element name=comment type=sev:CommentType / /sequence /complexType complexType name=ResultType sequence element name=id type=sev:IdType / element name=name type=string / element name=value type=sev:CommentType / /sequence /complexType complexType name=MyResultType complexContent extension base=sev:ResultType / /complexContent /complexType simpleType name=IdType restriction base=sev:AsciiStringType maxLength value=32 / pattern value=[0-9a-fA-F]* / /restriction /simpleType
Re: [VOTE] Graduate Tuscany as a top level project
+1 Jean-Sebastien Delfino [EMAIL PROTECTED] wrote on 10/09/2007 10:15:47 AM: +1 from me ant elder wrote: Looks like we've closed all the discussions around this so we can now vote on it. We've an Incubator discussion thread on our graduation but I don't see why we can't let that run in parallel, so ... Please vote on graduating Tuscany as a top level project and the proposal below. Heres my +1. ...ant WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software that simplifies the development and deployment of service oriented applications and provides a managed service-oriented runtime based on the standards defined by the OASIS OpenCSA group, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: Adriano Crestaniadrianocrestani at apache dot org Andrew Borley ajborley at apache dot org Andy Grove agrove at apache dot org ant elder antelder at apache dot org Brady Johnson bjohnson at apache dot org Frank Budinsky frankb at apache dot org Ignacio Silva-Lepe isilval at apache dot org Jean-Sebastien Delfino jsdelfino at apache dot org kelvin goodson kelvingoodson at apache dot org Luciano Resende lresende at apache dot org Mike Edwards edwardsmj at apache dot org Pete Robbinsrobbinspg at apache dot org Raymond Feng rfeng at apache dot org Simon Laws slaws at apache dot org Simon Nash nash at apache dot org Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged. -- Jean-Sebastien - 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]
[jira] Commented: (TUSCANY-1832) Complex type w/simple content restriction facets are ignored
[
https://issues.apache.org/jira/browse/TUSCANY-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533378
]
Frank Budinsky commented on TUSCANY-1832:
-
Hi Ron,
So, if we remove the EMF validation from the test listed above, is it
reasonable to expect the test to work?
Yes, other than the validator not complaining about invalid instances, it
should work. Doesn't it?
How tough would it be to implement this support in Tuscany SDO? Thoughts?
What support do you mean? Validation of constraints on subtypes of complex
types? If so, then I think it would be very difficult to get it working using
the existing EMF-based validator. But, it SDO 3, there are plans to provide
complete XSD metadata, so at that point I could imagine a proper XSD based
validator implementation that would be able to check the constraints that the
EMF-based model can not.
Complex type w/simple content restriction facets are ignored
Key: TUSCANY-1832
URL: https://issues.apache.org/jira/browse/TUSCANY-1832
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Namespace http://www.example.com/substitutionEV; includes two complex type
with simple content named CommentType and MyCommentType. MyCommentType
restricts CommentType with facet maxLength=40. This maxLength facet does
not appear to exist in the SDO metadata. The sample test case named
testComplexTypeWithSimpleContentExtension() is included below.
==
substitutionWithExtensionValues.xsd
==
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sev=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sev:ResultsType /
element name=result type=sev:ResultType /
element name=myResult type=sev:MyResultType
substitutionGroup=sev:result /
complexType name=ResultsType
sequence
element name=id type=sev:IdType /
element ref=sev:result minOccurs=0
maxOccurs=unbounded /
element name=comment type=sev:CommentType /
/sequence
/complexType
complexType name=ResultType
sequence
element name=id type=sev:IdType /
element name=name type=string /
element name=value type=sev:CommentType /
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sev:ResultType /
/complexContent
/complexType
simpleType name=IdType
restriction base=sev:AsciiStringType
maxLength value=32 /
pattern value=[0-9a-fA-F]* /
/restriction
/simpleType
simpleType name=AsciiStringType
restriction base=string
pattern value=\p{IsBasicLatin}* /
/restriction
/simpleType
complexType name=CommentType
simpleContent
extension base=sev:AsciiStringType
attribute name=language use=optional
simpleType
restriction base=string
enumeration
value=English /
enumeration
value=French /
enumeration
value=Spanish
Re: [Java SDO CTS] enhancing the CTS
Hi Kelvin, Getting the CTS structured in a way that better reflects exactly what APIs are being tested sounds like a great idea to me. I also like the idea of stub tests so that anybody, with a little time to spare, can easily write/contribute a missing test. Frank. kelvin goodson [EMAIL PROTECTED] wrote on 10/05/2007 07:12:26 AM: I've been thinking about the CTS a bit lately; trying to take stock of what we've got, and how we measure up. The CTS went through a period of healthy growth a while back, but I didn't manage to get a good feel for how well we were covering the API combined with the range of possible inputs to it. I ran the maven clover plugin to try to get some idea of how well we cover the API, but the results show coverage for the implementation classes, and it's not easy to get a good picture for how good the coverage of SDO API interface from that data (For example, there's much code in the Tuscany SDO implementation to support generated code which of course doesn't get exercised by the CTS). Does anyone know of good techniques for getting pure API coverage data? It would be good to get some structure into the CTS to make it more evident in the test code what is covered, and what is not. I'm thinking about perhaps restructuring and adding to the tests to achieve this. I may end up just adding stub tests in the first place in some places to highlight the fact that we are deficient in that area. 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]
[jira] Commented: (TUSCANY-1832) Complex type w/simple content restriction facets are ignored
[
https://issues.apache.org/jira/browse/TUSCANY-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532704
]
Frank Budinsky commented on TUSCANY-1832:
-
Hi Ron,
Your change will break the behavior that the SDO spec requires - the name of an
anonymous type should be the name of its enclosing element . For your case, we
have complex type with a nested anonymous simple type. So I think what you
probably want is something like this:
protected String getAliasName(XSDNamedComponent xsdNamedComponent) {
String result = xsdNamedComponent.getName();
if (result == null)
{
XSDConcreteComponent container = xsdNamedComponent.getContainer();
if (container instanceof XSDNamedComponent)
{
result = getAliasName((XSDNamedComponent)container);
if (container instanceof XSDTypeDefinition)
{
result = _ + result;
}
}
}
return result;
}
I hope that doesn't break anything else though.
One thing to notice about the EMF fix, is that it will now create a datatype
with the constraint metadata, but because the value feature is not using the
new datatype, the validator will still not check those constraints.
Complex type w/simple content restriction facets are ignored
Key: TUSCANY-1832
URL: https://issues.apache.org/jira/browse/TUSCANY-1832
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Namespace http://www.example.com/substitutionEV; includes two complex type
with simple content named CommentType and MyCommentType. MyCommentType
restricts CommentType with facet maxLength=40. This maxLength facet does
not appear to exist in the SDO metadata. The sample test case named
testComplexTypeWithSimpleContentExtension() is included below.
==
substitutionWithExtensionValues.xsd
==
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sev=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sev:ResultsType /
element name=result type=sev:ResultType /
element name=myResult type=sev:MyResultType
substitutionGroup=sev:result /
complexType name=ResultsType
sequence
element name=id type=sev:IdType /
element ref=sev:result minOccurs=0
maxOccurs=unbounded /
element name=comment type=sev:CommentType /
/sequence
/complexType
complexType name=ResultType
sequence
element name=id type=sev:IdType /
element name=name type=string /
element name=value type=sev:CommentType /
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sev:ResultType /
/complexContent
/complexType
simpleType name=IdType
restriction base=sev:AsciiStringType
maxLength value=32 /
pattern value=[0-9a-fA-F]* /
/restriction
/simpleType
simpleType name=AsciiStringType
restriction base=string
pattern value=\p{IsBasicLatin}* /
/restriction
/simpleType
complexType name=CommentType
simpleContent
extension base=sev:AsciiStringType
attribute name=language use=optional
simpleType
[jira] Commented: (TUSCANY-1832) Complex type w/simple content restriction facets are ignored
[
https://issues.apache.org/jira/browse/TUSCANY-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532762
]
Frank Budinsky commented on TUSCANY-1832:
-
Hi Ron,
It looks like you've run into an EMF limitation that can't be fixed easily, if
at all. The problem is that constraints imposed by a complex type with simple
content which extends another complex type with simple content will not be
validated. The problem is because the base type (CommentType) defines the
value property and the subtype (MyCommentType) can't override it. It's an EMF
limitation similar to the pre Java 5 limitation that said if a class defines a
method to return some base type, for example:
class Foo {
Base getFoo() { ... }
}
then you can't override the method in a subclass to return a sub type:
class Bar extends Foo {
Sub getFoo() { ... }
}
That's the analogous problem to the one EMF has with properties.
So, unless you run an actual XML validator, or merge the constraints into the
base type, you're not going to be able to validate them.
Complex type w/simple content restriction facets are ignored
Key: TUSCANY-1832
URL: https://issues.apache.org/jira/browse/TUSCANY-1832
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Namespace http://www.example.com/substitutionEV; includes two complex type
with simple content named CommentType and MyCommentType. MyCommentType
restricts CommentType with facet maxLength=40. This maxLength facet does
not appear to exist in the SDO metadata. The sample test case named
testComplexTypeWithSimpleContentExtension() is included below.
==
substitutionWithExtensionValues.xsd
==
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sev=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sev:ResultsType /
element name=result type=sev:ResultType /
element name=myResult type=sev:MyResultType
substitutionGroup=sev:result /
complexType name=ResultsType
sequence
element name=id type=sev:IdType /
element ref=sev:result minOccurs=0
maxOccurs=unbounded /
element name=comment type=sev:CommentType /
/sequence
/complexType
complexType name=ResultType
sequence
element name=id type=sev:IdType /
element name=name type=string /
element name=value type=sev:CommentType /
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sev:ResultType /
/complexContent
/complexType
simpleType name=IdType
restriction base=sev:AsciiStringType
maxLength value=32 /
pattern value=[0-9a-fA-F]* /
/restriction
/simpleType
simpleType name=AsciiStringType
restriction base=string
pattern value=\p{IsBasicLatin}* /
/restriction
/simpleType
complexType name=CommentType
simpleContent
extension base=sev:AsciiStringType
attribute name=language use=optional
simpleType
restriction base=string
enumeration
value=English
[jira] Commented: (TUSCANY-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension
[
https://issues.apache.org/jira/browse/TUSCANY-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531572
]
Frank Budinsky commented on TUSCANY-1812:
-
I think the last suggestion sounds like the simplest sollution. Eagerly
precache the holders for static packages. We can do it right away when we
register a static package. Maybe we could do it in
SDOExtendedMetaDataImpl.putPackage() which is called by the Factory.register()
method. We could simply add code to walk through the package and call
ExtnededMetaData.getName() on all the classifiers and structural features.
XMLHelper.load() IOException using schema that has both a substitution group
and an extension
-
Key: TUSCANY-1812
URL: https://issues.apache.org/jira/browse/TUSCANY-1812
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
Below, please find a failing Java test case and its XSD and XML test
resources. Also, please find the stacktrace from the failing Java test case.
It is interesting to note that this test does not fail when using dynamic
SDO. Please comment if you have questions.
- Ron
package org.apache.tuscany.sdo.test;
import java.io.IOException;
import junit.framework.TestCase;
import com.example.substitution.ev.SEVFactory;
import commonj.sdo.DataObject;
import commonj.sdo.helper.HelperContext;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.impl.HelperProvider;
public final class SubstitutionWithExtensionValuesTestCase extends TestCase {
public void test() throws IOException {
HelperContext hc = HelperProvider.getDefaultContext();
SEVFactory.INSTANCE.register(hc);
XMLHelper xmlHelper = hc.getXMLHelper();
DataObject loadedObject =
xmlHelper.load(getClass().getResourceAsStream(/substitutionWithExtensionValues1.xml)).getRootObject();
}
}
substitutionWithExtensionValues.xsd
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sv=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sv:ResultsType/
element name=result type=sv:ResultType/
element name=myResult type=sv:MyResultType
substitutionGroup=sv:result/
complexType name=ResultsType
sequence
element ref=sv:result minOccurs=0 maxOccurs=unbounded/
element name=comment type=string/
/sequence
/complexType
complexType name=ResultType
sequence
element name=name type=string/
element name=value type=string/
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sv:ResultType/
/complexContent
/complexType
/schema
substitutionWithExtensionValues1.xml
?xml version=1.0 encoding=ASCII?
sev:results xmlns:sev=http://www.example.com/substitutionEV;
sev:result
sev:namename1/sev:name
sev:valuevalue1/sev:value
/sev:result
sev:myResult
sev:namemyName1/sev:name
sev:valuemyValue1/sev:value
/sev:myResult
sev:commentcomment1/sev:comment
/sev:results
STACKTRACE
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'myResult' not found. (http:///temp.xml, 7, 17)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:278)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java
[jira] Commented: (TUSCANY-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension
[
https://issues.apache.org/jira/browse/TUSCANY-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531630
]
Frank Budinsky commented on TUSCANY-1812:
-
Hi Ron,
I think that with Ed's suggestion we don't want to use the
extendedMetaDataHolderCache. That is, you should not include my earlier
suggested fix. Ed's approach is to force the objects themselves to compute and
cache their own extendedMetaData. Then it doesn't matter what ExtendedMetaData
instance is used to access it.
Frank.
XMLHelper.load() IOException using schema that has both a substitution group
and an extension
-
Key: TUSCANY-1812
URL: https://issues.apache.org/jira/browse/TUSCANY-1812
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
Below, please find a failing Java test case and its XSD and XML test
resources. Also, please find the stacktrace from the failing Java test case.
It is interesting to note that this test does not fail when using dynamic
SDO. Please comment if you have questions.
- Ron
package org.apache.tuscany.sdo.test;
import java.io.IOException;
import junit.framework.TestCase;
import com.example.substitution.ev.SEVFactory;
import commonj.sdo.DataObject;
import commonj.sdo.helper.HelperContext;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.impl.HelperProvider;
public final class SubstitutionWithExtensionValuesTestCase extends TestCase {
public void test() throws IOException {
HelperContext hc = HelperProvider.getDefaultContext();
SEVFactory.INSTANCE.register(hc);
XMLHelper xmlHelper = hc.getXMLHelper();
DataObject loadedObject =
xmlHelper.load(getClass().getResourceAsStream(/substitutionWithExtensionValues1.xml)).getRootObject();
}
}
substitutionWithExtensionValues.xsd
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sv=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sv:ResultsType/
element name=result type=sv:ResultType/
element name=myResult type=sv:MyResultType
substitutionGroup=sv:result/
complexType name=ResultsType
sequence
element ref=sv:result minOccurs=0 maxOccurs=unbounded/
element name=comment type=string/
/sequence
/complexType
complexType name=ResultType
sequence
element name=name type=string/
element name=value type=string/
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sv:ResultType/
/complexContent
/complexType
/schema
substitutionWithExtensionValues1.xml
?xml version=1.0 encoding=ASCII?
sev:results xmlns:sev=http://www.example.com/substitutionEV;
sev:result
sev:namename1/sev:name
sev:valuevalue1/sev:value
/sev:result
sev:myResult
sev:namemyName1/sev:name
sev:valuemyValue1/sev:value
/sev:myResult
sev:commentcomment1/sev:comment
/sev:results
STACKTRACE
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'myResult' not found. (http:///temp.xml, 7, 17)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:278)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:97
[jira] Commented: (TUSCANY-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension
[
https://issues.apache.org/jira/browse/TUSCANY-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531632
]
Frank Budinsky commented on TUSCANY-1812:
-
Oops, I just noticed one more thing. You shouldn't be calling
ExtendedMetaData.INSTANCE.getName() in putPackage() but rather this.getName().
Frank.
XMLHelper.load() IOException using schema that has both a substitution group
and an extension
-
Key: TUSCANY-1812
URL: https://issues.apache.org/jira/browse/TUSCANY-1812
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
Below, please find a failing Java test case and its XSD and XML test
resources. Also, please find the stacktrace from the failing Java test case.
It is interesting to note that this test does not fail when using dynamic
SDO. Please comment if you have questions.
- Ron
package org.apache.tuscany.sdo.test;
import java.io.IOException;
import junit.framework.TestCase;
import com.example.substitution.ev.SEVFactory;
import commonj.sdo.DataObject;
import commonj.sdo.helper.HelperContext;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.impl.HelperProvider;
public final class SubstitutionWithExtensionValuesTestCase extends TestCase {
public void test() throws IOException {
HelperContext hc = HelperProvider.getDefaultContext();
SEVFactory.INSTANCE.register(hc);
XMLHelper xmlHelper = hc.getXMLHelper();
DataObject loadedObject =
xmlHelper.load(getClass().getResourceAsStream(/substitutionWithExtensionValues1.xml)).getRootObject();
}
}
substitutionWithExtensionValues.xsd
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sv=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sv:ResultsType/
element name=result type=sv:ResultType/
element name=myResult type=sv:MyResultType
substitutionGroup=sv:result/
complexType name=ResultsType
sequence
element ref=sv:result minOccurs=0 maxOccurs=unbounded/
element name=comment type=string/
/sequence
/complexType
complexType name=ResultType
sequence
element name=name type=string/
element name=value type=string/
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sv:ResultType/
/complexContent
/complexType
/schema
substitutionWithExtensionValues1.xml
?xml version=1.0 encoding=ASCII?
sev:results xmlns:sev=http://www.example.com/substitutionEV;
sev:result
sev:namename1/sev:name
sev:valuevalue1/sev:value
/sev:result
sev:myResult
sev:namemyName1/sev:name
sev:valuemyValue1/sev:value
/sev:myResult
sev:commentcomment1/sev:comment
/sev:results
STACKTRACE
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'myResult' not found. (http:///temp.xml, 7, 17)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:278)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:97)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:79)
at
org.apache.tuscany.sdo.test.SubstitutionWithExtensionValuesTestCase.test
[jira] Commented: (TUSCANY-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension
[
https://issues.apache.org/jira/browse/TUSCANY-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531242
]
Frank Budinsky commented on TUSCANY-1812:
-
Hi Ron,
Your suggestion sounds reasonable if there's no cleaner way to handle it. This
is probably another good question to ask on the EMF newsgroup. Ed Merks often
has clever ideas for things like this.
Frank.
XMLHelper.load() IOException using schema that has both a substitution group
and an extension
-
Key: TUSCANY-1812
URL: https://issues.apache.org/jira/browse/TUSCANY-1812
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
Below, please find a failing Java test case and its XSD and XML test
resources. Also, please find the stacktrace from the failing Java test case.
It is interesting to note that this test does not fail when using dynamic
SDO. Please comment if you have questions.
- Ron
package org.apache.tuscany.sdo.test;
import java.io.IOException;
import junit.framework.TestCase;
import com.example.substitution.ev.SEVFactory;
import commonj.sdo.DataObject;
import commonj.sdo.helper.HelperContext;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.impl.HelperProvider;
public final class SubstitutionWithExtensionValuesTestCase extends TestCase {
public void test() throws IOException {
HelperContext hc = HelperProvider.getDefaultContext();
SEVFactory.INSTANCE.register(hc);
XMLHelper xmlHelper = hc.getXMLHelper();
DataObject loadedObject =
xmlHelper.load(getClass().getResourceAsStream(/substitutionWithExtensionValues1.xml)).getRootObject();
}
}
substitutionWithExtensionValues.xsd
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sv=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sv:ResultsType/
element name=result type=sv:ResultType/
element name=myResult type=sv:MyResultType
substitutionGroup=sv:result/
complexType name=ResultsType
sequence
element ref=sv:result minOccurs=0 maxOccurs=unbounded/
element name=comment type=string/
/sequence
/complexType
complexType name=ResultType
sequence
element name=name type=string/
element name=value type=string/
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sv:ResultType/
/complexContent
/complexType
/schema
substitutionWithExtensionValues1.xml
?xml version=1.0 encoding=ASCII?
sev:results xmlns:sev=http://www.example.com/substitutionEV;
sev:result
sev:namename1/sev:name
sev:valuevalue1/sev:value
/sev:result
sev:myResult
sev:namemyName1/sev:name
sev:valuemyValue1/sev:value
/sev:myResult
sev:commentcomment1/sev:comment
/sev:results
STACKTRACE
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'myResult' not found. (http:///temp.xml, 7, 17)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:278)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:97)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:79
[jira] Commented: (TUSCANY-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension
[
https://issues.apache.org/jira/browse/TUSCANY-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531024
]
Frank Budinsky commented on TUSCANY-1812:
-
Ron, I'm not sure of the answer to your question. Asking it on the EMF
newsgroup should probably get you a quick answer.
XMLHelper.load() IOException using schema that has both a substitution group
and an extension
-
Key: TUSCANY-1812
URL: https://issues.apache.org/jira/browse/TUSCANY-1812
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
Below, please find a failing Java test case and its XSD and XML test
resources. Also, please find the stacktrace from the failing Java test case.
It is interesting to note that this test does not fail when using dynamic
SDO. Please comment if you have questions.
- Ron
package org.apache.tuscany.sdo.test;
import java.io.IOException;
import junit.framework.TestCase;
import com.example.substitution.ev.SEVFactory;
import commonj.sdo.DataObject;
import commonj.sdo.helper.HelperContext;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.impl.HelperProvider;
public final class SubstitutionWithExtensionValuesTestCase extends TestCase {
public void test() throws IOException {
HelperContext hc = HelperProvider.getDefaultContext();
SEVFactory.INSTANCE.register(hc);
XMLHelper xmlHelper = hc.getXMLHelper();
DataObject loadedObject =
xmlHelper.load(getClass().getResourceAsStream(/substitutionWithExtensionValues1.xml)).getRootObject();
}
}
substitutionWithExtensionValues.xsd
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sv=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sv:ResultsType/
element name=result type=sv:ResultType/
element name=myResult type=sv:MyResultType
substitutionGroup=sv:result/
complexType name=ResultsType
sequence
element ref=sv:result minOccurs=0 maxOccurs=unbounded/
element name=comment type=string/
/sequence
/complexType
complexType name=ResultType
sequence
element name=name type=string/
element name=value type=string/
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sv:ResultType/
/complexContent
/complexType
/schema
substitutionWithExtensionValues1.xml
?xml version=1.0 encoding=ASCII?
sev:results xmlns:sev=http://www.example.com/substitutionEV;
sev:result
sev:namename1/sev:name
sev:valuevalue1/sev:value
/sev:result
sev:myResult
sev:namemyName1/sev:name
sev:valuemyValue1/sev:value
/sev:myResult
sev:commentcomment1/sev:comment
/sev:results
STACKTRACE
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'myResult' not found. (http:///temp.xml, 7, 17)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:278)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:97)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:79)
at
org.apache.tuscany.sdo.test.SubstitutionWithExtensionValuesTestCase.test(SubstitutionWithExtensionValuesTestCase.java:40
[jira] Commented: (TUSCANY-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension
[
https://issues.apache.org/jira/browse/TUSCANY-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530795
]
Frank Budinsky commented on TUSCANY-1812:
-
Hi Ron, I'll try to look at it this afternoon, and append my thoughts later
today.
XMLHelper.load() IOException using schema that has both a substitution group
and an extension
-
Key: TUSCANY-1812
URL: https://issues.apache.org/jira/browse/TUSCANY-1812
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
Below, please find a failing Java test case and its XSD and XML test
resources. Also, please find the stacktrace from the failing Java test case.
It is interesting to note that this test does not fail when using dynamic
SDO. Please comment if you have questions.
- Ron
package org.apache.tuscany.sdo.test;
import java.io.IOException;
import junit.framework.TestCase;
import com.example.substitution.ev.SEVFactory;
import commonj.sdo.DataObject;
import commonj.sdo.helper.HelperContext;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.impl.HelperProvider;
public final class SubstitutionWithExtensionValuesTestCase extends TestCase {
public void test() throws IOException {
HelperContext hc = HelperProvider.getDefaultContext();
SEVFactory.INSTANCE.register(hc);
XMLHelper xmlHelper = hc.getXMLHelper();
DataObject loadedObject =
xmlHelper.load(getClass().getResourceAsStream(/substitutionWithExtensionValues1.xml)).getRootObject();
}
}
substitutionWithExtensionValues.xsd
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sv=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sv:ResultsType/
element name=result type=sv:ResultType/
element name=myResult type=sv:MyResultType
substitutionGroup=sv:result/
complexType name=ResultsType
sequence
element ref=sv:result minOccurs=0 maxOccurs=unbounded/
element name=comment type=string/
/sequence
/complexType
complexType name=ResultType
sequence
element name=name type=string/
element name=value type=string/
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sv:ResultType/
/complexContent
/complexType
/schema
substitutionWithExtensionValues1.xml
?xml version=1.0 encoding=ASCII?
sev:results xmlns:sev=http://www.example.com/substitutionEV;
sev:result
sev:namename1/sev:name
sev:valuevalue1/sev:value
/sev:result
sev:myResult
sev:namemyName1/sev:name
sev:valuemyValue1/sev:value
/sev:myResult
sev:commentcomment1/sev:comment
/sev:results
STACKTRACE
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'myResult' not found. (http:///temp.xml, 7, 17)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:278)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:97)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:79)
at
org.apache.tuscany.sdo.test.SubstitutionWithExtensionValuesTestCase.test(SubstitutionWithExtensionValuesTestCase.java:40
[jira] Commented: (TUSCANY-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension
[
https://issues.apache.org/jira/browse/TUSCANY-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530883
]
Frank Budinsky commented on TUSCANY-1812:
-
Hi Ron,
Well this certainly looks like a nasty oversight from the recent change we made
to decouple SDO from the EMF global registry.
I was experimenting with another approach to fix it using an
extendedMetaDataHolderCache, which avoids going directly to the objects.
I added this constant in SDOXSDEcoreBuilderImpl:
public static String SDO_ANNOTATION_URI =
http:///org/apache/tuscany/sdo/helper/SDOExtendedMetaData;;
and then changed the constructor to call a 2 argument base constructor like
this:
public SDOExtendedMetaDataImpl(Registry registry) {
super(SDO_ANNOTATION_URI, registry);
ecoreFactory = new SDOEcoreFactory();
demandMetaData = new SDODemandMetaData();
}
I also needed to change the ANNOTATION_SOURCE constant in FactoryBase:
//private static final String ANNOTATION_SOURCE =
http:///org/eclipse/emf/ecore/util/ExtendedMetaData;;
private static final String ANNOTATION_SOURCE =
SDOExtendedMetaDataImpl.SDO_ANNOTATION_URI;
With these changes, it seemed to fix the getAffiliation() problem, but it still
has a problem with the validator.
Unfortunately, I don't have any more time to look at it right now. If you want
to take it further, that would be great. Also, I'm not opposed to the approach
you suggested, if that works out better. Maybe a combiniation of the two would
be best.
Thanks,
Frank.
XMLHelper.load() IOException using schema that has both a substitution group
and an extension
-
Key: TUSCANY-1812
URL: https://issues.apache.org/jira/browse/TUSCANY-1812
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
Below, please find a failing Java test case and its XSD and XML test
resources. Also, please find the stacktrace from the failing Java test case.
It is interesting to note that this test does not fail when using dynamic
SDO. Please comment if you have questions.
- Ron
package org.apache.tuscany.sdo.test;
import java.io.IOException;
import junit.framework.TestCase;
import com.example.substitution.ev.SEVFactory;
import commonj.sdo.DataObject;
import commonj.sdo.helper.HelperContext;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.impl.HelperProvider;
public final class SubstitutionWithExtensionValuesTestCase extends TestCase {
public void test() throws IOException {
HelperContext hc = HelperProvider.getDefaultContext();
SEVFactory.INSTANCE.register(hc);
XMLHelper xmlHelper = hc.getXMLHelper();
DataObject loadedObject =
xmlHelper.load(getClass().getResourceAsStream(/substitutionWithExtensionValues1.xml)).getRootObject();
}
}
substitutionWithExtensionValues.xsd
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.com/substitutionEV;
xmlns:sv=http://www.example.com/substitutionEV;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sv:ResultsType/
element name=result type=sv:ResultType/
element name=myResult type=sv:MyResultType
substitutionGroup=sv:result/
complexType name=ResultsType
sequence
element ref=sv:result minOccurs=0 maxOccurs=unbounded/
element name=comment type=string/
/sequence
/complexType
complexType name=ResultType
sequence
element name=name type=string/
element name=value type=string/
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sv:ResultType/
/complexContent
/complexType
/schema
substitutionWithExtensionValues1.xml
?xml version=1.0 encoding=ASCII?
sev:results xmlns:sev=http://www.example.com/substitutionEV;
sev:result
sev:namename1/sev:name
sev:valuevalue1
[jira] Commented: (TUSCANY-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension
[
https://issues.apache.org/jira/browse/TUSCANY-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530551
]
Frank Budinsky commented on TUSCANY-1812:
-
Hi Ron, It looks like your myResult element is missing the substitutionGroup
attribute:
element name=myResult type=sv:MyResultType
substitutionGroup=sv:result/
XMLHelper.load() IOException using schema that has both a substitution group
and an extension
-
Key: TUSCANY-1812
URL: https://issues.apache.org/jira/browse/TUSCANY-1812
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
Below, please find a failing Java test case and its XSD and XML test
resources. Also, please find the stacktrace from the failing Java test case.
Please comment if you have questions.
- Ron
package org.apache.tuscany.sdo.test;
import java.io.IOException;
import java.net.URL;
import junit.framework.TestCase;
import commonj.sdo.DataObject;
import commonj.sdo.helper.HelperContext;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.helper.XSDHelper;
import commonj.sdo.impl.HelperProvider;
public final class SubstitutionWithExtensionValuesTestCase extends TestCase
{
public void test() throws IOException
{
HelperContext hc = HelperProvider.getDefaultContext();
URL url = getClass().getResource(/SubstitutionWithExtensionValues.xsd);
XSDHelper xsdHelper = hc.getXSDHelper();
xsdHelper.define(url.openStream(), url.toString());
XMLHelper xmlHelper = hc.getXMLHelper();
DataObject loadedObject =
xmlHelper.load(getClass().getResourceAsStream(/substitutionWithExtensionValues.xml)).getRootObject();
}
}
SubstitutionWithExtensionValues.xsd
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.apache.org/tuscany/SubstitutionWithExtensionValues;
xmlns:sv=http://www.apache.org/tuscany/SubstitutionWithExtensionValues;
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
element name=results type=sv:ResultsType/
element name=result type=sv:ResultType/
element name=myResult type=sv:MyResultType/
complexType name=ResultsType
sequence
element ref=sv:result minOccurs=0 maxOccurs=unbounded/
element name=comment type=string/
/sequence
/complexType
complexType name=ResultType
sequence
element name=name type=string/
element name=value type=string/
/sequence
/complexType
complexType name=MyResultType
complexContent
extension base=sv:ResultType/
/complexContent
/complexType
/schema
SubstitutionWithExtensionValues.xml
?xml version=1.0 encoding=ASCII?
sv:results
xmlns:sv=http://www.apache.org/tuscany/SubstitutionWithExtensionValues;
sv:result
sv:namename1/sv:name
sv:valuevalue1/sv:value
/sv:result
sv:myResult
sv:namemyName1/sv:name
sv:valuemyValue1/sv:value
/sv:myResult
sv:commentcomment1/sv:comment
/sv:results
STACKTRACE
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'myResult' not found. (http:///temp.xml, 7, 16)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:278)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266)
at
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:97)
at
org.apache.tuscany.sdo.helper.XMLHelperImpl.load
[jira] Commented: (TUSCANY-1811) ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:float
[
https://issues.apache.org/jira/browse/TUSCANY-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530554
]
Frank Budinsky commented on TUSCANY-1811:
-
Is the general problem that we need a notify() method in DataObjectBase for
every Java primitive type - boolean, byte, char, double, float, int, long,
short? Jjust like ENotificationImpl has a constructor for each of them?
ClassCastException saving codegen-based DataGraph with ChangeSummary
containing an xsd:float
Key: TUSCANY-1811
URL: https://issues.apache.org/jira/browse/TUSCANY-1811
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Reporter: Ron Gavlin
This problem is similar to TUSCANY-1393 except the schema type in this case
is an xsd:float instead of an xsd:int. The fix involves adding the following
lines to DataObjectBase.java. If you would like me to submit a patch with a
revised testcase, let me know.
LINES TO BE ADDED to DataObjectBase.java:
protected void notify(int changeKind, int property, float oldFloatValue,
float newFloatValue)
{
eNotify(new ENotificationImpl(this, Notification.SET, property,
oldFloatValue, newFloatValue));
}
protected void notify(int changeKind, int property, float oldFloatValue,
float newFloatValue, boolean isSetChange)
{
eNotify(new ENotificationImpl(this, Notification.SET, property,
oldFloatValue, newFloatValue, isSetChange));
}
END OF LINES TO BE ADDED
- Ron
P.S., below I have included the stacktrace for the problem.
java.lang.ClassCastException: java.lang.Double
at
org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertFloatToString(ModelFactoryImpl.java:2036)
at
org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertToString(ModelFactoryImpl.java:318)
at
org.apache.tuscany.sdo.impl.FactoryBase$SDOEFactoryImpl.convertToString(FactoryBase.java:291)
at
org.eclipse.emf.ecore.util.EcoreUtil.convertToString(EcoreUtil.java:2994)
at
org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.getDataValue(FeatureChangeImpl.java:228)
at
org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.eIsSet(FeatureChangeImpl.java:771)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:818)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1107)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
at
org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:620)
at
org.apache.tuscany.sdo.util.DataGraphResourceFactoryImpl$DataGraphResourceImpl$SaveImpl.traverse(DataGraphResourceFactoryImpl.java:382)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:993)
at
org.apache.tuscany.sdo.helper.SDOHelperImpl.saveDataGraph(SDOHelperImpl.java:182)
at org.apache.tuscany.sdo.api.SDOUtil.saveDataGraph(SDOUtil.java:158)
at
org.apache.tuscany.sdo.test.ChangeSummaryGenTestCase.testChangeSummaryOnDataGraphWithIntAndFloat(ChangeSummaryGenTestCase.java:128)
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:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106
[jira] Updated: (TUSCANY-1780) [JAVA-SDO] Incorrect generation of class with default value for a list
[ https://issues.apache.org/jira/browse/TUSCANY-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky updated TUSCANY-1780: Attachment: Address2.xsd The Address.xsd schema has a few errors. I'm attaching Address2.xsd, which is a valid schema illustrating the problem. [JAVA-SDO] Incorrect generation of class with default value for a list -- Key: TUSCANY-1780 URL: https://issues.apache.org/jira/browse/TUSCANY-1780 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-1.0, Java-SDO-Next Environment: Windows XP, JRE 1.4.2 and JRE 1.5 Reporter: Chris Mildebrandt Priority: Critical Attachments: Address.xsd, Address2.xsd Hello, There seems to be a problem when generating static classes when lists are involved. I have the following lines in my schema: xsd:attribute name=categoryType type=address:CategoryType use=required default=myCat/ simpleType name=CategoryType list itemType=category / /simpleType This generates the following line in the impl class: protected static final Object CATEGORY_TYPE_DEFAULT_ = ((EFactory)ModelFactory.INSTANCE).createFromString(ModelPackageImpl.eINSTANCE.getObject(), myCat); The class ModelPackageImpl doesn't exist. I've tried this with the 1.0 version of SDO and a version I built today. Let me know if you need any more information. Thanks, -Chris -- 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] Commented: (TUSCANY-1780) [JAVA-SDO] Incorrect generation of class with default value for a list
[ https://issues.apache.org/jira/browse/TUSCANY-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530562 ] Frank Budinsky commented on TUSCANY-1780: - This seems to be a part of the Class.javajet template that was overlooked when we changed to generate the new noEMF pattern. The template needs to be changed to generate the following: protected static final List CATEGORY_TYPE_DEFAULT_ = (List)((AddressFactoryImpl)AddressFactory.INSTANCE).createCategoryTypeFromString(myCat); instead of what it's currently generating: protected static final List CATEGORY_TYPE_DEFAULT_ = (List)((EFactory)AddressFactory.INSTANCE).createFromString(AddressPackageImpl.eINSTANCE.getCategoryType(), myCat); A temporary workagound is to change it by hand after generating. [JAVA-SDO] Incorrect generation of class with default value for a list -- Key: TUSCANY-1780 URL: https://issues.apache.org/jira/browse/TUSCANY-1780 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-1.0, Java-SDO-Next Environment: Windows XP, JRE 1.4.2 and JRE 1.5 Reporter: Chris Mildebrandt Priority: Critical Attachments: Address.xsd, Address2.xsd Hello, There seems to be a problem when generating static classes when lists are involved. I have the following lines in my schema: xsd:attribute name=categoryType type=address:CategoryType use=required default=myCat/ simpleType name=CategoryType list itemType=category / /simpleType This generates the following line in the impl class: protected static final Object CATEGORY_TYPE_DEFAULT_ = ((EFactory)ModelFactory.INSTANCE).createFromString(ModelPackageImpl.eINSTANCE.getObject(), myCat); The class ModelPackageImpl doesn't exist. I've tried this with the 1.0 version of SDO and a version I built today. Let me know if you need any more information. Thanks, -Chris -- 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]
Frank Budinsky/Toronto/IBM is out of the office.
I will be out of the office starting 09/18/2007 and will not return until 09/24/2007. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1505) Naming scheme used for variables in code gen factory init() method breaks under specific circumstances
[
https://issues.apache.org/jira/browse/TUSCANY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526536
]
Frank Budinsky commented on TUSCANY-1505:
-
The way the register method is using a boolean to guard against cycles is no
good:
private boolean registered = false;
public void register(HelperContext scope)
{
if( registered ) return; else registered = true;
if(scope == null) {
throw new IllegalArgumentException(Scope can not be null);
}
//Register dependent packages with provided scope
ModelFactory.INSTANCE.register(scope);
tuscany.jira.test1505.base.base.BaseFactory.INSTANCE.register(scope);
// Initialize this package
TypeHelperImpl th = (TypeHelperImpl)scope.getTypeHelper();
th.getExtendedMetaData().putPackage(NAMESPACE_URI, this);
}
The problem is that it needs to check if the model is already registered in the
given scope, but this is checking if it's been registered in any scope.
Here is how I suggest the method should be generated:
public void register(HelperContext scope)
{
if (scope == null) throw new IllegalArgumentException(Scope can not be
null);
TypeHelperImpl th = (TypeHelperImpl)scope.getTypeHelper();
if (th.getExtendedMetaData().getPackage(NAMESPACE_URI) != null) return;
th.getExtendedMetaData().putPackage(NAMESPACE_URI, this);
//Register dependent packages with provided scope
ModelFactory.INSTANCE.register(scope);
tuscany.jira.test1505.base.base.BaseFactory.INSTANCE.register(scope);
}
Naming scheme used for variables in code gen factory init() method breaks
under specific circumstances
--
Key: TUSCANY-1505
URL: https://issues.apache.org/jira/browse/TUSCANY-1505
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
Environment: n/a
Reporter: David T. Adcox
Priority: Minor
Fix For: Java-SDO-Next
Attachments: 1505.patch, test1505.zip
A new code gen pattern was recently added to change how dependent packages
are initialized in the xxxFactoryImpl.init() method. Under this new pattern,
all dependent packages are initialized via the factoryInterface.INSTANCE
method. An initialization call is made for each dependent gen package. The
getImportedFactoryInterfaceName() is used to retrieve the short name. This
value is mashed with the text 'Instnace' to form a variable name. If
circumstances dictate that multiple packages contain the same factory
interface name, the getImportedFactoryInterfaceName() will fully qualify the
response instead of using the short name. This breaks the generated code,
due to the use of a '.' in the variable name.
--
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: Current XQuery implementation issues
Hi Vasil, SDO could try to deduce the element to use, but in the general case it may not be a trivial thing to figure out. For example, what if you had two elements: xsd:element name=priceQuote1 type=pri:PriceQuote/ xsd:element name=priceQuote2 type=pri:PriceQuote/ Which one should it use? Also, when deducing the namespace, there may be priceQuote elements in more than one schema, or even if there is only one, it might be in a different schema (namespace) then the object type. Another possibility is that there may be an element, but the type is not PriceQuote, but instead some base class (e.g., BaseQuote). SDO has taken the approach of never guessing on this. If we wanted to add support to deduce the property, we would need to document very clearly what it deduces and when it doesn't. The most I personally think might be worthwhile is to deduce the element if the name is given and it is in the same schema as the type. Frank. Vasil Vasilev [EMAIL PROTECTED] wrote on 09/06/2007 04:38:00 PM: Hi, I tried to give a namespace in SDO object serialization. The reult was satisfactory: with null namespace parameter: priceQuote xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:pri= http://www.example.org/price; xsi:type=pri:PriceQuote customerNameAcme Inc/customerName ... with non-null namespace parameter: pri:priceQuote xmlns:pri=http://www.example.org/price; customerNameAcme Inc/customerName ... However, I think that the serializer should be able to deduce the right namespace (it is available in the factory) if the argument is null. One more thing: the serializer should be able to deduce the correct root element name if null is given as parameter to the serialization. It can deduce it from the schema, where I have written the root element: xsd:element name=priceQuote type=pri:PriceQuote/ Then during generation of the SDO types this element name can be preserved (for example in the factory), the same way as the namespace and the prefix are preserved and later it can be used in the serialization. What do you think about this? Bye, Vasil Оригинално писмо От: Raymond Feng [EMAIL PROTECTED] Относно: Re: Current XQuery implementation issues До: tuscany-dev@ws.apache.org Изпратено на: Вторник, 2007, Август 28 01:02:53 EEST -- Hi, Please see my comments inline. Thanks, Raymond - Original Message - From: Vasil Vasilev [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, August 27, 2007 1:17 PM Subject: Re: Current XQuery implementation issues Hi all, First some update of the Saxon related issues: You can see TUSCANY-1536 for information what I have changed. Could someone apply the changes in the repository? I'll apply the patch. Thank you for the contribution. When I applied the changes I found the following problems: 1. When serializing DataObject to stream using the following code: XMLHelper.save(DataObject, null, rootElementName, OutputStream); No prefices are attached to the serialized xml elements. This issomething that is introduced recently, because previously the behavior is was different - each element was prefixed with the right prefix. Did you try to use a non-null namespace? 2. If you open the xqueryquotewsclient.composite file you will see that I set xml properties to the QuoteJoinPropertiesComponent. If you note you will see that I have described each element and each attribute of the xml with a prefix. For example: pri:priceQuote xmlns:pri=http://www.example.org/price; pri:customerNameAcme Inc/pri:customerName pri:shipAddress pri:street=12 Springs Rd pri:city=Morris Plains pri:state=nj pri:zip=07960 / This style corresponds to the XSD attributeFormDefault=qualified. However if I omit the prefices of the attributes: pri:priceQuote xmlns:pri=http://www.example.org/price; pri:customerNameAcme Inc/pri:customerName pri:shipAddress street=12 Springs Rd city=Morris Plains state=nj zip=07960 / This style corresponds to the XSD attributeFormDefault=unqualified which is the default. An exception is thrown during initialiation of the SCA domain: org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.SCADomain. createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain. newInstance(SCADomain.java:69) at xquery.quote.XQueryQuoteClientTestCase. startClient(XQueryQuoteClientTestCase.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl. invoke(NativeMethodAccessorImpl.java:39) at
Re:CopyHelper.copy() fails to copy schema extensions
You need to first run the code generator (e.g., org.apache.tuscany.generate.XSD2JavaGenerator -javaPackage org.example.person Person.xsd) to generate them from the XML Schema. Frank. Christina Christina [EMAIL PROTECTED] wrote on 08/24/2007 03:18:15 AM: In the Tuscany-1565, there are two package are imported: import org.example.person.PersonFactory; import org.example.person.PersonType; but where can i find them? I am trying to reproduce the project, I can't find the source file of org.example.person.PersonFactory and org.example.person.PersonType. Thanks in advance :) Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1565) CopyHelper.copy() fails to copy schema extensions
[
https://issues.apache.org/jira/browse/TUSCANY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1565.
-
Resolution: Invalid
Hi Chris,
This is working as expected. This line:
person2.getList(addressProperty).add(address);
is adding to person2 the same address object from person1. Since it's a
contained DataObject, SDO removes the object from it's old container (person1).
See the last paragraph of section 3.1.6 in the spec
(http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1).
The exception you were seeing sounds like a generated code compatibility issue.
Make sure you regenerate the classes with the version of SDO that you will run
them with. If you do that and still see the problem (in the latest from HEAD -
bug may have been fixed) please reopen the JIRA for it.
Thanks,
Frank.
CopyHelper.copy() fails to copy schema extensions
-
Key: TUSCANY-1565
URL: https://issues.apache.org/jira/browse/TUSCANY-1565
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Environment: Win XP, IBM JRE 1.4.2 IBM JRE 1.5.0
Reporter: Chris Mildebrandt
Attachments: Address.xsd, CopyTest.java, Person.xsd
Hello,
I've been seeing some weird behavior with the copy implementation. I have two
schemas, one with the following line:
xsd:any namespace=##other processContents=lax minOccurs=0
maxOccurs=unbounded/
I'm inserting the second schema into the first as a part of this extension.
When I run the CopyHelper.INSTANCE.copy() method against it, weird things
start to happen.
The first case:
Both schema files are defined dynamically. The data objects are created and
one is added to the other. That looks like this:
HelperContext context = HelperProvider.getDefaultContext();
{
InputStream in = new File(Person.xsd).toURL().openStream();
context.getXSDHelper().define(in, null);
}
{
InputStream in = new File(Address.xsd).toURL().openStream();
context.getXSDHelper().define(in, null);
}
DataObject person1 =
context.getDataFactory().create(http://www.example.org/Person;,
PersonType);
DataObject address =
context.getDataFactory().create(http://www.example.org/Address;,
AddressType);
person1.set(Age, 30);
person1.set(Name, Jim);
address.set(Street, 123 Fake St.);
address.set(City, Springfield);
address.set(Zip, 46392);
Property addressProperty =
context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;,
Address, true);
(person1).getList(addressProperty).add(address);
DataObject person2 = CopyHelper.INSTANCE.copy(person1);
person2.getList(addressProperty).clear();
person2.getList(addressProperty).add(address);
When I save the data objects to files, the person1 data object doesn't
contain the address data object, but person2 does. When I remove the last
line that adds the address to person2, then the person1 data object correctly
contains the address data object. I would think the person1 data object
shouldn't be affected by changes to the person2 (copy of person1) data object.
The second case:
Static classes are generated for the first schema, the second is defined
dynamically. Data objects are created for both, and the second is added to
the first. That looks like this:
HelperContext context = HelperProvider.getDefaultContext();
PersonFactory.INSTANCE.register(context);
PersonType person1 = PersonFactory.INSTANCE.createPersonType();
person1.setAge(30);
person1.setName(Jim);
InputStream in = new File(Address.xsd).toURL().openStream();
context.getXSDHelper().define(in, null);
DataObject address =
context.getDataFactory().create(http://www.example.org/Address;,
AddressType);
address.set(Street, 123 Fake St.);
address.set(City, Springfield);
address.set(Zip, 46392);
Property addressProperty =
context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;,
Address, true);
((DataObject) person1).getList(addressProperty).add(address);
PersonType person2 = (PersonType)
CopyHelper.INSTANCE.copy((DataObject) person1);
((DataObject) person2).getList(addressProperty).clear();
((DataObject) person2).getList(addressProperty).add(address);
When I run with this, I get the following exception:
Exception in thread main java.lang.ArrayIndexOutOfBoundsException: Array
index out of range: -2
[jira] Resolved: (TUSCANY-1565) CopyHelper.copy() fails to copy schema extensions
[
https://issues.apache.org/jira/browse/TUSCANY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1565.
-
Resolution: Cannot Reproduce
I tried it with the latest from HEAD, and there was no exception. I guess it's
a bug in the 1.0 release that has since been fixed.
CopyHelper.copy() fails to copy schema extensions
-
Key: TUSCANY-1565
URL: https://issues.apache.org/jira/browse/TUSCANY-1565
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Environment: Win XP, IBM JRE 1.4.2 IBM JRE 1.5.0
Reporter: Chris Mildebrandt
Attachments: Address.xsd, CopyTest.java, Person.xsd
Hello,
I've been seeing some weird behavior with the copy implementation. I have two
schemas, one with the following line:
xsd:any namespace=##other processContents=lax minOccurs=0
maxOccurs=unbounded/
I'm inserting the second schema into the first as a part of this extension.
When I run the CopyHelper.INSTANCE.copy() method against it, weird things
start to happen.
The first case:
Both schema files are defined dynamically. The data objects are created and
one is added to the other. That looks like this:
HelperContext context = HelperProvider.getDefaultContext();
{
InputStream in = new File(Person.xsd).toURL().openStream();
context.getXSDHelper().define(in, null);
}
{
InputStream in = new File(Address.xsd).toURL().openStream();
context.getXSDHelper().define(in, null);
}
DataObject person1 =
context.getDataFactory().create(http://www.example.org/Person;,
PersonType);
DataObject address =
context.getDataFactory().create(http://www.example.org/Address;,
AddressType);
person1.set(Age, 30);
person1.set(Name, Jim);
address.set(Street, 123 Fake St.);
address.set(City, Springfield);
address.set(Zip, 46392);
Property addressProperty =
context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;,
Address, true);
(person1).getList(addressProperty).add(address);
DataObject person2 = CopyHelper.INSTANCE.copy(person1);
person2.getList(addressProperty).clear();
person2.getList(addressProperty).add(address);
When I save the data objects to files, the person1 data object doesn't
contain the address data object, but person2 does. When I remove the last
line that adds the address to person2, then the person1 data object correctly
contains the address data object. I would think the person1 data object
shouldn't be affected by changes to the person2 (copy of person1) data object.
The second case:
Static classes are generated for the first schema, the second is defined
dynamically. Data objects are created for both, and the second is added to
the first. That looks like this:
HelperContext context = HelperProvider.getDefaultContext();
PersonFactory.INSTANCE.register(context);
PersonType person1 = PersonFactory.INSTANCE.createPersonType();
person1.setAge(30);
person1.setName(Jim);
InputStream in = new File(Address.xsd).toURL().openStream();
context.getXSDHelper().define(in, null);
DataObject address =
context.getDataFactory().create(http://www.example.org/Address;,
AddressType);
address.set(Street, 123 Fake St.);
address.set(City, Springfield);
address.set(Zip, 46392);
Property addressProperty =
context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;,
Address, true);
((DataObject) person1).getList(addressProperty).add(address);
PersonType person2 = (PersonType)
CopyHelper.INSTANCE.copy((DataObject) person1);
((DataObject) person2).getList(addressProperty).clear();
((DataObject) person2).getList(addressProperty).add(address);
When I run with this, I get the following exception:
Exception in thread main java.lang.ArrayIndexOutOfBoundsException: Array
index out of range: -2
at
org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.dynamicGet(ExtensibleDataObjectImpl.java:128)
at
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicInverseRemove(EStructuralFeatureImpl.java:1687)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicInverseRemove(BasicEObjectImpl.java:1038)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseRemove(BasicEObjectImpl.java:1027)
at
org.apache.tuscany.sdo.impl.DataObjectBase.inverseRemove(DataObjectBase.java:307)
at
org.example.person.impl.PersonTypeImpl.inverseRemove
[jira] Reopened: (TUSCANY-1540) Abstract Static Base Types mixed with Dynamic Extended Types
[ https://issues.apache.org/jira/browse/TUSCANY-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky reopened TUSCANY-1540: - Reopening this issue until the test case is added. Murtaza, thanks for providing the patch. Abstract Static Base Types mixed with Dynamic Extended Types Key: TUSCANY-1540 URL: https://issues.apache.org/jira/browse/TUSCANY-1540 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Reporter: Murtaza Goga Fix For: Java-SDO-Next Attachments: TUSCANY-1540-TestCases.patch Setting a property on a static data object with an object of a type extended in a dynamic model results in a ClassCastException. Scenario: Static schema- xsd:complexType name=CustomerType xsd:all xsd:element name=number type=xsd:integer / xsd:element form=unqualified name=info type=InfoType / /xsd:all /xsd:complexType xsd:complexType name=InfoType abstract=true/ Dynamic Schema xsd:complexType name=InfoType xsd:complexContent xsd:extension base=staticNS:InfoType xsd:sequence xsd:element name=zipcode type=xsd:string / /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType The following will fail: DataFactory factory = scope.getDataFactory(); factory.create(CustomerType.class).setDataObject(info, factory.create(dynamicNS, InfoType)); It should be legal to assign a property to an object if they are in the same hierachy. Steps to reproduce within Tuscany: Testcase org.apache.tuscany.sdo.test.ExtensibleTestCase will break if 'InfoType' defined in extensible/customer.xsd is marked as abstract. -- 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: [jira] Created: (TUSCANY-1527) Allow for custom data binding of DataObjects in a Swing UI
Hi Bert,
Sorry about the delay in getting to this. I've been on vacation, and the
other two SDO committers are now on vacation. I'll try to take a look at
your code this week and provide my initial thoughts. If anybody else has
any thoughts on this issue, please feel free to reply.
Thanks,
Frank.
bert.robben (JIRA) tuscany-dev@ws.apache.org wrote on 08/10/2007
10:43:42 AM:
Allow for custom data binding of DataObjects in a Swing UI
--
Key: TUSCANY-1527
URL: https://issues.apache.org/jira/browse/TUSCANY-1527
Project: Tuscany
Issue Type: New Feature
Reporter: bert.robben
We're developing 3-tier applications with a swing client, JBoss app
server and a couple of databases in the back-end. On the client side
we use sdo objects as model objects for our UI. As such, we need a
mechanism for binding our objects to the UI controls such that
changes in the objects are reflected in the UI and vice versa.
At the moment, there is no real standard for data binding and many
different implementations exist. As such, it would not be a good
idea to build support for this directly into the sdo core. Ideally,
the sdo core would allow implementations supporting data binding to
be added as extensions [an extension as in jar, module, bundle,
component, ...]. This is a request for supporting this in Tuscany SDO.
-
For our applications, we developed our own implementation of the sdo
specification. This implementation is designed to support that kind
of extensions. In the rest of this description, I'd like to show
more details on our implementation to make this more clear and to
serve as food for a possible discussion.
Our sdo core module defines the abstract class
AbstractPartialDataObject implementing DataObject. This class
(together with its superclasses) implements the majority of the
bevahiour of DataObject. This includes bi-directional property
updates, type-safe properties, containment, ... It doesn't implement
however the basic access to property values.
Here's a code fragment.
public abstract class AbstractPartialDataObject extends
AbstractDataObject implements PartialDataObject {
protected abstract Object basicGet(Property property);
protected abstract void basicSet(Property property, Object value);
public Object get(Property property) { ... }
public void set(Property property, Object value) { ... }
...
}
The sdo core module also provides a non-abstract class
DataObjectImplementation that provides a simple implementation of
this abstract behaviour where the property values are stored in an
ArrayList.
On top of that we defined an extension that deals with our UI
requirements. Our UI is based on a proprietary UI framework. This
framework has the following requirements:
- single valued properties should be exposed as XObservables. An
XObservable is a kind of ValueModel that provides access to a value
(get/set) and also allows for registration of change listeners
- multi valued properties should be exposed as ListModel instances.
A ListModel is a proprietary class (a bit similar to the javax.
swing.ListModel) that provides List functionality and also allows
for change listeners
- the data object itself should allow registration of attribute
change listeners that are notified each time a property changes
The extension implements these requirements by providing an
appropriate subclass ObservableDataObject of
AbstractPartialDataObject. The only other pieces of code needed in
the extension is an appropriate implementation of DataFactory and a
wrapper to deal with the differences between ListModel and List.
Here's the class with the most important code snippets.
public class ObservableDataObject extends CompositePartialDataObject
implements {
private XObservable[] properties;
protected ObservableDataObject(com.agfa.hap.sdo.Type type) {
super(type);
this.properties = new XObservable[type.getProperties().size()];
for (int i = 0; i properties.length; i++) {
initializeProperty(type.getProperty(i));
}
}
private XObservableObject initializeProperty(Property prop) {
XObservableObject observable = XObservableFactory.
create(prop.getType().getInstanceClass(), this);
if (prop.isMany()) {
observable.init(new DataObjectListModel(this, prop));
}
properties[prop.getIndex()] = observable;
return observable;
}
public XObservable getObservable(commonj.sdo.Property property) {
XObservable result = properties[property.getIndex()];
return result;
}
public ListModel getListModel(Property property) {
return (ListModel) getObservable(property).get();
}
public ListModel
[jira] Updated: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
[ https://issues.apache.org/jira/browse/TUSCANY-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky updated TUSCANY-1541: Component/s: (was: Java SDO Implementation) Java SCA Problem Determination Seems to be an SCA transformation problem. XMLStreamException in when calling XMLHelper.load() with a large XML Key: TUSCANY-1541 URL: https://issues.apache.org/jira/browse/TUSCANY-1541 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Affects Versions: Java-SDO-Next Environment: Tomcat Reporter: Sunny Ip Priority: Critical Fix For: Java-SDO-Next When XMLHelper.load() is called with a very long XML string, OMStAXWrapper throws an XMLStreamException. I get this problem when I'm receiving a WS response with an SDO object containing a collection of records, leading to a TransformationException when databinding. -- 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] Resolved: (TUSCANY-1528) ClassCastException thrown when trying to deserializing an XML with undefined global element
[ https://issues.apache.org/jira/browse/TUSCANY-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1528. - Resolution: Fixed Committed revision 567056. Fuhwei's patch broke some of the CTS tests which I also fixed against this JIRA. The tests were not expecting a DocumentRoot Type to be included in the list returned from XSDHelper.define(). Those tests should not have been making any assumptions about DocumentRoot anyway, since it's implentation dependent. ClassCastException thrown when trying to deserializing an XML with undefined global element --- Key: TUSCANY-1528 URL: https://issues.apache.org/jira/browse/TUSCANY-1528 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Fix For: Java-SDO-Next Attachments: 1528-testcase.patch, 1528.patch Using simple.xsd, I can serialize and deserialize an XML with a undefined global element. If I removed the global element definition from the simple.xsd, a ClassCastException will be thrown. It seems without the global element definition's presence some required step was not done. Here is the stack trace and test case. junit.framework.AssertionFailedError: java.lang.ClassCastException: org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl incompatible with commonj.sdo.DataObject at junit.framework.Assert.fail(Assert.java:47) at org.apache.tuscany.sdo.test.XMLHelperTestCase.testDemandCreateRootObject(XMLHelperTestCase.java:248) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- 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] Commented: (TUSCANY-1498) Improve SubstitutionValuesTestCase
[ https://issues.apache.org/jira/browse/TUSCANY-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520582 ] Frank Budinsky commented on TUSCANY-1498: - This test is failing for me: assertTrue(hc.getEqualityHelper().equal(loadedObject, createdObject)); Not sure if it's a bug in the test or the impl. Improve SubstitutionValuesTestCase -- Key: TUSCANY-1498 URL: https://issues.apache.org/jira/browse/TUSCANY-1498 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: Ron Gavlin Priority: Minor Fix For: Java-SDO-Next Attachments: tuscany-sdo-impl.TUSCANY-1498.patch Improve SubstitutionValuesTestCase. Will attach a patch in the near future. -- 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-1545) Change default XML encoding to UTF-8.
Change default XML encoding to UTF-8. Key: TUSCANY-1545 URL: https://issues.apache.org/jira/browse/TUSCANY-1545 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Reporter: Frank Budinsky Priority: Minor Fix For: Java-SDO-Next XMLHelper.save() uses ASCII encoding by default, but the spec says the default encoding is UTF-8. -- 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] Resolved: (TUSCANY-1498) Improve SubstitutionValuesTestCase
[ https://issues.apache.org/jira/browse/TUSCANY-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1498. - Resolution: Fixed I changed the test to set the local groupHead property (instead of the global one) and committed in revision 567093. Improve SubstitutionValuesTestCase -- Key: TUSCANY-1498 URL: https://issues.apache.org/jira/browse/TUSCANY-1498 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: Ron Gavlin Priority: Minor Fix For: Java-SDO-Next Attachments: tuscany-sdo-impl.TUSCANY-1498.patch Improve SubstitutionValuesTestCase. Will attach a patch in the near future. -- 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] Commented: (TUSCANY-1498) Improve SubstitutionValuesTestCase
[ https://issues.apache.org/jira/browse/TUSCANY-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520610 ] Frank Budinsky commented on TUSCANY-1498: - Problem is that when loading substitutionValues2.xml, the effect is like setting the local groupHead property - i.e., dataObject.set(groupHead, ...) - which is different from dataObject.set(groupHeadGlobalProperty, ...), even though they look the same. EqualityHelper checks that the settings are using the exact same property, but since one is the local property of the type while the other is the global property, the test fails. Improve SubstitutionValuesTestCase -- Key: TUSCANY-1498 URL: https://issues.apache.org/jira/browse/TUSCANY-1498 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: Ron Gavlin Priority: Minor Fix For: Java-SDO-Next Attachments: tuscany-sdo-impl.TUSCANY-1498.patch Improve SubstitutionValuesTestCase. Will attach a patch in the near future. -- 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] Resolved: (TUSCANY-1540) Abstract Static Base Types mixed with Dynamic Extended Types
[
https://issues.apache.org/jira/browse/TUSCANY-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1540.
-
Resolution: Fixed
Fixed in revision 566876.
I changed the generator to generate a concrete inner subclass for abstract Impl
classes:
public abstract class AbstractTestImpl extends DataObjectBase implements
AbstractTest
{
public static class ConcreteBase extends AbstractTestImpl
{
public ConcreteBase()
{
super();
}
}
...
}
and then added code in FactoryBase$SDOEFactoryImpl.create() to use it if the
type is abstract.
I've tested it with the following simple program:
public static void main(String[] args) throws IOException
{
HelperContext context = SDOUtil.createHelperContext();
Junk3Factory.INSTANCE.register(context);
TypeHelper typeHelper = context.getTypeHelper();
DataFactory factory = context.getDataFactory();
Type abstractType = typeHelper.getType(http://www.example.org/junk/;,
AbstractTest);
//DataObject testObject = factory.create(abstractType); // should fail
// Create an subtype
DataObject exampleType = DataFactory.INSTANCE.create(commonj.sdo, Type);
exampleType.set(uri, NSURI);
exampleType.set(name, Example);
exampleType.getList(baseType).add(abstractType);
Type type = TypeHelper.INSTANCE.define(exampleType);
DataObject testObject2 = factory.create(type);
if (testObject2.getClass() == AbstractTestImpl.ConcreteBase.class)
System.out.println(SUCCESS);
else
System.out.println(FAIL);
}
It would be good to get a proper JUnit for it. Any volunteers?
Abstract Static Base Types mixed with Dynamic Extended Types
Key: TUSCANY-1540
URL: https://issues.apache.org/jira/browse/TUSCANY-1540
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Reporter: Murtaza Goga
Fix For: Java-SDO-Next
Setting a property on a static data object with an object of a type extended
in a dynamic model results in a ClassCastException.
Scenario:
Static schema-
xsd:complexType name=CustomerType
xsd:all
xsd:element name=number type=xsd:integer /
xsd:element form=unqualified name=info type=InfoType /
/xsd:all
/xsd:complexType
xsd:complexType name=InfoType abstract=true/
Dynamic Schema
xsd:complexType name=InfoType
xsd:complexContent
xsd:extension base=staticNS:InfoType
xsd:sequence
xsd:element name=zipcode type=xsd:string /
/xsd:sequence
/xsd:extension
/xsd:complexContent
/xsd:complexType
The following will fail:
DataFactory factory = scope.getDataFactory();
factory.create(CustomerType.class).setDataObject(info,
factory.create(dynamicNS, InfoType));
It should be legal to assign a property to an object if they are in the same
hierachy.
Steps to reproduce within Tuscany:
Testcase org.apache.tuscany.sdo.test.ExtensibleTestCase will break if
'InfoType' defined in extensible/customer.xsd is marked as abstract.
--
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] Commented: (TUSCANY-1505) Naming scheme used for variables in code gen factory init() method breaks under specific circumstances
[ https://issues.apache.org/jira/browse/TUSCANY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519694 ] Frank Budinsky commented on TUSCANY-1505: - This code doesn't make any sense. Why are you generating a variable at all, which then isn't even used? You should just call the init() methods of the dependent packages. Naming scheme used for variables in code gen factory init() method breaks under specific circumstances -- Key: TUSCANY-1505 URL: https://issues.apache.org/jira/browse/TUSCANY-1505 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Priority: Minor Fix For: Java-SDO-Next Attachments: 1505.patch, test1505.zip A new code gen pattern was recently added to change how dependent packages are initialized in the xxxFactoryImpl.init() method. Under this new pattern, all dependent packages are initialized via the factoryInterface.INSTANCE method. An initialization call is made for each dependent gen package. The getImportedFactoryInterfaceName() is used to retrieve the short name. This value is mashed with the text 'Instnace' to form a variable name. If circumstances dictate that multiple packages contain the same factory interface name, the getImportedFactoryInterfaceName() will fully qualify the response instead of using the short name. This breaks the generated code, due to the use of a '.' in the variable name. -- 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-1527) Allow for custom data binding of DataObjects in a Swing UI
[
https://issues.apache.org/jira/browse/TUSCANY-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky updated TUSCANY-1527:
Component/s: Java SDO Implementation
Fix Version/s: Java-SDO-Next
Allow for custom data binding of DataObjects in a Swing UI
--
Key: TUSCANY-1527
URL: https://issues.apache.org/jira/browse/TUSCANY-1527
Project: Tuscany
Issue Type: New Feature
Components: Java SDO Implementation
Reporter: bert.robben
Fix For: Java-SDO-Next
Attachments: com.zip
We're developing 3-tier applications with a swing client, JBoss app server
and a couple of databases in the back-end. On the client side we use sdo
objects as model objects for our UI. As such, we need a mechanism for binding
our objects to the UI controls such that changes in the objects are reflected
in the UI and vice versa.
At the moment, there is no real standard for data binding and many different
implementations exist. As such, it would not be a good idea to build support
for this directly into the sdo core. Ideally, the sdo core would allow
implementations supporting data binding to be added as extensions [an
extension as in jar, module, bundle, component, ...]. This is a request for
supporting this in Tuscany SDO.
-
For our applications, we developed our own implementation of the sdo
specification. This implementation is designed to support that kind of
extensions. In the rest of this description, I'd like to show more details on
our implementation to make this more clear and to serve as food for a
possible discussion.
Our sdo core module defines the abstract class AbstractPartialDataObject
implementing DataObject. This class (together with its superclasses)
implements the majority of the bevahiour of DataObject. This includes
bi-directional property updates, type-safe properties, containment, ... It
doesn't implement however the basic access to property values.
Here's a code fragment.
public abstract class AbstractPartialDataObject extends AbstractDataObject
implements PartialDataObject {
protected abstract Object basicGet(Property property);
protected abstract void basicSet(Property property, Object value);
public Object get(Property property) { ... }
public void set(Property property, Object value) { ... }
...
}
The sdo core module also provides a non-abstract class
DataObjectImplementation that provides a simple implementation of this
abstract behaviour where the property values are stored in an ArrayList.
On top of that we defined an extension that deals with our UI requirements.
Our UI is based on a proprietary UI framework. This framework has the
following requirements:
- single valued properties should be exposed as XObservables. An XObservable
is a kind of ValueModel that provides access to a value (get/set) and also
allows for registration of change listeners
- multi valued properties should be exposed as ListModel instances. A
ListModel is a proprietary class (a bit similar to the javax.swing.ListModel)
that provides List functionality and also allows for change listeners
- the data object itself should allow registration of attribute change
listeners that are notified each time a property changes
The extension implements these requirements by providing an appropriate
subclass ObservableDataObject of AbstractPartialDataObject. The only other
pieces of code needed in the extension is an appropriate implementation of
DataFactory and a wrapper to deal with the differences between ListModel and
List.
Here's the class with the most important code snippets.
public class ObservableDataObject extends CompositePartialDataObject
implements {
private XObservable[] properties;
protected ObservableDataObject(com.agfa.hap.sdo.Type type) {
super(type);
this.properties = new XObservable[type.getProperties().size()];
for (int i = 0; i properties.length; i++) {
initializeProperty(type.getProperty(i));
}
}
private XObservableObject initializeProperty(Property prop) {
XObservableObject observable =
XObservableFactory.create(prop.getType().getInstanceClass(), this);
if (prop.isMany()) {
observable.init(new DataObjectListModel(this, prop));
}
properties[prop.getIndex()] = observable;
return observable;
}
public XObservable getObservable(commonj.sdo.Property property) {
XObservable result = properties[property.getIndex()];
return result;
}
public ListModel getListModel(Property property) {
return (ListModel) getObservable(property).get
[jira] Resolved: (TUSCANY-1490) Compile error when generating a schema with a dependency on another schema with the same leaf element name
[ https://issues.apache.org/jira/browse/TUSCANY-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1490. - Resolution: Duplicate This is covered by https://issues.apache.org/jira/browse/TUSCANY-1505 Compile error when generating a schema with a dependency on another schema with the same leaf element name -- Key: TUSCANY-1490 URL: https://issues.apache.org/jira/browse/TUSCANY-1490 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SDO-Next Reporter: Sunny Ip Priority: Minor Attachments: helloworld.wsdl, helloworld.xsd, SDOFactoryClass.java When generating SDO classes using XSD2JavaGenerator, the FactoryImpl generated from a schema with a dependency on another schema with the same leaf element name (e.g. http://sample/helloworld and http://sample/type/helloworld) results in a compile error in the init() method, where the full package name (including .) is used as part of the variable name. -- 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] Commented: (TUSCANY-1505) Naming scheme used for variables in code gen factory init() method breaks under specific circumstances
[ https://issues.apache.org/jira/browse/TUSCANY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519746 ] Frank Budinsky commented on TUSCANY-1505: - Looking at this more closely, I wonder if this is needed at all, since it looks like initializeMetaData() also does the same thing. I think you should look at this whole pattern more carefully. I would suggest a test case that has cyclic dependenices, e.g., A.xsd (with an element of a type in B.xsd) and B.xsd (with an element of a type in A.xsd). The key to this is to make sure that all dependent metaobjects are available (have been created) by the time they're needed in initializeMetaData(). Naming scheme used for variables in code gen factory init() method breaks under specific circumstances -- Key: TUSCANY-1505 URL: https://issues.apache.org/jira/browse/TUSCANY-1505 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Priority: Minor Fix For: Java-SDO-Next Attachments: 1505.patch, test1505.zip A new code gen pattern was recently added to change how dependent packages are initialized in the xxxFactoryImpl.init() method. Under this new pattern, all dependent packages are initialized via the factoryInterface.INSTANCE method. An initialization call is made for each dependent gen package. The getImportedFactoryInterfaceName() is used to retrieve the short name. This value is mashed with the text 'Instnace' to form a variable name. If circumstances dictate that multiple packages contain the same factory interface name, the getImportedFactoryInterfaceName() will fully qualify the response instead of using the short name. This breaks the generated code, due to the use of a '.' in the variable name. -- 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: SDOFactory: NoClassDefFoundError.
Hi, From the stack trace below, this doesn't really sound like an EMF/SDO version problem. It looks like it's trying to load a Tuscany class: org/apache/tuscany/sdo/SDOFactory This should be in the tuscany impl project JAR. Since it's not finding it, it sounds like the classpath is missing some JAR(s). Frank Fuhwei Lwo [EMAIL PROTECTED] wrote on 08/13/2007 12:34:05 PM: Hi Ramesh, My best guess is you have EMF version conflict between WPS and SDO 2.1. The EMF in WPS is much older than the one in Tuscany SDO. Since EMF is a runtime library in WPS, you cannot upgrade it on your own. The only way to make your env work is to refactor EMF in Tuscany SDO to avoid EMF conflict. This is probably something Tuscany SDO should do - to refactor EMF so it can hide EMF as implementation details. I am not sure whether refactoring EMF is allowed under Eclipse license. Any investigation is welcome. Fuhwei [EMAIL PROTECTED] wrote: Hi All, I am trying to read out an XML file by using your library files (tuscany-sdo-api-r2.1-1.0-incubating.jar). I placed your library in my Websphere process server lib folder as well I set all the tuscany jar's in my class path. Still, I am experiencing the below error. YOUR SUGGESTIONS WILL BE VERY MUCH APPRECIATED. [8/13/07 13:30:19:616 IST] 005a ExceptionUtil E CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method transactionNotSupportedActivitySessionSupports on bean BeanId(XMLValidationApp#XMLValidationEJB.jar#Module, null). Exception data: java.lang.NoClassDefFoundError: org/apache/tuscany/sdo/SDOFactory at org.apache.tuscany.sdo.impl.FactoryBase.(FactoryBase.java:225) at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41) at org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelper Impl.java:63) at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java: 81) at org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl .java:64) at org.apache.tuscany.sdo.helper.DefaultHelperContextImpl.(DefaultHel perContextImpl.java:31) at org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(He lperProviderImpl.java:37) at org.apache.tuscany.sdo.spi.HelperProviderBase.(HelperProviderBase. java:81) at org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderIm pl.java:30) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA ccessorImpl.java(Compiled Code)) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons tructorAccessorImpl.java(Compiled Code)) at java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled Code)) at java.lang.Class.newInstance3(Class.java(Compiled Code)) at java.lang.Class.newInstance(Class.java(Compiled Code)) at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:1 57) at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126) at commonj.sdo.impl.HelperProvider.(HelperProvider.java:69) at commonj.sdo.helper.XMLHelper.(XMLHelper.java:200) at sca.component.java.impl.XMLValidateImpl.doValidation(XMLValidateImpl.jav a:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a(Compiled Code)) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a(Compiled Code)) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java(Compiled Code)) at java.lang.reflect.Method.invoke(Method.java(Compiled Code)) at com.ibm.ws.sca.internal.java.handler.JavaReflectionAdapter.invoke(JavaRe flectionAdapter.java:138) at com.ibm.ws.sca.internal.java.handler.JavaImplementationHandler.processMe ssage(JavaImplementationHandler.java:258) at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag e(MessageDispatcherImpl.java:386) at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM essageImpl.java:476) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessage(Mo duleSessionBean.java:335) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.transactionNotSuppor tedActivitySessionSupports(ModuleSessionBean.java:276) at com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.transactio nNotSupportedActivitySessionSupports(EJSLocalStatelessModule_43132892.ja va:199) at com.ibm.ws.sca.internal.uow.handler.UOWStrategyImpl.transactionLocalActi vitySessionAny(UOWStrategyImpl.java:406) at
[jira] Commented: (TUSCANY-1479) The code of method createXSDMetaData(ModelFactoryImpl) is exceeding the 65535 bytes limit
[
https://issues.apache.org/jira/browse/TUSCANY-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516038
]
Frank Budinsky commented on TUSCANY-1479:
-
The SDO generator in RAD is the Eclipse EMF generator supporting SDO 1.0. The
EMF codegenerator supports a large model pattern, whereby if a model is very
large, instead of generating code to initialize the metadata, it generates a
call to load the metadata from a file. The Tuscany SDO generator does not
currently have a similar feature, although it would be good to add one. Perhaps
you'd like to open a JIRA feature request for that.
In the meantime, the workaround is to manually break up the createXSDMetaData()
method into several smaller methods.
The code of method createXSDMetaData(ModelFactoryImpl) is exceeding the 65535
bytes limit
-
Key: TUSCANY-1479
URL: https://issues.apache.org/jira/browse/TUSCANY-1479
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
Environment: Rational 7.0.0.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32
j9vmxi3223ifx-20070323 (JIT enabled)
Reporter: Eric Coolman
I am attempting to have a number of root objects creatable from a single
factory, ie. my main xsd contains a number of imports:
xsd:include schemaLocation=SyncItemClass.xsd/
xsd:include schemaLocation=SyncCatalog.xsd/
xsd:include schemaLocation=AddRFQ.xsd/
xsd:include schemaLocation=CancelRFQ.xsd/
xsd:include schemaLocation=ProcessPO.xsd/
... etc.
This works well for me with the SDO Generator in RAD, but tuscany is
generating a very large createXSDMetaData() method that will not compile:
java.lang.Error: Unresolved compilation problem:
The code of method createXSDMetaData(ModelFactoryImpl) is exceeding the
65535 bytes limit
at
com.ibm.ocs.sdo.impl.SdoFactoryImpl.createXSDMetaData(SdoFactoryImpl.java:10695)
at
com.ibm.ocs.sdo.impl.SdoFactoryImpl.initializeMetaData(SdoFactoryImpl.java:10692)
at com.ibm.ocs.sdo.impl.SdoFactoryImpl.init(SdoFactoryImpl.java:3455)
at com.ibm.ocs.sdo.SdoFactory.clinit(SdoFactory.java:28)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:187)
at
com.ibm.ocs.sdo.test.ProcessPOTestCase.testSerializePO(ProcessPOTestCase.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
The createXSDMetaData method looks like this fragment:
protected void createXSDMetaData(ModelFactoryImpl theModelPackageImpl)
{
super.initXSD();
Property property = null;
addXSDMapping
(acknowledgeCompanyType,
new String[]
{
name, AcknowledgeCompany,
kind, elementOnly
});
addXSDMapping
(getProperty(acknowledgeCompanyType,
AcknowledgeCompanyImpl.INTERNAL_HEADER),
new String[]
{
kind, element,
name, header
});
addXSDMapping
(controlVerbType,
new String[]
{
name, ControlVerb,
baseType, commonj.sdo#String,
enumeration, GET GETLIST SHOW LIST VALIDATE ACKNOWLEDGE ADD CHANGE
CANCEL PROCESS REGISTER RESPOND SYNC
});
addXSDMapping
(countryCodeType,
new String[]
{
name, countryCode,
baseType, commonj.sdo#String,
enumeration, AD AE AF AG
RE: How does xsd:ID property type is distinguished from xsd:string
Hi Pinaki, This looks very cool, especially that you've got a working prototype! I have a couple of questions. 1) This seems to overlap with the DAS plan described here: http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+%28JPA%29 I'm not very familiar with the DAS work myself, but there seems to be some overlap with your work. 2) I'm also wondering if you were aware that SDO also defines a mapping to static Java interfaces/classes. See section 5 of the SDO spec: http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1 Does your SDO2POJOGenerator conform to that mapping? Have you tried the Tuscany static SDO generator (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any relashionship? Frank. Pinaki Poddar [EMAIL PROTECTED] wrote on 07/26/2007 10:41:27 PM: Hello, I have been asking newbie questions to this forum. And people have been very helpful. Those newbie questions were for a Apache Lab project named Fluid -- to explore possibilities of SDO persistence using JPA API. With all your help, I could put together an initial proptotype that creates/updates/queries SDO using JPA API. I used Tuscany and OpenJPA for SDO and JPA implementation respectively. Further details of this project (with user documentation) can be found at http://people.apache.org/~ppoddar/fluid/site/welcome.html Your comments/suggestions are most welcome -- Pinaki Poddar 972.834.2865 -Original Message- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 4:59 PM To: tuscany-dev@ws.apache.org Subject: RE: How does xsd:ID property type is distinguished from xsd:string EAttribute.isID() will only be true if the type is xsd:ID. Frank. Pinaki Poddar [EMAIL PROTECTED] wrote on 07/24/2007 05:31:09 PM: Hi Frank, Database IDs (e.g., primary and foreign keys) are more related to xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning to address all of them :-) Thanks for telling me this. Now is ((property.getType().isDataType()) ((EAttribute)property).isID())) == true for a property p that is declared as xsd:key or xsd:keyref? Or broadly, what is the semantics of Eattribute.isID()? Pinaki Poddar 972.834.2865 -Original Message- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 3:01 PM To: tuscany-dev@ws.apache.org Subject: RE: How does xsd:ID property type is distinguished from xsd:string Hi Pinaki, Identity support is also in the SDO 3 charter: Support for a concept of identity in SDO, and its relationship to other technologies. Database IDs (e.g., primary and foreign keys) are more related to xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning to address all of them :-) Frank. Pinaki Poddar [EMAIL PROTECTED] wrote on 07/24/2007 11:02:21 AM: Hi Frank, Thanks. SDO (SDO 3) is planning to provide an api for accessing extended XSD metadata That is good news. However, identity mechanics should appear more distinctly on API surface e.g. boolean Proprty.isIdentifier(); ListProperty Type.getIdentifiers(); I will qualify absence of any identity semantics from SDO a major drawback. Especially, if it comes to any persistence operation on SDO DataObject/DataGraph. Hopefully some of the SDO spec writers would notice this omission and add it to future spec version. After a quick pick in current DAS implementation, it appeared that 'primary key' identification is based on existing database column name ID (yes, hardcoded) -- but I may be wrong and am ready to learn how DAS is handling identity issue. SDO (SDO 3) is planning to provide an api for accessing extended XSD metadata That is a good decision. Wrapping should always provide access to what is being wrapped. downcasting to the EMF implementation class Thanks for this info. I will do this for now. But I heed your advice and have already a scheme in place that programs against *only* commonj.sdo API but can access underlying implementaion, if available, without any compile-time binding. Slightly costly -- but works for, say, extracting package name from Types. Pinaki Poddar 972.834.2865 -Original Message- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 9:16 AM To: tuscany-dev@ws.apache.org Subject: Re: How does xsd:ID property type is distinguished from xsd:string Hi Pinaki, They can't be distinguished in the current version of SDO metadata, you need to look at the original XSD. The next version of SDO (SDO 3) is planning to provide an api for accessing extended XSD metadata. In Tuscany, you can currently
Re: [VOTE] Release SDO Java version 1.0-incubating
+1. It appears to have everything in it that I expected and the samples ran fine for me. Quite an impressive list of new features and bug fixes :-) Thanks to everyone that helped. I think the project momentum is really starting to pick up. Frank. kelvin goodson [EMAIL PROTECTED] wrote on 07/25/2007 02:35:51 PM: Please review and vote to release the 1.0-incubating distribution of Tuscany SDO for Java The release candidate RC3 for Tuscany Java SDO archive distribution files are posted at [1] The release audit tool (rat) files and associated exceptions are posted at [1] also The maven repository artifacts are posted in a staging repository [2] http://people.apache.org/%7Ekelvingoodson/sdo_java/M3/RC2/The tag for the source code is at [3] The release notes for this release are attached below Changes to this release candidate from the RC2 candidate The SDO API jar file includes LICENSE, NOTICE and DISCLAIMER files The LICENSE and NOTICE files in other projects have been cleaned up to remove unnecessary references and to conform to current Apache standards The artifacts in the staging repo have been signed The sample artifacts have been removed from the staging repo The test classes in the tools project have been regenerated The tools pom has been commented to avoid confusion over the asm dependency The use of the 0.8-SNAPSHOT version of the maven-osgi-plugin has not been altered as there is no update to this plugin It looks OK to me so here's my +1 Regards, Kelvin. [1] http://people.apache.org/~kelvingoodson/sdo_java/1.0-incubating/RC3/ [2] http://people.apache.org/~kelvingoodson/repo/org/apache/tuscany/sdo/ [3] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0- incubating/ = Service Data Objects (SDO) Java version 1.0-incubating Release Notes The Service Data Objects (SDO) API simplifies and unifies Service Oriented Architecture (SOA) data access and code. SDO offers both a static and a dynamic programming model for data access. Choosing to generate static classes to repreent your data model gives you the ease and intuitive nature of the static programming model, backed up by the power of the dynamic model too. SDO also offers the capacity to track changes to data. If a graph of data includes a change summary property, then additions, modifications, and deletions made to the graph within the scope of that change summary will be recorded. What's new in this Release == Apache Tuscany's SDO Java Release 1.0-incubating is the first such release with full coverage of the SDO 2.1 specification. In addition to adding the few remaining SDO 2.1 features not included in the 1.0-incubating-beta1 release and fixing a number of bugs (see below for detail) there are a number of new features relating to XML serialization, and new support for handling dynamic derivation from static classes. There has also been significant focus on making the SDO sample programs more accessible. For previous revision history, take a look at http://svn.apache.org/viewvc/incubator/tuscany/tags/java/sdo/1.0- incubating-beta1/sdo/distribution/RELEASE_NOTES.txt SDO Java 1.0-incubating is a superset of previous SDO 1.0-incubating-beta1release. Anything in 1.0-incubating-beta1 is also in 1.0-incubating, but 1.0-incubating contains features and bugfixes not present in 1.0-incubating-beta1 release. Downloading === Please visit http://incubator.apache.org/tuscany/sdo-java-releases.html Binary Artifact Changes === PLEASE NOTE that Since the 1.0-incubating-beta release the following binary artifacts have been renamed The maven groupId of the SDO API binary artifact has changed from commonj to org.apache.tuscany.sdo The maven artifactId for the SDO API binary artifact has changed from sdo-api-r2.1 to tuscany-sdo-api-r2.1 The jar file containing the SDO API has a new tuscany- prefix, so what was .. sdo-api-r2.1-1.0-incubating-beta1.jar in the beta1 release becomes tuscany-sdo-api-r2.1-1.0-incubating.jar in this release. In addition a new maven artifact and jar has appeared. maven groupId=org.apache.tuscany.sdo maven artifactId=tuscany-sdo-lib jar archive=tuscany-sdo-lib-1.0-incubating This artifact provides a cleear distinction between Tuscany SDO implementation, and the Tuscany API which extends the SDO API. See the javadoc contained in the binary release for details of the function provded by this artifact. New Features and Fixes == For more detail on these fixes and features please see ... https://issues.apache.org/jira/secure/IssueNavigator.jspa? reset=truepid=12310210fixfor=12312521resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=issuetypesorter/order=DESC New Feature
Re: Persistence of Service Data Objects using OpenJPA
Hi Pinaki, I think your project has a lot of potential. Another related aspect is that there is interest in the SDO specification charter to discuss the possibility of converging/supporting JAXB with static SDO in version 3. JAXB2, as you may know, has a similar objective to support standard POJOs. If that happens, then I see even more synergy with your approach. At Tuscany, we'd also be very interested in the bytecode generation that you mentioned you've prototyped in Fluid. Tuscany has done a little bit of sandbox prototyping in that area as well, but nobody has had enough time to really pursue it. Given this work, I think you should consider getting involved with the DAS specification effort, if you haven't already. Frank. Pinaki Poddar [EMAIL PROTECTED] 07/27/2007 12:32 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc [EMAIL PROTECTED] Subject Persistence of Service Data Objects using OpenJPA Hi Frank, Thank you for your interest. Before I answer the specific questions let me say few words to explain why Fluid is attempted at first place. A) there is a natural synergy between SDO model and the POJO model where JPA excels. B) Object Persistence (be it strongly-typed POJO or loosely-typed SDO) is complex problem by itself. Throw in quirk of multiple database vendors -- and one really got a hard problem in hand. OpenJPA, Hibernate, TopLink had worked over many years to solve this problem to a reasonable degree. SDO persistence should leverage that knowledge/effort instead of reinventing a costly wheel. 1) Yes -- you're right. The views expressed in http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+% 28JPA%29 is in agreement with what promoted me to start the lab (actually I checked this page while researching and mentioned in in my blog). According to this wiki page: Work on the specification of a JPA data access service by the OSOA collaboration is envisaged sometime in the future but has not started yet. So Fluid can be considered as a prototype/exploration of similar ideas. 2) Yes, I am aware of SDO's generation of Java and I have played with org.apache.tuscany.sdo.generate.XSD2JavaGenerator briefly. I decided to write yet another code generator for Fluid because a) SDO2POJOGenerator handles JPA annotations as it sources SDO Type information defined by XSDHelper.define(). The annotations in the class will be made optional as we proceed -- because JPA allows a separate mapping file Orm.xml thereby retaining POJO-ness of the persistent domain classes. b) The generated Java classes is domain-ready i.e. they are self-consistent and independent. Proof: they can be compiled without any other package other that java.util.*. Adding annotation, however, makes them compile-dependent on jpa.jar, but that dependency will be made optional as mapping information can be externalized in orm.xml. C) as far as SDO metamodel to Java metamodel mapping goes, it is essentially isomorphic (at least for this prototype). SDO2POJO does not introduce any extra artifact (see below). I have not played enough with org.apache.tuscany.sdo.generate.XSD2JavaGenerator to make a fair judgement -- but most probably it is generating Java classes which has more dependency on framework classes in terms of (inheriting/implementing) as well as package imports. d) One mapping element is introduced in SDO-Java conversion process. It is about Container SDO Types. I describe the details in Fluid website. The reason for defining a Container Type abstraction is better alignment for mapping to relational database (save extra joins and allow navigational query across multi-cardinality relation paths). 3) Besides the source code generation route, another possibilities is dynamic Java bytecode generation for SDO Types. Fluid prototyped that approach too. Regards -- Pinaki Poddar 972.834.2865 -Original Message- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: Friday, July 27, 2007 10:39 AM To: tuscany-dev@ws.apache.org Subject: RE: How does xsd:ID property type is distinguished from xsd:string Hi Pinaki, This looks very cool, especially that you've got a working prototype! I have a couple of questions. 1) This seems to overlap with the DAS plan described here: http://www.osoa.org/display/Main/SDO+and+Java+Persistence+Architecture+% 28JPA%29 I'm not very familiar with the DAS work myself, but there seems to be some overlap with your work. 2) I'm also wondering if you were aware that SDO also defines a mapping to static Java interfaces/classes. See section 5 of the SDO spec: http://www.osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.p df?version=1 Does your SDO2POJOGenerator conform to that mapping? Have you tried the Tuscany static SDO generator (org.apache.tuscany.sdo.generate.XSD2JavaGenerator)? Is there any relashionship? Frank. Pinaki Poddar [EMAIL PROTECTED] wrote on 07/26
[jira] Commented: (TUSCANY-1483) Static SDO generator: problem with elements named internal*
[ https://issues.apache.org/jira/browse/TUSCANY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515709 ] Frank Budinsky commented on TUSCANY-1483: - I think that all that's necessary to make this change is globally replace INTERNAL_ with _INTERNAL_ in SDOClass.javajet and SDOFactory.javajet. Static SDO generator: problem with elements named internal* --- Key: TUSCANY-1483 URL: https://issues.apache.org/jira/browse/TUSCANY-1483 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Affects Versions: Java-SDO-beta1 Reporter: Daniel Peter Priority: Minor Fix For: Java-SDO-Next Hi, I run into a problem with the static generated SDOs, when having a xsd with the following two elements: xsd:element name=abc type=xsd:integer / xsd:element name=internalAbc type=xsd:integer / In the generated Impl class this leads twice to the same constant INTERNAL_ABC. The xsd elements might simply be renamed in order to avoid this clash, but there might be situations where this is not possible. The generator could use a different, less probable prefix (e.g. ___INTERNAL_). Thanks, Daniel. -- 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: How does xsd:ID property type is distinguished from xsd:string
Hi Pinaki, They can't be distinguished in the current version of SDO metadata, you need to look at the original XSD. The next version of SDO (SDO 3) is planning to provide an api for accessing extended XSD metadata. In Tuscany, you can currently determine this by downcasting to the EMF implementation class, although we don't recommend people do that: System.out.println( Property isID: + ((property.getType().isDataType()) ((EAttribute)property).isID())); Frank. Pinaki Poddar [EMAIL PROTECTED] wrote on 07/24/2007 01:00:03 AM: Hi, A newbie question: How does two Property: one defined as xsd:string and other as xsd:ID can be distiguished? Assume: 1. we have a simple XML schema defining a Person SDO Type with two properties as follows: xsd:complexType name=Person xsd:attribute name=firstName type=xsd:string/ xsd:attribute name=idtype=xsd:ID/ /xsd:complexType 2. TypeHelper.INSTANCE.define() defines SDO Type with two commonj.sdo.Property, p1 (for firstName) and p2 (for id) 3. both p1.getType().getInstanceClass() and p2.getType().getInstanceClass() return java.lang.String both p1.getType().isDataType() and p2.getType().isDataType() return true The question is, what can be done to identify p2 as a property that were defined as xsd:ID? Thanks for your help -- Pinaki Poddar 972.834.2865 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - 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: How does xsd:ID property type is distinguished from xsd:string
EAttribute.isID() will only be true if the type is xsd:ID. Frank. Pinaki Poddar [EMAIL PROTECTED] wrote on 07/24/2007 05:31:09 PM: Hi Frank, Database IDs (e.g., primary and foreign keys) are more related to xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning to address all of them :-) Thanks for telling me this. Now is ((property.getType().isDataType()) ((EAttribute)property).isID())) == true for a property p that is declared as xsd:key or xsd:keyref? Or broadly, what is the semantics of Eattribute.isID()? Pinaki Poddar 972.834.2865 -Original Message- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 3:01 PM To: tuscany-dev@ws.apache.org Subject: RE: How does xsd:ID property type is distinguished from xsd:string Hi Pinaki, Identity support is also in the SDO 3 charter: Support for a concept of identity in SDO, and its relationship to other technologies. Database IDs (e.g., primary and foreign keys) are more related to xsd:key/xsd:keyref, then xsd:ID, but fortunately SDO 3 is planning to address all of them :-) Frank. Pinaki Poddar [EMAIL PROTECTED] wrote on 07/24/2007 11:02:21 AM: Hi Frank, Thanks. SDO (SDO 3) is planning to provide an api for accessing extended XSD metadata That is good news. However, identity mechanics should appear more distinctly on API surface e.g. boolean Proprty.isIdentifier(); ListProperty Type.getIdentifiers(); I will qualify absence of any identity semantics from SDO a major drawback. Especially, if it comes to any persistence operation on SDO DataObject/DataGraph. Hopefully some of the SDO spec writers would notice this omission and add it to future spec version. After a quick pick in current DAS implementation, it appeared that 'primary key' identification is based on existing database column name ID (yes, hardcoded) -- but I may be wrong and am ready to learn how DAS is handling identity issue. SDO (SDO 3) is planning to provide an api for accessing extended XSD metadata That is a good decision. Wrapping should always provide access to what is being wrapped. downcasting to the EMF implementation class Thanks for this info. I will do this for now. But I heed your advice and have already a scheme in place that programs against *only* commonj.sdo API but can access underlying implementaion, if available, without any compile-time binding. Slightly costly -- but works for, say, extracting package name from Types. Pinaki Poddar 972.834.2865 -Original Message- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 9:16 AM To: tuscany-dev@ws.apache.org Subject: Re: How does xsd:ID property type is distinguished from xsd:string Hi Pinaki, They can't be distinguished in the current version of SDO metadata, you need to look at the original XSD. The next version of SDO (SDO 3) is planning to provide an api for accessing extended XSD metadata. In Tuscany, you can currently determine this by downcasting to the EMF implementation class, although we don't recommend people do that: System.out.println( Property isID: + ((property.getType().isDataType()) ((EAttribute)property).isID())); Frank. Pinaki Poddar [EMAIL PROTECTED] wrote on 07/24/2007 01:00:03 AM: Hi, A newbie question: How does two Property: one defined as xsd:string and other as xsd:ID can be distiguished? Assume: 1. we have a simple XML schema defining a Person SDO Type with two properties as follows: xsd:complexType name=Person xsd:attribute name=firstName type=xsd:string/ xsd:attribute name=idtype=xsd:ID/ /xsd:complexType 2. TypeHelper.INSTANCE.define() defines SDO Type with two commonj.sdo.Property, p1 (for firstName) and p2 (for id) 3. both p1.getType().getInstanceClass() and p2.getType().getInstanceClass() return java.lang.String both p1.getType().isDataType() and p2.getType().isDataType() return true The question is, what can be done to identify p2 as a property that were defined as xsd:ID? Thanks for your help -- Pinaki Poddar 972.834.2865 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail
[jira] Commented: (TUSCANY-1470) Generated SDO APIs have compilation errors when sub-type has the same name as super-type
[
https://issues.apache.org/jira/browse/TUSCANY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514621
]
Frank Budinsky commented on TUSCANY-1470:
-
The bug is in SDOClass.javajet. The calls to base.getClassName() should be
base.getImportedName() (in 9 places). Please make the change and confirm that
it fixes the problem. Thanks.
Generated SDO APIs have compilation errors when sub-type has the same name as
super-type
Key: TUSCANY-1470
URL: https://issues.apache.org/jira/browse/TUSCANY-1470
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
Environment: WinXP
Reporter: Fuhwei Lwo
Fix For: Java-SDO-1.0
Run the codegen tool on src/test/resources/extensible/infostreet.xsd. The
generated code like the one below cannot be compiled because
SDO_PROPERTY_COUNT becomes ambiguous.
*infostreet.xsd*
xsd:complexType name=InfoType
xsd:complexContent
xsd:extension base=customer:InfoType
xsd:sequence
xsd:element name=street
type=xsd:string /
/xsd:sequence
/xsd:extension
/xsd:complexContent
/xsd:complexType
public class InfoTypeImpl extends InfoTypeImpl implements InfoType
{
public final static int STREET = InfoTypeImpl.SDO_PROPERTY_COUNT + 0;
public final static int SDO_PROPERTY_COUNT =
InfoTypeImpl.SDO_PROPERTY_COUNT + 1;
--
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] Commented: (TUSCANY-1143) Generated code should separate metadata creation from registration to permit proper scoping
[
https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514240
]
Frank Budinsky commented on TUSCANY-1143:
-
I tracked down two places that the global EMF registry was being used. Fixes
are needed in TypeImpl.getInstanceClassName() and
DataObjectBase.resolveProxy(). Here are my fixed versions of the two methods:
public String getInstanceClassName()
{
if (javaClassFeature == null)
{
//FB TODO figure out what helper to use
javaClassFeature =
(EStructuralFeature)TypeHelper.INSTANCE.getOpenContentProperty(commonj.sdo/java,
javaClass);
}
Sequence anyAttribute = getAnyAttribute();
int count = anyAttribute.size();
for (int i = 0; i count; i++)
{
EStructuralFeature eFeature =
(EStructuralFeature)anyAttribute.getProperty(i);
if (eFeature == javaClassFeature)
{
return (String)anyAttribute.getValue(i);
}
}
return null;
}
protected Object resolveProxy(Object proxy)
{
Resource resource = this.eResource();
ResourceSet resourceSet = resource != null ? resource.getResourceSet() :
null;
if (resourceSet != null) return EcoreUtil.resolve((EObject)proxy,
resourceSet);
URI proxyURI = ((InternalEObject)proxy).eProxyURI();
if (proxyURI != null)
{
EPackage ePackage =
HelperContextImpl.getBuiltInModelRegistry().getEPackage(proxyURI.trimFragment().toString());
if (ePackage != null)
{
resource = ePackage.eResource();
if (resource != null)
{
return resource.getEObject(proxyURI.fragment().toString());
}
}
}
Generated code should separate metadata creation from registration to permit
proper scoping
---
Key: TUSCANY-1143
URL: https://issues.apache.org/jira/browse/TUSCANY-1143
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
Reporter: Kelvin Goodson
Fix For: Java-SDO-1.0
Attachments: 1143.patch, 1143.patch, 1143.patch
The switch to registration of metadata from the global scope to selected
scopes is not complete yet, although for all current test cases there are no
failures.
Currently the generated init() method for a factory calls the deprecated
SDOUtil.registerStaticTypes for its simple dependencies.
In the simple case this is just ModelFactory and SDOFactory, but could
contain other user generated dependencies if for example
there were to be an xsd import of another namespace (exposed a gap in our
test case set). This would mean that the user generated model dependency
would also be registered against the global registry.
It is proposed that all registrations, including the built in models, are
made against the helper context provided to the Factory's register method.
I.e. a state invariant that no models are ever registered against the global
registry.
The pattern of looking up models from within packages is not required, since
the code can just refer to each model's singleton INSTANCE (see below for the
exception SDOFactoryImpl). Creation of the metadata should be done in the
init
method, and the registration of all metadata (built-in or otherwise) should
be done in the register method. It would appear on inspection that no
reference to the simple dependencies of a factory need be made in its init
method, and simple reference to the dependencies INSTANCE in the register
will be enough to ensure that those dependencies are initialised before being
registered against the provided scope.
SDOFactoryImpl does not have an INSTANCE currently. The current proposed
solution is to modify SDOFactory to have an INSTANCE, in order that it can
behave like an ordinary generated dependency in this new approach.
--
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] Commented: (TUSCANY-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513997 ] Frank Budinsky commented on TUSCANY-1457: - The problem is that sdoModel.xsd includes datagraph.xsd. The SchemaLocator class in SDOXSDEcoreBuilder needs to avoid looking up the model in the package registry if locateSchema is being called for an include. I'll attach a patch. Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky updated TUSCANY-1457: Attachment: 1457.patch Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 Attachments: 1457.patch When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky updated TUSCANY-1457: Attachment: 1457.patch Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 Attachments: 1457.patch When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky updated TUSCANY-1457: Attachment: (was: 1457.patch) Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 Attachments: 1457.patch When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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] Resolved: (TUSCANY-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1457. - Resolution: Fixed Fixed in revision 557781. Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 Attachments: 1457.patch When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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] Commented: (TUSCANY-1459) Remove package registry delegation to EPackage.Registry.INSTANCE
[ https://issues.apache.org/jira/browse/TUSCANY-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514015 ] Frank Budinsky commented on TUSCANY-1459: - Patch looks perfect! Can we apply it or does it cause breakage if not syncronized with TUSCANY-1143? Remove package registry delegation to EPackage.Registry.INSTANCE Key: TUSCANY-1459 URL: https://issues.apache.org/jira/browse/TUSCANY-1459 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Priority: Critical Fix For: Java-SDO-1.0 Attachments: 1459.patch This improvement is to reduce today's 3 tier registry delegation mechanism to 2 tier's so we won't rely on EPackage.Registry.INSTANCE. Current design: The default HelperContext created by using HelperProvider.getDefaultContext() is using the EPackage.Registry.INSTANCE as its package registry that can be delegated to the TCCL's registry. The local HelperContext created by using api.SDOUtil.createHelperContext() is creating a local package registry that can delegate to the builtInModelRegistry that potentially delegates to the EPackage.Registry.INSTANCE. default HelperContext (EPackage.Registry.INSTANCE/TCCL based) local HelperContext (local package registry) --delegate-- builtInModelRegistry --delegate-- EPackage.Registry.INSTANCE EMF, SDO runtime models, SDO type models are resided in the EPackage.Registry.INSTANCE SDO type models (sdoModel.xsd, sdoJava.xsd, sdoXML.xsd, and sdoInternal.xsd) are resided in both builtInModelRegistry and EPackage.Registry.INSTANCE (registered in the FactoryBase.java) User models will reside either in the EPackage.Registry.INSTANCE or local package registry New design: The builtInModelRegistry will become the end of registry delegation chain that would contain all required EMF and SDO runtime models and type models. The user models will reside at the local registry created for the helper context. If it's the default helper context, the special registry will be the SDOPackageRegistryDelegator that is similar to EPackage.Registry.INSTANCE$Delegator that would look up TCCL's registry and at the end of chain delegates to the builtInModelRegistry. If it's the local HelperContext, a regular Hashmap registry will be used then delegates to the builtInModelRegistry. default HelperContext (SDOPackageRegistryDelegator/TCCL based) --delegate-- builtInModelRegistry local HelperContext (local package registry) --delegate-- builtInModelRegistry EMF, SDO runtime, and SDO type models all reside in the builtInModelRegistry User models will reside either in the SDOPackageRegistryDelegator(TCCL based) or local package registry -- 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] Resolved: (TUSCANY-1459) Remove package registry delegation to EPackage.Registry.INSTANCE
[ https://issues.apache.org/jira/browse/TUSCANY-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1459. - Resolution: Fixed Committed revision 557838. Remove package registry delegation to EPackage.Registry.INSTANCE Key: TUSCANY-1459 URL: https://issues.apache.org/jira/browse/TUSCANY-1459 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Priority: Critical Fix For: Java-SDO-1.0 Attachments: 1459.patch This improvement is to reduce today's 3 tier registry delegation mechanism to 2 tier's so we won't rely on EPackage.Registry.INSTANCE. Current design: The default HelperContext created by using HelperProvider.getDefaultContext() is using the EPackage.Registry.INSTANCE as its package registry that can be delegated to the TCCL's registry. The local HelperContext created by using api.SDOUtil.createHelperContext() is creating a local package registry that can delegate to the builtInModelRegistry that potentially delegates to the EPackage.Registry.INSTANCE. default HelperContext (EPackage.Registry.INSTANCE/TCCL based) local HelperContext (local package registry) --delegate-- builtInModelRegistry --delegate-- EPackage.Registry.INSTANCE EMF, SDO runtime models, SDO type models are resided in the EPackage.Registry.INSTANCE SDO type models (sdoModel.xsd, sdoJava.xsd, sdoXML.xsd, and sdoInternal.xsd) are resided in both builtInModelRegistry and EPackage.Registry.INSTANCE (registered in the FactoryBase.java) User models will reside either in the EPackage.Registry.INSTANCE or local package registry New design: The builtInModelRegistry will become the end of registry delegation chain that would contain all required EMF and SDO runtime models and type models. The user models will reside at the local registry created for the helper context. If it's the default helper context, the special registry will be the SDOPackageRegistryDelegator that is similar to EPackage.Registry.INSTANCE$Delegator that would look up TCCL's registry and at the end of chain delegates to the builtInModelRegistry. If it's the local HelperContext, a regular Hashmap registry will be used then delegates to the builtInModelRegistry. default HelperContext (SDOPackageRegistryDelegator/TCCL based) --delegate-- builtInModelRegistry local HelperContext (local package registry) --delegate-- builtInModelRegistry EMF, SDO runtime, and SDO type models all reside in the builtInModelRegistry User models will reside either in the SDOPackageRegistryDelegator(TCCL based) or local package registry -- 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] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class)
[ https://issues.apache.org/jira/browse/TUSCANY-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513250 ] Frank Budinsky commented on TUSCANY-1110: - I don't think this looks right: sdoTypeImplClass = Class.forName(sdoTypeImplClassName); Doesn't it need to use the ClassLoader of the interfaceClass to do this? Frank. Improve the performance of TypeHelperImpl.getType(Class) Key: TUSCANY-1110 URL: https://issues.apache.org/jira/browse/TUSCANY-1110 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: Raymond Feng Fix For: Java-SDO-1.0 Attachments: 1110.patch In the SDO databinding for SCA, we need to introspect a java class/interface to figure out the corresponding SDO type. Looking into the code, there is a TODO comment: //TODO more efficient implementation ... this is a really bad one! Do you plan to provide a more efficient impl :-)? Thanks, Raymond -- 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]
SDO standard schemas published at osoa.org
The xsd files containing the standard SDO types have recently been published at http://www.osoa.org/sdo/2.1/schemas/;. To reference commonj.sdo types, for example, in your xsd files you can now import them like this: xsd:import namespace=commonj.sdo schemaLocation=http://www.osoa.org/sdo/2.1/schemas/datagraph.xsd; / Frank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1380) DataObjectListTest.testGetInvalidInstanceProperty is invalid
[ https://issues.apache.org/jira/browse/TUSCANY-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1380. - Resolution: Fixed I changed aaa[1] to nonexistentProperty in revision 556085. DataObjectListTest.testGetInvalidInstanceProperty is invalid Key: TUSCANY-1380 URL: https://issues.apache.org/jira/browse/TUSCANY-1380 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Fix For: Java-SDO-CTS-Next The following callin DataObjectListTest.testGetInvalidInstanceProperty is invalid because getInstanceProperty() is not intended to work with xpath expressions, just property names. testObj.getInstanceProperty(aaa[1]); I don't have committer rights yet. Could someone please mark this test @Ignore for the moment. Thanks. -- 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] Resolved: (TUSCANY-1421) XMLHelper.save on root object of DataGraph gives serialization of href=root.xml#/
[ https://issues.apache.org/jira/browse/TUSCANY-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1421. - Resolution: Fixed Fixed in revision 556147. XMLHelper.save on root object of DataGraph gives serialization of href=root.xml#/ --- Key: TUSCANY-1421 URL: https://issues.apache.org/jira/browse/TUSCANY-1421 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-beta1 Reporter: Kelvin Goodson There's an issue reported on the user list ... http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200707.mbox/[EMAIL PROTECTED] which relates to a some missing logic in XMLDocumentImpl's save method The precondition for hitting this issue is when the data object is the root data object of a DataGraph. In this case the eContainer of the root object is null, but the root object is contained in a resource. We need to replicate the unhooking and replacing behaviour that exists for the container of the data object for the case where the data object is directly contained in a resource. -- 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-1430) SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls
SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls - Key: TUSCANY-1430 URL: https://issues.apache.org/jira/browse/TUSCANY-1430 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-beta1 Reporter: Frank Budinsky Fix For: Java-SDO-1.0 The SDOClass.javajet needs to use INTERNAL_ features when calling inverseAdd(), inverseRemove(), and notify() methods. ChangeSummary doesn't work properly otherwise. -- 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] Commented: (TUSCANY-1430) SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls
[
https://issues.apache.org/jira/browse/TUSCANY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512278
]
Frank Budinsky commented on TUSCANY-1430:
-
Test case that illustrates the problem:
The XSD:
xsd:schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://abc.com/services;
xmlns:tns=http://abc.com/services;
xmlns:sdo=commonj.sdo xmlns:sdoJava=commonj.sdo/java
xmlns:sdoXml=commonj.sdo/xml
sdoJava:package=com.abc.services
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xsd:import namespace=commonj.sdo schemaLocation=datagraph.xsd /
xsd:complexType name=NestedType
xsd:sequence
xsd:element name=test1
type=xsd:string /
xsd:element name=test2
type=xsd:string /
/xsd:sequence
/xsd:complexType
xsd:complexType name=MyDataGraph
complexContent
extension base=sdo:BaseDataGraphType
xsd:sequence
xsd:element name=NestedType
type=tns:NestedType /
/xsd:sequence
/extension
/complexContent
/xsd:complexType
xsd:complexType name=Input
xsd:sequence
xsd:element name=MyDataGraph type=tns:MyDataGraph/
/xsd:sequence
/xsd:complexType
/xsd:schema
The Java Test:
==
package com.abc.services;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import org.apache.tuscany.sdo.util.SDOUtil;
import com.abc.services.impl.TestFactoryImpl;
import commonj.sdo.DataGraph;
import commonj.sdo.DataObject;
import commonj.sdo.Type;
import commonj.sdo.helper.XMLHelper;
import commonj.sdo.impl.HelperProvider;
public class TestABC {
public static void main(String[] args) {
TestFactory.INSTANCE.register(HelperProvider.getDefaultContext());
NestedType nested;
System.out.println( static graph
**\n);
Input input = TestFactory.INSTANCE.createInput();
MyDataGraph staticGraph = TestFactory.INSTANCE.createMyDataGraph();
nested = TestFactory.INSTANCE.createNestedType();
staticGraph.setNestedType(nested);
((DataObject)nested).set(test1, test1);
((DataObject)nested).set(test2, test2);
staticGraph.getChangeSummary().beginLogging();
((DataObject)nested).set(test2, test2_modified);
nested.setTest1(test1_modified);
input.setMyDataGraph(staticGraph);
saveGraph(staticGraph);
System.out.println(\n\n);
System.out.println( dynamic graph
**\n);
DataGraph dynamicGraph = SDOUtil.createDataGraph();
Type type = ((TestFactoryImpl)TestFactory.INSTANCE).getNestedType();
nested = (NestedType)dynamicGraph.createRootObject(type);
((DataObject)nested).set(test1, test1);
((DataObject)nested).set(test2, test2);
dynamicGraph.getChangeSummary().beginLogging();
((DataObject)nested).set(test2, test2_modified);
nested.setTest1(test1_modified);
saveGraph(dynamicGraph);
}
/**
* @param dataobject
*/
private static void saveGraph(MyDataGraph dataobject) {
ByteArrayOutputStream os = new ByteArrayOutputStream();
try {
XMLHelper.INSTANCE.save((DataObject)dataobject, null, datagraph,
os);
System.out.println(os.toString());
} catch (IOException e) {
e.printStackTrace();
}
}
/**
* @param datagraph
*/
private static void saveGraph(DataGraph datagraph) {
try {
ByteArrayOutputStream os = new ByteArrayOutputStream();
SDOUtil.saveDataGraph(datagraph, os, null);
System.out.println(os.toString());
} catch (IOException e1) {
e1.printStackTrace();
}
}
}
SDO codegen is needs to use internal property numbers for inverseAdd,
inverseRemove, and notify calls
-
Key: TUSCANY-1430
URL: https://issues.apache.org/jira/browse/TUSCANY-1430
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
Reporter: Frank Budinsky
Fix For: Java-SDO-1.0
The SDOClass.javajet needs to use INTERNAL_ features when calling
inverseAdd(), inverseRemove(), and notify() methods. ChangeSummary doesn't
work properly otherwise
[jira] Resolved: (TUSCANY-1430) SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls
[ https://issues.apache.org/jira/browse/TUSCANY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1430. - Resolution: Fixed Fixed in revision 555790. SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls - Key: TUSCANY-1430 URL: https://issues.apache.org/jira/browse/TUSCANY-1430 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-beta1 Reporter: Frank Budinsky Fix For: Java-SDO-1.0 The SDOClass.javajet needs to use INTERNAL_ features when calling inverseAdd(), inverseRemove(), and notify() methods. ChangeSummary doesn't work properly otherwise. -- 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: Runtime access to sdoJava:package
Given a Type, you can call type.getInstanceClass() and if it's not null, the package name can be retrieved from the Class. If the instanceClass is null, there is no static class, and hence no package for the type. Frank. Pinaki Poddar [EMAIL PROTECTED] wrote on 07/09/2007 05:53:21 PM: Thanks Fuhwei. But the underlying EMF Ecore allowed a path to do the same -- at least as far I can see in my debugger. In a implementation that is based upon another impl -- it often helps to make the underlying impl available via 'public Object getDelegate();' or some such method. Is there any such under-the-hood way to get hold of EMF impl classes in Tuscany's SDO impl -- even it does require me to cast to specific impl from the commonj.sdo API instances. Pinaki Poddar 972.834.2865 -Original Message- From: Fuhwei Lwo [mailto:[EMAIL PROTECTED] Sent: Monday, July 09, 2007 4:46 PM To: tuscany-dev@ws.apache.org Subject: Re: Runtime access to sdoJava:package Hi Pinaki, sdoJava:package is only used by the users to control what Java package name should be generated during the generation of static SDO APIs. I don't think its info can be accessed from the standard SDO APIs. Fuhwei Pinaki Poddar [EMAIL PROTECTED] wrote: Hello, a newbie question: 1. *.xsd has declared sdoJava:package=com.acme.mydomain 2. With XSDHelper.INSTANCE (or with some other helper) how does one programatically access the package name com.acme.mydomain? A more general question, does SDO Type has a 'package' notion or such notion is only valid if SDO Type is converted to Java Class? Thanks Pinaki Poddar 972.834.2865 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - 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: Runtime access to sdoJava:package
Hi Pinaki,
As you said, what you're doing isn't very kosher. First, you shouldn't
rely on EMF behavior, because it's subject to change and second, the
EPackage name isn't always the same as the Java package, even though it is
when sdoJava:package is specified. I don't really understand why you want
this value anyway. It's only purpose (see SDO spec) is for the code
generator to determine the java package for generated interfaces. It's
meaningless information if you don't generate static SDOs, and if you do
generate them, then getInstanceClass() will be non-null and you can get
the value from it.
Frank
Pinaki Poddar [EMAIL PROTECTED] wrote on 07/10/2007 12:43:04 PM:
Hi,
Thanks for your help.
When the only input is a XML Schema, and SDO types are defined via:
List types = XSDHelper.INSTANCE.define(xsdInputStream,
schemaLocation);
The resultant types have non-null getInstanceClass() only when
type.isDataType()==true.
However, I have figured a way to access the sdoJava:package. May not be
kosher but here it is:
Runtime class of commonj.sdo.Type is
org.apache.tuscany.sdo.impl.ClassImpl.
This runtime class will reveal the underlying EMF implementaion's
Epackage.
For example, if 'po.xsd' defines a type named 'USAddress' and declares
sdoJava:package=com.acme.foo, then following test will pass:
public void testPackageNameIsAvailableViaDowncast() {
Type addressType = getType(USAddress);
assertTrue(addressType instanceof ClassImpl);
assertEquals(com.acme.foo,((ClassImpl)addressType).getEPackage().getNa
me());
}
And following tests will pass too:
public void testInstanceClassIsNullForUserType() {
Type addressType = getType(USAddress);
assertFalse(addressType.isDataType());
assertNull(addressType.getInstanceClass());
}
public void testInstanceClassIsNotNullForDataType() {
Type skuType = getType(SKU);
assertTrue(skuType.isDataType());
assertNotNull(skuType.getInstanceClass());
}
Pinaki Poddar
972.834.2865
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 10, 2007 7:55 AM
To: tuscany-dev@ws.apache.org
Subject: RE: Runtime access to sdoJava:package
Given a Type, you can call type.getInstanceClass() and if it's not null,
the package name can be retrieved from the Class. If the instanceClass
is null, there is no static class, and hence no package for the type.
Frank.
Pinaki Poddar [EMAIL PROTECTED] wrote on 07/09/2007 05:53:21 PM:
Thanks Fuhwei.
But the underlying EMF Ecore allowed a path to do the same -- at least
as far I can see in my debugger.
In a implementation that is based upon another impl -- it often helps
to make the underlying impl available via 'public Object
getDelegate();' or some such method. Is there any such under-the-hood
way to get hold of EMF impl classes in Tuscany's SDO impl -- even it
does require me to cast to specific impl from the commonj.sdo API
instances.
Pinaki Poddar
972.834.2865
-Original Message-
From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
Sent: Monday, July 09, 2007 4:46 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Runtime access to sdoJava:package
Hi Pinaki,
sdoJava:package is only used by the users to control what Java package
name should be generated during the generation of static SDO APIs. I
don't think its info can be accessed from the standard SDO APIs.
Fuhwei
Pinaki Poddar [EMAIL PROTECTED] wrote: Hello, a newbie question:
1. *.xsd has declared
sdoJava:package=com.acme.mydomain
2. With XSDHelper.INSTANCE (or with some other helper)
how does one programatically access the package name
com.acme.mydomain?
A more general question,
does SDO Type has a 'package' notion or such notion is only valid if
SDO Type is converted to Java Class?
Thanks
Pinaki Poddar
972.834.2865
Notice: This email message, together with any attachments, may
contain information of BEA Systems, Inc., its subsidiaries and
affiliated entities, that may be confidential, proprietary,
copyrighted and/or legally privileged, and is intended solely for the
use of the individual or entity named in this message. If you are not
the intended recipient, and have received this message in error,
please immediately return this by email and then delete it.
Notice: This email message, together with any attachments, may
contain information of BEA Systems, Inc., its subsidiaries and
affiliated entities, that may be confidential, proprietary,
copyrighted and/or legally privileged, and is intended solely for the
use of the individual or entity named in this message. If you are not
the intended recipient, and have received this message in error,
please immediately return this by email and then delete
Re: [SDO Java Question] - Is this checking sufficient?
The SDOHelper.isDocumentRoot() method is the client API for this. In our
EMF-based impl, checking for the ExtendedMetaData name is is the right
check. The ExtendedMetaData name of a DocumentRoot type is never
DocumentRoot - it's always .
Frank.
Fuhwei Lwo [EMAIL PROTECTED] wrote on 07/09/2007 12:53:41 PM:
In SDOHelperImpl.java, there is a method called isDocumentRoot()
described below. I remember in some cases the name of DocumentRoot
type is called DocumentRoot that would fail the method. My
question is what checking is sufficient for identifying a document
root type. Thanks.
public boolean isDocumentRoot(Type type)
{
return
.equals(SDOExtendedMetaData.INSTANCE.getName((EClassifier)type));
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1408) Cannot programmatically define a SDO property matching to XSD element
[ https://issues.apache.org/jira/browse/TUSCANY-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510683 ] Frank Budinsky commented on TUSCANY-1408: - The spec says this in section 7.1.3: The xmlElement property is set to true on Properties that are represented as XML elements. If no value is present there is no information about the mapping. If the value is false, it indicates that it is not an element, but it does not guarantee that there is mapping to an XML attribute. Only if the property was defined using an XML Schema will a value of false indicate that the property maps to an attribute. If the property was defined using other means, for example, TypeHelper.define(), then a value of false indicates a desire to represent the property as an attribute, but it may not be possible. For example, a containment or nullable property must be serialized as an XML element. So, what I think is the simplest approach that is compliant and also works is to simply make Element the default. If we want to also add support for xmlElement=False, we need to make sure that we set it back to Element in setContainment and setNullable (any where else?) methods. I'm also not sure if we should be adding the xmlElment argument to the createProperty method, since it's an XML specific thing. It would probably be better to have a setPropertyXMLKind(Property, boolean) method instead, which is called after createProperty(). Cannot programmatically define a SDO property matching to XSD element - Key: TUSCANY-1408 URL: https://issues.apache.org/jira/browse/TUSCANY-1408 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Fix For: Java-SDO-1.0 Attachments: 1408.patch The following code will define XSD attributes for name and address properties. I cannot find a way to define them as XSD elements. HelperContext hc = HelperProvider.getDefaultContext(); DataFactory dataFactory = hc.getDataFactory(); TypeHelper types = hc.getTypeHelper(); Type stringType = types.getType(commonj.sdo, String); DataObject customerType = dataFactory.create(commonj.sdo,Type); customerType.set(uri, http://sample.data/customer;); customerType.set(name, Customer); //create customer name property DataObject custNameProperty = customerType.createDataObject(property); custNameProperty.set(name, name); custNameProperty.set(type, stringType); //create address property DataObject addressProperty = customerType.createDataObject(property); addressProperty.set(name, address); addressProperty.set(type, stringType); //now define the Customer type so that customers can be made Type typeDefined = types.define(customerType); -- 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] Resolved: (TUSCANY-1410) DataHelperImpl.toCalendar() with null locale should use default locale
[
https://issues.apache.org/jira/browse/TUSCANY-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1410.
-
Resolution: Fixed
Fixed in revision 553921.
DataHelperImpl.toCalendar() with null locale should use default locale
--
Key: TUSCANY-1410
URL: https://issues.apache.org/jira/browse/TUSCANY-1410
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Andy Grove
Priority: Minor
DataHelperImpl.toCalendar() currently returns null if the locale parameter is
null. However, according to the published SDO API javadoc comments, if locale
is null then the default locale should be used. To resolve this, the
following code can be added at the start of the method.
if (locale == null) {
locale = Locale.getDefault();
}
--
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: How does one specify a Property as containment property in XML Schema?
Or better yet would be to add the po: to the types where it's missing:
xsd:element name=shipTo type=USAddress/
xsd:element name=billTo type=USAddress/
xsd:element name=items type=Items/
like this:
xsd:element name=shipTo type=po:USAddress/
xsd:element name=billTo type=po:USAddress/
xsd:element name=items type=po:Items/
The problem is that XSDHelper.define() doesn't complain about errors like
this, it just treats type=USAddress as an unknown type.
Frank.
[EMAIL PROTECTED] wrote on 07/03/2007 07:29:40 AM:
Pinaki,
there are errors in the schema you are using. If you remove the :po
from
xmlns:po=http://www.example.com/PO; and remove po: from the rest of
the
file, when used in referencing type or element definitions, then your
test
code succeeds.
Regards,Kelvin.
Regards, Kelvin.
On 03/07/07, Pinaki Poddar [EMAIL PROTECTED] wrote:
I switched to EMF core API. The same error. Looks like Tuscany SDO is
wrapping EMF core -- is that right?
Pinaki Poddar
972.834.2865
-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 3:54 AM
To: tuscany-dev@ws.apache.org
Subject: Re: How does one specify a Property as containment property
in
XML Schema?
Pinaki,
perfect, thanks (yes, the attachments are stripped by the list),
will
try them out soon.
Kelvin
On 03/07/07, Pinaki Poddar [EMAIL PROTECTED] wrote:
Are you not seeing the e-mail attachements TestSDO.java and po.xsd?
In any case, here they are
= TestSDO.java
==
package test;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.List;
import javax.persistence.EntityManager; import
javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
import org.apache.tuscany.sdo.helper.HelperProviderImpl;
import com.bea.jpa.SDOEntityManager;
import com.bea.jpa.SDOEntityManagerFactory;
import commonj.sdo.DataObject;
import commonj.sdo.helper.DataFactory; import
commonj.sdo.helper.XMLHelper; import commonj.sdo.helper.XSDHelper;
import commonj.sdo.impl.HelperProvider;
import junit.framework.TestCase;
/**
* JUnit Tests to read a meta-model from XML Schema and create
instances
* according to the meta-model.
*
* @author ppoddar
*
*/
public class TestSDO extends TestCase {
private static final String RESOURCE_SDO_MODEL = po.xsd;
private static final String SDO_MODEL_NAMESPACE =
http://www.example.com/PO;;
/**
* Create a SDO MetaData Model from a XML Schema and
populate
instances.
* Assumes 'po.xsd' be available in classpath as resource.
*
*/
public void testCreateModel() {
InputStream xsdInputStream =
this.getClass().getClassLoader()
.getResourceAsStream(RESOURCE_SDO_MODEL);
assertNotNull(xsdInputStream);
String schemaLocation = null;
List/* Type */types =
XSDHelper.INSTANCE.define(xsdInputStream,
schemaLocation);
assertTrue(types != null !types.isEmpty());
assertTrue(types.size() = 2);
DataObject purchaseOrder =
DataFactory.INSTANCE.create(
SDO_MODEL_NAMESPACE,
PurchaseOrderType);
purchaseOrder.setString(orderDate, 1999-10-20);
DataObject shipTo =
purchaseOrder.createDataObject(shipTo);
shipTo.set(country, US);
shipTo.set(name, Alice Smith);
shipTo.set(street, 123 Maple Street);
shipTo.set(city, Mill Valley);
shipTo.set(state, CA);
shipTo.setString(zip, 90952);
DataObject billTo =
purchaseOrder.createDataObject(billTo);
billTo.set(country, US);
billTo.set(name, Robert Smith);
billTo.set(street, 8 Oak Avenue);
billTo.set(city, Mill Valley);
billTo.set(state, PA);
billTo.setString(zip, 95819);
purchaseOrder.set(comment, Hurry, my lawn is
going
wild!);
DataObject items =
purchaseOrder.createDataObject(items);
DataObject item1 = items.createDataObject(item);
item1.set(partNum, 872-AA);
item1.set(productName, Lawnmower);
item1.setInt(quantity, 1);
item1.setString(USPrice, 148.95);
item1.set(comment, Confirm this is electric);
DataObject
Frank Budinsky/Toronto/IBM is out of the office.
I will be out of the office starting 06/27/2007 and will not return until 07/09/2007. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Fuhwei Lwo for Tuscany Committer
Absolutely +1 from me! Frank. kelvin goodson [EMAIL PROTECTED] wrote on 06/26/2007 07:10:23 AM: I'd like to propose Fuhwei Lwo as a Tuscany Committer. According to my gmail archive he has, since mid of 2006, posted 114 times to tusany-dev, 79 of those times resulting from interactions with JIRA issue management. He has raised 34 JIRAs (see [1]) The gmail search -- from:fuhwei [jira] Attachment: shows that Fuhwei has attached around 27 patches to JIRAs. The JIRAs he raises, the comments he makes and the solutions he provides demonstrate in depth knowledge of SDO and clearly he will be a strong asset for the community. Please vote to give Fuhwei this well deserved status Regards, Kelvin. [1] http://issues.apache.org/jira/secure/IssueNavigator.jspa? reset=truepid=12310210reporterSelect=specificuserreporter=fuhweisorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CTS] safeguarding setUp() methods against failure due to existing types
Hi Andy, That sounds like a reasonable approach to me. Thanks, Frank. [EMAIL PROTECTED] wrote on 06/26/2007 09:21:23 AM: CTS test setUp() methods generally make use of the TestHelper.createHelperContext method to create a new context. I agree that this is the correct design. However, SDO 2.1 does not require implementations to support multiple contexts - only a default context is mandated. Therefore I am planning to add some additional code to some setUp() methods so they do not attemp to create types if those types already exist in the HelperContext provided by the TestHelper. This approach will ensure that the CTS works equally well for implementations that support multiple contexts as well as implementations that only support a single default context. If anyone has any objections, please let me know. Thanks, Andy. - 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: [Tuscany SDO] JIRA-1317 - questions/doubts
Since the word feature is an EMF term (in SDO it's called property) I would recommend changing the name of the new option in Tuscany. Something like XMLOptions.XML_LOAD_UNKNOWN_PROPERTIES would be a good name. Frank. Amita Vadhavkar [EMAIL PROTECTED] wrote on 06/22/2007 09:33:22 AM: Hello, I am trying to summarize the discussion so far below and about to finish the patch based on that. I will attach it when tested completely in a day or so. Please see the ASSUMPTIONS and PATHS in particular to see if there is some wrong understanding there. ASSUMPTION: -- No new load options except XMLResource.OPTION_RECORD_UNKNOWN_FEATURE are required. This JIRA caters for only load options to be provided by default and does not consider save options. Existing load options XML_LOAD_SCHEMA - already implemented in SDOXMLResourceImpl XML_LOAD_LAX_FORM - already implemented in SDOXMLResourceImpl Behavior - the above options are required to be passed using xmlhelper.load() by user. There is no way at present in tuscany-sdo-lib where user can assume default options. This JIRA is to provide this default behavior where XML_LOAD_SCHEMA and XML_LOAD_LAX_FORM will assume default true. User will need to pass FALSE option if this is not desired (For XML_LOAD_SCHEMA - Boolean.FALSE, for XML_LOAD_LAX_FORM Integer(0)) As the mail [Tuscany SDO] JIRA-1317 - questions/doubts says - ResolvableImpl - is not in working condition, no code changes done to it. Also, there is a mail discussion http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17479.html which says need to have XML_LOAD_SCHEMA ON by default, it is done using this JIRA. CHANGES: marked with //JIRA-1317 -- impl *XMLHelperImpl *HelperContextImpl *HelperProviderImpl *AllTests *XLMOptionsTestCase *SDOHelperImpl *XMLStreamHelperImpl lib *SDOUtil *HelperProviderBase *SDOHelper *XMLStreamHelper QUESTION: -- Is there a need to modify CTS for this? or just tuscany-sdo-impl/tests? What is the standard convention we follow for Unit Testing JIRA in SDO? NOTE: -- This JIRA does not include anything for XMLResource.OPTION_RECORD_UNKNOWN_FEATURE. Checking more details for that. PATHS: -- HelperProviderBase-HelperProviderImpl-HelperContextImpl-XMLHelperImpl-XMLDocumentImpl SDOUtil-SDOHelper-SDOHelperImpl-HelperContextImpl-XMLHelperImpl-XMLDocumentImpl SDOUtil-SDOHelperImpl-XMLStreamHelperImpl-XMLDocumentImpl Regards, Amita On 6/22/07, Frank Budinsky [EMAIL PROTECTED] wrote: Amita, This part of your mapping is wrong: XML_SAVE_LINE_BREAK OPTION_FORMATTED XML_SAVE_INDENT OPTION_FORMATTED XML_SAVE_MARGIN OPTION_FORMATTED These options don't map to anything in EMF. They are Tuscany defined options which are processed in SDOXMLResourceImpl. Frank. Fuhwei Lwo [EMAIL PROTECTED] wrote on 06/21/2007 02:44:55 PM: Hi Amita, Currently Tuscany SDO is not exposing all the EMF options for load and save. Also it's not 1:1 mapping from SDO to EMF options. That's why all the supported SDO options are described in the org.apache. tuscany.sdo.api.SDOHelper$XMLOptions. In order to add more options to SDO, you need to modify SDOHelper$XMLOptions then implement the new SDO option by either mapping to EMF's option or implementing your own. Also, I believe load and save options are mutually exclusive which means passing save options to load method will be a no-op. In your test case for JIRA 1317, you cannot do something like this: options.put(XMLResource.OPTION_SAVE_DOCTYPE, Boolean.FALSE); because it's using EMF API not SDO's. From a SDO user point of view because it's using EMF API not SDO's. From a SDO user point of view, he/she should not need to import any EMF packages in his/her SDO program. Fuhwei Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I got the below mapping between Tuscany's XMLOptions and emf XMLResource Options Is this what is intended to be passed to in load method, i.e. is it expected to have this mapping and pass appropriate options set to the doLoad()? Also, we have multiple options for line formatting whereas there is only OPTION_FORMATTED in emf XMLResource, so what needs to be done here? Mapping:- XML_SAVE_LINE_BREAK OPTION_FORMATTED XML_SAVE_LINE_BREAK OPTION_FORMATTED XML_SAVE_INDENT OPTION_FORMATTED XML_SAVE_MARGIN OPTION_FORMATTED XML_SAVE_LINE_WIDTH OPTION_LINE_WIDTH XML_SAVE_DOCTYPE OPTION_SAVE_DOCTYPE XML_LOAD_SCHEMA OPTION_SCHEMA_LOCATION XML_LOAD_LAX_FORM OPTION_EXTENDED_META_DATA - already implemented When we talk about moving away from emf, what will happen to these options? I am yet to follow all the answers to the questions I had, but after passing a couple of options (say OPTION_FORMATTED, OPTION_SAVE_DOCTYPE) and calling load(), I
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
The options are moved to lib as well (see org.apache.tuscany.sdo.api.SDOHelper.XMLOptions). Implementation of the options needs to be in the impl project since they have EMF dependencies. Frank. kelvin goodson [EMAIL PROTECTED] wrote on 06/21/2007 05:23:56 AM: snip/ 2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in tuscany-sdo-impl? As this class is in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of options implementation in tuscany-sdo-impl, as these impl classes are not visible in tuscany-sdo-lib. snip/ Frank Budinsky has the reorganisation of code from just the impl project to an impl/lib split as work in progress [1]. So I guess we need to understand the reason for having ResolvableImpl in the lib project. Without deep investigation my guess is that Frank has good reasons for making the move, so I can see a couple of alternatives, but I need to gain more insight to know which would be best 1) investigate whether the correct home for the options is in the lib project 2) provide some kind of a mapping of options between the impl layer and the lib layer I think it would be good if you could put down your design ideas or provide a prototype patch so that I can see the problem for the wider perspective. Regards, Kelvin. [1] http://issues.apache.org/jira/browse/TUSCANY-1283 - 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: [Tuscany SDO] JIRA-1317 - questions/doubts
Amita,
This part of your mapping is wrong:
XML_SAVE_LINE_BREAK OPTION_FORMATTED
XML_SAVE_INDENT OPTION_FORMATTED
XML_SAVE_MARGIN OPTION_FORMATTED
These options don't map to anything in EMF. They are Tuscany defined
options which are processed in SDOXMLResourceImpl.
Frank.
Fuhwei Lwo [EMAIL PROTECTED] wrote on 06/21/2007 02:44:55 PM:
Hi Amita,
Currently Tuscany SDO is not exposing all the EMF options for load
and save. Also it's not 1:1 mapping from SDO to EMF options. That's
why all the supported SDO options are described in the org.apache.
tuscany.sdo.api.SDOHelper$XMLOptions. In order to add more options
to SDO, you need to modify SDOHelper$XMLOptions then implement the
new SDO option by either mapping to EMF's option or implementing
your own. Also, I believe load and save options are mutually
exclusive which means passing save options to load method will be a
no-op.
In your test case for JIRA 1317, you cannot do something like this:
options.put(XMLResource.OPTION_SAVE_DOCTYPE, Boolean.FALSE);
because it's using EMF API not SDO's. From a SDO user point
of view
because it's using EMF API not SDO's. From a SDO user point of view,
he/she should not need to import any EMF packages in his/her SDO
program.
Fuhwei
Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi,
I got the below mapping between Tuscany's XMLOptions and emf XMLResource
Options
Is this what is intended to be passed to in load method, i.e. is it
expected
to
have this mapping and pass appropriate options set to the doLoad()?
Also, we
have
multiple options for line formatting whereas there is only
OPTION_FORMATTED
in emf XMLResource, so what needs to be done here?
Mapping:-
XML_SAVE_LINE_BREAK OPTION_FORMATTED
XML_SAVE_LINE_BREAK OPTION_FORMATTED
XML_SAVE_INDENT OPTION_FORMATTED
XML_SAVE_MARGIN OPTION_FORMATTED
XML_SAVE_LINE_WIDTH OPTION_LINE_WIDTH
XML_SAVE_DOCTYPE OPTION_SAVE_DOCTYPE
XML_LOAD_SCHEMA OPTION_SCHEMA_LOCATION
XML_LOAD_LAX_FORM OPTION_EXTENDED_META_DATA - already implemented
When we talk about moving away from emf, what will happen to these
options?
I am yet to follow all the answers to the questions I had, but after
passing
a couple of
options (say OPTION_FORMATTED, OPTION_SAVE_DOCTYPE) and calling load(),
I
see that in
SDOXMLResourceImpl.doLoad() that options are getting passed, but I do
not
see any
difference in the deserialized DO(see the testcase - dumping do to
console
using xmlhelper)
with the option ON/OFF? So what super.doLoad() is
doing?
I am attaching a patch file JIRA_1317_June21.txt, just to show what code
changes I have done so far, this is
far away from the solution though. I will collect all answers from this
thread and
refine the patch, but kind of getting lost with doLoad().
Regards,
Amita
On 6/21/07, Frank Budinsky wrote:
The GENERATED_LOADER was used in conjuction with the -generateLoader
option in JavaGenerator. The JavaDoc says this:
* -generateLoader
* Generate a fast XML parser/loader for instances of the
model.
The details of this option are
* subject to change, but currently it generates two additional
classes in a util package:
*
ResourceImpl and
ResourceFactoryImpl. To use
the generated loader at runtime,
* you need to pass an option to the XMLHelper.load() method
like
this:
* Map options = new HashMap();
* options.put(GENERATED_LOADER,
ResourceFactoryImpl.class);
* XMLDocument doc = XMLHelper.INSTANCE.load(new
FileInputStream(somefile.xml), null, options);
* Note: this option currently only works for simple schemas
without substitution groups or wildcards.
Note, however, that this was always an unsupported option (prototype)
and
it is now completely broken, since we swiched to the -noEMF code
generator
patterns.
Frank.
kelvin goodson wrote on 06/21/2007 05:47:37
AM:
3)What is meaning of below code in XMLDocumentImpl?
if (options instanceof Map)
{
Class resourceFactoryClass =
(Class)((Map)options).get(GENERATED_LOADER);
if (resourceFactoryClass != null)
{
try
{
Object resourceFactory =
resourceFactoryClass.newInstance();
resourceSet.getResourceFactoryRegistry().
getExtensionToFactoryMap().put(*,
resourceFactory);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
I looked back at the svn history, and this code has been there
since
the original contribution of code to Apache.
My guess from the name of the option and other brushes with topics
of
a similar nature is that this allows optimised loads of XML
documents
of a specific nature by employing a generated Factory which loads
only
documents conforming to s specific XML schema.
It would
[jira] Updated: (TUSCANY-1364) sdo-impl should export org.apache.tuscany.sdo.model.internal
[
https://issues.apache.org/jira/browse/TUSCANY-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky updated TUSCANY-1364:
Component/s: Java SDO Implementation
Fix Version/s: Java-SDO-1.0
Affects Version/s: Java-SDO-beta1
sdo-impl should export org.apache.tuscany.sdo.model.internal
Key: TUSCANY-1364
URL: https://issues.apache.org/jira/browse/TUSCANY-1364
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
Reporter: Brian Murray
Fix For: Java-SDO-1.0
Attachments: 1364.patch
The org.apache.tuscany.sdo.model.internal package was introduced somewhat
recently, and is visible in a statically generated class. The problem is
that the impl project does not export this package.
For example, I ran the XSD2JavaGenerator tool on
sdo\impl\src\test\resources\bank.xsd and here are some snippets from the
resulting MybankFactory.impl:
import org.apache.tuscany.sdo.model.internal.InternalFactory;
...
public static MybankFactoryImpl init()
{
if (isInited) return
(MybankFactoryImpl)FactoryBase.getStaticFactory(MybankFactoryImpl.NAMESPACE_URI);
MybankFactoryImpl theMybankFactoryImpl = new MybankFactoryImpl();
isInited = true;
// Initialize dependencies
SDOUtil.registerStaticTypes(SDOFactory.class);
SDOUtil.registerStaticTypes(ModelFactory.class);
SDOUtil.registerStaticTypes(InternalFactory.class);
I am providing a patch to the sdo/impl/pom.xml which will export this package.
--
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: IDE-specific files in svn
Agree with all that, plus the fact that you need to install maven and check-out using the command line. If we had .project files, people could check-out the projects they want directly into Eclipse and work with them without ever needing mvn. Frank. kelvin goodson [EMAIL PROTECTED] wrote on 06/14/2007 04:56:40 AM: There's pain in the process, not huge, but irritating first off there's the definition of the M2_REPO variable, not a huge problem, especially if you stick to just one workspace. I tend to create workspaces as and when I need them, and I can't see how to make my variable definition cross multiple workspaces. Next, and probably more significant is removing the binary dependencies and setting up inter project dependencies. After the maven eclipse:eclipse command for example, the tools project depends on the binary artifacts generated from the maven build of the impl, lib and api projects . What most developers are going to want is inter project dependencies. So there's quite a bit of manual deletion of jars from the class path entries, then, you might want for example the lib project to expose the api projects interface, etc. etc. I'm quite well practised at setting this up, but its still a 5 minute job. Regards, Kelvin. On 14/06/07, ant elder [EMAIL PROTECTED] wrote: On 6/14/07, Frank Budinsky [EMAIL PROTECTED] wrote: Hi, I remember about a year ago discussing whether or not it is acceptable/appropriate to check-in IDE specific files (e.g., Eclipse .project files) into svn, and we decided to not do it. Does anyone remember if this was really an Apache policy, or just a decision we made for Tuscany? If the latter, I wonder if we should reconsider. Personally, I think it would be very convenient if we had the Eclipse .project and .classfile in the projects, so that people could just check out Tuscany projects directly into Eclipse. For people not using Eclipse, having these superfluous files around really doesn't seem like a big deal. I also wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files that Eclipse users (like me) would just ignore. What do others think about this? AFAIK there's no 'rule' that says this must not be done. However no other Apache (or non-Apache) project that i can think of does this so it would be unusual and that makes me wonder why. Is it just the extra mvn -Pelcipse eclipse:eclipse thats the problem or is there something else about it thats a pain? (Also we may be able to get rid of the '-Peclipse' bit now if that would make it easier to bare? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IDE-specific files in svn
I was assuming we would check in one default configuration. There's nothing preventing people from running maven eclipse:eclipse or manually changing them in their own environments. We wouldn't want people to accidentally check their changes back in so we'd probably want them on the svn:ignore list. I wasn't really implying that we need to have a policy that every Tuscany project include IDE files. I was really just wondering if it would be acceptable to allow such files to be checked in to any of the projects. For SDO, for example, the two projects that I know are currently being reused by other projects (in isolation) are sdo-api and sdo-lib. Having Eclipse files for just those two would be helpful. Frank. [EMAIL PROTECTED] wrote on 06/14/2007 05:14:44 AM: Right thats the problem isn't it. If we check in the IDE files in we're assuming one particular way of using the code. For the SCA project which is quite big i've several different workspaces - one with every thing including modules, samples and itest, another workspace just with modules, and another just with samples etc. That wouldn't work with the IDE files checked in as I'd have to change them for the the different workspaces and then when doing checkin's try real hard to not accidentally commit my local changes to the IDE files which would be a real pain and almost certainly quite often happen by accident. ...ant On 6/14/07, kelvin goodson [EMAIL PROTECTED] wrote: There's pain in the process, not huge, but irritating first off there's the definition of the M2_REPO variable, not a huge problem, especially if you stick to just one workspace. I tend to create workspaces as and when I need them, and I can't see how to make my variable definition cross multiple workspaces. Next, and probably more significant is removing the binary dependencies and setting up inter project dependencies. After the maven eclipse:eclipse command for example, the tools project depends on the binary artifacts generated from the maven build of the impl, lib and api projects . What most developers are going to want is inter project dependencies. So there's quite a bit of manual deletion of jars from the class path entries, then, you might want for example the lib project to expose the api projects interface, etc. etc. I'm quite well practised at setting this up, but its still a 5 minute job. Regards, Kelvin. On 14/06/07, ant elder [EMAIL PROTECTED] wrote: On 6/14/07, Frank Budinsky [EMAIL PROTECTED] wrote: Hi, I remember about a year ago discussing whether or not it is acceptable/appropriate to check-in IDE specific files (e.g., Eclipse .project files) into svn, and we decided to not do it. Does anyone remember if this was really an Apache policy, or just a decision we made for Tuscany? If the latter, I wonder if we should reconsider. Personally, I think it would be very convenient if we had the Eclipse .project and .classfile in the projects, so that people could just check out Tuscany projects directly into Eclipse. For people not using Eclipse, having these superfluous files around really doesn't seem like a big deal. I also wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files that Eclipse users (like me) would just ignore. What do others think about this? AFAIK there's no 'rule' that says this must not be done. However no other Apache (or non-Apache) project that i can think of does this so it would be unusual and that makes me wonder why. Is it just the extra mvn -Pelcipse eclipse:eclipse thats the problem or is there something else about it thats a pain? (Also we may be able to get rid of the '-Peclipse' bit now if that would make it easier to bare? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMF Maven Repository] EMF 2.3 Repository?
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]
Re: [SDO Java DISCUSS] Contents of the next SDO release
Ant, You said this: While building that it could also rename the emf packages to start with org.apache.tuscany to avoid any version problems when using Tuscany SDO with existing EMF code. We have discussed doing this for quite some time. It would certainly eliminate the EMF version problems, but I never knew if the Eclipse and Apache licenses actually allow us to do this. Are you sure that this is allowed? Thanks, Frank [EMAIL PROTECTED] wrote on 06/13/2007 08:54:23 AM: On 6/11/07, kelvin goodson [EMAIL PROTECTED] wrote: 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 One thing we should do for this right now is move spec/sdo-api from the Tuscany SVN trunk top-level folder into the sdo folder, so sdo/sdo-api. Another thing i'd wondered about was making an sdo jar that contained all the emf dependencies to simplify things for users. So that would be something like all the codegen, ecore, xsd and tuscany-sdo-* jars merged into a single sdo-complete.jar. While building that it could also rename the emf packages to start with org.apache.tuscany to avoid any version problems when using Tuscany SDO with existing EMF code. Does anyone else think this would be useful? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IDE-specific files in svn
Hi, I remember about a year ago discussing whether or not it is acceptable/appropriate to check-in IDE specific files (e.g., Eclipse .project files) into svn, and we decided to not do it. Does anyone remember if this was really an Apache policy, or just a decision we made for Tuscany? If the latter, I wonder if we should reconsider. Personally, I think it would be very convenient if we had the Eclipse .project and .classfile in the projects, so that people could just check out Tuscany projects directly into Eclipse. For people not using Eclipse, having these superfluous files around really doesn't seem like a big deal. I also wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files that Eclipse users (like me) would just ignore. What do others think about this? Thanks, Frank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO Java DISCUSS] Contents of the next SDO release
This sounds good to me. I assume Christian's suggestion for additional SDOUtil methods, and Bert/Steffen's request for notification support, are two more candidates for 1.0. Christian and Bert/Steffen, are you planning to open JIRAs for those? I'm worried about how many things are really doable, given the target we have in mind for the release (next month). Are people going to help with these features by providing patches? If not, is delaying the release for another month or two acceptable? Personally, I'd like to stick with a July target for the release. If somebody wants a feature that we can't handle in time, they'll need to help implement it. Otherwise it slips to the next release. What do others think? By the way, that reminds me that we need someone to be release manager for this release. Any volunteers? If not, maybe Kelvin, you would be willing to do it, since you've already been doing lots of the prep work. Thanks, Frank [EMAIL PROTECTED] wrote on 06/11/2007 06:02:20 AM: 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
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503542 ] Frank Budinsky commented on TUSCANY-513: Hi Ron, If I understand this, the only template change you made was to rename the getType() method in the generated impl classes to getStaticType(). If that's true, I wounldn't go through all the trouble of regening all the generated models, but instead I would just manually rename the methods in the necessary classes. If we had a better regen story in Tuscany (like EMF has auto merge) that would be a different story. Frank. Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. Hi Ron, Looking at this, it looks like the problem is that you're trying to create dynamic subclasses of statically generated types. The bad news is that Tuscany doesn't currently support that. The good news is that it's not too hard to add the support. The problem is that currently Tuscany only has these two primary DataObject implementation classes: 1. DataObjectImpl - is the base class used for statically generated types. It is highly tuned for performance and footprint, so, unlike the base class in SDO1 (actually EMF) it doesn't support dynamic extensions. 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is designed for pure dynamic types, not a mixture of static and dynamic. To support what you want, we will need another base class, say ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, but doesn't make the assumption that eStaticFeatureCount() is 0. My guess is that there are only a few simple method overrides needed in this class. Maybe you would like to try to prototype such a class yourself and hand modify your generated classes to extend from it? If you did that and tested it, you could submit a patch and we could then very quickly add a generator option to use it (maybe even make it the default). If you'd like to help with this, it would be very much appreciated! At any rate, you should probably open a JIRA feature request for this. Thanks, Frank Frank, I am working with a mixed static/dynamic model similar to the one listed at the bottom of this post. The http://example.org/ord namespace is statically registered and has code-generated classes. The http://example.org/info/zipcode and http://example.org/info/street namespaces are dynamically registered with no code-generated classes. When I attempt to load the Sample Instance (chapter04.xml), I receive an UnsupportedOperationException thrown from DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the exception is an instance of InfoTypeImpl from the ord namespace/ePackage. The EClass parameter is InfoType from the zipcode namespace. This instance document loads fine using EMF/SDO 1.0. Any suggestions I can try to work-around this problem? - Ron Sample Instance (chapter04.xml) ord:order xmlns:ord=http://example.org/ord; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://example.org/ord chapter04ord1.xsd ord:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/size color value=blue/ /product /ord:items /ord:order Schema Document 1 (chapter04ord1.xsd) xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;; targetNamespace=http://example.org/ord;; xmlns=http://example.org/ord;; xmlns:prod=http://example.org/prod;; elementFormDefault=qualified xsd:import namespace=http://example.org/prod;; schemaLocation=chapter04prod.xsd/ xsd:simpleType name=OrderNumType xsd:restriction base=xsd:string/ /xsd:simpleType xsd:complexType name=InfoType/ xsd:complexType name=CustomerType xsd:sequence
[jira] Resolved: (TUSCANY-1333) [Java SDO] ClassCastException when defining schema file without .xsd extension
[ https://issues.apache.org/jira/browse/TUSCANY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1333. - Resolution: Fixed I checked in a simple fix in revision 545346. Please test and reopen if it's not working. Thanks. [Java SDO] ClassCastException when defining schema file without .xsd extension -- Key: TUSCANY-1333 URL: https://issues.apache.org/jira/browse/TUSCANY-1333 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-beta1 Environment: IBM JDK 1.4.2 Reporter: Chris Mildebrandt With the following code: HelperContext context = SDOUtil.createHelperContext(); context.getXSDHelper().define(new FileInputStream(./Person.xsd.tmp), (new File(./Person.xsd.tmp)).toURI().toString()); I get the following exception: java.lang.ClassCastException: org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:245) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:236) at Test.doubleContextTest(Test.java:193) at Test.main(Test.java:214) Exception in thread main java.lang.IllegalArgumentException: org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:278) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:236) at Test.doubleContextTest(Test.java:193) at Test.main(Test.java:214) If I remove the .tmp from the schema file name, the exception goes away. -- 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] Commented: (TUSCANY-1327) Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include
[ https://issues.apache.org/jira/browse/TUSCANY-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501951 ] Frank Budinsky commented on TUSCANY-1327: - If I remember correctly, types defined in wsdl files cannot be imported or included in anther schema (they are effectively private local types). The XSD spec says that the schemaLocation for an import must have a schema element at the root, which says that it can't be a wsdl file). Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include --- Key: TUSCANY-1327 URL: https://issues.apache.org/jira/browse/TUSCANY-1327 Project: Tuscany Issue Type: New Feature Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: WinXP Reporter: Fuhwei Lwo Today, SDO codegen tool can recognize and parse wsdl:types content to generate static SDO APIs. However, it ignores wsdl:import and wsdl:include. This means if I have types defined in other wsdl files and they are imported or included by wsdl:import or wsdl:include elements, they won't never get generated. -- 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]
