[jira] Updated: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue
[ https://issues.apache.org/jira/browse/TUSCANY-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-2007: - Attachment: 2007.patch changed DocumentSamples.java and distribution\src\main\release\bin\samples\sampleProgramContents.html. SDO Samples - fix sampleProgramContents.html's Firefox display issue Key: TUSCANY-2007 URL: https://issues.apache.org/jira/browse/TUSCANY-2007 Project: Tuscany Issue Type: Bug Components: Java SDO Samples Affects Versions: Java-SDO-Next Reporter: Amita Vadhavkar Priority: Minor Fix For: Java-SDO-Next Attachments: 2007.patch By below line to the https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html it worked fine on firefox. Without it, it was displaying as html text on the browser. !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN title=http://www.w3.org/TR/html4/loose.dtd; class=linkhttp://www.w3.org/TR/html4/loose.dtd; So fixing variable HTML_HEADER from sample-sdo/DocumentSamples to contain the above line will fix the rendering issue on Firefox. -- 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: Request to propogate the value of a references target= attribute on its associated bindings model object
On Jan 21, 2008 6:55 PM, Lou Amodeo [EMAIL PROTECTED] wrote: This is a request to propogate the value of a references target= attribute as a first class attribute on its associated bindings model object. This request is based on a requirement to provide support to implement a late-endpoint resolution capability for service references when a reference specifies the target= attribute. This value in conjunction with a domain wide services registry allows the binding invokers to use the value specified for reference target= as a key to perform a service lookup to obtain the services endpoint URI dynamically during the invocation of the service rather than during compositie startup. The primary benefits of this approach are to provide a degree of location transparency for services and remove the requirement of the client from knowing the services endpoint at installation time. This would only apply to clients that are running in the same domain as the services they reference. Hi Lou This is interesting as I've been thinking about this myself. We currently take this approach in the Tuscany code base so let me give a bit a of a review of that and we can then discuss what is required. In the Tuscany code we have a 'Domain' service which acts as the manager/registry of all of the 'Nodes' that in turn run composites. Our domain level wiring support started out life in the default binding only, I.e. you could only wire between remote components using 'target=' if the reference also used the default binding. The default binding has some code in it that used the binding URI, which by default contains information from target=, to ask the domain registry what the physical URI of the target service is. Now to extend this support across different types of binding we started to look at this in a slightly different way. Rather than embedding code in each different type of binding we added some code at the Domain level that looks across the whole domain model and matches references with services. Where a match is found the reference URI is completed with URI information from the service. The intention with this domain level processing is that we can more easily handle binding selection, policy matching and autowiring at the domain level. The result of this processing is an amended composite that can be sent to the node for execution. This all sounds great but its starting to get a little complicated. This is because we are doing the processing dynamically. When a composite is started it registers its available services. The result of this is that every time a composite is started the domain changes and you get a ripple effect of composites being amended as references are updated to include new service URIs. In your note its interesting that you say The primary benefits of this approach are to provide a degree of location transparency for services and remove the requirement of the client from knowing the services endpoint at installation time.. I've been mulling over an alternative approach. What I mean is that I recognize the need for the location transparency but that we could pre-process all of the domain's composites to take account of this location transparency before we try and run them. This would give rise to a several, more deterministic, processing steps 1. Add all of the contributions to the domain 2. Assign composites to the nodes where they will run 3. Based on 2 perform domain level wiring 4. Re-write the composites to contain the updated reference information 5. deploy to the contributions/composites to their allotted nodes for execution I'd be interested to understand what steps in bringing up a system you have in mind. If we can work toward agreement on the steps involved we can decide how we should amend the Tuscany code. Regards Simon
[jira] Commented: (TUSCANY-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly
[
https://issues.apache.org/jira/browse/TUSCANY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561294#action_12561294
]
Amita Vadhavkar commented on TUSCANY-2009:
--
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/util/EcoreUtil.EqualityHelper.html
specifies that Java equality is followed and in Java below bt1 is not equal to
bt2.
byte[] bt1 = new byte[]{120, 80, -40};
byte[] bt2 = new byte[]{120, 80, -40};
if(bt1.equals(bt2)) {
//false
}
In SDO Impl, super.haveEqualAttribute(eObject1, eObject2, attribute); is
called. So to make meaningful comparisons, instead of calling super viz. EMF
EcoreUtil.EqualityHelper(), will meaningful equality check be needed inside SDO
Impl itself?
Regards,
Amita
Java SDO's EqualityHelper doesn't compare Bytes values correctly
Key: TUSCANY-2009
URL: https://issues.apache.org/jira/browse/TUSCANY-2009
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Environment: n/a
Reporter: David T. Adcox
Fix For: Java-SDO-Next
Attachments: Test2009.java
Comparison of two Bytes values fails when it should succeed. The test for
equality passes through the EqualityHelperImpl.equal method. In that method,
the test is passed to EcoreUtil.haveEqualAttribute(EObject, EObject,
EAttribute). For a simple type, it defers to java's '==' operator. So, two
different object arrays are being compared, not for their contents, but
rather if they are the same object. Attached is a test case which
demonstrates this issue.
--
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-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561304#action_12561304 ] Kelvin Goodson commented on TUSCANY-2009: - I'm surprised that the Ecore equality helper doesn't handle this. If my understanding is correct then Ecore could check the eAttribute.getEAttributeType().getInstanceClass().isArray() and then use Arrays.equals() for all arrays. Maybe there's a fix in a later version of EMF? This is our only array of primitives type, so we can special case it. We should check for type Bytes and use java.util.Arrays.equals(arg1,arg2) in our impl of haveEqualAttribute Java SDO's EqualityHelper doesn't compare Bytes values correctly Key: TUSCANY-2009 URL: https://issues.apache.org/jira/browse/TUSCANY-2009 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Next Attachments: Test2009.java Comparison of two Bytes values fails when it should succeed. The test for equality passes through the EqualityHelperImpl.equal method. In that method, the test is passed to EcoreUtil.haveEqualAttribute(EObject, EObject, EAttribute). For a simple type, it defers to java's '==' operator. So, two different object arrays are being compared, not for their contents, but rather if they are the same object. Attached is a test case which demonstrates this issue. -- 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 contribution packaging schemes: was: SCA runtimes
On Jan 21, 2008 9:31 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: Jean-Sebastien Delfino wrote: - Under which circumstances does the app packager want to package the Tuscany and dependency JARs with the application artifacts. [snip] With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. [snip] Trying to address Under which circumstances does the app packager want to package the Tuscany and dependency JARs with the application artifacts? My (maybe simplistic) view is: A) We can package in a WAR: - several SCA contributions JARs - any SCA deployment composites - the required API JARs - the required Tuscany JARs and runtime dependency JARs This allows deployment of an SCA/Tuscany based solution to JEE Web containers without requiring any system configuration or software installation besides the Webapp. There are some basic architectural limitations to that scheme: - no good support for other bindings than HTTP based bindings - footprint issue with every Webapp packaging the whole runtime Also we're not quite there yet as I don't think we support: - several SCA contributions in the packaged solution - SCA deployment composites B) Package SCA contributions as simple JARs, containing only the application artifacts (no API JARs, no runtime dependency JARs). Packaging SCA contributions as OSGi bundles is a variation of the same scheme. Any thoughts? What other packaging schemes do people want to support and when? -- Jean-Sebastien Here's all the options I can think of: A) - app dependencies and tuscany and its dependencies in web-inf/lib B) - app dependencies in web-inf/lib, tuscany and its dependencies in container shared library (geronimo/websphere/..) C) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany and its dependencies in web-inf/tuscany (to issolate tuscany from app CL) D) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany and its dependencies in folder outside of webapp ie c:/Tuscany/lib E) - app dependencies in web-inf/lib, tuscany using deep integration in container (tomcat/geronimo/...) F) - all tuscany and its dependencies in web-inf/lib, app (sca contributions) in web-inf/sca-contributions G) - all tuscany and its dependencies in web-inf/lib, app (sca contributions) outside of webapp ie c:/MySCAContributions H) - tuscany using deep integration in container (tomcat/geronimo/...), app's (sca contributions) in folder in container, ie c:/apache-tomcat-6.0.10 /SCAContributions Are there any other configurations anyone can think of? Most of our webapp samples today use (A) but we've code scattered about SVN and SVN history that do most of the others. (C) and (D) is what i think was being suggested by Simon Nash in [1]. The app can see the Tuscany classes and dependencies with (A) and (B) which we were trying to avoid at one point. (B) (D) (E) and (H) reduce the size of the application as Tuscany is outside of the webapp but that requires an extra install step (G) (and F) is what I think users were interested in doing in TUSCANY-1884 and [2] So its just a matter of deciding which we want to support and distribute :) As everyone seems to have different ideas about whats important I'm tempted to say lets try to support all of these for now so we play around and see which we think are really useful. How to distribute each option could be left to another thread. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200801.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200710.mbox/[EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1026) Java SDO Overview page on Web site has out of date information on samples
[ https://issues.apache.org/jira/browse/TUSCANY-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1026. - Resolution: Invalid The passage of time has made this JIRA invalid. Improvements will be made to the website structure, but this specific issue has disappeared. Java SDO Overview page on Web site has out of date information on samples - Key: TUSCANY-1026 URL: https://issues.apache.org/jira/browse/TUSCANY-1026 Project: Tuscany Issue Type: Bug Components: Website Affects Versions: Java-SCA-M2 Environment: all Reporter: Simon Nash Fix For: Java-SDO-Next The file java_sdo_overview.xml has a section at the end entitiled Test/Example programs. This section is out of date and needs to be updated to reflect the current state of the SDO Java technology samples and the Tuscany Java sample applications. The latter are described in java-projects.html#Running the Samples. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue
[ https://issues.apache.org/jira/browse/TUSCANY-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar resolved TUSCANY-2007. -- Resolution: Fixed completed at revision 614190 SDO Samples - fix sampleProgramContents.html's Firefox display issue Key: TUSCANY-2007 URL: https://issues.apache.org/jira/browse/TUSCANY-2007 Project: Tuscany Issue Type: Bug Components: Java SDO Samples Affects Versions: Java-SDO-Next Reporter: Amita Vadhavkar Priority: Minor Fix For: Java-SDO-Next Attachments: 2007.patch By below line to the https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html it worked fine on firefox. Without it, it was displaying as html text on the browser. !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN title=http://www.w3.org/TR/html4/loose.dtd; class=linkhttp://www.w3.org/TR/html4/loose.dtd; So fixing variable HTML_HEADER from sample-sdo/DocumentSamples to contain the above line will fix the rendering issue on Firefox. -- 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]
JMS services and threading
Right now JMS services use a single JMS consumer per service so requests are single threaded. We could do nothing and just live with this restriction or we could improve this by doing things such as: 1) have the consumer spawn new threads to process each request (using the existing Tuscany thread pool). One problem with that is i don't think we can't do QOS using the standard JMS APIs as once the consumer returns the message is considered successfully processed but the spawned thread may still be processing or have an exception. Note though that we don't currently support QOS option with the JMS binding. 2) In a J2EE environment we could use an MDB. That gets more complicated to implement and may require some manual configuration 3) Use a JCA adapter. I don't know so much about implementing this but i believe that would enable control of both the threading and QOS aspects. Of those (1) seems like the easiest to do right now to get concurrent requests on JMS services working but one of the other approaches is probably needed in the long term. Anyone have any comments on this or other approaches to suggest? ...ant
Re: JMS services and threading
snip... 1) have the consumer spawn new threads to process each request (using the existing Tuscany thread pool). One problem with that is i don't think we can't do QOS using the standard JMS APIs as once the consumer returns the message is considered successfully processed but the spawned thread may still be processing or have an exception. Not sure I understand this para. If the consumer starts processing the message shouldn't we consider that it has been successfully delivered. Processing it may cause errors but these should be application errors that in the @OneWay case presumably get written to a log or when the operation is not one way are put in a return message and sent back to the reply to address. Simon
helloworld JMS sample
I created a helloworld-reference/service pair for JMS last week when I was looking into some JMS questions on the list. They use the same scenario as the binding.jms unit tests but seems a shame to throw them away so I checked them into samples. The service unit test is currently turned off as it has highlighted an issue with calling a JMS service via a service reference obtained from the domain. I need to investigate a bit more. Regards Simon
Re: Does Tuscany support jaxws implementation?
Hi, Thank you for the info. I just checked in a module interface-java-jaxws under r614265. The basic idea is to enable the JAXWS annotations and provide extra metadata for the Tuscany runtime. Please feel free to jump in and help. Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, January 21, 2008 11:53 PM Subject: Re: Does Tuscany support jaxws implementation? To help with motivation for doing this here's a blog post also asking for it - http://biemond.blogspot.com/2008/01/tuscany-sca-java-and-jdeveloper-11g.html ...ant On Jan 7, 2008 5:39 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I'm looking into the JAXWS support from a slight different perspetive. Basically, I'm adding JAXWS annotation processing capability into Tuscany so that Tuscany can capture the addtional metadata from the annotations and use them during runtime. Thanks, Raymond - Original Message - From: Denny Xu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 02, 2008 12:24 AM Subject: Does Tuscany support jaxws implementation? Hi all I create a web service using stp jaxws project, and now, I want assembly these services as using sca components, I wondered if Tuscany supports jaxws service as its implementation. I am trying to create a sca component in composite file by following MikeEdwards's article in OSOA which url is http://www.osoa.org/display/Main/JAX-WS+Services+Integration. component name=GreeterComponment tuscany: implementation.jaxws class= org.apache.hellow_world_soap.GreeterImpl/ /component Does Tuscany know the tag implementation.jaxws Thanks Denny - 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: [jira] Created: (TUSCANY-2002) SDO databinding doesn't have access to the SDO factories which are not referenced by an component service/reference interface
Please see my comments inline. Thanks, Raymond - Original Message - From: Scott Kurz [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, January 18, 2008 3:47 PM Subject: Re: [jira] Created: (TUSCANY-2002) SDO databinding doesn't have access to the SDO factories which are not referenced by an component service/reference interface Raymond, Can I ask a question about this? For static SDOs (Ignoring the wrapper types which have this problem), we're only registering the SDOs with the Composite HelperContext during transformation, right? Right. We create JAXBContext at transformation time based on the static SDO classes referenced by the java interfaces. During introspection the SDODataBinding.introspect calls TypeHelper.getType(Class) but that does not do a registration, right? Right. That's why we have the register's in SDOContextHelper which the SDO-related transformers invoke at transform time. And that's how for the past few months we avoided import.sdo for static SDO... Is this right? Yes. Thanks, Scott On Jan 18, 2008 12:10 PM, Raymond Feng (JIRA) tuscany-dev@ws.apache.org wrote: SDO databinding doesn't have access to the SDO factories which are not referenced by an component service/reference interface - Key: TUSCANY-2002 URL: https://issues.apache.org/jira/browse/TUSCANY-2002 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng In a doc-lit-wrapped WSDL (a.wsdl), we define the wrapper element (http://ns1) in the inline schema which imports other XSD types (http://ns2) from an XSD file (b.xsd), Running the SDO XSD2Java codegen on a.wsdl and b.xsd will generate two SDO factories, one for http://ns1 and one for http://ns2. Now let's assume a java interface is used by the component, and it has the following method. Quote getQuote(String symbol); // Quote is a generated SDO class/interface, getQuote and getQuoteResponse are the wrapper elements. The SDO databinding gains access to the fatory for http://ns2 but not http://ns1 since the getQuote/getQuoteResponse is not referenced on this method. As a result, the SDO wrapping/unwrapping data transformation will be broken as the SDO factory for http://ns2 is not registered. The workaround is to use import.sdo. -- 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] - 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]
Distribution zips and what they contain, was: SCA runtimes
Simon Nash wrote: Jean-Sebastien Delfino wrote: - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? [snip] With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. [snip] I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
On Jan 22, 2008 5:36 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: Jean-Sebastien Delfino wrote: - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? [snip] With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. [snip] I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need We do need to do something about the distribution but having multiple distro's doesn't actually make it easier to find what you need does it? It actually makes it harder as right now we have a single distro so its pretty easy to know where to look :) I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Would each distro include everthing it needs or is tuscany-core.zip a prereq? Where do all the different data bindings go? Doesn't one of the SCA specs say an SCA runtime MUST support binding.ws? Is interface.wsdl supported in the others or only with tuscany-web? Is the core distro really so useful with nothing except implementation.javaand no bindings Do all those distro's include everything to support both tomcat and Jetty standalone and webapps...and all the runtimes being discussed like Geronimo and Tomcat deep integration? Would any/all of those work with all the new domain/node stuff? And i think right now that requires things like the WS and JSON support? Where would all the demo's get included? If this is mainly about reducing the size of the download then as an alternative way of splitting things - what sort of size would be ok and using that number could we then add the most useful extensions until we get to that size and make the others optional downloads? ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Please see my comments inline. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, January 22, 2008 9:36 AM Subject: Distribution zips and what they contain, was: SCA runtimes Simon Nash wrote: Jean-Sebastien Delfino wrote: - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? [snip] With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. [snip] I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components +1. - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components +1. - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components I think we should have WS binding in tuscany-jee.zip as WS is part of JEE. (Maybe -jee should be a superset of -web). - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Are the BPEL/XQuery mature enough to have a separate tuscany-process.zip? Maybe the users could download tuscany-all.zip for now if they want to work with BEPL and XQuery. Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. +1 to keep the zips at the same level. I'm also assuming that the relevant samples are included in each zip. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-2009: Attachment: 2009.patch This patch validates byte[] types in the EqualityHelperImpl class. I've augmented the SimpleEqualityTestCase to test for this condition, as well. Java SDO's EqualityHelper doesn't compare Bytes values correctly Key: TUSCANY-2009 URL: https://issues.apache.org/jira/browse/TUSCANY-2009 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Next Attachments: 2009.patch, Test2009.java Comparison of two Bytes values fails when it should succeed. The test for equality passes through the EqualityHelperImpl.equal method. In that method, the test is passed to EcoreUtil.haveEqualAttribute(EObject, EObject, EAttribute). For a simple type, it defers to java's '==' operator. So, two different object arrays are being compared, not for their contents, but rather if they are the same object. Attached is a test case which demonstrates this issue. -- 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-2009) Java SDO's EqualityHelper doesn't compare Bytes values correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561598#action_12561598 ] Amita Vadhavkar commented on TUSCANY-2009: -- The patch looks fine to me. There is another pre-existing issue in the current SDO code base. Please see - http://www.mail-archive.com/[EMAIL PROTECTED]/msg02434.html, is this a known issue and is there a solution to it? Java SDO's EqualityHelper doesn't compare Bytes values correctly Key: TUSCANY-2009 URL: https://issues.apache.org/jira/browse/TUSCANY-2009 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Next Attachments: 2009.patch, Test2009.java Comparison of two Bytes values fails when it should succeed. The test for equality passes through the EqualityHelperImpl.equal method. In that method, the test is passed to EcoreUtil.haveEqualAttribute(EObject, EObject, EAttribute). For a simple type, it defers to java's '==' operator. So, two different object arrays are being compared, not for their contents, but rather if they are the same object. Attached is a test case which demonstrates this issue. -- 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: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Hi, I have changed this now to put the computed intents back into the binding/implementation instance. So the bindings and implementations can now parse the intents and filter the mayProvided ones and take appropriate actions. I'm trying to see if I can get this demonstrated on our axis2 binding. I've also made some changes to now get the bindingType and implementationType definitions in order. Here is how things should work from now on : - - every binding and implementation type has a definitions.xml file in the META-INF/services directory in which will be defined a bindingType or implementationType element that contains all the intents mayProvided and alwaysProvided by the binding / implementation type. - ever binding / implementation instance will have reference to this corresponding type bindingType or implementationType definition. All this under r614447. Thanks - Venkat On Jan 16, 2008 12:52 AM, Greg Dritschler [EMAIL PROTECTED] wrote: I agree that intents that are listed in mayProvide do not require a policy set. The binding/implementation provides the functionality of the intent if the intent is present on the relevant composite element. It looks to me that CompositeWireBuilderImpl, as part of the process of trying to find matching policy sets, removes intents that are found in mayProvide from the model object. In that case, how would the binding/implementation know it should provide the intent functionality if the intent isn't present in the model anymore? Greg Dritschler
