Re: Cleaning up / moving some old modules
On 9/26/07, Luciano Resende [EMAIL PROTECTED] wrote: This is already due... +1 On 9/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm looking at java/sca/modules and java/sca/itest and would like to delete or move to contrib some old / dormant / broken / unused modules. Delete - modules/host-home, an empty module created by me, I'm happy to remove it as I was initially planning to put some admin pages there, but the admin stuff is now somewhere else. Move to contrib - modules/discovery-jms and modules/jmx, dormant for more than 6 months, not building. - modules/topology and modules/topology-xml, not used at the moment, as node/node-impl/domain/domain-impl seem to be the new modules for handling domain topology/distribution. - itest/old, outdated test cases which seem to have been replicated in new modules under itest. Let me know if you want to resurrect and start working on some of these old modules, otherwise if there's no objection I'll move them to contrib later this week. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 all look old to me Simon
Re: Tuscany and IRC #tuscany on freenode
In Apache mailing lists are the preferred communication medium and IRC use is discouraged. There's been tons of discussion about this, searching the [EMAIL PROTECTED] archives should find some. IRC might be ok for complete newbie user queries or is the build broken for you type questions but if it starts being used for much more than that then decisions start getting made and those who aren't there start missing out on things. Publishing the logs is not a complete solution as the logs of IRC discussions don't provide anything like the clarity of written email exchanges. IIRC in the past the use of IRC has delayed projects graduating from the Incubator so i think we should be careful about starting to use it much more now. ...ant On 9/25/07, Philippe Ombredanne [EMAIL PROTECTED] wrote: I am a big fan of IRC. There is a channel #tuscany on freenode. Why not have more folks join the fun there? I would suggest that there is a public log of the channel that is setup, to keep the chats in the open. I could ask a buddy there : http://echelog.matzon.dk/logs/ to setup a log bot for it. Any objections? -- Cheers Philippe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki diagram source
On 9/25/07, Luciano Resende [EMAIL PROTECTED] wrote: Some static files are still stored in SVN [1], and I see a image-sources there, so we could either use that one, or a new one. As for syncup, yes, it's still happening. [1] https://svn.apache.org/repos/asf/incubator/tuscany/site/ On 9/25/07, Simon Laws [EMAIL PROTECTED] wrote: I have the source for a few of the diagrams that are used in the wiki in my sandbox. Not the best place for them. 1/ Where is everyone putting this kind of source? How about we have a wiki/diagrams section of svn? 2/ I note that the doc on the website wiki about cwiki setup ( http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56590) suggest that content is being updated in SVN. Is this really happening and if so where is it going? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano Are you saying that content is being synched 1) from svn to the web site or 2) from the web site to svn. Looking at the svn like you posted it doesn't look like there is new content there so I'm assuming you mean 1). If so what is this content being used for. If there is already a director there for images I think we should use it (sorry I didn't spot it). But this somewhat depends on the behaviour of the synch operation. I.e. what is the implication of putting new content under the site directory. Will it be either 1) appear on the site in an unexpected place or 2) get overwritten by updates from the sit. Can you point me to the job that is doing the web site generation/svn synching? Thanks Simon
Re: [DISCUSS] JIRA - was:Fwd: Change freeze on 1.0 branch
On 9/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 9/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: Hi It feels like we have been getting better at using JIRA in the run up to 0.99 and 1.0 release in terms of the consistency with which we raise bug reports and assign them to releases. Based on Ant's branch freeze suggestion how about we now 1/ create the following versions in JIRA JAVA-SCA-1.1 - as the trunk target JAVA-SCA-1.0.1 - as the 1.0 branch target in case we need it Dare I ask :) Java SCA 1.0.1 has 12 unresolved issues? Is anybody working on fixing these 12 issues for a 1.0.1 release different from 1.1 ? When can I download 1.0.1? 2/ Review the JIRA components to make them match the modules we currently have. Several options here, e.g. a/ add a component for any module we have in svn that is not represented b/ stick with the shorter list, as we have now, making sure we have one for each extension and general ones for Itests, samples, demos , distribution etc. +1 for b, stick to the list we have now, until components disappear or new components emerge and have issues that need to be tracked. 3/ Continue the theme of creating JIRAs for the bug/enhancements we see and assigning them to the release where we want them to be fixed. +1 therefore my question above about 1.0.1 :) B.t.w I'm happy to do admin tasks as appropriate. Simon -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I think that we, as a community, have to decide what sort of change would necessitate a 1.0.1 release. Looking at the JIRAs there now these can all be addressed in 1.1 in my opinion. 1.0.1 would just be for emergencies when people can't take the latest code from trunk for some reason. I will reassign them unless anyone shouts. Simon just for emergencies seems too strong to me, I'll wait a bit to see what problems get discovered but I'm quite keen on some 1.0.x releases and think any common problem that users see with 1.0 could be a candidate. Take TUSCANY-1795 as an example, if this is really what happens when anyone tries the sample then thats not a very good user experience so if its an easy fix why not fix it? I think the important thing is to try to keep the changes in each 1.0.x release small so its really easy to review and get the votes through with minimum effort. ...ant
Re: [DISCUSS] JIRA - was:Fwd: Change freeze on 1.0 branch
On 9/26/07, ant elder [EMAIL PROTECTED] wrote: On 9/25/07, Simon Laws [EMAIL PROTECTED] wrote: On 9/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: Hi It feels like we have been getting better at using JIRA in the run up to 0.99 and 1.0 release in terms of the consistency with which we raise bug reports and assign them to releases. Based on Ant's branch freeze suggestion how about we now 1/ create the following versions in JIRA JAVA-SCA-1.1 - as the trunk target JAVA-SCA-1.0.1 - as the 1.0 branch target in case we need it Dare I ask :) Java SCA 1.0.1 has 12 unresolved issues? Is anybody working on fixing these 12 issues for a 1.0.1 release different from 1.1 ? When can I download 1.0.1? 2/ Review the JIRA components to make them match the modules we currently have. Several options here, e.g. a/ add a component for any module we have in svn that is not represented b/ stick with the shorter list, as we have now, making sure we have one for each extension and general ones for Itests, samples, demos , distribution etc. +1 for b, stick to the list we have now, until components disappear or new components emerge and have issues that need to be tracked. 3/ Continue the theme of creating JIRAs for the bug/enhancements we see and assigning them to the release where we want them to be fixed. +1 therefore my question above about 1.0.1 :) B.t.w I'm happy to do admin tasks as appropriate. Simon -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I think that we, as a community, have to decide what sort of change would necessitate a 1.0.1 release. Looking at the JIRAs there now these can all be addressed in 1.1 in my opinion. 1.0.1 would just be for emergencies when people can't take the latest code from trunk for some reason. I will reassign them unless anyone shouts. Simon just for emergencies seems too strong to me, I'll wait a bit to see what problems get discovered but I'm quite keen on some 1.0.x releases and think any common problem that users see with 1.0 could be a candidate. Take TUSCANY-1795 as an example, if this is really what happens when anyone tries the sample then thats not a very good user experience so if its an easy fix why not fix it? I think the important thing is to try to keep the changes in each 1.0.x release small so its really easy to review and get the votes through with minimum effort. ...ant Ok, point taken. Emergency was maybe a little strong. The question is how we decide that a 1.0.X release is required. There are no hard and fast rules and no release plan (there has been no release discussion for 1.1 on the list yet either but that is a different discussion). At some point someone will stick their hand up and suggest a 1.0.1 release is required. I was suggesting the trigger for this is a problem that seriously detracts from the usability of 1.0 (a common problem that users see). I.e. we need to set the expectation that just because JIRAs get flagged against 1.0.1 doesn't mean that's where they will get fixed. Simon
[jira] Closed: (TUSCANY-1781) Will binding-jms be available in Tuscany SCA Java 1.0?
[ https://issues.apache.org/jira/browse/TUSCANY-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1781. -- Resolution: Fixed No its not ready in time for 1.0, seems like there's some interest in it so hopefully it should be in the 1.1 release Will binding-jms be available in Tuscany SCA Java 1.0? -- Key: TUSCANY-1781 URL: https://issues.apache.org/jira/browse/TUSCANY-1781 Project: Tuscany Issue Type: New Feature Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-1.0 Reporter: Yan I am just wondering if binding-jms will be available in the Tuscany SCA Java 1.0 release? It doesn't seem to exist in current 0.99 version. 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] Updated: (TUSCANY-1789) Is binding-jms available?
[ https://issues.apache.org/jira/browse/TUSCANY-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1789: --- Fix Version/s: Java-SCA-Next Is binding-jms available? - Key: TUSCANY-1789 URL: https://issues.apache.org/jira/browse/TUSCANY-1789 Project: Tuscany Issue Type: New Feature Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.99 Reporter: Yan Fix For: Java-SCA-Next I wish to expose service to JMS client through SCA's JMS binding component. But I can't find the binding-jms module in the current tuscany sca 0.99 version or the future 1.0 version. I browsed the previous posts, it seems that the JMS binding has ever been included in the tuscany sca 0.90 release. I am wondering if it is available in the current release and how I should use it. Thank you very much!! -- 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: Contribute to SCA-OSGi integration
Bill, We are prototyping some code which require SCA modules running in an OSGi container, and would be very keen on using your implementation (SCA container built using OSGi). If you have prototype code which already runs with Felix, would it be possible for you to submit the code? At the moment, it would be sufficient for us to have SCA modules running in OSGi with dependency resolution handled by OSGi, and it doesn't matter if the OSGi service registry is not used for service lookup. Thank you... Regards, Rajini On 6/23/07, Bill Barnhill [EMAIL PROTECTED] wrote: Hi, I've made some progress using host embedded, and have that running within Felix. I have a barebones module that is also a bundle, but all the regular modules are in one big Tuscany bundle right now. It's been shelved the past few weeks due to transitioning to a new project, but now I'm settled in on my new task I should be able to make time to work on Tuscany again. I'd like to execute the following tasks before I submit a patch with an attached src zip (that is right way, yes?): .. Refactor to a) make it easier to use with Eclipse, Oscar; b) clean up code .. My test coverage is at about 60%, and I'd like to get it up above 85% before submitting .. Write tool that takes an already packaged Tuscany module in a jar and injects necessary components to make it an OSGI bundle as well. I have design notes, a collaboration diagram, and a couple of sequence diagrams, but no code yet, so that may take a while Given the above and my schedule I'd like to allow plenty of time, so figure 1st patch submit NLT 7/30. On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Community is a verb, increase your Communitivity today! Visit us at http://Communitivity.com; =Bill.Barnhill, President Communitivity, Inc.
[jira] Updated: (TUSCANY-1802) RMI Implementation Error Handling lost inner exception's detail information
[
https://issues.apache.org/jira/browse/TUSCANY-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder updated TUSCANY-1802:
---
Fix Version/s: (was: Java-SCA-0.99)
Java-SCA-Next
RMI Implementation Error Handling lost inner exception's detail information
---
Key: TUSCANY-1802
URL: https://issues.apache.org/jira/browse/TUSCANY-1802
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Reporter: Yang Sun
Fix For: Java-SCA-Next
Here is an email I sent to the tuscany user group. Raymond Feng confirms it
may be a potential bug. Please have a look.
/--
Hi,
I am a new user of Tuscany and I am very excited with this great software. I
am trying to introduce it into my project and currently I am evaluate it with
every possible situations.
Currently, I met a small problem with the spring implementation. I am not
sure if I understand the background and configure the composites right.
Please correct me if I make anything wrong.
The problem I met is that I cannot get the detailed original exception when
the server-side throw any kinds of exceptions. After a rough looking at the
src code and debugging, I see the following code in SpringInvoker.java :
---
private Object doInvoke(Object payload) throws SpringInvocationException {
if (theMethod == null)
setupMethod();
if (badInvoker)
throw new SpringInvocationException(Spring invoker incorrectly
configured);
// Invoke the method on the Spring bean using the payload, returning
the results
try {
Object ret;
if (payload != null !payload.getClass().isArray()) {
ret = theMethod.invoke(bean, payload);
} else {
ret = theMethod.invoke(bean, (Object[])payload);
}
return ret;
} catch (InvocationTargetException e) {
throw new SpringInvocationException(e.getMessage());
} catch (Exception e) {
throw new SpringInvocationException(e.getMessage());
}
} // end method doInvoke
When the invoked method throw an exception (checked or unchecked), the
program flow will go to the InvocationTargetException exception handler. Then
the program only put the message of the original message to the wrapper
exception SpringInvocationException. The detailed information of the original
exception is missing. I am thinking it is here that will lost the detailed
information of the original exception detail.
The reason for me to bring this question is that if we cannot get the
detailed information of the original exception, how can we deal with the
application exceptions (such as NotEnoughMoneyException)? The only thing I
can get is the java.lang.reflect.InvocationTargetException wrapped in
java.rmi.UnexpectedException. And with those information, I cannot get the
right information to make the further decision in the program.
I am not sure whether I got the right point or if I misunderstand anything.
Please give me some suggestions on this problem.
Best Regards,
Yang Sun
/
--
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]
[DISCUSS] SCA Domain
We have two SCADomain interfaces (I'm leaving aside EmbeddedSCADomain for now) 1) o.a.t.s.host.embedded.SCADomain (supports a domian with a single node) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String contributionLocation, String... composites) *A* public static void removeInstance(SCADomain domainInstance) *A* public static SCADomain connect(String domainURI) public void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName) private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String contributionLocation, String... composites) *B* public ComponentManager getComponentManager() 2) o.a.t.s.domain.SCADomain (supports a domain with one or more nodes) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) public abstract void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName); private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) I propose we move to having one. I've marked the parts that differ with *?*. There are two main points. *A* The mechanism by which this local domain representation (the node) is associated with a wider logical domain *B* The mechanism by which the domain is managed (the components in the domains single node in the case of 1 above) Before we start re-positioning interfaces though we need to agree what we mean by the words we use here as there has been some confusion. We've discussed these issues before [1][2][3] etc. The result was a separation of node and domain so that you could operate on a node and on a domain. This approach/API is currently hidden behind SCADomain as there was no consensus that this was the right approach. e.g. I've heard people saying things like a node shouldn't provide an interface for adding contributions as you add contributions to a domain. I want to push on the issue of how we expect users to deal with a domain and the nodes in that domain before going back to look at the API. My starter for 10 is... - There are different types of users we must consider. Here are two examples, 1/ the developer who uses the Tuscany APIs to build a node implementation and makes contributions and manages components programmatically (see our samples for an example of this approach) 2/ the user who manages one or more nodes as a domain, making contributions and managing components through a GUI. - Programmatically, to developer 1/, a node API provides sca runtime support and has to implement all of the management interfaces for accepting contributions, managing components etc, so that developer 1/ can wire tuscany into whatever mechanism they have in their implementation and so that, once the node is added to a domain, the domain can configure and manage the node. The implication here is that the node is configured and managed through contribution/component management interfaces that is a superset of that of a domain (a superset as I would expect use of other detailed Tuscany APIs to get the node to work) - Programmatically, to developer 1/, there should also be a domain representation so that they can include their node in a domain and perform domain level operations like locating a service (or even adding contributions, management components at a domain level). Developer 1/ would associate their node implementation with a domain (within a single VM this would be as easy as passing the node object into the domain interface). - To the user of type 2/ all of these operations may be performed through a GUI using some slick drag and drop management interface. However, they are the same operations. We don't have a slick GUI interface currently so contributions find their way directly to nodes because they are made programmatically in the node in question. The implication though is that if we do things at the domain level under the covers the real processing is delegated to the nodes in the domain. So opinions please on how you see domains and nodes working. Regards Simon [1]
Re: OSGi manifests in SDO Jars, was: Tuscany and OSGi
You are right, as far as I understand it's just history/legacy. If
there's a volunteer to help clean this up and make the jars more
friendly that would be really great; I don't have a detailed
understanding of what's best here.
Kelvin.
On 26/09/2007, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:
Philippe Ombredanne wrote:
All:
Some of the built binaries alreday have a manifest that is
semi-osgi'fied.
I suggest that it would be really nice if all the tuscany binaries could
be delivered with a complete OSGi manifest.
I can see only good stuffs from that as it makes OSGi friendly for Felix
or Eclipse or general OSGi consumption.
That is something that could be done as part of the build with little to
no core code change.
There are tools at Felix and http://www.aqute.biz/Code/Bnd that can help
there.
Ideally we should be to infer most everything from the poms.
In practice there may be some subtle devilish details that may require
some manual adjustments, but nothing extra ordinary.
What do you think?
It's not the first time that this comes up:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/[EMAIL
PROTECTED]
... good that you bring it up again as it looks like there was
consensus to add OSGi manifest entries to the SCA API Jar, but it has
not been done yet :)
Only the SDO API Jar manifest contain OSGi entries at the moment,
generated using the Felix plugin like that:
plugin
groupIdorg.apache.felix.plugins/groupId
artifactIdmaven-osgi-plugin/artifactId
version0.8.0-SNAPSHOT/version
extensionstrue/extensions
configuration
osgiManifest
bundleName${pom.name}/bundleName
bundleDescription${pom.description}/bundleDescription
bundleVendor${pom.organization.name}/bundleVendor
bundleLocalizationplugin/bundleLocalization
bundleSymbolicNamecommonj.sdo/bundleSymbolicName
exportPackage
commonj.sdo;version=${specVersion},
commonj.sdo.helper;version=${specVersion},
commonj.sdo.impl;version=${specVersion}
/exportPackage
/osgiManifest
/configuration
/plugin
The SDO pom.xml probably needs to upgrade from Felix 0.8.0-SNAPSHOT to
1.0.0, and I believe that the plugin has been renamed to
maven-bundle-plugin now.
+1 from me to start adding OSGi manifest entries to the SCA sca-api
and domain-api Jars.
I'm not sure about adding OSGi manifests entries to all the other
implementation Jars which do not publish any Application programming
interfaces. Which configuration / use case will benefit from having
OSGi manifest entries in these Jars?
Thoughts?
Actually more SDO Jars have OSGi manifests entries, generated
differently, like that:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.1/version
configuration
archive
manifestEntries
Extension-Name${project.artifactId}/Extension-Name
Specification-Title${project.name}/Specification-Title
Specification-Vendor${project.organization.name}/Specification-Vendor
Specification-Version${version}/Specification-Version
Implementation-Title${project.artifactId}/Implementation-Title
Implementation-Vendor${project.organization.name}/Implementation-Vendor
Implementation-Vendor-Idorg.apache/Implementation-Vendor-Id
Implementation-Version${project.version}/Implementation-Version
!--
Bundle-ManifestVersion2/Bundle-ManifestVersion
Bundle-Name${project.name}/Bundle-Name
Bundle-SymbolicNameorg.apache.tuscany.sdo.impl/Bundle-SymbolicName
Bundle-Version1.0.0/Bundle-Version
Bundle-Vendor${project.organization.name}/Bundle-Vendor
--
Require-Bundleorg.eclipse.emf.common,org.eclipse.emf.ecore,org.eclipse.emf.ecore.change,org.eclipse.emf.ecore.xmi,org.eclipse.xsd,org.apache.tuscany.sdo.spec;visibility:=reexport/Require-Bundle
Export-Packagecommonj.sdo.impl,org.apache.tuscany.sdo,org.apache.tuscany.sdo.helper,org.apache.tuscany.sdo.impl,org.apache.tuscany.sdo.test,org.apache.tuscany.sdo.util/Export-Package
/manifestEntries
/archive
/configuration
/plugin
This looks a little more complicated than the Felix way... Could the SDO
folks shed some light on why some modules use Felix and others not? is
it history? legacy? :) or is there a technical reason for that?
Thanks
--
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: [DISCUSS] SCA Domain
On 9/26/07, Simon Laws [EMAIL PROTECTED] wrote: We have two SCADomain interfaces (I'm leaving aside EmbeddedSCADomain for now) 1) o.a.t.s.host.embedded.SCADomain (supports a domian with a single node) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String contributionLocation, String... composites) *A* public static void removeInstance(SCADomain domainInstance) *A* public static SCADomain connect(String domainURI) public void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName) private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String contributionLocation, String... composites) *B* public ComponentManager getComponentManager() 2) o.a.t.s.domain.SCADomain (supports a domain with one or more nodes) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) public abstract void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName); private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) I propose we move to having one. I've marked the parts that differ with *?*. There are two main points. *A* The mechanism by which this local domain representation (the node) is associated with a wider logical domain *B* The mechanism by which the domain is managed (the components in the domains single node in the case of 1 above) Before we start re-positioning interfaces though we need to agree what we mean by the words we use here as there has been some confusion. We've discussed these issues before [1][2][3] etc. The result was a separation of node and domain so that you could operate on a node and on a domain. This approach/API is currently hidden behind SCADomain as there was no consensus that this was the right approach. e.g. I've heard people saying things like a node shouldn't provide an interface for adding contributions as you add contributions to a domain. I want to push on the issue of how we expect users to deal with a domain and the nodes in that domain before going back to look at the API. My starter for 10 is... - There are different types of users we must consider. Here are two examples, 1/ the developer who uses the Tuscany APIs to build a node implementation and makes contributions and manages components programmatically (see our samples for an example of this approach) 2/ the user who manages one or more nodes as a domain, making contributions and managing components through a GUI. - Programmatically, to developer 1/, a node API provides sca runtime support and has to implement all of the management interfaces for accepting contributions, managing components etc, so that developer 1/ can wire tuscany into whatever mechanism they have in their implementation and so that, once the node is added to a domain, the domain can configure and manage the node. The implication here is that the node is configured and managed through contribution/component management interfaces that is a superset of that of a domain (a superset as I would expect use of other detailed Tuscany APIs to get the node to work) - Programmatically, to developer 1/, there should also be a domain representation so that they can include their node in a domain and perform domain level operations like locating a service (or even adding contributions, management components at a domain level). Developer 1/ would associate their node implementation with a domain (within a single VM this would be as easy as passing the node object into the domain interface). - To the user of type 2/ all of these operations may be performed through a GUI using some slick drag and drop management interface. However, they are the same operations. We don't have a slick GUI interface currently so contributions find their way directly to nodes because they are made programmatically in the node in question. The implication though is that if we do things at the domain level under the covers the real processing is delegated to the nodes in the domain.
Re: Wiki diagram source
The sync is being done from the svn to the website. The sync script I'm using is : https://svn.apache.org/repos/asf/incubator/tuscany/site/bin/sync On 9/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 9/25/07, Luciano Resende [EMAIL PROTECTED] wrote: Some static files are still stored in SVN [1], and I see a image-sources there, so we could either use that one, or a new one. As for syncup, yes, it's still happening. [1] https://svn.apache.org/repos/asf/incubator/tuscany/site/ On 9/25/07, Simon Laws [EMAIL PROTECTED] wrote: I have the source for a few of the diagrams that are used in the wiki in my sandbox. Not the best place for them. 1/ Where is everyone putting this kind of source? How about we have a wiki/diagrams section of svn? 2/ I note that the doc on the website wiki about cwiki setup ( http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56590) suggest that content is being updated in SVN. Is this really happening and if so where is it going? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano Are you saying that content is being synched 1) from svn to the web site or 2) from the web site to svn. Looking at the svn like you posted it doesn't look like there is new content there so I'm assuming you mean 1). If so what is this content being used for. If there is already a director there for images I think we should use it (sorry I didn't spot it). But this somewhat depends on the behaviour of the synch operation. I.e. what is the implication of putting new content under the site directory. Will it be either 1) appear on the site in an unexpected place or 2) get overwritten by updates from the sit. Can you point me to the job that is doing the web site generation/svn synching? Thanks Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1810) SDOUtil.createHelperContext() fails with NPE on HP-UX and Solaris
SDOUtil.createHelperContext() fails with NPE on HP-UX and Solaris - Key: TUSCANY-1810 URL: https://issues.apache.org/jira/browse/TUSCANY-1810 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: This fails on HP-UX and Solaris. It works fine on all other platforms tested. Reporter: Travis Nelson Priority: Blocker The following exception is thrown when attempting to create the helper context: java.lang.NullPointerException at org.eclipse.emf.ecore.impl.EPackageRegistryImpl$Delegator.getEFactory(EPackageRegistryImpl.java:250) at org.eclipse.emf.ecore.impl.EcoreFactoryImpl.init(EcoreFactoryImpl.java:55) at org.eclipse.emf.ecore.EcoreFactory.clinit(EcoreFactory.java:35) at org.eclipse.emf.ecore.util.BasicExtendedMetaData.clinit(BasicExtendedMetaData.java:2139) at org.apache.tuscany.sdo.helper.DefaultHelperContextImpl.init(DefaultHelperContextImpl.java:31) at org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:37) at org.apache.tuscany.sdo.spi.HelperProviderBase.init(HelperProviderBase.java:81) at org.apache.tuscany.sdo.helper.HelperProviderImpl.init(HelperProviderImpl.java:30) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:157) at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126) at commonj.sdo.impl.HelperProvider.clinit(HelperProvider.java:69) at org.apache.tuscany.sdo.api.SDOUtil.clinit(SDOUtil.java:47) at org.apache.tuscany.sdo.util.SDOUtil.createHelperContext(SDOUtil.java:389) -- 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-1795) helloworld-bpel sample fails with NoClassDefFoundError
[
https://issues.apache.org/jira/browse/TUSCANY-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530479
]
Raymond Feng commented on TUSCANY-1795:
---
It might be related to http://jira.codehaus.org/browse/SUREFIRE-322
helloworld-bpel sample fails with NoClassDefFoundError
--
Key: TUSCANY-1795
URL: https://issues.apache.org/jira/browse/TUSCANY-1795
Project: Tuscany
Issue Type: Bug
Components: Java SCA Samples
Affects Versions: Java-SCA-1.0
Environment: Windows XP
Reporter: Simon Nash
Fix For: Java-SCA-1.0.1
I ran the helloworld-bpel sample following the instructions in the README to
update the pom to use
useSystemClassLoadertrue/useSystemClassLoader
The sample failed with the following output:
[INFO] [compiler:compile]
[INFO] Compiling 6 source files to
H:\tuscany-1.0-rc3a\tuscany-sca-1.0-incubating\samples\helloworld-bpel\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to
H:\tuscany-1.0-rc3a\tuscany-sca-1.0-incubating\samples\helloworld-bpel\target\test-classes
[INFO] [dependency:unpack {execution: unpack}]
[INFO] Configured Artifact: org.apache.ode:ode-dao-jpa-ojpa-derby:1.1:zip
[INFO] Expanding: C:\Documents and
Settings\nash\.m2\repository\org\apache\ode\ode-dao-jpa-ojpa-derby\1.1\ode-dao-jpa-ojpa-derby-1.1.zip
into
:\tuscany-1.0-rc3a\tuscany-sca-1.0-incubating\samples\helloworld-bpel\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
H:\tuscany-1.0-rc3a\tuscany-sca-1.0-incubating\samples\helloworld-bpel\target\surefire-reports
[INFO] Building jar: C:\DOCUME~1\nash\LOCALS~1\Temp\surefirebooter7486.jar
java.lang.NoClassDefFoundError:
org/apache/maven/surefire/booter/SurefireBooter
Exception in thread main
[INFO]
[ERROR] BUILD FAILURE
[INFO]
--
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-1811) ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:float
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)
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:130)
at
Re: [DISCUSS] SCA Domain
On 9/26/07, ant elder [EMAIL PROTECTED] wrote: On 9/26/07, Simon Laws [EMAIL PROTECTED] wrote: We have two SCADomain interfaces (I'm leaving aside EmbeddedSCADomain for now) 1) o.a.t.s.host.embedded.SCADomain (supports a domian with a single node) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String contributionLocation, String... composites) *A* public static void removeInstance(SCADomain domainInstance) *A* public static SCADomain connect(String domainURI) public void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName) private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String contributionLocation, String... composites) *B* public ComponentManager getComponentManager() 2) o.a.t.s.domain.SCADomain (supports a domain with one or more nodes) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) public abstract void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName); private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) I propose we move to having one. I've marked the parts that differ with *?*. There are two main points. *A* The mechanism by which this local domain representation (the node) is associated with a wider logical domain *B* The mechanism by which the domain is managed (the components in the domains single node in the case of 1 above) Before we start re-positioning interfaces though we need to agree what we mean by the words we use here as there has been some confusion. We've discussed these issues before [1][2][3] etc. The result was a separation of node and domain so that you could operate on a node and on a domain. This approach/API is currently hidden behind SCADomain as there was no consensus that this was the right approach. e.g. I've heard people saying things like a node shouldn't provide an interface for adding contributions as you add contributions to a domain. I want to push on the issue of how we expect users to deal with a domain and the nodes in that domain before going back to look at the API. My starter for 10 is... - There are different types of users we must consider. Here are two examples, 1/ the developer who uses the Tuscany APIs to build a node implementation and makes contributions and manages components programmatically (see our samples for an example of this approach) 2/ the user who manages one or more nodes as a domain, making contributions and managing components through a GUI. - Programmatically, to developer 1/, a node API provides sca runtime support and has to implement all of the management interfaces for accepting contributions, managing components etc, so that developer 1/ can wire tuscany into whatever mechanism they have in their implementation and so that, once the node is added to a domain, the domain can configure and manage the node. The implication here is that the node is configured and managed through contribution/component management interfaces that is a superset of that of a domain (a superset as I would expect use of other detailed Tuscany APIs to get the node to work) - Programmatically, to developer 1/, there should also be a domain representation so that they can include their node in a domain and perform domain level operations like locating a service (or even adding contributions, management components at a domain level). Developer 1/ would associate their node implementation with a domain (within a single VM this would be as easy as passing the node object into the domain interface). - To the user of type 2/ all of these operations may be performed through a GUI using some slick drag and drop management interface. However, they are the same operations. We don't have a slick GUI interface currently so contributions find their way directly to nodes because they are made programmatically in the
Re: [DISCUSS] SCA Domain
Should we also consider how this SCADomain would work in the context of multiple contributions ? On 9/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 9/26/07, ant elder [EMAIL PROTECTED] wrote: On 9/26/07, Simon Laws [EMAIL PROTECTED] wrote: We have two SCADomain interfaces (I'm leaving aside EmbeddedSCADomain for now) 1) o.a.t.s.host.embedded.SCADomain (supports a domian with a single node) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String contributionLocation, String... composites) *A* public static void removeInstance(SCADomain domainInstance) *A* public static SCADomain connect(String domainURI) public void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName) private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String contributionLocation, String... composites) *B* public ComponentManager getComponentManager() 2) o.a.t.s.domain.SCADomain (supports a domain with one or more nodes) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) public abstract void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName); private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) I propose we move to having one. I've marked the parts that differ with *?*. There are two main points. *A* The mechanism by which this local domain representation (the node) is associated with a wider logical domain *B* The mechanism by which the domain is managed (the components in the domains single node in the case of 1 above) Before we start re-positioning interfaces though we need to agree what we mean by the words we use here as there has been some confusion. We've discussed these issues before [1][2][3] etc. The result was a separation of node and domain so that you could operate on a node and on a domain. This approach/API is currently hidden behind SCADomain as there was no consensus that this was the right approach. e.g. I've heard people saying things like a node shouldn't provide an interface for adding contributions as you add contributions to a domain. I want to push on the issue of how we expect users to deal with a domain and the nodes in that domain before going back to look at the API. My starter for 10 is... - There are different types of users we must consider. Here are two examples, 1/ the developer who uses the Tuscany APIs to build a node implementation and makes contributions and manages components programmatically (see our samples for an example of this approach) 2/ the user who manages one or more nodes as a domain, making contributions and managing components through a GUI. - Programmatically, to developer 1/, a node API provides sca runtime support and has to implement all of the management interfaces for accepting contributions, managing components etc, so that developer 1/ can wire tuscany into whatever mechanism they have in their implementation and so that, once the node is added to a domain, the domain can configure and manage the node. The implication here is that the node is configured and managed through contribution/component management interfaces that is a superset of that of a domain (a superset as I would expect use of other detailed Tuscany APIs to get the node to work) - Programmatically, to developer 1/, there should also be a domain representation so that they can include their node in a domain and perform domain level operations like locating a service (or even adding contributions, management components at a domain level). Developer 1/ would associate their node implementation with a domain (within a single VM this would be as easy as passing the node object into the domain interface). - To the user of type 2/ all of these operations may be performed
Re: [DISCUSS] SCA Domain
On 9/26/07, Luciano Resende [EMAIL PROTECTED] wrote: Should we also consider how this SCADomain would work in the context of multiple contributions ? On 9/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 9/26/07, ant elder [EMAIL PROTECTED] wrote: On 9/26/07, Simon Laws [EMAIL PROTECTED] wrote: We have two SCADomain interfaces (I'm leaving aside EmbeddedSCADomain for now) 1) o.a.t.s.host.embedded.SCADomain (supports a domian with a single node) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String contributionLocation, String... composites) *A* public static void removeInstance(SCADomain domainInstance) *A* public static SCADomain connect(String domainURI) public void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName) private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String contributionLocation, String... composites) *B* public ComponentManager getComponentManager() 2) o.a.t.s.domain.SCADomain (supports a domain with one or more nodes) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) public abstract void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName); private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) I propose we move to having one. I've marked the parts that differ with *?*. There are two main points. *A* The mechanism by which this local domain representation (the node) is associated with a wider logical domain *B* The mechanism by which the domain is managed (the components in the domains single node in the case of 1 above) Before we start re-positioning interfaces though we need to agree what we mean by the words we use here as there has been some confusion. We've discussed these issues before [1][2][3] etc. The result was a separation of node and domain so that you could operate on a node and on a domain. This approach/API is currently hidden behind SCADomain as there was no consensus that this was the right approach. e.g. I've heard people saying things like a node shouldn't provide an interface for adding contributions as you add contributions to a domain. I want to push on the issue of how we expect users to deal with a domain and the nodes in that domain before going back to look at the API. My starter for 10 is... - There are different types of users we must consider. Here are two examples, 1/ the developer who uses the Tuscany APIs to build a node implementation and makes contributions and manages components programmatically (see our samples for an example of this approach) 2/ the user who manages one or more nodes as a domain, making contributions and managing components through a GUI. - Programmatically, to developer 1/, a node API provides sca runtime support and has to implement all of the management interfaces for accepting contributions, managing components etc, so that developer 1/ can wire tuscany into whatever mechanism they have in their implementation and so that, once the node is added to a domain, the domain can configure and manage the node. The implication here is that the node is configured and managed through contribution/component management interfaces that is a superset of that of a domain (a superset as I would expect use of other detailed Tuscany APIs to get the node to work) - Programmatically, to developer 1/, there should also be a domain representation so that they can include their node in a domain and perform domain level operations like locating a service (or even adding contributions, management components at a domain level). Developer 1/ would associate their node
Re: [jira] Created: (TUSCANY-1809) Build Error - SCA topology XML model fails to resolve tuscany-core-spi
On 9/25/07, dinesh shahane (JIRA) tuscany-dev@ws.apache.org wrote: Build Error - SCA topology XML model fails to resolve tuscany-core-spi -- Key: TUSCANY-1809 URL: https://issues.apache.org/jira/browse/TUSCANY-1809 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.0 Reporter: dinesh shahane Fix For: Java-SCA-1.0 I am seeing the following error while building modules. [INFO] Building Apache Tuscany SCA Topology XML Model [INFO] - --- [INFO] No goals needed for project - skipping Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/t uscany/sca/tuscany-core-spi/1.1-incubating-SNAPSHOT/tuscany- core-spi-1.1-incubat ing-SNAPSHOT.jar Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/tus cany/sca/tuscany-core-spi/1.1-incubating-SNAPSHOT/tuscany- core-spi-1.1-incubatin g-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.tuscany.sca:tuscany-core-spi:jar:1.1-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca-DartifactId=tus cany-core-spi \ -Dversion=1.1-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.tuscany.sca-DartifactId=tuscany -core-spi \ -Dversion=1.1-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:tuscany-contribution-namespace:jar:1.1-incubat ing-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-core-spi:jar:1.1-incubating-SNAPSHOT -- 1 required artifact is missing. -- 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] Hi Dinesh This seems to be ok for me. Not a great help to you I know. The topology modules don't actually get used at the moment and there is discussion about removing them altogether so you can ignore these problems if these are the only ones you see. Bit strange that you see them and I don't though. Looks like you have checked out of the trunk code judging by the version numbers. There is a bit of turbulence in trunk at the moment so maybe something was a little out of line when you checked out. The topology-ml pom doesn't have an explicit dependency stated for core-spi but I would expect this to have been build by the time topology gets built. Try compiling core-spi manually first if it's not there. Regards Simon
[jira] Commented: (TUSCANY-1809) Build Error - SCA topology XML model fails to resolve tuscany-core-spi
[ https://issues.apache.org/jira/browse/TUSCANY-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530520 ] dinesh shahane commented on TUSCANY-1809: - Thanks raymond, I could now build the trunk successfully once I moved to maven 2.0.5. Should I keep this issue open? Build Error - SCA topology XML model fails to resolve tuscany-core-spi -- Key: TUSCANY-1809 URL: https://issues.apache.org/jira/browse/TUSCANY-1809 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.0 Reporter: dinesh shahane Fix For: Java-SCA-1.0 I am seeing the following error while building modules. [INFO] Building Apache Tuscany SCA Topology XML Model [INFO] - --- [INFO] No goals needed for project - skipping Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/t uscany/sca/tuscany-core-spi/1.1-incubating-SNAPSHOT/tuscany-core-spi-1.1-incubat ing-SNAPSHOT.jar Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/tus cany/sca/tuscany-core-spi/1.1-incubating-SNAPSHOT/tuscany-core-spi-1.1-incubatin g-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.tuscany.sca:tuscany-core-spi:jar:1.1-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca -DartifactId=tus cany-core-spi \ -Dversion=1.1-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany -core-spi \ -Dversion=1.1-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:tuscany-contribution-namespace:jar:1.1-incubat ing-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-core-spi:jar:1.1-incubating-SNAPSHOT -- 1 required artifact is missing. -- 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-1812) XMLHelper.load() IOException using schema that has both a substitution group and an extension
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(XMLHelperImpl.java:79)
at
org.apache.tuscany.sdo.test.SubstitutionWithExtensionValuesTestCase.test(SubstitutionWithExtensionValuesTestCase.java:51)
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
[jira] Commented: (TUSCANY-1806) Support for SOAP over JMS in Axis binding
[ https://issues.apache.org/jira/browse/TUSCANY-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530523 ] dinesh shahane commented on TUSCANY-1806: - Simon, I have created testcases for helloworld-service and helloworld-reference samples and it seem to work fine after I removed parameters from transportReceiver element in axis2.xml. I don't see any issue with any other samples and tests in my fresh build. Attached is the patch file (tuscany_1.0_binding-ws-axis2_soap_jms_TUSCANY-1806_with_testcases.diff) that includes the testcases. thanks, Dinesh Support for SOAP over JMS in Axis binding - Key: TUSCANY-1806 URL: https://issues.apache.org/jira/browse/TUSCANY-1806 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0, Java-SCA-1.0.1 Reporter: dinesh shahane Assignee: Simon Laws Attachments: tuscany_1.0_binding-ws-axis2_soap_jms_TUSCANY-1806.diff Axis2 binding currently supports SOAP over HTTP, a simple SOAP/JMS support could be added using the Axis2 functionality. The following email thread has information about the proposed enhancements. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20760.html Attached patch file has support for SOAP/JMS along with samples containing service and reference. This patch modifies axis2.xml and Axis2ServiceProvider class to create a SOAP/JMS service based on specified @wsdl.port and @uri/@wsdl.binding in binding.ws element. Currently it doesn't support EndpointReference or extensibility elements as discussed in the email thread. -- 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-1806) Support for SOAP over JMS in Axis binding
[ https://issues.apache.org/jira/browse/TUSCANY-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dinesh shahane updated TUSCANY-1806: Attachment: tuscany_1.0_binding-ws-axis2_soap_jms_TUSCANY-1806_with_testcases.diff Support for SOAP over JMS in Axis binding - Key: TUSCANY-1806 URL: https://issues.apache.org/jira/browse/TUSCANY-1806 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0, Java-SCA-1.0.1 Reporter: dinesh shahane Assignee: Simon Laws Attachments: tuscany_1.0_binding-ws-axis2_soap_jms_TUSCANY-1806.diff, tuscany_1.0_binding-ws-axis2_soap_jms_TUSCANY-1806_with_testcases.diff Axis2 binding currently supports SOAP over HTTP, a simple SOAP/JMS support could be added using the Axis2 functionality. The following email thread has information about the proposed enhancements. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20760.html Attached patch file has support for SOAP/JMS along with samples containing service and reference. This patch modifies axis2.xml and Axis2ServiceProvider class to create a SOAP/JMS service based on specified @wsdl.port and @uri/@wsdl.binding in binding.ws element. Currently it doesn't support EndpointReference or extensibility elements as discussed in the email thread. -- 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-1813) WSDL Message Types stored in SDO DataFactory incorrectly
WSDL Message Types stored in SDO DataFactory incorrectly Key: TUSCANY-1813 URL: https://issues.apache.org/jira/browse/TUSCANY-1813 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M3 Environment: All platforms Reporter: Brady Johnson Fix For: Cpp-Next Once all of the WSLDs, Composites, etc have been parsed for a particular service, the WSDL types are incorrectly stored in the SDO DataFactory. I found this by loading the CppBigBank service in a container and trying to use/create data types that should have been loaded when the wsdls were parsed, but the types were not found. I then called Utils::printTypes() to see what exactly was in the SDO DataFactory and saw the following excerpt: ... Type: http://www.bigbank.com/AccountService#http://www.bigbank.com/AccountService#getAccountReport Property: customerID type: commonj.sdo#String Type: http://www.bigbank.com/AccountService#http://www.bigbank.com/AccountService#getAccountReportResponse Property: result type: http://www.bigbank.com/AccountService#AccountReport ... It appears as though the type is being stored as follows: URI = http://www.bigbank.com/AccountService Type=http://www.bigbank.com/AccountService#getAccountReport Its not necessary to store the namespace in the type name. I'm working on localizing the problem now. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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]
[SCA Native] WSDL Message Types stored incorrectly in the SDO DataFactory
I created a JIRA for this and am currently working on localizing where the problem is. https://issues.apache.org/jira/browse/TUSCANY-1813 Basically, it appears that the types are being stored in the SDO DataFactory as follows (copied from Utils::printTypes() ): URI= http://www.bigbank.com/AccountService http://www.bigbank.com/AccountService Type=http://www.bigbank.com/AccountService#getAccountReport http://www.bigbank.com/AccountService#getAccountReport Its not necessary to store the namespace for the type name. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
[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
[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)
at
[jira] Updated: (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:all-tabpanel
]
Ron Gavlin updated TUSCANY-1812:
Description:
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)
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)
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
[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_12530557
]
Ron Gavlin commented on TUSCANY-1812:
-
Hi Frank,
Sorry 'bout that. Interestingly, with that correction, the originally posted
dynamic test case runs fine. I reposted the description which now runs the test
using static SDO and the problem returns. My internal application that is
failing is using static SDO.
This is a regression that appears to have been introduced with the
SDOPackageRegistryDelegator. I have been looking at it a little while but no
solution yet. It appears the EStructuralFeatureExtendedMetaData returned by
BasicExtendedMetaData.getExtendedMetaData(EStructuralFeature) is loosing the
SDOExtendedMetaDataImpl scope and eventually tries to get an EPackage from the
wrong registry. This occurs during its attempt to get the Affiliation. Does
that make sense?
If you have time to look at it, that would be great. If not, I would appreciate
any pointers you can provide. We are trying to migrate to a post-SDO 1.0 build
from a pre-SDO 1.0 build and this is a showstopper.
Regards,
- Ron
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
[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-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_12530559
]
Ron Gavlin commented on TUSCANY-1811:
-
Precisely!
It would probably be a good idea to generalize
ChangeSummaryGenTestCase.testChangeSummaryOnDataGraphWithInt to include all
primitives.
- Ron
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)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at
[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]
RE: [SCA Native] WSDL Message Types stored incorrectly in the SDO DataFactory
I figured out the problem. It's a matter of how DataFactory::create() is called, since the type in question is an anonymous type. Calling like this does not work: DataFactory::create( http://www.bigbank.com/AccountService;, getAccountReport ) But this does: DataFactory::create( http://www.bigbank.com/AccountService;, http://www.bigbank.com/AccountService#getAccountReport; ) The best way to get the DataObject is like this: const Property prop = XSDHelperPtr-getGlobalProperty( http://www.bigbank.com/AccountService;, getAccountReport, true ); DataObjectPtr sdoObj = dataFactory-create( prop.getType() ); I'll close the JIRA. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Brady Johnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 2:01 PM To: tuscany-dev@ws.apache.org Subject: [SCA Native] WSDL Message Types stored incorrectly in the SDO DataFactory I created a JIRA for this and am currently working on localizing where the problem is. https://issues.apache.org/jira/browse/TUSCANY-1813 Basically, it appears that the types are being stored in the SDO DataFactory as follows (copied from Utils::printTypes() ): URI= http://www.bigbank.com/AccountService http://www.bigbank.com/AccountService Type=http://www.bigbank.com/AccountService#getAccountReport http://www.bigbank.com/AccountService#getAccountReport Its not necessary to store the namespace for the type name. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1813) WSDL Message Types stored in SDO DataFactory incorrectly
[ https://issues.apache.org/jira/browse/TUSCANY-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530578 ] Brady Johnson commented on TUSCANY-1813: I figured out the problem. It's a matter of how DataFactory::create() is called, since the type in question is an anonymous type. Calling like this does not work: DataFactory::create( http://www.bigbank.com/AccountService;, getAccountReport ) But this does: DataFactory::create( http://www.bigbank.com/AccountService;, http://www.bigbank.com/AccountService#getAccountReport; ) The best way to get the DataObject is like this: const Property prop = XSDHelperPtr-getGlobalProperty( http://www.bigbank.com/AccountService;, getAccountReport, true ); DataObjectPtr sdoObj = dataFactory-create( prop.getType() ); I'll close the JIRA. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] WSDL Message Types stored in SDO DataFactory incorrectly Key: TUSCANY-1813 URL: https://issues.apache.org/jira/browse/TUSCANY-1813 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M3 Environment: All platforms Reporter: Brady Johnson Fix For: Cpp-Next Once all of the WSLDs, Composites, etc have been parsed for a particular service, the WSDL types are incorrectly stored in the SDO DataFactory. I found this by loading the CppBigBank service in a container and trying to use/create data types that should have been loaded when the wsdls were parsed, but the types were not found. I then called Utils::printTypes() to see what exactly was in the SDO DataFactory and saw the following excerpt: ... Type: http://www.bigbank.com/AccountService#http://www.bigbank.com/AccountService#getAccountReport Property: customerID type: commonj.sdo#String Type: http://www.bigbank.com/AccountService#http://www.bigbank.com/AccountService#getAccountReportResponse Property: result type: http://www.bigbank.com/AccountService#AccountReport ... It appears as though the type is being stored as follows: URI = http://www.bigbank.com/AccountService Type=http://www.bigbank.com/AccountService#getAccountReport Its not necessary to store the namespace in the type name. I'm working on localizing the problem now. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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] Closed: (TUSCANY-1813) WSDL Message Types stored in SDO DataFactory incorrectly
[ https://issues.apache.org/jira/browse/TUSCANY-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson closed TUSCANY-1813. -- Resolution: Invalid This turned out to be an issue with how I was using SDO. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] WSDL Message Types stored in SDO DataFactory incorrectly Key: TUSCANY-1813 URL: https://issues.apache.org/jira/browse/TUSCANY-1813 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M3 Environment: All platforms Reporter: Brady Johnson Fix For: Cpp-Next Once all of the WSLDs, Composites, etc have been parsed for a particular service, the WSDL types are incorrectly stored in the SDO DataFactory. I found this by loading the CppBigBank service in a container and trying to use/create data types that should have been loaded when the wsdls were parsed, but the types were not found. I then called Utils::printTypes() to see what exactly was in the SDO DataFactory and saw the following excerpt: ... Type: http://www.bigbank.com/AccountService#http://www.bigbank.com/AccountService#getAccountReport Property: customerID type: commonj.sdo#String Type: http://www.bigbank.com/AccountService#http://www.bigbank.com/AccountService#getAccountReportResponse Property: result type: http://www.bigbank.com/AccountService#AccountReport ... It appears as though the type is being stored as follows: URI = http://www.bigbank.com/AccountService Type=http://www.bigbank.com/AccountService#getAccountReport Its not necessary to store the namespace in the type name. I'm working on localizing the problem now. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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-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: wsdl.zip 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 Attachments: 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-1814) Large memory footprint with large wsdl/schemas
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 Attachments: 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] 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: Memory Footprint (Startup Profile).png A graph created from a memory profiler. This was taken from a Websphere installation with Spring loading SDO objects defined as beans, followed by Tuscany servlet startup. The blue is actual memory used while the yellow is memory allocated. 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 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]
Re: Graduation
Here is an attempt to clarify the description a bit more. Old description: 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 related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA, for distribution at no charge to the public. Suggestion: 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 creation and maintenance of open-source software that simplifies development and management of applications using service oriented approach. The lightweight, extensible runtime can be embedded or used stand-alone. This software is for distribution at no charge to the public. On 9/24/07, Matthieu Riou [EMAIL PROTECTED] wrote: On 9/24/07, Luciano Resende [EMAIL PROTECTED] wrote: I have reviewed and updated our STATUS file [1] and Status page (that should be refreshed soon) [2] with latest and missing news. Please let me know if I missed something :) Looks good, it's great that you revived this thread! Any other task from the Graduation checklist [4] that I could help ? You could maybe start a separate thread to discuss the resolution draft? Is everybody happy with the description? Also it's a detail but the common practice is usually to list people Apache e-mail address (@apache.org) for the PMC as it gives the apache id. You have a nice collection of gmail addresses though ;) Matthieu [1] https://svn.apache.org/repos/asf/incubator/tuscany/STATUS [2] http://incubator.apache.org/projects/tuscany.html [3] http://incubator.apache.org/guides/graduation.html [4] http://incubator.apache.org/guides/graduation#checklist On 9/13/07, Matthieu Riou [EMAIL PROTECTED] wrote: Guys, I'm definitely +1 for both graduation and ant as the chair. For the tasks, as ant mentioned the graduation guide [1] is definitely a good read. A few additional details: * In your resolution, one of the most important parts is the description. Don't be too broad, you can eventually expand the scope later on if necessary (simple request/ack to the board). Right now the wording is good but a bit too fuzzy I think. It's also good to add a statement about how the project can interact or play with other projects. * The other important parts of the resolution are the chair and the PMC list. Look like you're pretty much set on that side. You can choose to extend the PMC too, and add committers that aren't in the PPMC yet but would deserve to. * Make sure that your project status page is up-to-date [2] Once you're set, you can start a formal vote on the board resolution in the community. Then you'll ask for the incubator vote. You'll also have to take the board schedule into account. Usually meetings are the third Wednesday of each month so it's too late for this month but you could be in good shape for October (should be the 17th). Cheers! Matthieu [1] http://incubator.apache.org/guides/graduation .html [2] http://incubator.apache.org/projects/tuscany.html On 9/12/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, +1. +1. Can we start to identify work tasks to get us there and then start to parcel out work amongst folk on the project? Yours, Mike. ant elder wrote: So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution , we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html . ..ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: Graduation
Matthieu Riou wrote: Guys, I'm definitely +1 for both graduation and ant as the chair. For the tasks, as ant mentioned the graduation guide [1] is definitely a good read. A few additional details: * In your resolution, one of the most important parts is the description. Don't be too broad, you can eventually expand the scope later on if necessary (simple request/ack to the board). Right now the wording is good but a bit too fuzzy I think. It's also good to add a statement about how the project can interact or play with other projects. * The other important parts of the resolution are the chair and the PMC list. Look like you're pretty much set on that side. You can choose to extend the PMC too, and add committers that aren't in the PPMC yet but would deserve to. * Make sure that your project status page is up-to-date [2] Once you're set, you can start a formal vote on the board resolution in the community. Then you'll ask for the incubator vote. You'll also have to take the board schedule into account. Usually meetings are the third Wednesday of each month so it's too late for this month but you could be in good shape for October (should be the 17th). Cheers! Matthieu [1] http://incubator.apache.org/guides/graduation .html [2] http://incubator.apache.org/projects/tuscany.html I just looked at the calendar at [3] and I'm not sure what people are planning on Sunday but according to this calendar we should start a vote on the resolution this Sunday to be in a good shape for the 17th :) As you said it's better if the resolution is not too fuzzy, I'll try to propose small changes to crisp it up a bit (just saw that Haleh just proposed some changes to it too in this thread). What else can I can help with? [3] http://incubator.apache.org/guides/graduation.html#process -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
On 9/26/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Matthieu Riou wrote: Guys, I'm definitely +1 for both graduation and ant as the chair. For the tasks, as ant mentioned the graduation guide [1] is definitely a good read. A few additional details: * In your resolution, one of the most important parts is the description. Don't be too broad, you can eventually expand the scope later on if necessary (simple request/ack to the board). Right now the wording is good but a bit too fuzzy I think. It's also good to add a statement about how the project can interact or play with other projects. * The other important parts of the resolution are the chair and the PMC list. Look like you're pretty much set on that side. You can choose to extend the PMC too, and add committers that aren't in the PPMC yet but would deserve to. * Make sure that your project status page is up-to-date [2] Once you're set, you can start a formal vote on the board resolution in the community. Then you'll ask for the incubator vote. You'll also have to take the board schedule into account. Usually meetings are the third Wednesday of each month so it's too late for this month but you could be in good shape for October (should be the 17th). Cheers! Matthieu [1] http://incubator.apache.org/guides/graduation .html [2] http://incubator.apache.org/projects/tuscany.html I just looked at the calendar at [3] and I'm not sure what people are planning on Sunday but according to this calendar we should start a vote on the resolution this Sunday to be in a good shape for the 17th :) Yeah, the calendar shows more the expected duration of each steps but as a timeline it's a bit confusing. The tasks can be parallelized and it's also possible to do stuff on Thursdays and Fridays :) The hard constraints are the following: * the board meeting is the 17th * the resolution must be submitted at least 72 hours before (the deadline is usually Monday) which would be the 15th. * the IPMC must have voted the board resolution before, another 72 hours, usually the week-ends don't count so that would be the 9th * finally the community vote is one more 72 hours which would get you to the 4th. So you have 4 more days after Sunday :) But there's no reason to rush out, I'm just clarifying the timeline, you'll be ready when you'll be ready and you can also target Nov. 21st. As you said it's better if the resolution is not too fuzzy, I'll try to propose small changes to crisp it up a bit (just saw that Haleh just proposed some changes to it too in this thread). What else can I can help with? I think that's pretty much it. Compared to everything that comes before, graduation is a pretty straightforward process (even if it takes time). Matthieu [3] http://incubator.apache.org/guides/graduation.html#process -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] SCA Domain
Comments inline. Simon Laws wrote: On 9/26/07, ant elder [EMAIL PROTECTED] wrote: On 9/26/07, Simon Laws [EMAIL PROTECTED] wrote: We have two SCADomain interfaces (I'm leaving aside EmbeddedSCADomain for now) 1) o.a.t.s.host.embedded.SCADomain (supports a domian with a single node) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String contributionLocation, String... composites) *A* public static void removeInstance(SCADomain domainInstance) *A* public static SCADomain connect(String domainURI) public void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName) private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String contributionLocation, String... composites) *B* public ComponentManager getComponentManager() 2) o.a.t.s.domain.SCADomain (supports a domain with one or more nodes) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) public abstract void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName); private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) I propose we move to having one. I've marked the parts that differ with *?*. There are two main points. *A* The mechanism by which this local domain representation (the node) is associated with a wider logical domain *B* The mechanism by which the domain is managed (the components in the domains single node in the case of 1 above) Before we start re-positioning interfaces though we need to agree what we mean by the words we use here as there has been some confusion. We've discussed these issues before [1][2][3] etc. The result was a separation of node and domain so that you could operate on a node and on a domain. This approach/API is currently hidden behind SCADomain as there was no consensus that this was the right approach. e.g. I've heard people saying things like a node shouldn't provide an interface for adding contributions as you add contributions to a domain. I want to push on the issue of how we expect users to deal with a domain and the nodes in that domain before going back to look at the API. My starter for 10 is... - There are different types of users we must consider. Here are two examples, 1/ the developer who uses the Tuscany APIs to build a node implementation and makes contributions and manages components programmatically (see our samples for an example of this approach) 2/ the user who manages one or more nodes as a domain, making contributions and managing components through a GUI. - Programmatically, to developer 1/, a node API provides sca runtime support and has to implement all of the management interfaces for accepting contributions, managing components etc, so that developer 1/ can wire tuscany into whatever mechanism they have in their implementation and so that, once the node is added to a domain, the domain can configure and manage the node. The implication here is that the node is configured and managed through contribution/component management interfaces that is a superset of that of a domain (a superset as I would expect use of other detailed Tuscany APIs to get the node to work) - Programmatically, to developer 1/, there should also be a domain representation so that they can include their node in a domain and perform domain level operations like locating a service (or even adding contributions, management components at a domain level). Developer 1/ would associate their node implementation with a domain (within a single VM this would be as easy as passing the node object into the domain interface). - To the user of type 2/ all of these operations may be performed through a GUI using some slick drag and drop management interface. However, they are the same operations. We don't have a slick GUI interface currently so contributions find their way directly to nodes because they are made
Re: [DISCUSS] SCA Domain
Simon thanks for starting this and its really useful discussion for me - it just about deals with things that I had 'vowed' to clear up in my mind post Rel 1.0 ;-) +1 for the proposal to prune down to have a single SCADomain abstraction. I am more in line with Sebastien's suggestion of I don't care about nodes, I go to the domain, contribute contributions, declare composites, then just ask the domain do start my composite, however it wants, wherever it wants. To do that the domain will have to create one or more nodes under the covers, configure them with the composite and contributions, start it etc. But as a user of the domain, I'm not exposed to nodes at all. I really don't want to have nodes to deal with Composites or Contributions. The Node is to be a handle that an SCADomain can use to identify an instance of a SCA runtime. I'd imagine that or every logical SCADomain there is a NodeRegistry that runs in a well known location, which an SCADomain can look up to find the list of nodes which run SCADomain instances that are a part of the same logical SCADomain. By default, in the absence of any node specific information all operations are perform on the local SCADomain instance i.e. the local SCA runtime. Where operations have node specific info, the NodeRegistry is consulted, the remote SCADomain instance associated with the given Node is contacted and operations delegated over to that remote SCADomain instance. These are some intial thoughts that occur... let me take a look at Sebastien's sandbox and get back.. maybe with better clarity ;-) thanks - Venkat On 9/27/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Comments inline. Simon Laws wrote: On 9/26/07, ant elder [EMAIL PROTECTED] wrote: On 9/26/07, Simon Laws [EMAIL PROTECTED] wrote: We have two SCADomain interfaces (I'm leaving aside EmbeddedSCADomain for now) 1) o.a.t.s.host.embedded.SCADomain (supports a domian with a single node) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String contributionLocation, String... composites) *A* public static void removeInstance(SCADomain domainInstance) *A* public static SCADomain connect(String domainURI) public void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName) private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String contributionLocation, String... composites) *B* public ComponentManager getComponentManager() 2) o.a.t.s.domain.SCADomain (supports a domain with one or more nodes) public static SCADomain newInstance() public static SCADomain newInstance(String composite) *A* public static SCADomain newInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) public abstract void close() public abstract String getURI() public abstract B, R extends CallableReferenceB R cast(B target) public abstract B B getService(ClassB businessInterface, String serviceName) public abstract B ServiceReferenceB getServiceReference(ClassB businessInterface, String referenceName); private static String getServiceName(ClassLoader classLoader, String name) static SCADomain createNewInstance(String domainURI, String nodeURI, String contributionLocation, String... composites) I propose we move to having one. I've marked the parts that differ with *?*. There are two main points. *A* The mechanism by which this local domain representation (the node) is associated with a wider logical domain *B* The mechanism by which the domain is managed (the components in the domains single node in the case of 1 above) Before we start re-positioning interfaces though we need to agree what we mean by the words we use here as there has been some confusion. We've discussed these issues before [1][2][3] etc. The result was a separation of node and domain so that you could operate on a node and on a domain. This approach/API is currently hidden behind SCADomain as there was no consensus that this was the right approach. e.g. I've heard people saying things like a node shouldn't provide an interface for adding contributions as you add contributions to a domain. I want to push on the issue of how we expect users to deal with a domain and the nodes in that domain before going back to look at the API. My starter for 10 is... - There are different types of users we must consider. Here are
