Re: Tracking web-traffic in Tuscany Website
This should be transparent for the user that is accessing the website. On 5/30/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi, I am ok with this. Is there going to be any trade off to get this in ?. For example do you see our users having to feed in some information about their profile or is there any other thing that could impact the user experience a bit - just curious :). Thanks. - Venkat On 5/31/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > Looks like this thread got forgotten, but with the re-design of our > website, looks like it's a good time to revisit the subject. > > Also, there has been some discussion on other projects about this > subject, and looks like couple other apache projects are already using > Google Analytics for web-traffic or download-traffic monitoring, so it > should not be a problem for us to start using as well. > > If people are still OK, I'll take a look about adding the tracking .js > code from Google into our exported website. > > [1] http://www.google.com/analytics/ > > On 2/21/07, haleh mahbod <[EMAIL PROTECTED]> wrote: > > +1 if allowed by Apache. > > > > On 2/16/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > > > > > I have been doing some web-traffic monitoring on our Tuscany Blog > using > > > Google Analytics and StatCounter. > > > > > > I was wondering if would be a good idea to do same on our Project > website, > > > and this might be give us a better idea of traffic on specific areas > > > (e.gSCA/SDO/DAS or Java/C++, etc) > > > > > > I was checking with ASF Infra, and they only have stats log files, but > no > > > visual tool that shows traffic by individual projects, so if people on > the > > > Tuscany dev community like the idea, I'd go and check if it's ok with > the > > > Incubator PMC to add these 3rd party web trackers to our project > website. > > > > > > Toughts ? > > > > > > -- > > > Luciano Resende > > > http://people.apache.org/~lresende > > > > > > > > -- > 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] > > -- 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]
Re: Tracking web-traffic in Tuscany Website
Hi, I am ok with this. Is there going to be any trade off to get this in ?. For example do you see our users having to feed in some information about their profile or is there any other thing that could impact the user experience a bit - just curious :). Thanks. - Venkat On 5/31/07, Luciano Resende <[EMAIL PROTECTED]> wrote: Looks like this thread got forgotten, but with the re-design of our website, looks like it's a good time to revisit the subject. Also, there has been some discussion on other projects about this subject, and looks like couple other apache projects are already using Google Analytics for web-traffic or download-traffic monitoring, so it should not be a problem for us to start using as well. If people are still OK, I'll take a look about adding the tracking .js code from Google into our exported website. [1] http://www.google.com/analytics/ On 2/21/07, haleh mahbod <[EMAIL PROTECTED]> wrote: > +1 if allowed by Apache. > > On 2/16/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > > > I have been doing some web-traffic monitoring on our Tuscany Blog using > > Google Analytics and StatCounter. > > > > I was wondering if would be a good idea to do same on our Project website, > > and this might be give us a better idea of traffic on specific areas > > (e.gSCA/SDO/DAS or Java/C++, etc) > > > > I was checking with ASF Infra, and they only have stats log files, but no > > visual tool that shows traffic by individual projects, so if people on the > > Tuscany dev community like the idea, I'd go and check if it's ok with the > > Incubator PMC to add these 3rd party web trackers to our project website. > > > > Toughts ? > > > > -- > > Luciano Resende > > http://people.apache.org/~lresende > > > -- 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]
[SDO C++] DataFactory::generateInterface() function problem
I used the DataFactory::generateInterface() and I got the following code:
...
DataObjectList& Config::getRelationship //missing parameters definition
{
return the_object->getList("Relationship");
}
...
It is not generating the parameters definition of any function that returns
a DataObjectList&. Bellow is the code I use to generate the code above:
commonj::sdo::DataFactoryPtr dataFactory =
commonj::sdo::DataFactory::getDataFactory();
commonj::sdo::XSDHelperPtr xsdh =
commonj::sdo::HelperProvider::getXSDHelper(dataFactory);
xsdh->defineFile("config.xsd");
dataFactory->generateInterface("DataFactoryImpl", "DataFactoryImpl");
And here is the config.xsd:
http://www.w3.org/2001/XMLSchema";
targetNamespace="apache.das.rdb.config"
elementFormDefault="qualified">
Am I committing some mistake or it's really a bug?
Adriano Crestani
Re: Cleaning up some of the new sample modules
Responses inline. Jean-Sebastien Delfino wrote: Comments inline. Simon Nash wrote: There were problems with the previous structure that led to the splitting of these samples. With all the files together in a single module, the only way to allow the samples to run "out of the box" in the binary distro was to place the client/application code that used the extension in the same jar as the extension itself, which does not show how people should actually build a new extension. There were various emails to the list last week about this and the separation into two samples seemed like the best solution. I apologize if I missed something obvious in the previous discussions, but Is that a problem with the Ant build? Can't we run out of classes outside of the Jar? Actually it's an issue with the maven build. By default, the jar step will put all .class files under target/classes into the jar. These classes are the result of compiling all the java code that's under src/main. The code under src/test is compiled into target/test-classes, and maven does not include this code in the jar. So the options were: 1) put the client/application code into src/test, which is misleading as it is sample client code and not test code, or 2) find a way to stop maven from putting all the target/classes code into the jar. The latter might have been possible, but neither SimonL or I knew how to do it, and it seemed cleaner to go with a separate module (and jar) for the sample application code. I would like to keep the "split" structure as it currently is rather than make a last minute change just before the 0.90 RC without opportunity for discussion. (I'm on a plane tomorrow so I won't have any email access all day.) I am fine with the proposed renaming of the samples as suggested: - echo-binding to echo-binding-extension - echo-binding-appl to echo-binding - implementation-crud to implementation-crud-extension - implementation-crud-client to implementation-crud Adding the "extension" suffix to the extension samples makes the purpose of these samples clearer and solves the awkwardness over how to describe the non-extension code. Now that the release work is done, I'd like to see if we could simplify this in the trunk and reduce the number of modules, then we won't have to find good names for them :) Quite a few of the samples come in pairs, with client code and server code or (now) extension code and application code. I think the most important thing is for the samples to follow a simple, clear and readily understandable pattern, and to observe good practice that people will use to develop real applications and extensions. If we can reduce the number of modules without breaking these principles, that's great :-) In this case, I think combining the extension and application modules would lead to some loss of clarity and good structure. The purpose of the junit test code in the "client/appl" samples is to ensure that the client code runs successfully. The only way to test this is by actually invoking the client code. At present the sample client code is very similar to the junit test client code, but over time I would expect more divergence. If it is considered undesirable to ship a junit test for the client code as part of the samples, then we could put it under sca/itest/samples as I originally suggested. It was moved to its current location after discussion on the list last week. Note that the extension sample modules contain "normal" junit test code to ensure the extension is loaded and functional. I think we can use the unit tests to show people: - how to test their extension, in implementation-crud - how to test the invocation of SCA service components, in implementation-crud-client - how to test the client side of an SCA application, by mocking an SCA component, we could do this in implementation-crud-client too, but it'll require some thinking to keep it simple. There is a very fine line between testing the first of these and testing the second. Implementation extensions like implementation-crud are activated by invocations of SCA service components of that implementation type. Can you suggest some other way to test extension code? Would this be done with mocking code that drives the extension code using the SPIs? Testing that our sample client doesn't fail with an exception is useful to us and may deserve a test in our integration test suite (if we think that having a proper unit test case testing the bits and pieces in that module is not good enough), but I don't thing that it's interesting to keep it in the sample itself, as it's not going to teach anything to an application developer looking at the sample, and doesn't look like a "normal" unit test case. Yes, agreed that this does not really belong in the samples. I would be inclined to put this test code in itest/samples, just to have the build confirm automatically that all the sample clients actually do
Re: Tracking web-traffic in Tuscany Website
Looks like this thread got forgotten, but with the re-design of our website, looks like it's a good time to revisit the subject. Also, there has been some discussion on other projects about this subject, and looks like couple other apache projects are already using Google Analytics for web-traffic or download-traffic monitoring, so it should not be a problem for us to start using as well. If people are still OK, I'll take a look about adding the tracking .js code from Google into our exported website. [1] http://www.google.com/analytics/ On 2/21/07, haleh mahbod <[EMAIL PROTECTED]> wrote: +1 if allowed by Apache. On 2/16/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > I have been doing some web-traffic monitoring on our Tuscany Blog using > Google Analytics and StatCounter. > > I was wondering if would be a good idea to do same on our Project website, > and this might be give us a better idea of traffic on specific areas > (e.gSCA/SDO/DAS or Java/C++, etc) > > I was checking with ASF Infra, and they only have stats log files, but no > visual tool that shows traffic by individual projects, so if people on the > Tuscany dev community like the idea, I'd go and check if it's ok with the > Incubator PMC to add these 3rd party web trackers to our project website. > > Toughts ? > > -- > Luciano Resende > http://people.apache.org/~lresende > -- 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]
Re: Automated nightly builds
[snip] Luciano Resende wrote: I can look into these requirements, and try to get it setup on vmbuild. Right now I'm having a more basic issue, where the SCA test cases that need http require a port that, in the apache machine, is already in use by the continuum http web container (jetty), should we have an easy way to globally identify the ports to use for the unit tests ? And could we use something different then the defaults ? The port numbers are configured by the binding uri or the wsdl port or endpoint. Changing all 8080 to 8083 or another available port number in the composite and wsdl files should work. I am suggesting 8083 as 8081 and 8082 are already used by some test cases if I remember correctly. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Automated nightly builds
I can look into these requirements, and try to get it setup on vmbuild. Right now I'm having a more basic issue, where the SCA test cases that need http require a port that, in the apache machine, is already in use by the continuum http web container (jetty), should we have an easy way to globally identify the ports to use for the unit tests ? And could we use something different then the defaults ? On 5/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Luciano Resende wrote: >> From previous discussions on the mailing list [1], there are two > scenarios here : > > * Users interested in only checking out specific Tuscany sub-projects > and be able to build it and work with it. These users would rely on > all dependencies to be available from a maven repo (e.g SDO and DAS, > among external dependencies) > > * Users interested in all Tuscany, they would come and build from the > root, and would expect the trunk version of SCA, SDO and DAS to build > and work together. > > So, maybe we could try to have both scenarios automated, instead of > deciding for one, as I was proposing in the original question. OK, people can check out SVN trees and build them themselves using Maven. They can either build SDO + SCA + DAS or just a subset and Maven published snapshots for the rest. Actually they can even go more fine grained and build individual modules if they want. I guess this is development / build as usual... > > As for the downloading, I wasn't planning to publish any jars from the > nightly build, at least for now... but if people think we should do > it, I can look into it as well. > > [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg17979.html > Yes... I guess a build becomes more useful if you can actually download and use what's built :) The scenario I'm particularly interested in is: - I'm a user of Tuscany/SCA and I'm not interested in building the bleeding edge source on my machine, I care about integrating Tuscany with my environment, developing Tuscany extensions, or developing SCA applications that run on top of Tuscany. - I reported a Tuscany/SCA bug, the bug got fixed, I'd like to use the latest Tuscany nightly build which contains the fix. - I'm not necessarily using Maven. I could be using Maven, but maybe I'm just using my IDE and/or Ant. I'm assuming that I can just point my Web browser to a few Zips or some other form of archive, download them, and go from there. - I'd like to understand what I need to download. I think that this is a pretty simple use case. Will the new nightly builds support it? Will I get a Tuscany/SCA distribution? Or will I have to download individual Tuscany/SCA, SDO and DAS pieces? Can I get some indication from the build status that the various pieces are going to work together? Thanks > On 5/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >> Luciano Resende wrote: >> > I pretty much have it working locally, building SCA, SDO and DAS >> > independently. >> > >> > As for hosting the build at the shared machine at Apache, I have >> > created a JIRA [1] asking for an account to add and administer the >> > builds on the shared machine. >> > >> > [1] https://issues.apache.org/jira/browse/INFRA-1261 >> > >> > On 5/26/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: >> >> Thanks for doing this :). +1 for separating out SCA, SDO and DAS >> builds >> >> >> >> - Venkat >> >> >> >> On 5/23/07, Luciano Resende <[EMAIL PROTECTED]> wrote: >> >> > >> >> > I'm starting to pursue a nightly build for Apache Tuscany with the >> >> > Apache Infra guys, and I just want to double check what people >> think >> >> > it's the best build layout that we should use >> >> > >> >> > - Have one top-down build, that would build all Tuscany subprojects >> >> > (SCA/SDO/DAS) >> >> > >> >> > - Have three builds, that would build each project separately >> >> > >> >> > I particularly would prefer the second option, as that would >> ensure >> >> > each subproject can work independently, based on published >> >> > releases/snapshots of it's dependencies. >> >> > >> >> > Thoughts ? >> >> > >> >> > -- >> >> > 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] >> >> > >> >> > >> >> >> > >> > >> >> Nice. Quick question, as it looks like you're going to have 3 different >> builds for SCA, SDO and DAS: >> >> If I download the SCA and SDO builds for example, will the SCA build use >> the exact same level of SDO that I'll get with the SDO build? In other >> words are we making sure that they work together? >> >> Thanks >> >> -- >> Jean-Sebastien >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-m
Tuscany website
Looks like we already have a published website based on wiki at [1], but if you come to the website from our incubator link [2] it is still forwarding you to the regular wiki. If people are ok with the current layout, I can look into fixing the forward from incubator to the new exported website, this is probably a short term solution, and we should look into an automated way to get the wiki exported html contents published into our svn repository [3]. Thoughts ? [1] http://cwiki.apache.org/TUSCANY/ [2] http://incubator.apache.org/tuscany/ [3] https://svn.apache.org/repos/asf/incubator/tuscany/site/ -- 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] Commented: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
[ https://issues.apache.org/jira/browse/TUSCANY-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500173 ] Raymond Feng commented on TUSCANY-824: -- There have been a lot of changes since this JIRA was opened. Basically, we have switched to a mode that the runtime will try to recognize the databindings by introspection without user annotations. There is one issue left and being discussed on the ML to figure out if we need the @DataBinding annotation to specify the interface/operation level databinding mapping. Another issue is if interface.wsdl is used, usally a XML/java binding such as SDO or JAXB is used by the java implementation class. We need to find the corresponding databinding for the interface.wsdl in these cases. I'll leave it open for now until we have a better view. > DataBinding: Is it a concern of Programming Model vs. Assembly? > --- > > Key: TUSCANY-824 > URL: https://issues.apache.org/jira/browse/TUSCANY-824 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-M2 >Reporter: ant elder >Assignee: Raymond Feng >Priority: Critical > Fix For: Java-SCA-Next > > > There have been some question about the DataBinding framework and if it > should be a concern of the Programming Model vs. Assembly? > See: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08679.html > and a follow up mention in: > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09363.html -- 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: [Java Sca]-Parse two interface error.
Hi,
It seems that the 1.0 SCA java spec defines an algorithm to introspect the
services provided by a java interface as follows:
1. @Service will be checked first and honored
2. The following is quoted from Java spec 1.2.1.3.
Introspecting services offered by a Java implementation
In the cases described below, the services offered by a Java implementation
class may be determined
through introspection, eliding the need to specify them using @Service. The
following algorithm is used
to determine how services are introspected from an implementation class:
If the interfaces of the SCA services are not specified with the @Service
annotation on the
implementation class, it is assumed that all implemented interfaces that
have been annotated
as @Remotable are the service interfaces provided by the component. If none
of the implemented
interfaces is remotable, then by default the implementation offers a single
service whose type
is the implementation class.
Based on the above, CalculatorServiceImpl is going to have one single
service typed by CalculatorServiceImpl. I believe some of the test cases
assume that all the local interfaces will be taken as the services,
especially if only one interface is implemented by the java class. With the
latest spec, the assumption will be incorrect.
Am I right?
If so, I can change the code to behave this way.
Thanks,
Raymond
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, May 29, 2007 5:53 PM
Subject: Re: [Java Sca]-Parse two interface error.
Tony Wang wrote:
hi,
when a componentImpl implementation two interface,tuscany parse error.
public interface CalculatorService1 {
double add(double n1, double n2);
double subtract(double n1, double n2);
}
public interface CalculatorService2 {
double multiply(double n1, double n2);
double divide(double n1, double n2);
}
public class CalculatorServiceImpl implements
CalculatorService1,CalculatorService2{
...
}
...
The error is:
-
Exception in thread "main" org.osoa.sca.ServiceRuntimeException:
org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceTypeNotFoundException:
calculator.CalculatorServiceImpl
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:263)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:81)
at calculator.CalculatorClient.main(CalculatorClient.java:31)
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceTypeNotFoundException:
calculator.CalculatorServiceImpl
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:106)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 2 more
Caused by:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceTypeNotFoundException:
calculator.CalculatorServiceImpl
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:121)
at
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:1)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:387)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:466)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:1)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:83)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:1)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:73)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:317)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:254)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:119)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:104)
... 3 more
Caused by:
org.apache.
Re: Wire binding selection?
Hi, Simon. Please see my comments inline. Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: Sent: Tuesday, May 29, 2007 11:51 PM Subject: Re: Wire binding selection? Ok, Raymond, this is useful. So what it does seem to come down to is binding selection. It's not clear from your comment whether you believe this is already done somewhere or whether this is a new piece of functinality that we need to add. I think we need to fix some of the code to make it fully supported. From what I see in the code I think we do need a way of marking which binding is intended to be active between any particular reference/service pair. When you say "Should it be done when we flatten the model?" do you mean when the components that each reference targets are resolved or do you mean later on?. I meant when the CompositeBuilder creates the model which reflects the effective configuration of the assembly. The issue I see at resoltuion time is that a reference holds bindings and targets independently. So we could change the model to allow us to create a relationship between target and binding at this point. Alternatively we can make the change at wire generation time where we have the wire structures to hold this relationship. Can you think of scenarios where we don't want to be deterministic and include this information in the model? We could do it either way. But to be consistent, maybe it's better to do it before the wire generation. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1233) Enhance SDO static codegen (XSD2Java) to support multiple namespaces in a single pass.
[ https://issues.apache.org/jira/browse/TUSCANY-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500161 ] Kelvin Goodson commented on TUSCANY-1233: - I'm working through this patch, and feeling a little uncomfortable about the use of the "-schemaNamespace all" incantation. I think I would prefer to either have a -allNamespaces argument, in order to avoid having to reserve the [aA][lL][lL] namespaces. Alternatively, whilst I'm not a fan of changing default behaviours, I wonder if it would be a problem to make the "all" behaviour the default, and then only select a subset of namespaces if either the schemaNamespace or namespaceInfo arguments are applied. > Enhance SDO static codegen (XSD2Java) to support multiple namespaces in a > single pass. > -- > > Key: TUSCANY-1233 > URL: https://issues.apache.org/jira/browse/TUSCANY-1233 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Tools >Affects Versions: Java-SDO-M2 > Environment: n/a >Reporter: David T. Adcox >Assignee: Kelvin Goodson >Priority: Minor > Fix For: Java-SDO-1.0 > > Attachments: 1233.patch > > > The SDO static codegen tool (XSD2Java) is currently only able to process a > single namespace per invocation. This limitation is problematic when the > target schema contains multiple namespaces or includes other schemas with > namespaces that are different from the target schema. The user of the tool > is forced to invoke the tool multiple times, once for each namespace > referenced. More troubling is the case where the javapackage option is used. > In that case, the java package information is changed from the default > naming scheme. This change will break any generated classes that point to > the name-modified package. > Supporting this feature would include items such as these listed below: > - Support the processing of multiple namespaces via a command-line option > (this behavior should not be the default) > - Provide support for multiple namespaces within a single schema or WSDL > - Support processing of multiple namespaces imported by the target schema or > WSDL. > - Allow for all namespaces to be discovered through interrogation of the > target and its dependencies. > - Allow for user input to determine all namespaces to be processed (enhanced > schemaNamespace option). > - Provide support for javaPackage to namespace mapping. In effect, enhance > the current javaPackage option to allow for multiple package-namespace pairs. > - Provide support for prefix to namespace mapping. Again, much like the > previous item, enhance the current prefix option to support multiple > prefix-namespace pairs. -- 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: An Atom+RSS Feed binding, was: Work items for the next release?
Ok, sounds good. I started to look at ROME but go distracted by something else and I haven't looked at Abdera. So if you have a binding on the way that would be really good. Am back looking at bringing up the aggregator sample so I'll leave the implementation of the feed readers a little hazy in anticipation of using your stuff. Thanks Simon
An Atom+RSS Feed binding, was: Work items for the next release?
[snip] Simon Laws wrote: Demos Port feed aggregator over from Native SCA - has implications for scriting so I can help out there a bit. I've started to put together a binding.feed extension. I'm currently using Apache Abdera for Atom feeds, and have just started to look at the ROME library for its RSS support. It looks like it'll take just a few lines of code to implement a binding like: http://uri of the feed"/> Such a binding should help us easily implement applications similar to the Tuscany Native SCA aggregator app on the Java runtime, while shielding the SCA component implementation from the details of getting and parsing the Atom or RSS feed. I'll put that code in my sandbox later this week for people to take a look. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cleaning up some of the new sample modules
Comments inline. Simon Nash wrote: There were problems with the previous structure that led to the splitting of these samples. With all the files together in a single module, the only way to allow the samples to run "out of the box" in the binary distro was to place the client/application code that used the extension in the same jar as the extension itself, which does not show how people should actually build a new extension. There were various emails to the list last week about this and the separation into two samples seemed like the best solution. I apologize if I missed something obvious in the previous discussions, but Is that a problem with the Ant build? Can't we run out of classes outside of the Jar? I would like to keep the "split" structure as it currently is rather than make a last minute change just before the 0.90 RC without opportunity for discussion. (I'm on a plane tomorrow so I won't have any email access all day.) I am fine with the proposed renaming of the samples as suggested: - echo-binding to echo-binding-extension - echo-binding-appl to echo-binding - implementation-crud to implementation-crud-extension - implementation-crud-client to implementation-crud Adding the "extension" suffix to the extension samples makes the purpose of these samples clearer and solves the awkwardness over how to describe the non-extension code. Now that the release work is done, I'd like to see if we could simplify this in the trunk and reduce the number of modules, then we won't have to find good names for them :) The purpose of the junit test code in the "client/appl" samples is to ensure that the client code runs successfully. The only way to test this is by actually invoking the client code. At present the sample client code is very similar to the junit test client code, but over time I would expect more divergence. If it is considered undesirable to ship a junit test for the client code as part of the samples, then we could put it under sca/itest/samples as I originally suggested. It was moved to its current location after discussion on the list last week. Note that the extension sample modules contain "normal" junit test code to ensure the extension is loaded and functional. I think we can use the unit tests to show people: - how to test their extension, in implementation-crud - how to test the invocation of SCA service components, in implementation-crud-client - how to test the client side of an SCA application, by mocking an SCA component, we could do this in implementation-crud-client too, but it'll require some thinking to keep it simple. Testing that our sample client doesn't fail with an exception is useful to us and may deserve a test in our integration test suite (if we think that having a proper unit test case testing the bits and pieces in that module is not good enough), but I don't thing that it's interesting to keep it in the sample itself, as it's not going to teach anything to an application developer looking at the sample, and doesn't look like a "normal" unit test case. I agree with making the client/application packages different from the extension packages. This had been discussed and agreed on the list and it should have already been that way. I'd like to better understand the comment about putting test resources into src/test/resources. In both implementation-crud-client and binding-echo-appl, the only resources are the composites, and these are used by the client/application code in src/main. The junit tests invoke the client code, and the client code uses these resources. The client code also uses these resources even when it is invoked directly from the command line and not from the junit tests. So I don't think it would be correct to move these composites from src/main to src/test. I was talking about incubator/tuscany/java/sca/samples/implementation-crud/src/main/resources/crud.composite It was only used by the test case in this module, and I moved it to src/test/resources in revision r539773. Simon Raymond Feng wrote: Hi, The main purposes of the implementation-crud and binding-echo are to demonstrate how to add new implementation and binding types using the extension SPIs. As part of that, we have some code to show/verfiy how the extensions are used and runnable with the Tuscany runtime in the format of test case. I suggest that we keep each of them a single module instead of splitting into two which seems to me a bit over-killed. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Saturday, May 19, 2007 10:15 AM Subject: Re: Cleaning up some of the new sample modules ant elder wrote: On 5/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I'd like to do a little bit of cleanup of the new sample modules that we've added to better separate the sample extensions and the samples showing how to use them. I'll make the following chan
Re: Wiki Download page cleanup
There doesn't seem to been much distance between the last two suggestions. It feels to me like people are starting to talk about the same structure. Let me try and summarize... Home Downloads SCA Java ---> SCA Java Releases SCA Native -> SCA Native Releases SDO Java --> SDO Java Releases SDO Native --> SDO Native Releases DAS --> DAS Releases SCA Java SCA Java Releases Latest release ---> SCA 0.90 Release M2 ---> SCA M2 Release M1> SCA M1 Release SCA Native SCA Native Releases etc. I would hold ActiveMQ up as having quite a nice clear approach to the Releases and individual Release pages we are discussing: Their equivalient of "SCA Java Releases" is http://activemq.apache.org/download.html Their equivalent of "SCA 0.90 Release" is http://activemq.apache.org/activemq-411-release.html (note that their change log appears to be driven directly off of JIRAS as we have been discussing in another thread) Their homepage download link points to their equivalent of the "Downloads" page that Haleh suggested previously ( http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+Downloads) Regards Simon
