Re: [DISCUSS] SCA Domain
On 10/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> ant elder wrote:
> > On 9/27/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> >> Why all the static and abstract methods? Is there a reason SCADomain
> >>
> couldn't just be an interface with a separate SCADomainFactory for
> creating
> instances?
>
>
> >>> I don't know. A factory works for me.
> >>>
> >> +1 for making SCADomain an interface
> >>
> >> +1 for having a factory
> >>
> >> So instead of:
> >> SCADomain domain = SCADomain.newInstance(...)
> >>
> >> We'll have:
> >> SCADomainFactory domainFactory;
> >> SCADomain domain = domainFactory.createSCADomain(domainURI)
> >>
> >> Now how do people would like to the get factory? a pretty common
> pattern
> >> is:
> >> SCADomainFactory domainFactory = SCADomainFactory.newInstance(...)
> >>
> >> Is there a better pattern?
> >>
> >> Does that answer the question about "why the static and abstract
> >> methods"? :)
> >>
> >
> >
> > The question wasn't so much about why use static and abstract methods
> but
> > why they were all munged into the one SCADomain class, now that its
> accepted
> > that is better to have a separate SCADomain interface i think its fine
> to
> > keep the static and abstract methods on the SCADomainFactory as that
> keeps
> > the API simple to use. So this code:
> >
> > SCADomainFactory domainFactory = SCADomainFactory.newInstance();
> > SCADomain domain = domainFactory.createSCADomain("
> > http://mydomain:7890/asmalldomain";);
> >
> > could be simplified to:
> >
> > SCADomain domain = SCADomainFactory.createSCADomain("
> > http://mydomain:7890/asmalldomain";);
> >
> >...ant
> >
> >
>
> Can you help me understand:
> - how people will be able to plug-in different factories?
> - how to pass the factory to use? I'm not sure I understand how it'll be
> possible with createSCADomain() being a static method.
>
> Thanks
>
> --
> Jean-Sebastien
Um, it would just work similarly to the current SCADomain class, the impl of
any other static methods can still call newInstance so can still plug in
different factories.
...ant
Re: [DISCUSS] SCA Domain
On 10/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> ant elder wrote:
> > On 9/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > Here's sample code to illustrate that use case:
> >
> >>
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/domain-and-node/samples/
> >> SampleTuscanyDomainImplementation.java
> >>
> >
> >
> > Why does that sample need to add and start composites with:
> >
> > // Add the Calculator deployable composite to the domain
> composite
> > domain.addComposite(new QName("http://calc";, "Calculator"));
> >
> > // Start the Calculator composite
> > domain.startComposite(new QName("http://calc";, "Calculator"));
> >
> > The contribution jar is going to have the sca-contribution.xml (or the
> > composites in the "deployables" folder we once talked of supporting),
>
> No, sca-contribution.xml is optional.
>
> > so
> > can't the simplest case just be adding the contribution and the
> deployable
> > composites get started automatically?
> >
>
> I don't think that having to write a sca-contribution.xml file is the
> simplest case.
>
> http://www.osoa.org/xmlns/sca/1.0";
> targetNamespace="http://calc";
> xmlns:sample="http://calc";>
>
>
>
> vs
>
> domain.addComposite(new QName("http://calc";, "Calculator"));
>
> Placing the composite file under META-INF/deployables will appear simple
> to some people, but will not necessarily play well with other people
> using IDEs for example which often hide META-INF, or people who are not
> used to place their development artifacts, .wsdl, .xsd, .componentType,
> or .composite... under META-INF.
Agree about sca-contribution.xml not being simplest nor
META-INF/deployables, but we've had this discussion before and couldn't get
much agreement on anything else. Take the Tuscany/Geronimo integration as an
example, deploying an sca contribution jar on that and the code can only
tell which composites to add based on somethng like sca-contribution.xml or
doing some default behaviour like add all composites or add no composites.
Does the spec say anywhere that when there is no sca-contribution.xml then
composites in a contribution must not be added by default?
...ant
[jira] Updated: (TUSCANY-1827) SDO Types based PK map needed in GraphMerger
[ https://issues.apache.org/jira/browse/TUSCANY-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1827: - Attachment: 1827.patch changes in:- rdb/src/main/java/org/apache/tuscany/das/rdb/config/wrapper/MappingWrapper.java rdb/src/main/java/org/apache/tuscany/das/rdb/ConfigHelper.java rdb/src/main/java/org/apache/tuscany/das/rdb/impl/Changes.java rdb/src/main/java/org/apache/tuscany/das/rdb/merge/impl/GraphMerger.java rdb/src/test/java/org/apache/tuscany/das/rdb/test/GraphMergeTests.java //test case for fix - testMergeUpdateSingleTable() rdb/src/test/java/org/apache/tuscany/das/rdb/test/OperationOrderingTests.java // a minor bug fix - comments inside code rdb/src/test/resources/CustomersOrdersConfigProps.xml > SDO Types based PK map needed in GraphMerger > > > Key: TUSCANY-1827 > URL: https://issues.apache.org/jira/browse/TUSCANY-1827 > Project: Tuscany > Issue Type: Bug >Affects Versions: Java-DAS-Next >Reporter: Amita Vadhavkar >Assignee: Amita Vadhavkar > Fix For: Java-DAS-Next > > Attachments: 1827.patch > > > DAS GraphMerger code has getPrimaryKeyName() based on SDO Type and > addPrimaryKey() based on database Column name. > So when these 2 are different GraphMerges fails to detect PKs. This is very > similar bug to JIRA-1807. -- 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: A demo application to showcase our XML integration story
On 10/4/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I put together a demo application to showcase our XML integration story.
> The
> business scenario is derived from the bigbank demo and the main function
> is
> to calculate the total value (using a selected currency) of a customer who
> has checking/saving/stock accounts.
>
> At this moment, I add three different sources to provide XML data.
>
> 1) A live feed to retrieve the exchange rate (binding.feed) and use XPath
> to
> exact the rate for a given currency. I have to use Rome API to convert the
> feed as our feed binding produces Feed objects.
>
> 2) The account data for a customer is loaded from a XML file. (We can use
> implementation.data once Sebastien's proposal is implemented).
>
> 3) A live Web Service invocation to get the quotes for a list of symbols.
> Only XMLStreamReader is used as the input and output. (binding.ws)
>
> 4) The calculation of the total value is implemented using XQuery to join
> the XML data from 2 and 3. (implementation.xquery)
>
> The demo application is checked in under r581755. I hope we can use it as
> a
> test-bed to further drive our XML integration story. Please feel free to
> chime in with your ideas, for example, add implementation.data or
> implementation.das, or implementation.bpel.
>
> Thanks,
> Raymond
That looks really good. The XML integration story is something I've always
thought could be a great demonstration of Tuscany's value...and of the value
of things like Tuscany's support for dynamic/script languages.
I'd really like to be able to replace the CustomerAssetImpl Java class used
in that demo with a dynamic language component, say Ruby or JavaScript, for
example, like this with JavaScript/E4X which seems much more concise and
readable to me than the Java code:
function getTotalValue(currency) {
java.lang.System.out.println("Retrieving exchange rate...");
feed = exchangeRate.getRates();
entry = feed.getEntries().get(0);
rateTable = new XML(entry.getSummary().getValue());
rate = rateTable.TR.(TD[0]==currency).TD[1]
accounts = accountData.getAccounts();
quotes = stockQuote.GetStockQuotes(
http://swanandmokashi.com";>
IBM,GOOG,MSFT
);
value = stockValue.calculate(quotes, accounts);
java.lang.System.out.println("Total Value=USD " + value);
return value;
}
And even that could probably be simplified if we could get
exchangeRate.getRates() to return e4x xml.
Unfortunately none of that JavaScript code is working in Tuscany any more :(
Similar things did used to work but we're lost the the E4X databinding and
support for xml references in script components that we used to have. It
would be a fair bit of work to get all that going again so before i (or
anyone else who wants to help) does that - is there much interested in
supporting stuff like this?
...ant
[jira] Commented: (TUSCANY-1765) Component implementation has wrong intent
[ https://issues.apache.org/jira/browse/TUSCANY-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532395 ] Venkatakrishnan commented on TUSCANY-1765: -- Hi.. thanks for the patch. This does solve the problem to some extent - for the case where intents are directly attached to an implementation element. But what about the case of intents inherited from ancestors. For example ... http://www.osoa.org/xmlns/sca/1.0"; name="CompositeX"> The computation / aggregation of intents is done after the resolution phase. So I guess this problem will still persist for this case. Isnt it ? > Component implementation has wrong intent > - > > Key: TUSCANY-1765 > URL: https://issues.apache.org/jira/browse/TUSCANY-1765 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Assembly Model >Affects Versions: Java-SCA-0.99 >Reporter: Greg Dritschler >Assignee: Venkatakrishnan >Priority: Minor > Fix For: Java-SCA-Next > > Attachments: TUSCANY-1765.patch > > > Suppose there is a composite with multiple components that use the same > implementation class but different implementation intents, as shown below. > http://www.osoa.org/xmlns/sca/1.0"; name="CompositeX"> > > requires="managedTransaction.none"/> > > > requires="managedTransaction.global"/> > > > In this case the components will share a common Implementation model object > because only the class name is being used to determine whether a component's > implementation is the same as another's. This means one of the components > will have the wrong implementation intents recorded in the model. -- 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-1831) Make SDOPackageRegistryDelegator pluggable
Make SDOPackageRegistryDelegator pluggable -- Key: TUSCANY-1831 URL: https://issues.apache.org/jira/browse/TUSCANY-1831 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: Ron Gavlin The current SDOPackageRegistryDelegator implementation assumes that a standard, hierarchical classloader structure is present in the "hosting environment". BEA WebLogic, for example, uses an unusual "change aware" classloading scheme which does not meet the expectations of the SDOPackageRegistryDelegator. Prior to Tuscany SDO 1.0, I was able to work-around this former EMF problem by setting the EMF JVM property "org.eclipse.emf.ecore.EPackage.Registry.INSTANCE". In Tuscany SDO 1.0, this setting is no longer relevant. I would like to be able to plugin my own SDOPackageRegistryDelegator implementation that provides a non-classloader-aware registry, knowing full well the limitations of of this implementation. -- 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: Build problems in trunk
On 10/4/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > I just updated the trunk and did a clean build and it is SUCCESSFUL! > > - Venkat > > On 10/4/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > I've been trying to get a clean build for a long time today so I can > check > > the Domain/Node changes in and I can't manage it. This is what I'm > seeing > > now... > > > > [INFO] Apache Tuscany SCA Web Services Void Args and Return > Test SUCCESS > > [ > > 13.21 > > 8s] > > [INFO] > > > > [INFO] Error for project: Apache Tuscany SCA BPEL Implementation > Extension > > (duri > > ng install) > > [INFO] > > > > [INFO] There are test failures. > > [INFO] > > > > [INFO] Error for project: Apache Tuscany SCA HelloWorld Secure Web > Service > > Refer > > ence Sample (during install) > > [INFO] > > > > [INFO] There are test failures. > > [INFO] > > > > [INFO] Error for project: Apache Tuscany SCA POJO Implementation > Extension > > Sampl > > e (during install) > > [INFO] > > > > [INFO] There are test failures. > > [INFO] > > > > [INFO] Error for project: Apache Tuscany SCA Callback API Integration > > Tests > > (dur > > ing install) > > [INFO] > > > > [INFO] There are test failures. > > [INFO] > > > > [INFO] Error for project: Apache Tuscany SCA Callback Basic Integration > > Tests (d > > uring install) > > [INFO] > > > > [INFO] There are test failures. > > [INFO] > > > > [INFO] Error for project: Apache Tuscany Interface Integration Tests > > (during > > ins > > tall) > > [INFO] > > > > [INFO] There are test failures. > > [INFO] > > > > [INFO] For more information, run Maven with the -e switch > > [INFO] > > > > [INFO] BUILD ERRORS > > [INFO] > > > > [INFO] Total time: 20 minutes 56 seconds > > [INFO] Finished at: Wed Oct 03 22:10:02 BST 2007 > > [INFO] Final Memory: 65M/119M > > [INFO] > > > > > > And there are some really strange ones in there that are not real errors > > but > > have something to do with the way the build is working (or not > working!), > > i.e. classes that it's complaining it can't see that are plainly on the > > classpath. Obviously I suspect my own changes but I'm just not seeing > why > > > > Anyone else see these kinds of problems with the build. Be interested in > > the > > off chance that it's not just my changes. > > > > Thanks > > > > Simon > > > Thank you Venkat. At least it gives me some confidence that what is out there works for at least one person. Simon
Re: could databinding-axiom Object2OMElement construct a default elem?
Yes, SimpleJavaType2Node does this.
Raymond, do you think it would be better to use the same QName for the dummy
element:
{"http://tuscany.apache.org/xmlns/sca/databinding/dom/1.0";, "root"}
or a different one, scoped to the Axiom DB?
Scott
On 10/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> In a short answer, yes. We should try to create a dummy element in such
> case. I believe we already do that for DOM. Do you want to provide a patch
> :-)?
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Scott Kurz" <[EMAIL PROTECTED]>
> To:
> Sent: Wednesday, October 03, 2007 7:53 PM
> Subject: could databinding-axiom Object2OMElement construct a default
> elem?
>
>
> >I noticed that if I try to use the XMLStreamReader databinding at the end
> >of
> > a chain starting with the SimpleJavaDB, I end up in the following
> > transform
> > chain:
> >
> > org.apache.tuscany.sca.databinding.axiom.Object2OMElement,
> > org.apache.tuscany.sca.databinding.axiom.OMElement2XMLStreamReader
> >
> > This will give an NPE in the case that the logical type is an XMLType
> with
> > a
> > Type but no Element. (Roughly speaking, this will be the case if my
> > simple type doesn't
> > correspond to some XSD/WSDL definition).
> >
> > I can't say I really grasp what's involved in creating a default element
> > name... but that's what we do in SimpleJavaType2Node.
> >
> > Is there a reason we can't do the same? Otherwise this
> Object2OMElement
> > transformer ends up causing some problems I'd say.
> >
> > Scott
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
concerns w/ Tuscany databinding framework and Java-centric databindings
I wonder what we think about the Tuscany databinding framework and how it could be used with Java-centric databindings (as opposed to say, XML-based databindings). Say I'm writing a binding which will use Java serialization to send/receive data over the binding transport. One approach would be to use the java.lang.Object databinding for my binding's interface contract. I've found that if I want to do this, it seems to be a lot easier if I introduce a few very basic transformers: Simple2Object, Object2Simple, DataObject2Object, with each doing no more than returning the input source object passed to transform(). Otherwise I end up in transformer chains like: SimpleJavaType2Node, DOMNode2JavaBeanTransformer which is unnecessary to simply pass along a Java primitive type. I'm just wondering, though, how Raymond and others who've given the databinding framework some thought would react to introducing those transforms into the web of transformers. Every entry "pollutes" the web a bit, of course. An alternative approach is to do everything possible to avoid the Tuscany databinding framework and to make sure a DataTransformationInterceptor is not set up on the wire to/from the binding. I wonder if that is the "preferred" approach Raymond had in mind?? Of course the downside of this is that I lose the ability for my binding to handle, say, a DOM Node, which Tuscany has a transform to Object for. I realize that there's some other context in my situation I'm not mentioning. Namely, I'm partly doing things the way I am to workaround JIRAS 1679,1680. But still, maybe my question is worth addressing on its own. Thanks, Scott
Using Tuscany as a library
Hello, I would like to use Tuscany as a library (rather than a runtime) to parse a reference or service definition containing bindings, and obtain a proxy to a service. At the moment, I create a composite containing a dummy component with a reference, and then create an SCA domain, add a contribution containing the composite, and then obtain the reference and get a proxy through the runtimeWire. Apart from being very messy, this requires a large number of Tuscany modules to be in the classpath. Is there a better way for me to use the modules in Tuscany - specifically the bindings modules? Thank you... Regards, Rajini
[jira] Created: (TUSCANY-1832) Complex type w/simple content restriction facets are ignored
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 == http://www.w3.org/2001/XMLSchema"; targetNamespace="http://www.example.com/substitutionEV"; xmlns:sev="http://www.example.com/substitutionEV";> == substitutionWithExtensionValues2.xsd == http://www.w3.org/2001/XMLSchema"; targetNamespace="http://www.example.com/substitutionEV2"; xmlns:sev2="http://www.example.com/substitutionEV2"; xmlns:sev="http://www.example.com/substitutionEV";> http://www.example.com/substitutionEV"; schemaLocation="substitutionWithExtensionValues.xsd" /> == substitutionWithExtensionValues1.xml == http://www.example.com/substitutionEV2";> http://www.example.com/substitutionEV";> name1 value1 myName2 myValue2 comment0 http://www.example.com/substitutionEV";> myNameB myValueB commentA commentZZ == SubstitutionWithExtensionValuesTestCase.java == /** * * 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. */ package org.apache.tuscany.sdo.test; import java.io.IOException; import java.io.In
[jira] Commented: (TUSCANY-1830) SimpleType extension across mixed static/dynamic namespaces is broken
[
https://issues.apache.org/jira/browse/TUSCANY-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532454
]
Ron Gavlin commented on TUSCANY-1830:
-
I am planning to submit a patch for this in the near future.
- Ron
> SimpleType extension across mixed static/dynamic namespaces is broken
> -
>
> Key: TUSCANY-1830
> URL: https://issues.apache.org/jira/browse/TUSCANY-1830
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Ron Gavlin
>
> I have a statically registered namespace
> "http://www.example.com/substitutionEV"; with a simpleType named UuidType with
> a pattern facet. I also have a dynamically registered namespace
> "http://www.example.com/substitutionEV2"; with a simpleType named Uuid2Type
> which is a restriction of UuidType. When I invoke uuid2Type.getBaseTypes(),
> the parent UuidType is not returned. I have included a sample test below.
> ==
> substitutionWithExtensionValues.xsd
> ==
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="http://www.example.com/substitutionEV";
> xmlns:sev="http://www.example.com/substitutionEV";>
>
>
>
>
>substitutionGroup="sev:result"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>value="[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-f]{12}"/>
>
>
>
>
>
>
>
>
>
>
> ==
> substitutionWithExtensionValues2.xsd
> ==
> http://www.w3.org/2001/XMLSchema";
> targetNamespace="http://www.example.com/substitutionEV2";
> xmlns:sev2="http://www.example.com/substitutionEV2";
> xmlns:sev="http://www.example.com/substitutionEV";>
>
> http://www.example.com/substitutionEV";
> schemaLocation="substitutionWithExtensionValues.xsd" />
>
>
>
>
>maxOccurs="unbounded"
> type="sev2:Results2Type" />
>
>
>
>
>
>
>
>
>
>
>
>
> ==
> substitutionWithExtensionValues1.xml
> ==
>
> http://www.example.com/substitutionEV2";>
> ----
> http://www.example.com/substitutionEV";>
> ----
>
>
> ----
> name1
> value1
>
>
>
> ----
> myName2
> myValue2
>
> comment0
>
> http://www.example.com/substitutionEV";>
> ----
>
>
> ----
> myNameB
> myValueB
>
> commentA
>
> commentZ
>
> ==
> SubstitutionWithExtensionValuesTestCase.java
> ==
> /**
> *
> * 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.
> */
> package org.apache.tuscany.sdo.test;
> import java.io.IOException;
> import java.io.InputStream;
> import java.net.URL;
> import java.util.List;
> import junit.framework.TestCase;
> import org.eclipse.emf.common.util.Diagnostic;
> import org.eclipse.emf.ecore.EObject;
> import org.eclipse.emf.ecore.util.Diagnostician;
> import com.example.substitution.ev.SEVFactory;
> import com.example.substitution.ev.impl.SEVFactoryImpl;
> import commonj.sdo.DataObject;
> imp
Re: could databinding-axiom Object2OMElement construct a default elem?
Hi,
Initially I was trying to use the same dummy root element for all
databindings. But I ran into an issue with SDO databinding which seems to be
only happy with commonj.sdo namespace. At this moment, it's one dummy
namespace per databinding.
Thanks,
Raymond
- Original Message -
From: "Scott Kurz" <[EMAIL PROTECTED]>
To:
Sent: Thursday, October 04, 2007 6:20 AM
Subject: Re: could databinding-axiom Object2OMElement construct a default
elem?
Yes, SimpleJavaType2Node does this.
Raymond, do you think it would be better to use the same QName for the
dummy
element:
{"http://tuscany.apache.org/xmlns/sca/databinding/dom/1.0";, "root"}
or a different one, scoped to the Axiom DB?
Scott
On 10/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
In a short answer, yes. We should try to create a dummy element in such
case. I believe we already do that for DOM. Do you want to provide a
patch
:-)?
Thanks,
Raymond
- Original Message -
From: "Scott Kurz" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, October 03, 2007 7:53 PM
Subject: could databinding-axiom Object2OMElement construct a default
elem?
>I noticed that if I try to use the XMLStreamReader databinding at the
>end
>of
> a chain starting with the SimpleJavaDB, I end up in the following
> transform
> chain:
>
> org.apache.tuscany.sca.databinding.axiom.Object2OMElement,
> org.apache.tuscany.sca.databinding.axiom.OMElement2XMLStreamReader
>
> This will give an NPE in the case that the logical type is an XMLType
with
> a
> Type but no Element. (Roughly speaking, this will be the case if my
> simple type doesn't
> correspond to some XSD/WSDL definition).
>
> I can't say I really grasp what's involved in creating a default
> element
> name... but that's what we do in SimpleJavaType2Node.
>
> Is there a reason we can't do the same? Otherwise this
Object2OMElement
> transformer ends up causing some problems I'd say.
>
> Scott
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532470 ] Sunny Ip commented on TUSCANY-1814: --- There was no stacktrace in the console, but stepping into the code, I see this as the cause: 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:82) at org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:163) at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:51) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:223) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:304) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:77) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3600) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4193) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:904) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:867) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getElement(WSDLOperationIntrospectorImpl.java:219) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.access$000(WSDLOperationIntrospectorImpl.java:62) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl$WSDLPart.(WSDLOperationIntrospectorImpl.java:260) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getMessageType(WSDLOperationIntrospectorImpl.java:186) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getInputType(WSDLOperationIntrospectorImpl.java:128) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getOperation(WSDLOperationIntrospectorImpl.java:206) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceIntrospectorImpl.introspectOperations(WSDLInterfaceIntrospectorImpl.java:50) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceIntrospectorImpl.introspectPortType(WSDLInterfaceIntrospectorImpl.java:57) at org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLFactoryImpl.createWSDLInterface(WSDLFactoryImpl.java:51) at org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolveWSDLInterface(WSDLInterfaceProcessor.java:152) at org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolve(WSDLInterfaceProcessor.java:168) at org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLInterfaceProcessor.resolve(WSDLInterfaceProcessor.java:43) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211) at org.apache.tuscany.sca.contribution.processor.Extensi
Re: concerns w/ Tuscany databinding framework and Java-centric databindings
Hi, Please see my comments inline. Thanks, Raymond - Original Message - From: "Scott Kurz" <[EMAIL PROTECTED]> To: Sent: Thursday, October 04, 2007 6:13 AM Subject: concerns w/ Tuscany databinding framework and Java-centric databindings I wonder what we think about the Tuscany databinding framework and how it could be used with Java-centric databindings (as opposed to say, XML-based databindings). Say I'm writing a binding which will use Java serialization to send/receive data over the binding transport. Let's define a new databinding such as "java:serialized" to capture this format. One approach would be to use the java.lang.Object databinding for my binding's interface contract. We should rename the java beans data binding from "java.lang.Object" to "java:complexType" to avoid confusions. I've found that if I want to do this, it seems to be a lot easier if I introduce a few very basic transformers: Simple2Object, Object2Simple, DataObject2Object, with each doing no more than returning the input source object passed to transform(). Do you try to use these transformers to convert the simple types to the serialized java format? Otherwise I end up in transformer chains like: SimpleJavaType2Node, DOMNode2JavaBeanTransformer which is unnecessary to simply pass along a Java primitive type. In your case, we can add a transformer from java:simpleType to java:serialized to support the pass through. For complex types, java:complexType --> java:serialized will do. I'm just wondering, though, how Raymond and others who've given the databinding framework some thought would react to introducing those transforms into the web of transformers. Every entry "pollutes" the web a bit, of course. Some transformers can only be used as either the first or last edge on the path. I use a very heavy weight to avoid a transformer to be used as intermediaries. We can even add a flag to a transformer to tell if it can serve as an intermediary. An alternative approach is to do everything possible to avoid the Tuscany databinding framework and to make sure a DataTransformationInterceptor is not set up on the wire to/from the binding. I wonder if that is the "preferred" approach Raymond had in mind?? Of course the downside of this is that I lose the ability for my binding to handle, say, a DOM Node, which Tuscany has a transform to Object for. A good balance is needed. The databinding framework is used to help the "well-known" types of transformation that can be handled as system code. For a binding, it expresses its expectation of data format and the framework helps to meet such requirement. I realize that there's some other context in my situation I'm not mentioning. Namely, I'm partly doing things the way I am to workaround JIRAS 1679,1680. But still, maybe my question is worth addressing on its own. Thanks, Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding intents and policy sets to JavaImplementation instances
Hi, As I am extending policy support for implementations I realize that we have trouble with aggregating intents and policysets in an JavaImplementation instance. The reason for this is that JavaImplementation instances could be reused in cases where two or more components provide services thro the same implementation. There is also a JIRA - https://issues.apache.org/jira/browse/TUSCANY-1765that talks of this problem with a nice example. The JIRA has a patch that solves the issue to some extent and not entirely. If JavaImplementaition instances are going to be reused when the same implemenation is used by two or more components, then we need an alternative to store the intents / policy sets so that they are unique for each component. Take for example http://www.osoa.org/xmlns/sca/1.0"; name="CompositeX"> Here there is going to be a single instance of JavaImplementation that will be used for both components. But it happens that both these components have different intents defined and these intents will be inherited by the implementations. At the present moment I can only think of storing this info in the Component but I am absolutely uncomfortable with this pollutes the assembly model design for 'Component'. Any other ideas that folks can suggest for this ? Thanks - Venkat
[jira] Commented: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532496 ] Raymond Feng commented on TUSCANY-1814: --- Hi, Can you try to pick up r581976 to see it fixes your problem? Thanks, Raymond > Large memory footprint with large wsdl/schemas > -- > > Key: TUSCANY-1814 > URL: https://issues.apache.org/jira/browse/TUSCANY-1814 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Data Binding Runtime >Affects Versions: Java-SCA-1.0 > Environment: Windows/Tomcat >Reporter: Sunny Ip >Assignee: Raymond Feng > Fix For: Java-SCA-Next > > Attachments: Memory Footprint (Startup Profile).png, wsdl.zip > > > Creating services and components based on large wsdl/schemas (SDO > generation/databinding, ws binding, etc.) results in very high memory > footprint. Attaching sample wsdls that make use of the very large schema that > we are using. -- 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-1833) XML2JavaBeanTransformer has problem transforming to beans with array fields
XML2JavaBeanTransformer has problem transforming to beans with array fields
---
Key: TUSCANY-1833
URL: https://issues.apache.org/jira/browse/TUSCANY-1833
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.0
Reporter: Jiang Chen
I tried to use complex properties in a POJO which requires the SCA runtime at
injection time to convert complex XML property values into Java beans. The
XML2JavaBeanTransformer in the java beans data binding package seems to have
problem converting to beans with array members. Mapping exception was thrown.
In both the setFieldValue and the setFieldValueUsingSetter methods of
org.apache.tuscany.sca.databinding.javabeans.XML2JavaBeanTransformer, when the
field type is Array, it probably should convert all the child elements of the
field value to Java objects and add them to the field value array. The current
implementation tries to convert the field value itself (the parent of the array
elements) yet using the component type of the array.
The following fix seems to have fixed my problem.
private void setFieldValue(Object javaInstance,
Field javaField,
T fieldValue,
Map> arrayFields,
TransformationContext context) throws
IllegalAccessException {
Class javaFieldType = (Class) javaField.getType();
if (javaFieldType.isArray()) {
Class componentType = javaFieldType.getComponentType();
List fldValueArray = arrayFields.get(javaField);
if (fldValueArray == null) {
fldValueArray = new ArrayList();
arrayFields.put(javaField, fldValueArray);
}
/*** Fix Starts */
// Old code commented out:
// fldValueArray.add(createJavaObject(fieldValue, componentType,
context));
// New code added:
List childElements = getChildElements(fieldValue);
for (int i = 0; i < childElements.size(); i++)
if (!isTextElement(childElements.get(i)))
fldValueArray.add(createJavaObject(childElements.get(i), componentType,
context));
/*** Fix Ends */
} else {
javaField.setAccessible(true);
javaField.set(javaInstance, createJavaObject(fieldValue,
javaFieldType, context));
}
}
private void setFieldValueUsingSetter(Class javaType,
Object javaInstance,
String fieldName,
T fieldValue,
Map>
arraySetters,
TransformationContext context) throws
IllegalAccessException,
InvocationTargetException {
char firstChar = Character.toUpperCase(fieldName.charAt(0));
StringBuilder methodName = new StringBuilder(SET + fieldName);
methodName.setCharAt(SET.length(), firstChar);
boolean methodNotFound = true;
for (int methodCount = 0; methodNotFound && methodCount <
javaType.getMethods().length; ++methodCount) {
Method aMethod = javaType.getMethods()[methodCount];
if (aMethod.getName().equals(methodName.toString())
&& aMethod.getParameterTypes().length == 1) {
Class paramType = aMethod.getParameterTypes()[0];
if (paramType.isArray()) {
Class componentType = paramType.getComponentType();
List setterValueArray = arraySetters.get(aMethod);
if (setterValueArray == null) {
setterValueArray = new ArrayList();
arraySetters.put(aMethod, setterValueArray);
}
/*** Fix Starts
*/
// Old code commented out:
// setterValueArray.add(createJavaObject(fieldValue,
componentType, context));
// New code added:
List childElements = getChildElements(fieldValue);
for (int i = 0; i < childElements.size(); i++)
if (!isTextElement(childElements.get(i)))
setterValueArray.add(createJavaObject(childElements.get(i), componentType,
context));
/*** Fix Ends */
} else {
aMethod.invoke(javaInstance, new Objec
[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_12532517 ] Ron Gavlin commented on TUSCANY-1832: - See Eclipse EMF bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=205506. Frank, I'm hoping Ed will be able to walk me through a general approach to fixing this bug. However, if you have any pointers that could help me, I would surely appreciate it. This bug is a big problem for us. Once a patch is developed, I'll submit it here to be applied to BaseSDOXSDEcoreBuilder as well as to the EMF folks. Thanks, - Ron > 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 > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV"; > xmlns:sev="http://www.example.com/substitutionEV";> > > > > substitutionGroup="sev:result" /> > > > > maxOccurs="unbounded" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >value="English" /> >value="French" /> >value="Spanish" /> > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues2.xsd > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV2"; > xmlns:sev2="http://www.example.com/substitutionEV2"; > xmlns:sev="http://www.example.com/substitutionEV";> > > http://www.example.com/substitutionEV"; > schemaLocation="substitutionWithExtensionValues.xsd" /> > > > > >maxOccurs="unbounded" > type="sev2:Results2Type" /> > > > > > > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues1.xml > == > > http://www.example.com/substitutionEV2";> > > http://www.example.com/substitutionEV";> > > > > name1 > value1 > > > > myName2 > myValue2 > > comment0 > > http://www.example.com/substitutionEV";> > > > > myNameB > myValueB > > commentA > > > commentZZ > > > == > SubstitutionWithExtensionValuesTestCase.ja
[jira] Commented: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532555 ] Chris Lo commented on TUSCANY-1814: --- Hi Raymond, We have tested r581976 that you mentioned. The null pointer went away. However, we notice that when we use xsd:include, the data types defined in that include file could not be resolved. Sunny will be uploading an example after he verifies the findings. Thanks, Chris > Large memory footprint with large wsdl/schemas > -- > > Key: TUSCANY-1814 > URL: https://issues.apache.org/jira/browse/TUSCANY-1814 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Data Binding Runtime >Affects Versions: Java-SCA-1.0 > Environment: Windows/Tomcat >Reporter: Sunny Ip >Assignee: Raymond Feng > Fix For: Java-SCA-Next > > Attachments: Memory Footprint (Startup Profile).png, wsdl.zip > > > Creating services and components based on large wsdl/schemas (SDO > generation/databinding, ws binding, etc.) results in very high memory > footprint. Attaching sample wsdls that make use of the very large schema that > we are using. -- 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-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_12532563 ] Ron Gavlin commented on TUSCANY-1832: - It turns out the EMF bug I opened is a duplicate of https://bugs.eclipse.org/bugs/show_bug.cgi?id=164462 which was fixed in EMF 2.3 but not the 2.2.x stream. I'll manually apply the fix to BaseSDOXSDEcoreBuilder and test. I'll post the patch if it works as advertised. Regards, - Ron > 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 > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV"; > xmlns:sev="http://www.example.com/substitutionEV";> > > > > substitutionGroup="sev:result" /> > > > > maxOccurs="unbounded" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >value="English" /> >value="French" /> >value="Spanish" /> > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues2.xsd > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV2"; > xmlns:sev2="http://www.example.com/substitutionEV2"; > xmlns:sev="http://www.example.com/substitutionEV";> > > http://www.example.com/substitutionEV"; > schemaLocation="substitutionWithExtensionValues.xsd" /> > > > > >maxOccurs="unbounded" > type="sev2:Results2Type" /> > > > > > > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues1.xml > == > > http://www.example.com/substitutionEV2";> > > http://www.example.com/substitutionEV";> > > > > name1 > value1 > > > > myName2 > myValue2 > > comment0 > > http://www.example.com/substitutionEV";> > > > > myNameB > myValueB > > commentA > > > commentZZ > > > == > SubstitutionWithExtensionValuesTestCase.java > == > /** > * > * Licensed to the Apache Software Foundation (ASF) under one > * or more contrib
[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_12532564 ] Ron Gavlin commented on TUSCANY-1832: - My previous statement was incorrect. This bug is fixed in EMF 2.2.3. However, BaseSDOXSDEcoreBuilder.computeEClass() completely overrides the method in the parent EMF XSDEcoreBuilder class. The fix was never ported from the base class to the Tuscany subclass. We should document which Tuscany SDO classes contain methods that completely override their EMF base class counterparts with an almost copy-and-paste implementation. Whenever we upgrade to later versions of EMF, we should be careful to revisit these classes and incorporate any modifications applied to their base classes. - Ron > 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 > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV"; > xmlns:sev="http://www.example.com/substitutionEV";> > > > > substitutionGroup="sev:result" /> > > > > maxOccurs="unbounded" /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >value="English" /> >value="French" /> >value="Spanish" /> > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues2.xsd > == > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.example.com/substitutionEV2"; > xmlns:sev2="http://www.example.com/substitutionEV2"; > xmlns:sev="http://www.example.com/substitutionEV";> > > http://www.example.com/substitutionEV"; > schemaLocation="substitutionWithExtensionValues.xsd" /> > > > > >maxOccurs="unbounded" > type="sev2:Results2Type" /> > > > > > > > > > > > > > > > > > > > > > > > == > substitutionWithExtensionValues1.xml > == > > http://www.example.com/substitutionEV2";> > > http://www.example.com/substitutionEV";> > > > > name1 > value1 > > > > myName2 > myValue2 > > comment0 > > http://www.example.com/substitutionEV";> > > > > myNameB > myValueB >
[jira] Updated: (TUSCANY-1814) Large memory footprint with large wsdl/schemas
[ https://issues.apache.org/jira/browse/TUSCANY-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1814: -- Attachment: trninq.zip Attached a zip containing a single wsdl and the dependent schemas. The elements and import statement in the included schema are not read properly when the TuscanyServletFilter starts. > Large memory footprint with large wsdl/schemas > -- > > Key: TUSCANY-1814 > URL: https://issues.apache.org/jira/browse/TUSCANY-1814 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Data Binding Runtime >Affects Versions: Java-SCA-1.0 > Environment: Windows/Tomcat >Reporter: Sunny Ip >Assignee: Raymond Feng > Fix For: Java-SCA-Next > > Attachments: Memory Footprint (Startup Profile).png, trninq.zip, > wsdl.zip > > > Creating services and components based on large wsdl/schemas (SDO > generation/databinding, ws binding, etc.) results in very high memory > footprint. Attaching sample wsdls that make use of the very large schema that > we are using. -- 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]
