[jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions
[ http://issues.apache.org/jira/browse/TUSCANY-773?page=comments#action_12439743 ] Venkatakrishnan commented on TUSCANY-773: - Hi Raymond, thank you very much. I have updated my code with the commits and will now take a look and digest the changes you have made after which we shall get to the next steps. Thanks for all the help - Venkat > Fix Property Value Loading from Component Definitions > - > > Key: TUSCANY-773 > URL: http://issues.apache.org/jira/browse/TUSCANY-773 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: Venkatakrishnan > Assigned To: Raymond Feng > Attachments: rfeng.patch, Tuscany-kernel-core-02-Oct.diff, > Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel-core-03-Oct.diff, > Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany-spec-sca-02-Oct.diff, > Tuscany-spec-sca-03-Oct.diff > > > Currently property loading for application components does not work. There > is NPE exception thrown when creating a property instance factory based on > the property value defined in the Component Defn. > Also the property loading works only for simply types whose values can be > represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Modeling persistence services, was Re: EJB3 (JPA) support
I think there are two aspects here, 1. Injecting an entity manager factory (using @PersistenceUnit annotation on a property) 2. Injecting an entity manager (using @PersistenceContext annotation on a property) The first one is pretty straight forward as the binding is load time and pretty straight forward. We could have something that looks at properties annotated with the PersistneceUnit annotation at load time and scan the current classloader and parents for any persistence.xml files with a matching persistence unit name. From the XML, we can find the provider class for the JPA implementation and use that configure the entity manager factory and inject the reference to the component. The second one is more tricky, entity manager instances are dynamically bound based on the transaction scope and may require the policy framework to create and inject a reference on a per invocation stack basis. This could use the relavant entity manager factory that is made available as a system service. Lot of these things are generic and should be common for any JPA implementation. From that perspective, I am not sure whether we need specialized modules for OpenJPA, Hibernate, Toplink etc. Most of the customizations of the runtime behaviour and configuration will be within the persistence.xml file. Jim, I would be interested in knowing your views on this. I wouldn't mind starting a look at implementing support for PersistenceUnit annotation for a start based around the stuff Jim checked in. Ta Meeraj >> -Original Message- >> From: Jeremy Boynes [mailto:[EMAIL PROTECTED] >> Sent: 03 October 2006 21:05 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Modeling persistence services, was Re: EJB3 >> (JPA) support >> >> I see wires in the assembly as representing the interaction >> between application components. Properties on the other hand >> represent a contract between the application component and >> the container (by which I mean the container is responsible >> for configuring an instance of the application component >> with the value of that property). >> >> One way to represent an EntityManager would be to add a >> component to the system that exposed that as a service. You >> could then wire components to it as normal. >> >> That does seem a little odd to me in that you would probably >> need a custom implementation type for such a component that >> allowed you to specify the EntityManagerFactory >> configuration. It also seems odd to be using EntityManager >> as a service interface (valid, but odd). >> >> Less odd to me is the idea of things (like EntityManager) >> that are services provided by the runtime environment where >> a component is running. They are part of a contract between >> an implementation and its environment rather than between an >> implementation and another component. We have that concept >> already in the form of Property (contract with the >> environment to instantiate a value) so extending that >> concept to more complex things would seem natural. >> >> This would allow me to change the implementation type for >> the component without changing the business level services >> that it connects to. I can swap the implementation from one >> that uses JPA to one that uses JDO or JDBC or XML or C++ >> with ODBC without removing/ adding other components to my assembly. >> >> Being of the "cake and eating it camp" I think we should do both: >> * provide that can be used to define a >> component with an EntityManager service interface >> * support properties with a type of "EntityManager" that can >> be injected to a component >> >> The same would go for other similar things such as SDO >> Helpers, JDO PersistenceManagers, ... >> -- >> Jeremy >> >> On Oct 3, 2006, at 9:29 AM, scabooz wrote: >> >> > H...a service modeled as a property is what seems odd. >> I'm trying >> > to keep an open mind. >> > Imagine drawing a picture of this using the icons from the >> SCA spec. >> > You'd have some kind of a connection from a component's >> property to a >> > database? That's what doesn't make sense. I need to >> think more on >> > this, and maybe I'll change my mind. Didn't want to let >> this thread >> > just die. >> > >> > Dave >> > >> > - Original Message - From: "Jim Marino" >> > <[EMAIL PROTECTED]> >> > To: >> > Sent: Tuesday, October 03, 2006 11:40 AM >> > Subject: Re: EJB3 (JPA) support >> > >> > >> >> On Oct 3, 2006, at 7:44 AM, scabooz wrote: >> >>> Hi Jim, >> >>> >> >>> Somewhere buried in your explanation is the answer to my >> question, >> >>> but I can't find it, so I'll have to ask. I'm trying to >> understand >> >>> how you have modeled this WRT the assembly model. It looks like >> >>> you've added in a SCDL extension, and are playing with >> the semantics >> >>> of a property. I would have expected such a formal part of the >> >>> application to have been modeled in a formal way, such >> as with an >> >>>
RE: Modeling persistence services, was Re: EJB3 (JPA) support
I don't look at persistence context/unit injection as a service, rather, as a resource utilized by a service for handling domain persistence. I don't know how well this fits into the SCA specification, however, as an add-on it is an appealing feature to Tuscany. Frameworks like Spring already support such features and there are efforts in implementing non-JPA aspects of EJB 3.0 in lightweight Ioc containers (pitchfork for example). Also, according to my understanding of composites conceptually, services can be as coarse-grained or fine-grained as they need to be. From that perspective you could have a data access service for domain persistence, that may need resources like datasources and persistence contexts. Ta Meeraj >> -Original Message- >> From: scabooz [mailto:[EMAIL PROTECTED] >> Sent: 03 October 2006 17:29 >> To: tuscany-dev@ws.apache.org >> Subject: Modeling persistence services, was Re: EJB3 (JPA) support >> >> H...a service modeled as a property is what seems odd. >> I'm trying to keep an open mind. >> Imagine drawing a picture of this using the icons from the >> SCA spec. You'd have some kind of a connection from a >> component's property to a database? That's what doesn't >> make sense. I need to think more on this, and maybe I'll >> change my mind. Didn't want to let this thread just die. >> >> Dave >> >> - Original Message - >> From: "Jim Marino" <[EMAIL PROTECTED]> >> To: >> Sent: Tuesday, October 03, 2006 11:40 AM >> Subject: Re: EJB3 (JPA) support >> >> >> > >> > On Oct 3, 2006, at 7:44 AM, scabooz wrote: >> > >> >> Hi Jim, >> >> >> >> Somewhere buried in your explanation is the answer to >> >> my question, but I can't find it, so I'll have to ask. I'm >> >> trying to understand how you have modeled this WRT >> >> the assembly model. It looks like you've added in a >> >> SCDL extension, and are playing with the semantics >> >> of a property. I would have expected such a formal >> >> part of the application to have been modeled in a >> >> formal way, such as with an SCA component. >> > It's a property (or "resource") just like a datasource or >> type system >> > helper (e.g. SDO) would be. Modeling it as a service on a >> component >> > seems kind of odd. There's a system service responsible >> for providing >> > a value for the property (just like all property values in >> Tuscany) >> > but that's an implementation detail. Make sense? >> >> Am I >> >> understanding this correctly? I'm asking from a spec >> >> perspective, trying to make sure that we're clean. >> >> >> >> Dave >> >> >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> This message has been checked for all email viruses by MessageLabs. >> >> * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions
[ http://issues.apache.org/jira/browse/TUSCANY-773?page=comments#action_12439737 ] Raymond Feng commented on TUSCANY-773: -- Hi, Venkat. I made changes based on your latest patch. 1) The component loader will create a map of PropertyValue(s) for each Property in the componentType. 2) We load the value of the PropertyValue as a DOM Document. The value can be the content of the element, from the source XPath or file URI. 3) A PropertyValue will be created for a property that is not overrided by the component. The value is the default. 4) We attach a ValueFactory to each PropertyValue. The factory should be able to create the desired instance for a property value (basically it transforms the DOM into the target databinding.) I have added a SimplePropertyFactory which knows how to create java simple types. The PropertyFactory will use the databnding framework to do complexType conversions. 5) The component builder will provide the property databinding information for the component impl and then it can get the value factory for each PropertyValue to create the instances and use its own way to pass to the component impl. I'll commit the changes as the base. Thanks, Raymond > Fix Property Value Loading from Component Definitions > - > > Key: TUSCANY-773 > URL: http://issues.apache.org/jira/browse/TUSCANY-773 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: Venkatakrishnan > Assigned To: Raymond Feng > Attachments: rfeng.patch, Tuscany-kernel-core-02-Oct.diff, > Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel-core-03-Oct.diff, > Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany-spec-sca-02-Oct.diff, > Tuscany-spec-sca-03-Oct.diff > > > Currently property loading for application components does not work. There > is NPE exception thrown when creating a property instance factory based on > the property value defined in the Component Defn. > Also the property loading works only for simply types whose values can be > represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing users in the JIRA "assign" list
I added Geoff Winn and Simon Laws to tuscany-developers On Oct 3, 2006, at 8:17 PM, Jean-Sebastien Delfino wrote: I am not able to assign a JIRA issue to Geoff. Simon Laws does not seem to be in the "assign" list either. How can we add these users (who already created many of issues) to that list? I looked everywhere in JIRA and could not see a way to add these users. Aren't committers able to perform these JIRA admin tasks? -- 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] Assigned: (TUSCANY-773) Fix Property Value Loading from Component Definitions
[ http://issues.apache.org/jira/browse/TUSCANY-773?page=all ] Raymond Feng reassigned TUSCANY-773: Assignee: Raymond Feng > Fix Property Value Loading from Component Definitions > - > > Key: TUSCANY-773 > URL: http://issues.apache.org/jira/browse/TUSCANY-773 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: Venkatakrishnan > Assigned To: Raymond Feng > Attachments: rfeng.patch, Tuscany-kernel-core-02-Oct.diff, > Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel-core-03-Oct.diff, > Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany-spec-sca-02-Oct.diff, > Tuscany-spec-sca-03-Oct.diff > > > Currently property loading for application components does not work. There > is NPE exception thrown when creating a property instance factory based on > the property value defined in the Component Defn. > Also the property loading works only for simply types whose values can be > represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modeling persistence services, was Re: EJB3 (JPA) support
On Oct 3, 2006, at 6:17 PM, Jeremy Boynes wrote: On Oct 3, 2006, at 5:26 PM, Jim Marino wrote: This sounds like having cake, eating it, and also being able to give it to a friend :-) We provide the flexibility for users: 1) to access infrastructure services through properties Yes for things like JPA, JDBC, etc. 2) to reference infrastructure services through inclusion in their assembly If we do 1 I don't think we should do 2 (that doesn't stop someone from extending Tuscany to do it though). See my comments below. "Thanks for volunteering" :-) If someone wants to contribute these, I think we should welcome it like we would any other contribution. Hey, I'm only volunteering for 1, not the others. But sure, if someone wants to do the others, great :-) 3) to access data through an application service with declarative implementation by DAS Yes, that's the value I see in DAS I think this is already on the DAS folks radar. -- Jeremy - 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: Modeling persistence services, was Re: EJB3 (JPA) support
I'm starting to look in ways we could have a declarative DAS and will be posting my progress into the list / wiki soon... - Luciano On 10/3/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Oct 3, 2006, at 5:26 PM, Jim Marino wrote: >> This sounds like having cake, eating it, and also being able to >> give it to a friend :-) We provide the flexibility for users: >> 1) to access infrastructure services through properties > Yes for things like JPA, JDBC, etc. >> 2) to reference infrastructure services through inclusion in their >> assembly > If we do 1 I don't think we should do 2 (that doesn't stop someone > from extending Tuscany to do it though). See my comments below. "Thanks for volunteering" :-) If someone wants to contribute these, I think we should welcome it like we would any other contribution. >> 3) to access data through an application service with declarative >> implementation by DAS > Yes, that's the value I see in DAS I think this is already on the DAS folks radar. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Missing users in the JIRA "assign" list
I am not able to assign a JIRA issue to Geoff. Simon Laws does not seem to be in the "assign" list either. How can we add these users (who already created many of issues) to that list? I looked everywhere in JIRA and could not see a way to add these users. Aren't committers able to perform these JIRA admin tasks? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Created Cpp-M2 version in JIRA
I created a Cpp-M2 version in JIRA to help us sort JIRA issues and assign them to our M2 release. Right now only JIRA TUSCANY-781, which I just created, is assigned to Cpp-M2. We'll probably need to move more issues to M2 :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-781) Files created by SDO make check should be listed in svn:ignore property
[ http://issues.apache.org/jira/browse/TUSCANY-781?page=all ] Jean-Sebastien Delfino updated TUSCANY-781: --- Fix Version/s: Cpp-M2 (was: Cpp-current) Affects Version/s: Cpp-M2 > Files created by SDO make check should be listed in svn:ignore property > --- > > Key: TUSCANY-781 > URL: http://issues.apache.org/jira/browse/TUSCANY-781 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current, Cpp-M2 >Reporter: Jean-Sebastien Delfino > Fix For: Cpp-M2 > > > The SDO make check build runs a bunch of tests which create output test files > under the source tree. These files are not ignored in svn:ignore properties > and show up in the next svn st. This is error prone and we may check in these > files by mistake, they should be listed in the svn:ignore property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-781) Files created by SDO make check should be listed in svn:ignore property
[ http://issues.apache.org/jira/browse/TUSCANY-781?page=all ] Jean-Sebastien Delfino updated TUSCANY-781: --- Summary: Files created by SDO make check should be listed in svn:ignore property (was: SDO make check pollutes source dir with test output files) > Files created by SDO make check should be listed in svn:ignore property > --- > > Key: TUSCANY-781 > URL: http://issues.apache.org/jira/browse/TUSCANY-781 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current >Reporter: Jean-Sebastien Delfino > Fix For: Cpp-current > > > The SDO make check build runs a bunch of tests which create output test files > under the source tree. These files are not ignored in svn:ignore properties > and show up in the next svn st. This is error prone and we may check in these > files by mistake, they should be listed in the svn:ignore property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-781) SDO make check pollutes source dir with test output files
SDO make check pollutes source dir with test output files - Key: TUSCANY-781 URL: http://issues.apache.org/jira/browse/TUSCANY-781 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Reporter: Jean-Sebastien Delfino Fix For: Cpp-current The SDO make check build runs a bunch of tests which create output test files under the source tree. These files are not ignored in svn:ignore properties and show up in the next svn st. This is error prone and we may check in these files by mistake, they should be listed in the svn:ignore property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions
Sure Jim. Will look that up. Thanks - Venkat On 10/4/06, Jim Marino <[EMAIL PROTECTED]> wrote: Venkat, do you also want to file a bug with the spec group on osoa.org so we can fix this in the Java spec? Jim On Oct 3, 2006, at 5:03 PM, Jim Marino wrote: > O.K. that's fine. I just noticed the patch file but didn't look > closely at what it was. > > Jim > > On Oct 3, 2006, at 3:09 PM, Raymond Feng wrote: > >> Hi, Jim. >> >> I think Venkat has proposed to change the @Property annotation to >> reflect the "override" attribute defined by the SCA spec to to be >> "may", "no" or "must". It's not a Tuscany extension to me. >> >> Thanks, >> Raymond >> >> - Original Message - From: "Jim Marino (JIRA)" > [EMAIL PROTECTED]> >> To: >> Sent: Tuesday, October 03, 2006 12:22 PM >> Subject: [jira] Commented: (TUSCANY-773) Fix Property Value >> Loading from Component Definitions >> >> >>>[ http://issues.apache.org/jira/browse/TUSCANY-773? >>> page=comments#action_12439633 ] >>> >>> Jim Marino commented on TUSCANY-773: >>> >>> >>> I noticed the spec files changed. Venkat, could you explain why >>> this is necessary as I don't think we should be adding any >>> Tuscany extensions into the osoa namespace. >>> >>> Jim >>> >>> Fix Property Value Loading from Component Definitions - Key: TUSCANY-773 URL: http://issues.apache.org/jira/browse/ TUSCANY-773 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Venkatakrishnan Attachments: rfeng.patch, Tuscany-kernel-core-02- Oct.diff, Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel- core-03-Oct.diff, Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany- spec-sca-02-Oct.diff, Tuscany-spec-sca-03-Oct.diff Currently property loading for application components does not work. There is NPE exception thrown when creating a property instance factory based on the property value defined in the Component Defn. Also the property loading works only for simply types whose values can be represented as a simple xml text content. >>> >>> -- >>> This message is automatically generated by JIRA. >>> - >>> If you think it was sent incorrectly contact one of the >>> administrators: http://issues.apache.org/jira/secure/ >>> Administrators.jspa >>> - >>> For more information on JIRA, see: http://www.atlassian.com/ >>> software/jira >>> >>> >>> >>> >>> - >>> 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modeling persistence services, was Re: EJB3 (JPA) support
On Oct 3, 2006, at 5:26 PM, Jim Marino wrote: This sounds like having cake, eating it, and also being able to give it to a friend :-) We provide the flexibility for users: 1) to access infrastructure services through properties Yes for things like JPA, JDBC, etc. 2) to reference infrastructure services through inclusion in their assembly If we do 1 I don't think we should do 2 (that doesn't stop someone from extending Tuscany to do it though). See my comments below. "Thanks for volunteering" :-) If someone wants to contribute these, I think we should welcome it like we would any other contribution. 3) to access data through an application service with declarative implementation by DAS Yes, that's the value I see in DAS I think this is already on the DAS folks radar. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions
Venkat, do you also want to file a bug with the spec group on osoa.org so we can fix this in the Java spec? Jim On Oct 3, 2006, at 5:03 PM, Jim Marino wrote: O.K. that's fine. I just noticed the patch file but didn't look closely at what it was. Jim On Oct 3, 2006, at 3:09 PM, Raymond Feng wrote: Hi, Jim. I think Venkat has proposed to change the @Property annotation to reflect the "override" attribute defined by the SCA spec to to be "may", "no" or "must". It's not a Tuscany extension to me. Thanks, Raymond - Original Message - From: "Jim Marino (JIRA)" [EMAIL PROTECTED]> To: Sent: Tuesday, October 03, 2006 12:22 PM Subject: [jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions [ http://issues.apache.org/jira/browse/TUSCANY-773? page=comments#action_12439633 ] Jim Marino commented on TUSCANY-773: I noticed the spec files changed. Venkat, could you explain why this is necessary as I don't think we should be adding any Tuscany extensions into the osoa namespace. Jim Fix Property Value Loading from Component Definitions - Key: TUSCANY-773 URL: http://issues.apache.org/jira/browse/ TUSCANY-773 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Venkatakrishnan Attachments: rfeng.patch, Tuscany-kernel-core-02- Oct.diff, Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel- core-03-Oct.diff, Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany- spec-sca-02-Oct.diff, Tuscany-spec-sca-03-Oct.diff Currently property loading for application components does not work. There is NPE exception thrown when creating a property instance factory based on the property value defined in the Component Defn. Also the property loading works only for simply types whose values can be represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modeling persistence services, was Re: EJB3 (JPA) support
On Oct 3, 2006, at 2:43 PM, Jeremy Boynes wrote: On Oct 3, 2006, at 1:41 PM, Jim Marino wrote: I like most types of cake too but I think we should really have one way of doing this. I've vacillated in the past on whether things such as DataSources, EntityManagers, etc. are modeled as services in an *application* assembly or are contracts a particular implementation may have with the container, i.e. a property. I believe they are the second. My understanding of DAS on the other hand is that it models data services which should be represented as services in an application assembly. So, if someone wants to model data access as a service then they should use DAS (which could, as an implementation strategy, use JPA or DAS for SQL data). I think there's a big difference between something like and Agreed, that's what I said previously although I see I had a typo at the end that may have confused things: DAS could use JPA or JDBC for SQL data access. I think is about simplifying the configuration of a complex component with a specific service interface (in this case EntityManager). SCA assembly allows you to do this and although it may seem odd, it is valid. We may suggest alternatives but in the end providing the freedom for users to choose is essential to our success. DAS on the other hand is about declarative definition of data access. Whereas in the case the service contract is fixed, DAS is about allowing the user to define data access in terms of a service design pattern. The application developer defines the service contract (as Java, WSDL, ...) with SCA supporting multiple implementations of that contract. Someone may choose an implementation based on JPA, JDO or some other programmatic technology, or they can choose an implementation based on DAS's declarative model. This sounds like having cake, eating it, and also being able to give it to a friend :-) We provide the flexibility for users: 1) to access infrastructure services through properties Yes for things like JPA, JDBC, etc. 2) to reference infrastructure services through inclusion in their assembly If we do 1 I don't think we should do 2 (that doesn't stop someone from extending Tuscany to do it though). See my comments below. 3) to access data through an application service with declarative implementation by DAS Yes, that's the value I see in DAS IMO users will want to do all of these and we should not do anything to stop them. Allowing people to do it and facilitating it are two separate things. We allow people to do it in that someone could come along an extend the runtime in (almost) any way they please. I don't think we should be facilitating it by doing it out of the box since having multiple APIs/metadata for doing the same thing is generally not good (although there are exceptions). Also, in the spec group we have discussed use of Commons Annotations @Resource for *property* injection, which includes things such as DataSources. If we do this in the spec it would seem kind of funny to implement the opposite. Another approach would be to entertain the idea of eliminating the distinction between properties and references altogether and just have "configuration sites" on components. I think an argument can be made that a component implementation should only care about a contract being fulfilled, not where it comes from. The fact that Tuscany uses SCA "services" and assembly to constitute the runtime is opaque to the application. Tuscany could have chosen a different implementation strategy, for example using PicoContainer, Spring, or Java "new", etc., but the application does not need this knowledge. I believe it is important to maintain this divide and that we do not cross namespaces. In other words, it should not be possible to address a system service *directly* from an application implementation. I think this is a different issue. I agree that we do not want to provide users with direct access to the services we use to create the runtime, which I believe is what you mean by "cross namespaces." However, we do not want to prevent users from defining services in the application namespace that happen to use system- or implementation-specific interfaces. Of course, that's how @PersistenceContext would work. I believe "crossing" namespaces (couldn't think of a better term) will become something we will need to increasingly be aware of with autowire by intent. IOW, as a user I should be able to define a component with a service of type "EntityManager" and provide my own Java implementation for that component (for example using the Persistence API directly). Someone else should also be able to provide alternative implementation types for that (which is what is). This places all this function firmly in the application space, maintaining separation from the runtime's implement
Re: [jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions
O.K. that's fine. I just noticed the patch file but didn't look closely at what it was. Jim On Oct 3, 2006, at 3:09 PM, Raymond Feng wrote: Hi, Jim. I think Venkat has proposed to change the @Property annotation to reflect the "override" attribute defined by the SCA spec to to be "may", "no" or "must". It's not a Tuscany extension to me. Thanks, Raymond - Original Message - From: "Jim Marino (JIRA)" [EMAIL PROTECTED]> To: Sent: Tuesday, October 03, 2006 12:22 PM Subject: [jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions [ http://issues.apache.org/jira/browse/TUSCANY-773? page=comments#action_12439633 ] Jim Marino commented on TUSCANY-773: I noticed the spec files changed. Venkat, could you explain why this is necessary as I don't think we should be adding any Tuscany extensions into the osoa namespace. Jim Fix Property Value Loading from Component Definitions - Key: TUSCANY-773 URL: http://issues.apache.org/jira/browse/ TUSCANY-773 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Venkatakrishnan Attachments: rfeng.patch, Tuscany-kernel-core-02- Oct.diff, Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel- core-03-Oct.diff, Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany- spec-sca-02-Oct.diff, Tuscany-spec-sca-03-Oct.diff Currently property loading for application components does not work. There is NPE exception thrown when creating a property instance factory based on the property value defined in the Component Defn. Also the property loading works only for simply types whose values can be represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - 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]
[jira] Updated: (TUSCANY-780) Numerous broken links at http://incubator.apache.org/tuscany/java-projects.html
[ http://issues.apache.org/jira/browse/TUSCANY-780?page=all ] Lee Surprenant updated TUSCANY-780: --- Attachment: sitePatch.patch The attached sitePatch includes a change to the site.vsl file used to generate all of the site content. I have done my best to make sure that the change will not break other pages, but we must be careful of this. An alternative to patching this file that is used in other xml files on the site, is the usage of within the xml (as apposed to generating these anchors via the section macro). The patch also includes a very basic howto file for running the java sca samples. This file includes information I have found on the lists and in my own limited insight. It is hopefully better than the M1 info for the current revision, but will likely need to be improved as I am still a bit new to Tuscany (for now, it is better than a broken link). > Numerous broken links at > http://incubator.apache.org/tuscany/java-projects.html > --- > > Key: TUSCANY-780 > URL: http://issues.apache.org/jira/browse/TUSCANY-780 > Project: Tuscany > Issue Type: Improvement >Reporter: Lee Surprenant > Attachments: sitePatch.patch > > > There are a number of broken links at > http://incubator.apache.org/tuscany/java-projects.html including the internal > links in the opening "Tuscany JAVA Project" section, as well as an external > link to GettingStarted.htm in the "Running The Samples" section. Not sure if > we are waiting until M2 to update the site, but as a new user, these broken > links were very discouraging to me. In particular, the "GettingStarted.htm" > which results in a 404:Page not Found error was quite frustrating. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-780) Numerous broken links at http://incubator.apache.org/tuscany/java-projects.html
Numerous broken links at http://incubator.apache.org/tuscany/java-projects.html --- Key: TUSCANY-780 URL: http://issues.apache.org/jira/browse/TUSCANY-780 Project: Tuscany Issue Type: Improvement Reporter: Lee Surprenant There are a number of broken links at http://incubator.apache.org/tuscany/java-projects.html including the internal links in the opening "Tuscany JAVA Project" section, as well as an external link to GettingStarted.htm in the "Running The Samples" section. Not sure if we are waiting until M2 to update the site, but as a new user, these broken links were very discouraging to me. In particular, the "GettingStarted.htm" which results in a 404:Page not Found error was quite frustrating. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions
Hi, Jim. I think Venkat has proposed to change the @Property annotation to reflect the "override" attribute defined by the SCA spec to to be "may", "no" or "must". It's not a Tuscany extension to me. Thanks, Raymond - Original Message - From: "Jim Marino (JIRA)" To: Sent: Tuesday, October 03, 2006 12:22 PM Subject: [jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions [ http://issues.apache.org/jira/browse/TUSCANY-773?page=comments#action_12439633 ] Jim Marino commented on TUSCANY-773: I noticed the spec files changed. Venkat, could you explain why this is necessary as I don't think we should be adding any Tuscany extensions into the osoa namespace. Jim Fix Property Value Loading from Component Definitions - Key: TUSCANY-773 URL: http://issues.apache.org/jira/browse/TUSCANY-773 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Venkatakrishnan Attachments: rfeng.patch, Tuscany-kernel-core-02-Oct.diff, Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel-core-03-Oct.diff, Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany-spec-sca-02-Oct.diff, Tuscany-spec-sca-03-Oct.diff Currently property loading for application components does not work. There is NPE exception thrown when creating a property instance factory based on the property value defined in the Component Defn. Also the property loading works only for simply types whose values can be represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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: Modeling persistence services, was Re: EJB3 (JPA) support
On Oct 3, 2006, at 1:41 PM, Jim Marino wrote: I like most types of cake too but I think we should really have one way of doing this. I've vacillated in the past on whether things such as DataSources, EntityManagers, etc. are modeled as services in an *application* assembly or are contracts a particular implementation may have with the container, i.e. a property. I believe they are the second. My understanding of DAS on the other hand is that it models data services which should be represented as services in an application assembly. So, if someone wants to model data access as a service then they should use DAS (which could, as an implementation strategy, use JPA or DAS for SQL data). I think there's a big difference between something like and I think is about simplifying the configuration of a complex component with a specific service interface (in this case EntityManager). SCA assembly allows you to do this and although it may seem odd, it is valid. We may suggest alternatives but in the end providing the freedom for users to choose is essential to our success. DAS on the other hand is about declarative definition of data access. Whereas in the case the service contract is fixed, DAS is about allowing the user to define data access in terms of a service design pattern. The application developer defines the service contract (as Java, WSDL, ...) with SCA supporting multiple implementations of that contract. Someone may choose an implementation based on JPA, JDO or some other programmatic technology, or they can choose an implementation based on DAS's declarative model. This sounds like having cake, eating it, and also being able to give it to a friend :-) We provide the flexibility for users: 1) to access infrastructure services through properties 2) to reference infrastructure services through inclusion in their assembly 3) to access data through an application service with declarative implementation by DAS IMO users will want to do all of these and we should not do anything to stop them. The fact that Tuscany uses SCA "services" and assembly to constitute the runtime is opaque to the application. Tuscany could have chosen a different implementation strategy, for example using PicoContainer, Spring, or Java "new", etc., but the application does not need this knowledge. I believe it is important to maintain this divide and that we do not cross namespaces. In other words, it should not be possible to address a system service *directly* from an application implementation. I think this is a different issue. I agree that we do not want to provide users with direct access to the services we use to create the runtime, which I believe is what you mean by "cross namespaces." However, we do not want to prevent users from defining services in the application namespace that happen to use system- or implementation-specific interfaces. IOW, as a user I should be able to define a component with a service of type "EntityManager" and provide my own Java implementation for that component (for example using the Persistence API directly). Someone else should also be able to provide alternative implementation types for that (which is what is). This places all this function firmly in the application space, maintaining separation from the runtime's implementation. I think the "property" style takes this even further, eliminating the need for this kind of "infrastructure-esque" component to be present / in application space./ It is providing a controlled way to bridge from application space to runtime space, a way controlled by the runtime itself. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: binding.ejb and binding.jms support in Tuscany
On Oct 3, 2006, at 1:15 PM, Seth White wrote: Hi, I am interested in giving SCA components access to EJB components; stateless, stateful, and message driven. I've read the white paper that talks about accessing EJB 2.1 stateless session beans. Hi Seth, +1 I think this would be a great thing to support. Jim Is anyone working on EJB support for Tuscany? Thanks. Seth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modeling persistence services, was Re: EJB3 (JPA) support
On Oct 3, 2006, at 1:05 PM, Jeremy Boynes wrote: I see wires in the assembly as representing the interaction between application components. Properties on the other hand represent a contract between the application component and the container (by which I mean the container is responsible for configuring an instance of the application component with the value of that property). One way to represent an EntityManager would be to add a component to the system that exposed that as a service. You could then wire components to it as normal. That does seem a little odd to me in that you would probably need a custom implementation type for such a component that allowed you to specify the EntityManagerFactory configuration. It also seems odd to be using EntityManager as a service interface (valid, but odd). Less odd to me is the idea of things (like EntityManager) that are services provided by the runtime environment where a component is running. They are part of a contract between an implementation and its environment rather than between an implementation and another component. We have that concept already in the form of Property (contract with the environment to instantiate a value) so extending that concept to more complex things would seem natural. This would allow me to change the implementation type for the component without changing the business level services that it connects to. I can swap the implementation from one that uses JPA to one that uses JDO or JDBC or XML or C++ with ODBC without removing/adding other components to my assembly. Being of the "cake and eating it camp" I think we should do both: * provide that can be used to define a component with an EntityManager service interface * support properties with a type of "EntityManager" that can be injected to a component I like most types of cake too but I think we should really have one way of doing this. I've vacillated in the past on whether things such as DataSources, EntityManagers, etc. are modeled as services in an *application* assembly or are contracts a particular implementation may have with the container, i.e. a property. I believe they are the second. My understanding of DAS on the other hand is that it models data services which should be represented as services in an application assembly. So, if someone wants to model data access as a service then they should use DAS (which could, as an implementation strategy, use JPA or DAS for SQL data). Using lower-level technologies such as JPA, JDBC, etc. to me are really about solving different use cases. For example, the EntityManager API does not represent an "application service contract"; it is a low-level technology one (I don't like the term "business service contract" but it can be used instead of "application service contract"). This could apply to a host of things as mentioned below by Jeremy, including WorkManagers, JDO, etc. I view this as analogous to newing up java.io.File in an implementation: importing java.io.File is part of the implementation's contract with the container (JVM, the SCA runtime making java.io available) but it is not a "service" in the sense of "PriceEngine". In our case, instead of newing up EntityManager, we are using an annotation so that the container may choose an instance to inject. The fact that Tuscany uses SCA "services" and assembly to constitute the runtime is opaque to the application. Tuscany could have chosen a different implementation strategy, for example using PicoContainer, Spring, or Java "new", etc., but the application does not need this knowledge. I believe it is important to maintain this divide and that we do not cross namespaces. In other words, it should not be possible to address a system service *directly* from an application implementation. Jim The same would go for other similar things such as SDO Helpers, JDO PersistenceManagers, ... -- Jeremy On Oct 3, 2006, at 9:29 AM, scabooz wrote: H...a service modeled as a property is what seems odd. I'm trying to keep an open mind. Imagine drawing a picture of this using the icons from the SCA spec. You'd have some kind of a connection from a component's property to a database? That's what doesn't make sense. I need to think more on this, and maybe I'll change my mind. Didn't want to let this thread just die. Dave - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Tuesday, October 03, 2006 11:40 AM Subject: Re: EJB3 (JPA) support On Oct 3, 2006, at 7:44 AM, scabooz wrote: Hi Jim, Somewhere buried in your explanation is the answer to my question, but I can't find it, so I'll have to ask. I'm trying to understand how you have modeled this WRT the assembly model. It looks like you've added in a SCDL extension, and are playing with the semantics of a property. I would have expected such a formal part of the applicatio
[jira] Created: (TUSCANY-779) Update to new Apache Licence text
Update to new Apache Licence text - Key: TUSCANY-779 URL: http://issues.apache.org/jira/browse/TUSCANY-779 Project: Tuscany Issue Type: New Feature Components: C++ SCA, C++ SDO Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Text in all src files to be updated to the new Apache wording -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-613) Move to 0.95 spec Assembly model
[ http://issues.apache.org/jira/browse/TUSCANY-613?page=all ] Pete Robbins closed TUSCANY-613. Resolution: Fixed > Move to 0.95 spec Assembly model > > > Key: TUSCANY-613 > URL: http://issues.apache.org/jira/browse/TUSCANY-613 > Project: Tuscany > Issue Type: New Feature > Components: C++ SCA >Affects Versions: Cpp-current >Reporter: Pete Robbins > Assigned To: Pete Robbins > Fix For: Cpp-current > > Attachments: TUSCANY-613-2.patch, TUSCANY-613.patch > > > To cover work for composites etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
binding.ejb and binding.jms support in Tuscany
Hi, I am interested in giving SCA components access to EJB components; stateless, stateful, and message driven. I've read the white paper that talks about accessing EJB 2.1 stateless session beans. Is anyone working on EJB support for Tuscany? Thanks. Seth
Re: Modeling persistence services, was Re: EJB3 (JPA) support
I see wires in the assembly as representing the interaction between application components. Properties on the other hand represent a contract between the application component and the container (by which I mean the container is responsible for configuring an instance of the application component with the value of that property). One way to represent an EntityManager would be to add a component to the system that exposed that as a service. You could then wire components to it as normal. That does seem a little odd to me in that you would probably need a custom implementation type for such a component that allowed you to specify the EntityManagerFactory configuration. It also seems odd to be using EntityManager as a service interface (valid, but odd). Less odd to me is the idea of things (like EntityManager) that are services provided by the runtime environment where a component is running. They are part of a contract between an implementation and its environment rather than between an implementation and another component. We have that concept already in the form of Property (contract with the environment to instantiate a value) so extending that concept to more complex things would seem natural. This would allow me to change the implementation type for the component without changing the business level services that it connects to. I can swap the implementation from one that uses JPA to one that uses JDO or JDBC or XML or C++ with ODBC without removing/ adding other components to my assembly. Being of the "cake and eating it camp" I think we should do both: * provide that can be used to define a component with an EntityManager service interface * support properties with a type of "EntityManager" that can be injected to a component The same would go for other similar things such as SDO Helpers, JDO PersistenceManagers, ... -- Jeremy On Oct 3, 2006, at 9:29 AM, scabooz wrote: H...a service modeled as a property is what seems odd. I'm trying to keep an open mind. Imagine drawing a picture of this using the icons from the SCA spec. You'd have some kind of a connection from a component's property to a database? That's what doesn't make sense. I need to think more on this, and maybe I'll change my mind. Didn't want to let this thread just die. Dave - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Tuesday, October 03, 2006 11:40 AM Subject: Re: EJB3 (JPA) support On Oct 3, 2006, at 7:44 AM, scabooz wrote: Hi Jim, Somewhere buried in your explanation is the answer to my question, but I can't find it, so I'll have to ask. I'm trying to understand how you have modeled this WRT the assembly model. It looks like you've added in a SCDL extension, and are playing with the semantics of a property. I would have expected such a formal part of the application to have been modeled in a formal way, such as with an SCA component. It's a property (or "resource") just like a datasource or type system helper (e.g. SDO) would be. Modeling it as a service on a component seems kind of odd. There's a system service responsible for providing a value for the property (just like all property values in Tuscany) but that's an implementation detail. Make sense? Am I understanding this correctly? I'm asking from a spec perspective, trying to make sure that we're clean. Dave - 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-778) DAS Website content updates - Need to add steps to Build and Run samples and unit tests
[ http://issues.apache.org/jira/browse/TUSCANY-778?page=all ] Luciano Resende updated TUSCANY-778: Attachment: tuscany-778.lresende.20061003.txt Addes intructions on how to build and run samples and unit tests. > DAS Website content updates - Need to add steps to Build and Run samples and > unit tests > --- > > Key: TUSCANY-778 > URL: http://issues.apache.org/jira/browse/TUSCANY-778 > Project: Tuscany > Issue Type: Improvement > Components: Website >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany-778.lresende.20061003.txt > > > Tuscany DAS website need instructions on how to build and run sample apps, as > well on how to run unit tests -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-778) DAS Website content updates - Need to add steps to Build and Run samples and unit tests
DAS Website content updates - Need to add steps to Build and Run samples and unit tests --- Key: TUSCANY-778 URL: http://issues.apache.org/jira/browse/TUSCANY-778 Project: Tuscany Issue Type: Improvement Components: Website Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Fix For: Java-M2 Tuscany DAS website need instructions on how to build and run sample apps, as well on how to run unit tests -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modeling persistence services, was Re: EJB3 (JPA) support
For JPA/Hibernate support I like the idea of extending code gen such that static SDOs could be anotated for persistence using JPA. From my perspective this would do a better job of maintaining seperation of application logic, serivces and the data model. thoughts . . . ? Robbie On 10/3/06, scabooz <[EMAIL PROTECTED]> wrote: H...a service modeled as a property is what seems odd. I'm trying to keep an open mind. Imagine drawing a picture of this using the icons from the SCA spec. You'd have some kind of a connection from a component's property to a database? That's what doesn't make sense. I need to think more on this, and maybe I'll change my mind. Didn't want to let this thread just die. Dave - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Tuesday, October 03, 2006 11:40 AM Subject: Re: EJB3 (JPA) support > > On Oct 3, 2006, at 7:44 AM, scabooz wrote: > >> Hi Jim, >> >> Somewhere buried in your explanation is the answer to >> my question, but I can't find it, so I'll have to ask. I'm >> trying to understand how you have modeled this WRT >> the assembly model. It looks like you've added in a >> SCDL extension, and are playing with the semantics >> of a property. I would have expected such a formal >> part of the application to have been modeled in a >> formal way, such as with an SCA component. > It's a property (or "resource") just like a datasource or type system > helper (e.g. SDO) would be. Modeling it as a service on a component > seems kind of odd. There's a system service responsible for providing > a value for the property (just like all property values in Tuscany) > but that's an implementation detail. Make sense? >> Am I >> understanding this correctly? I'm asking from a spec >> perspective, trying to make sure that we're clean. >> >> Dave >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
[jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions
[ http://issues.apache.org/jira/browse/TUSCANY-773?page=comments#action_12439633 ] Jim Marino commented on TUSCANY-773: I noticed the spec files changed. Venkat, could you explain why this is necessary as I don't think we should be adding any Tuscany extensions into the osoa namespace. Jim > Fix Property Value Loading from Component Definitions > - > > Key: TUSCANY-773 > URL: http://issues.apache.org/jira/browse/TUSCANY-773 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: Venkatakrishnan > Attachments: rfeng.patch, Tuscany-kernel-core-02-Oct.diff, > Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel-core-03-Oct.diff, > Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany-spec-sca-02-Oct.diff, > Tuscany-spec-sca-03-Oct.diff > > > Currently property loading for application components does not work. There > is NPE exception thrown when creating a property instance factory based on > the property value defined in the Component Defn. > Also the property loading works only for simply types whose values can be > represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release parent pom and buildtools for M2
+1 from me. Jim On Oct 2, 2006, at 8:28 AM, Jeremy Boynes wrote: The parent pom and buildtools are pre-reqs for all other Java projects in the M2 release. These are distributed through the maven repo rather than as a end-user distribution. Please vote to approve the release content: parent-pom [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java-pom-parent/1 [binary] http://people.apache.org/repo/m2-incubating-repository/org/ apache/tuscany/parent/1-incubator/ buildtools [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/ java-buildtools/1.0-incubator-M2 [binary] http://people.apache.org/repo/m2-incubating-repository/org/ apache/tuscany/buildtools/1.0-incubator-M2/ Here's my +1 -- Jeremy - 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-773) Fix Property Value Loading from Component Definitions
[ http://issues.apache.org/jira/browse/TUSCANY-773?page=all ]
Venkatakrishnan updated TUSCANY-773:
Attachment: Tuscany-sca-kernel-core-03-Oct.diff
Tuscany-sca-kernel-spi-03-Oct.diff
Tuscany-spec-sca-03-Oct.diff
Hi Raymond,
I have now included the missing file. I pulled down the latest revision and
have created these patchs over it.
I have tested for the following component defn. I created a simple Java Bean
called HelloSayer that has two string fields - firstName and lastName. Then I
added this as a field in the component implementation and exposed it as a
property (with annotations). And then here in this comp. defn. i configure
those properties.
Hullow
Tuscany
World
HelloSayer.java
--
public class HelloSayer {
public String firstName = "";
public String lastName = "";
}
HelloWorldServiceImpl.java
-
public class HelloWorldServiceImpl implements HelloWorldService {
@Property
public String greeting = "Default hello";
@Property
public HelloSayer helloSayer = new HelloSayer();
public String sayHello(String s) {
return greeting + " " + s + " from " + helloSayer.firstName + " " +
helloSayer.lastName;
}
}
*) to the question on support for xpath thro the 'source' attribute, I would
prefer to get into this after we have containers (javascript, ruby and maybe
even groovy) work for properties that are specified as xml within the comp.
defn. itself. Just want to have the basic functionality working across
containers. I see that 'source' will not be stop show since the user will
still be able to get a feel of property config. for components. Is my view
right here ?
*) As for the 'databinding', well I am really interested in getting that
onboard for this with your help :). Right now the xml document is transformed
to a java object using reflection. Do we have a databinding transformer that
does this more and in more scalable way? And if so how do we fit it here -
mean the programming model to be used to exploit the databinding facility.
This is going to be something we may need across containers albiet in different
forms.
Thanks
- Venkat
> Fix Property Value Loading from Component Definitions
> -
>
> Key: TUSCANY-773
> URL: http://issues.apache.org/jira/browse/TUSCANY-773
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core
>Affects Versions: Java-M2
>Reporter: Venkatakrishnan
> Attachments: rfeng.patch, Tuscany-kernel-core-02-Oct.diff,
> Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel-core-03-Oct.diff,
> Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany-spec-sca-02-Oct.diff,
> Tuscany-spec-sca-03-Oct.diff
>
>
> Currently property loading for application components does not work. There
> is NPE exception thrown when creating a property instance factory based on
> the property value defined in the Component Defn.
> Also the property loading works only for simply types whose values can be
> represented as a simple xml text content.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Transcript of IRC chat on C++ M2 release
Hi all, We just had a good IRC chat about the forthcoming Tuscany C++ M2 release. Main things decided: - We will try to get Release Candidate 1 out by end of this week/early next - Items in RC1 have been decided & volunteered for, the list will be available at http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks (when I've done it) Transcript below. Cheers! Andy 18:00:29tick tock ... it's 18:00 BST 18:00:35Hi all - my clock says it's 18:00 - good to go? 18:00:43Pete beat me to it 18:01:02I live slightly further east than you ;-) 18:01:03hey 18:01:27Are you going to run this Andy? 18:01:41Yep, I'm happy to run this 18:01:49OK, so we've put a list of items up on the wiki 18:02:03http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks 18:02:34and there's a lot there, I expect quite a few things won't make it if we want to get a first RC out by the end of this week 18:02:57So, the first question is - is an RC by the end of the week a good idea? 18:03:15Any items that really should go in & will take more than a week? 18:03:47The first RC does not have to be perfect and I'd like to see us have the infrastructure to make the release in place 18:04:14so we know we can turn the handle and create a RC 18:04:16yes, I guess the first RC is there to allow us to polish the build infra 18:04:22Yep sounds good - do you think the infrastructure can be updated by the end of the week? 18:04:46that means getting the licence stuff correct and a working build and package on linux and windows 18:05:05yes I think it's doable 18:05:08Yep - doesn't look too bad 18:05:37-->|slaws ([EMAIL PROTECTED]/ibm/x-4d3c867d81249199) has joined #tuscany 18:05:52what do we need to do to the Linux build? is it good as of today? 18:05:56so I'm currently updating the licence info so mark that one down to me 18:06:30The linux build is ok but we need to make sure that make dist works 18:06:40I think te linux build is mostly good - not sure what the script that packages bin and src distros is good 18:06:59and that the resulting distro contains all the right stuff to enable ./configure, make in the samples 18:07:13That took some work for M1 18:07:20ah ok, I can help test the linux build if it helps 18:07:45great - thanks 18:08:19Should we go through the list to decide if items should be in or out? 18:08:24Windows is built via a bat which basically runs the vc6 compile followed by copying/zipping 18:08:54are we building with vc6, 7 or 8 for this release? 18:09:04ok. How up-to-date are the vc7 files? 18:09:11sorry vc6 18:09:33I think we still have an issue with vc8 18:09:46I vote we stay with vc6 for this releas 18:09:58I know vc7 is good, but I don't have a vc6 system 18:10:17VC6 projects don't work at all at the moment but are easily fixable 18:10:21which version of vc7? 18:10:28Pete - could you do vc6 things for the release? 18:10:35it;s the generating of the batch makefiles which makes vc6 attractive 18:10:36I think mine is vc7.1 18:10:39-->|jmarino ([EMAIL PROTECTED]) has joined #tuscany 18:10:45Pete - agreed 18:10:54I suggest we stick to one, and maybe even take out the other versions, it's a little confusing to have multiple versions of the project files, some up to date, some outdated 18:10:56it's nice to have a command line build 18:10:59if pete can generate the make can we use them? 18:11:19Yep, vc6 make worked with vc7 last time 18:11:27-->|gwinn ([EMAIL PROTECTED]) has joined #tuscany 18:11:33k - sounds like a plan 18:11:38I will fix up VC6 and generate the makefiles... and oh well I may as well do the distro packagingtoo 18:11:47:) cool 18:12:12ok, I'll try to get a VC6 install on my machine, I only have vc8 now 18:12:36so we are using VC6 for this release right? 18:12:38well you should be able to run the command line with your VC7 I think 18:12:53jsdelfino - it would be good to try the command line build with vc8 18:13:09+1 for vc6 build only 18:13:17I mainly use VC 7 so I can test that if no one else does. 18:13:25vc8 doesn't work at all for now, SDOs don't run, throwing an incompatible list exception 18:13:28ok. I'll post on dev when I have a working VC6 and generated make 18:13:41great 18:13:56I'll try to get a VC6 install 18:14:04So what samples will we include in the distro? 18:14:05So the other things we should work on this week are docs and samples 18:14:14still quicker than me :) 18:14:17jsdelfino ... I don;t think you need VC6 18:14:57samples- Calculator, PythonCalculator, RubyCalculator, BigBank are all good at the moment 18:15:06not sure about SupplyChain 18:15:24I think that's good. Let's leave SupplyChain out for now 18:15:50RubyBank? jsdelfino - do you know the status of that one? 18:15:58How are we going to package the "optional" language extensions - Ruby, Pyhton 18:15:58yes, it's working 18:16:18can we add a simple HelloWorld? what do you think? 18:16:35Calulator is our HelloWorld 18:16:49I think Calculator is simple enough 18:17:00okay :) that's fine too 18:17:10I don't think we should add anything else until we get wha
Re: [jira] Updated: (TUSCANY-775) Web deployment broken
So a major dis-connect here is that the currently checked in spring samples (which Andy was working off) were never migrated to use the tuscany WAR plugin -- it still uses the standard maven war packaging and manually includes a bunch of jars etc. I've taken Andy's patch and started doing the migration to the tuscany war plugin, including moving/keeping the extension directory in WEB-INF. Seem right? On 10/3/06, Andy Piper <[EMAIL PROTECTED]> wrote: Hi Jeremy At 14:35 03/10/2006, Jeremy Boynes wrote: >There seem to be a few changes mixed in here. All necessary to fix things :) >The extension directory moves from /WEB-INF to /META-INF and that >seems like an odd place to me. Is this what the plugin is doing? Well it used to be META-INF from the looks of things. But I don't particularly mind _as long as its consistent_ - these paths keeps getting changed without examples getting fixed. >Registering the RuntimeInfo and WebappRuntimeInfo separately to work >around an autowire issue seems hacky - I thought autowire had been >fixed ages ago to support matching by assignablity rather than an >exact match; if not, it should. I agree, but this _used to work_ and now it does not. I'm afraid I don't have the cycles to keep tracking down problems that others have introduced, I have already spent all day just getting this far. >What do getInstallDirectory() and getApplicationRootDirecotry() do in >a webapp environment that may not have any directories at all? The spring impl relies on these right now. Yes its a hack, but not my hack, its been there a while and I need something actually working. We can clean things up, but please lets get this working again. The webapp stuff really needs an end-to-end test to keep it clean. >getScdlUrl() is looking up absolute paths in the classloader _ does >that work? I thought classloaders needed paths that do not begin with >'/' The docs say otherwise and it certainly works for me. Without this you have to install webapp.scdl in the app which is tacky. andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-773) Fix Property Value Loading from Component Definitions
Hi, You should be able to apply the patch using either "svn" command or TortoiseSVN if you're on Windows. Thanks, Raymond - Original Message - From: "Raymond Feng (JIRA)" To: Sent: Monday, October 02, 2006 6:21 PM Subject: [jira] Updated: (TUSCANY-773) Fix Property Value Loading from Component Definitions [ http://issues.apache.org/jira/browse/TUSCANY-773?page=all ] Raymond Feng updated TUSCANY-773: - Attachment: rfeng.patch Hi, Venkata. I made some changes on top of your patch. I have attached the new one here. BTW, one class is missing in your path: JavaPropertyFactory. Can you add it? I'm also expecting more feautures such as XPath resolution against the "source" and DataBinding integration for the injection. Any plan? Thanks, Raymond Fix Property Value Loading from Component Definitions - Key: TUSCANY-773 URL: http://issues.apache.org/jira/browse/TUSCANY-773 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Venkatakrishnan Attachments: rfeng.patch, Tuscany-kernel-core-02-Oct.diff, Tuscany-kernel-spi-02-Oct.diff, Tuscany-spec-sca-02-Oct.diff Currently property loading for application components does not work. There is NPE exception thrown when creating a property instance factory based on the property value defined in the Component Defn. Also the property loading works only for simply types whose values can be represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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: maven expertise required for samples inclusion
With lucianos help I have fixed this problem. I've captured the solution in rough on the wiki, hbut will append here for reference. I also added a manifest entry to the samples jar that allows the top level sample to be run using "java -jar .jar" ... see below src/main/java src/main/java src/main/resources org.apache.maven.plugins maven-jar-plugin org.apache.tuscany.samples.sdo.ExecuteSamples On 03/10/06, kelvin goodson <[EMAIL PROTECTED]> wrote: I just sent this posting to the maven user list, but we may have the expertise to answer it in house. Can anyone help please? Hello, I'm new to configuring maven, and I am trying to create a release for a project. The project includes a number of modules, one of which contains sample source code. I would like my distribution to contain the source and binary artifacts for the samples. I have discovered the maven-source-plugin and have been able to run mvn source:jar against the project, which creates a jar of source for me. How do I get the overall project build to package both the source and the compiled artifacts. Am I heading in the right direction here? Is there a specific project archetype for a samples project? Regards, Kelvin.
Modeling persistence services, was Re: EJB3 (JPA) support
H...a service modeled as a property is what seems odd. I'm trying to keep an open mind. Imagine drawing a picture of this using the icons from the SCA spec. You'd have some kind of a connection from a component's property to a database? That's what doesn't make sense. I need to think more on this, and maybe I'll change my mind. Didn't want to let this thread just die. Dave - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Tuesday, October 03, 2006 11:40 AM Subject: Re: EJB3 (JPA) support On Oct 3, 2006, at 7:44 AM, scabooz wrote: Hi Jim, Somewhere buried in your explanation is the answer to my question, but I can't find it, so I'll have to ask. I'm trying to understand how you have modeled this WRT the assembly model. It looks like you've added in a SCDL extension, and are playing with the semantics of a property. I would have expected such a formal part of the application to have been modeled in a formal way, such as with an SCA component. It's a property (or "resource") just like a datasource or type system helper (e.g. SDO) would be. Modeling it as a service on a component seems kind of odd. There's a system service responsible for providing a value for the property (just like all property values in Tuscany) but that's an implementation detail. Make sense? Am I understanding this correctly? I'm asking from a spec perspective, trying to make sure that we're clean. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-777) HTTPSessionScope needs to be made a listener to HTTPStart and HTTPStop events.
[ http://issues.apache.org/jira/browse/TUSCANY-777?page=comments#action_12439553 ] Rick Rineholt commented on TUSCANY-777: --- Trying to figure out where to best do this. Haven't had any luck as of yet. > HTTPSessionScope needs to be made a listener to HTTPStart and HTTPStop > events. > --- > > Key: TUSCANY-777 > URL: http://issues.apache.org/jira/browse/TUSCANY-777 > Project: Tuscany > Issue Type: Bug > Components: Java BigBank Scenario, Java SCA Tomcat Integration >Affects Versions: Java-M2 >Reporter: Rick Rineholt >Priority: Blocker > Fix For: Java-M2 > > > The HTTPSessionScopeContainer while created is not registering as a listener > for HTTPSessionStart and End events generated by TuscanySessionListener. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-777) HTTPSessionScope needs to be made a listener to HTTPStart and HTTPStop events.
HTTPSessionScope needs to be made a listener to HTTPStart and HTTPStop events. --- Key: TUSCANY-777 URL: http://issues.apache.org/jira/browse/TUSCANY-777 Project: Tuscany Issue Type: Bug Components: Java BigBank Scenario, Java SCA Tomcat Integration Affects Versions: Java-M2 Reporter: Rick Rineholt Priority: Blocker Fix For: Java-M2 The HTTPSessionScopeContainer while created is not registering as a listener for HTTPSessionStart and End events generated by TuscanySessionListener. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB3 (JPA) support
On Oct 3, 2006, at 7:44 AM, scabooz wrote: Hi Jim, Somewhere buried in your explanation is the answer to my question, but I can't find it, so I'll have to ask. I'm trying to understand how you have modeled this WRT the assembly model. It looks like you've added in a SCDL extension, and are playing with the semantics of a property. I would have expected such a formal part of the application to have been modeled in a formal way, such as with an SCA component. It's a property (or "resource") just like a datasource or type system helper (e.g. SDO) would be. Modeling it as a service on a component seems kind of odd. There's a system service responsible for providing a value for the property (just like all property values in Tuscany) but that's an implementation detail. Make sense? Am I understanding this correctly? I'm asking from a spec perspective, trying to make sure that we're clean. Dave - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Tuesday, October 03, 2006 4:00 AM Subject: Re: EJB3 (JPA) support Hi Meeraj, I checked in some minor changes to the JPA extension. I was thinking things would work along the following lines: - An application developer could specify a JPA persistence context in their assembly using an . - JPAImportLoader would process and resolve JPA artifacts (persistence.xml, mapping files, etc.). It may need the composite classloader to do this or come up with a better mechanism (I'm too tired to really think about it now). JPAImportLoader would also create an model of a JPA system service which would be used by constructed by JPAComponentBuilder to create a JPAAtomicComponent. The builder would register this system service in the parent (application composite) tree. - There would be an EntityManagerProcessor registered in the *runtime* (as opposed to the application) system tree. When a user component marked with @PersistenceContext is encountered, EntityManagerProcessor would create a property and populate the component type. the property would have a EntityManagerObjectFactory which is responsible for injecting entity managers on the implementation instance. EntityManagerProcessor would call resolveSystemInstance() on the parent application composite and get the EMF, passing it to an EntityManagerObjectFactory. The latter would then be set as the default object factory on the property. - When the user component is instantiated, the EntityManagerObjectFactory will call to the EMF and create an EntityManager. I started skeleton work to support this but most of the hard stuff is missing. For example, I believe we are going to need to figure out dependency classloading as both the runtime system EntityManagerProcessor and application components need access to JPA classes. I probably haven't explained this very well, but maybe you could take a look at the skeletal code and we could go from there? I definitely think we should draw inspiration from what Spring did in terms of integration. For example, we will probably need to figure out how to support persistence contexts that span more than a transaction. Once we get a basic working extension, we may want to look at plugging this into a transaction manager, which we'll need for policy support. Jim On Oct 2, 2006, at 11:51 PM, Meeraj Kunnumpurath wrote: I will take a look Jim and try to assist, I have been doing a bit recently at work with Hibernate JPA and the Spring 2.0 JPA support. May be we can draw some inspiration from Spring 2.0 as well. Ta -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 03 October 2006 07:46 To: tuscany-dev@ws.apache.org Subject: Re: EJB3 (JPA) support Yep. I'm working on some minor things to the JPA extension now and I should have them checked in soon (hour or so). I'm still figuring out how this stuff is going to work (I'm more familiar with the Hibernate API than JPA) but perhaps when I do the check in I can send another note describing the changes and you can have a look to see if it makes sense, and maybe take it forward a bit? I think the Hibernate API one should work similarly. Jim On Oct 2, 2006, at 11:36 PM, Meeraj Kunnumpurath wrote: Do you mean the Hibernate session API without using the entity manager? -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 02 October 2006 20:30 To: tuscany-dev@ws.apache.org Subject: Re: EJB3 (JPA) support On Oct 2, 2006, at 11:35 AM, Meeraj Kunnumpurath wrote: Jim, From your reply, I think the key is injecting in a persistence unit. Hibernate has an EJB 3.0 implementation (both the OR annotations and the entity manager). This will work pretty much the same as open JPA (or any closed JPA :-), sorry couldn't resist it) Yes I think we want to have a generic integration if possible so we can use ClosedJPA too ;-) There may be some customi
maven expertise required for samples inclusion
I just sent this posting to the maven user list, but we may have the expertise to answer it in house. Can anyone help please? Hello, I'm new to configuring maven, and I am trying to create a release for a project. The project includes a number of modules, one of which contains sample source code. I would like my distribution to contain the source and binary artifacts for the samples. I have discovered the maven-source-plugin and have been able to run mvn source:jar against the project, which creates a jar of source for me. How do I get the overall project build to package both the source and the compiled artifacts. Am I heading in the right direction here? Is there a specific project archetype for a samples project? Regards, Kelvin.
[jira] Closed: (TUSCANY-715) Update tools module to use latest XmlSchema version
[ http://issues.apache.org/jira/browse/TUSCANY-715?page=all ] ant elder closed TUSCANY-715. - Resolution: Fixed > Update tools module to use latest XmlSchema version > --- > > Key: TUSCANY-715 > URL: http://issues.apache.org/jira/browse/TUSCANY-715 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Reporter: Jeremy Boynes > Assigned To: ant elder >Priority: Critical > Attachments: Tuscany-SCA-Tools-Patch-Sept-12.diff, > Tuscany-sca-tools-update-Sept-19.diff, Tuscany-sca-tools-update-Sept-20.diff > > > The API for XmlSchema has changed since the 1.0.2 version. We are using a > newer version due to updates in Axis2 and the tools need to be modified to > use its new API. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB3 (JPA) support
Jim, Pls see my comments below. Ta Meeraj >> -Original Message- >> From: Jim Marino [mailto:[EMAIL PROTECTED] >> Sent: 03 October 2006 09:00 >> To: tuscany-dev@ws.apache.org >> Subject: Re: EJB3 (JPA) support >> >> Hi Meeraj, >> >> I checked in some minor changes to the JPA extension. I was >> thinking things would work along the following lines: >> >> - An application developer could specify a JPA persistence >> context in their assembly using an . Does the name attribute specifies the name of the persistence unit? >> >> - JPAImportLoader would process and resolve JPA >> artifacts (persistence.xml, mapping files, etc.). It may >> need the composite classloader to do this or come up with a >> better mechanism (I'm too tired to really think about it >> now). JPAImportLoader would >> also create an model of a JPA system service which would be >> used by >> constructed by JPAComponentBuilder to create a JPAAtomicComponent. >> The builder would register this system service in the parent >> (application composite) tree. >> >> - There would be an EntityManagerProcessor registered in the >> *runtime* (as opposed to the application) system tree. When >> a user component marked with @PersistenceContext is >> encountered, EntityManagerProcessor would create a property >> and populate the component type. the property would have a >> EntityManagerObjectFactory which is responsible for >> injecting entity managers on the implementation instance. >> EntityManagerProcessor would call >> resolveSystemInstance() on the parent application composite >> and get the EMF, passing it to an >> EntityManagerObjectFactory. The latter would then be set as >> the default object factory on the property. This is quite similar to how Spring does this. In Spring you can have any managed bean with instance variables of type EntityManagerFactory with the annotation @PersistenceUnit(unitName = "accountModule"). The annotation processor will scan all the persistence XML files for the specified persistence unit name and inject an entity mnager factory that will create the required entity manager. >> >> - When the user component is instantiated, the >> EntityManagerObjectFactory will call to the EMF and create >> an EntityManager. >> >> I started skeleton work to support this but most of the hard >> stuff is missing. For example, I believe we are going to >> need to figure out dependency classloading as both the >> runtime system EntityManagerProcessor and application >> components need access to JPA classes. I probably haven't >> explained this very well, but maybe you could take a look at >> the skeletal code and we could go from there? I have done an svn up and building, I should be able to come back to you by tonight (hopefully :-)) >> >> I definitely think we should draw inspiration from what >> Spring did in terms of integration. For example, we will >> probably need to figure out how to support persistence >> contexts that span more than a transaction. Once we get a >> basic working extension, we may want to look at plugging >> this into a transaction manager, which we'll need for policy support. We can specify the transaction mode (for eg, resource local or JTA) within the persistence XML. JTA would assume a transaction manager is available for lookup (jta-datasource-name property). However, lot of these things should be the concerns of the JPA implementation. >> >> Jim >> >> >> On Oct 2, 2006, at 11:51 PM, Meeraj Kunnumpurath wrote: >> >> > I will take a look Jim and try to assist, I have been doing a bit >> > recently at work with Hibernate JPA and the Spring 2.0 JPA support. >> > May >> > be we can draw some inspiration from Spring 2.0 as well. >> > >> > Ta >> > >> > -Original Message- >> > From: Jim Marino [mailto:[EMAIL PROTECTED] >> > Sent: 03 October 2006 07:46 >> > To: tuscany-dev@ws.apache.org >> > Subject: Re: EJB3 (JPA) support >> > >> > Yep. I'm working on some minor things to the JPA extension >> now and I >> > should have them checked in soon (hour or so). I'm still >> figuring out >> > how this stuff is going to work (I'm more familiar with >> the Hibernate >> > API than JPA) but perhaps when I do the check in I can >> send another >> > note describing the changes and you can have a look to see >> if it makes >> > sense, and maybe take it forward a bit? I think the >> Hibernate API one >> > should work similarly. >> > >> > Jim >> > >> > On Oct 2, 2006, at 11:36 PM, Meeraj Kunnumpurath wrote: >> > >> >> Do you mean the Hibernate session API without using the entity >> >> manager? >> >> >> >> -Original Message- >> >> From: Jim Marino [mailto:[EMAIL PROTECTED] >> >> Sent: 02 October 2006 20:30 >> >> To: tuscany-dev@ws.apache.org >> >> Subject: Re: EJB3 (JPA) support >> >> >> >> >> >> On Oct 2, 2006, at 11:35 AM, Meeraj Kunnumpurath wrote: >> >> >> >>> Jim, >> >>> >> >>> From your reply, I think the key is injecting in a >> persiste
Re: [jira] Updated: (TUSCANY-775) Web deployment broken
On Oct 3, 2006, at 7:55 AM, Jim Marino wrote: On Oct 3, 2006, at 6:35 AM, Jeremy Boynes wrote: There seem to be a few changes mixed in here. The extension directory moves from /WEB-INF to /META-INF and that seems like an odd place to me. Is this what the plugin is doing? Registering the RuntimeInfo and WebappRuntimeInfo separately to work around an autowire issue seems hacky - I thought autowire had been fixed ages ago to support matching by assignablity rather than an exact match; if not, it should. Not yet, and it requires Java interfaces. It's probably time to start making it more query/intent-oriented as well. I'll have a look. Can we baby-step this and just do the assignability bit first? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-767) NPE in CompositeReference.java when service is defined using interface wsdl
Hi Ignacio, I'll have a look once I am caffeinated. Jim On Oct 3, 2006, at 6:19 AM, Ignacio Silva-Lepe (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-767?page=all ] Ignacio Silva-Lepe updated TUSCANY-767: --- Attachment: OperationInvocationHandlersWithTestCase.patch Here's a new patch that also contains a test case. As soon as TUSCAY-768 is resolved I should be able to verify this patch with the inner.composite sample as well. NPE in CompositeReference.java when service is defined using interface wsdl - -- Key: TUSCANY-767 URL: http://issues.apache.org/jira/browse/TUSCANY-767 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Rick Rineholt Assigned To: Jim Marino Priority: Blocker Fix For: Java-M2 Attachments: OperationInvocationHandlers.patch, OperationInvocationHandlersWithTestCase.patch If a service is defined using interface wsdl the service contract does not have an interface class this results in org.apache.tuscany.core.implementation.composite.CompositeReference g etting an NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-565) Windows Debug build of Calculator sample incorrect
[ http://issues.apache.org/jira/browse/TUSCANY-565?page=comments#action_12439528 ] Andrew Borley commented on TUSCANY-565: --- Issues 2 & 3 on VC7 fixed at r452522 > Windows Debug build of Calculator sample incorrect > -- > > Key: TUSCANY-565 > URL: http://issues.apache.org/jira/browse/TUSCANY-565 > Project: Tuscany > Issue Type: Bug > Components: C++ SCA >Affects Versions: Cpp-M1 >Reporter: Pete Robbins > Assigned To: Pete Robbins > Fix For: Cpp-M1 > > > 1. Debug build on VC6 builds Calc.exe instead of Client.exe > 2. deploy.cmd and wsdeploy.cmd copy Release versions of exes > 3. VC7 debug builds Client.exe bu Calc.pdb -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-566) Debug mode deploy and wsdeploy command files need altering
[ http://issues.apache.org/jira/browse/TUSCANY-566?page=comments#action_12439525 ] Andrew Borley commented on TUSCANY-566: --- Verified working on VC7 at r452522 with the wsdeploy.cmd and deploy.cmd as they are. > Debug mode deploy and wsdeploy command files need altering > -- > > Key: TUSCANY-566 > URL: http://issues.apache.org/jira/browse/TUSCANY-566 > Project: Tuscany > Issue Type: Bug > Components: C++ Build, C++ SCA >Reporter: Ed Slattery >Priority: Minor > > The wsdeploy and deploy command files located in the Calculator directory > under samples/ides/devstudio6 and samples/ides/devstudio7 are always copying > the Release dll rather than selecting the Debug or Release based on active > configuration. > This: > set buildMode=Release > if .Debug == %1. ( > set buildMode=Debug > ) > should be this: > set buildMode=Release > if Debug. == %1. ( > set buildMode=Debug > ) > (The dot has moved from before Debug to after). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-775) Web deployment broken
On Oct 3, 2006, at 6:35 AM, Jeremy Boynes wrote: There seem to be a few changes mixed in here. The extension directory moves from /WEB-INF to /META-INF and that seems like an odd place to me. Is this what the plugin is doing? Registering the RuntimeInfo and WebappRuntimeInfo separately to work around an autowire issue seems hacky - I thought autowire had been fixed ages ago to support matching by assignablity rather than an exact match; if not, it should. Not yet, and it requires Java interfaces. It's probably time to start making it more query/intent-oriented as well. I'll have a look. What do getInstallDirectory() and getApplicationRootDirecotry() do in a webapp environment that may not have any directories at all? getScdlUrl() is looking up absolute paths in the classloader _ does that work? I thought classloaders needed paths that do not begin with '/' -- Jeremy On Oct 3, 2006, at 4:25 AM, Andy Piper (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-775?page=all ] Andy Piper updated TUSCANY-775: --- Attachment: web.patch Fixes webapp issues generically and in spring. Web deployment broken - Key: TUSCANY-775 URL: http://issues.apache.org/jira/browse/ TUSCANY-775 Project: Tuscany Issue Type: Bug Components: Java SCA Core, Java SCA Samples Affects Versions: Java-M2 Reporter: Andy Piper Attachments: web.patch Web deployment is broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB3 (JPA) support
Hi Jim, Somewhere buried in your explanation is the answer to my question, but I can't find it, so I'll have to ask. I'm trying to understand how you have modeled this WRT the assembly model. It looks like you've added in a SCDL extension, and are playing with the semantics of a property. I would have expected such a formal part of the application to have been modeled in a formal way, such as with an SCA component. Am I understanding this correctly? I'm asking from a spec perspective, trying to make sure that we're clean. Dave - Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Tuesday, October 03, 2006 4:00 AM Subject: Re: EJB3 (JPA) support Hi Meeraj, I checked in some minor changes to the JPA extension. I was thinking things would work along the following lines: - An application developer could specify a JPA persistence context in their assembly using an . - JPAImportLoader would process and resolve JPA artifacts (persistence.xml, mapping files, etc.). It may need the composite classloader to do this or come up with a better mechanism (I'm too tired to really think about it now). JPAImportLoader would also create an model of a JPA system service which would be used by constructed by JPAComponentBuilder to create a JPAAtomicComponent. The builder would register this system service in the parent (application composite) tree. - There would be an EntityManagerProcessor registered in the *runtime* (as opposed to the application) system tree. When a user component marked with @PersistenceContext is encountered, EntityManagerProcessor would create a property and populate the component type. the property would have a EntityManagerObjectFactory which is responsible for injecting entity managers on the implementation instance. EntityManagerProcessor would call resolveSystemInstance() on the parent application composite and get the EMF, passing it to an EntityManagerObjectFactory. The latter would then be set as the default object factory on the property. - When the user component is instantiated, the EntityManagerObjectFactory will call to the EMF and create an EntityManager. I started skeleton work to support this but most of the hard stuff is missing. For example, I believe we are going to need to figure out dependency classloading as both the runtime system EntityManagerProcessor and application components need access to JPA classes. I probably haven't explained this very well, but maybe you could take a look at the skeletal code and we could go from there? I definitely think we should draw inspiration from what Spring did in terms of integration. For example, we will probably need to figure out how to support persistence contexts that span more than a transaction. Once we get a basic working extension, we may want to look at plugging this into a transaction manager, which we'll need for policy support. Jim On Oct 2, 2006, at 11:51 PM, Meeraj Kunnumpurath wrote: I will take a look Jim and try to assist, I have been doing a bit recently at work with Hibernate JPA and the Spring 2.0 JPA support. May be we can draw some inspiration from Spring 2.0 as well. Ta -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 03 October 2006 07:46 To: tuscany-dev@ws.apache.org Subject: Re: EJB3 (JPA) support Yep. I'm working on some minor things to the JPA extension now and I should have them checked in soon (hour or so). I'm still figuring out how this stuff is going to work (I'm more familiar with the Hibernate API than JPA) but perhaps when I do the check in I can send another note describing the changes and you can have a look to see if it makes sense, and maybe take it forward a bit? I think the Hibernate API one should work similarly. Jim On Oct 2, 2006, at 11:36 PM, Meeraj Kunnumpurath wrote: Do you mean the Hibernate session API without using the entity manager? -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 02 October 2006 20:30 To: tuscany-dev@ws.apache.org Subject: Re: EJB3 (JPA) support On Oct 2, 2006, at 11:35 AM, Meeraj Kunnumpurath wrote: Jim, From your reply, I think the key is injecting in a persistence unit. Hibernate has an EJB 3.0 implementation (both the OR annotations and the entity manager). This will work pretty much the same as open JPA (or any closed JPA :-), sorry couldn't resist it) Yes I think we want to have a generic integration if possible so we can use ClosedJPA too ;-) There may be some customizations we need for particular vendor impls. May be we can have a framework that can support any JPA implementation make the EMF available as a system service. Yes agreed, although we may not want to say "EMF" since that may confuse people with Eclipse Modeling Framework :-) I'd also like to get a Hibernate integration going for people that like that API. Jim Ta Meeraj From: Jim Marino <[EMAIL PR
[jira] Closed: (TUSCANY-693) Add support for properties in Python implementation extension
[ http://issues.apache.org/jira/browse/TUSCANY-693?page=all ] Andrew Borley closed TUSCANY-693. - Fix Version/s: Cpp-current Resolution: Fixed Assignee: Andrew Borley Fixed at r443317 > Add support for properties in Python implementation extension > - > > Key: TUSCANY-693 > URL: http://issues.apache.org/jira/browse/TUSCANY-693 > Project: Tuscany > Issue Type: New Feature > Components: C++ SCA >Affects Versions: Cpp-current >Reporter: Andrew Borley > Assigned To: Andrew Borley > Fix For: Cpp-current > > > Would like to have properties pre-initialised & available for use inside > Python components -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monday OCT 3, 2006 Tuscany regular IRC chat log.
Should have been Oct 2 :-) (can I use not enough caffeine excuse) :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Monday OCT 3, 2006 Tuscany regular IRC chat log.
[11:35] morning all [11:35] morning [11:35] * simonnash has joined #Tuscany [11:35] hello [11:35] I'd like to chat about the M2 release but that's likely to soak up a lot of time [11:35] before doing that, is there anything else others would like to bring up? [11:36] M2 is my main interest at this point [11:38] ok, I'll kick off on where I think we are and I'd like feedback from everyone about what's left to do [11:38] we need to track this on the list but we can share info here easily [11:38] I just posted tags of the parent pom and buildtools that everything depends on [11:39] these are things that the other distros need in place to build [11:39] your post to the list mentioned SDO [11:39] I'd ask everyone to review them and respond to the vote thread [11:39] did you mean SCAas well or just SDO? [11:40] I meant SDO - they will be needed for DAS and SCA as well but I believe SDO is just about ready to go [11:40] ok [11:41] and SDO is a pre-req for DAS and SCA [11:43] kgoodson: is SDO ready to go? [11:44] not quite, sorry, otp, can i get back to you in c. 45 mins [11:44] ok [11:45] I take back the Q anyway - I think we still need to finish legal review [11:45] and we had the issue yesterday of how we were going to package the samples in the distro [11:46] one thing we did yesterday for SDO is move the samples into that tree [11:47] so instead of samples/sdo we now have sdo/sample [11:47] same with the distribution goal [11:48] that means all the sdo stuff is in one source tree (and hence in one source distro) [11:48] which makes tagging it much much easier [11:48] why are we not changing spec/sdo to sdo/spec? [11:48] we thought the spec would be a separate distro [11:48] as we would want to rev our impl separately [11:50] * lresende has joined #tuscany [11:50] is the SDO spec at some standard level such as 2.1 or 2.01? [11:50] 2.0.1 I belive [11:50] or is it between these levels? [11:50] i know Frank had put some things in from 2.1 [11:50] not sure if they impacted spec APIs [11:50] ah, they may have [11:51] I've been wondering about that but its what the sdo folk seem to want to do [11:51] we should check. if it is not a standard level then it is really tied to our impl [11:52] I'd be dubious about releasing a non-standard level [11:52] but then I have JCP scars ;) [11:52] if our impl needs it then we need to release it [11:53] i don't think we should release anything in the commonj namespace that does not conform [11:53] let's find out first if there is an issue [11:53] yeah [11:53] anyone on the chat who can confirm? [11:54] are you thinking we would package the sdo spec separate from the impl? [11:54] separate and as part of [11:54] a user can get it separately [11:55] but they also get it as part of the impl's distro [11:55] ok [11:57] for milestone releases, I think it's fine to only have the impl's distro. would it simplify anything? [11:57] Yes, Frank added some 2.1 methods to TypeHelper in spec/sdo [11:57] is it all of 2.1 or just parts of it? [11:58] and is 2.1 released? [11:58] not yet [11:58] Just parts [11:58] sounds like we have an issue then [12:00] let's take that to the list and move on [12:00] ok? [12:01] lresende: where are we with DAS? [12:01] yes ok to taking that issue to the list [12:03] lresende: where are we with DAS? [12:03] guess lresende is lurking [12:03] ok, where are we with SCA? [12:04] jboynes: i have just sent the mail for RC1 [12:04] i was waitting for a place to post it, and kgoodson helpedme over the weekend and is now available at : [12:04] http://people.apache.org/~kelvingoodson/das_java/RC1 [12:04] Will we need to move samples/das to das/samples? [12:05] "need", no [12:05] * Venkat has joined #tuscany [12:05] not sure if we will need that, for das we have a binary and sample distribution [12:06] you're including the samples in the source distro though [12:07] y [12:07] how do we tag that? [12:07] * isilval_ has joined #tuscany [12:07] not sure :) if taging is the problem, we can move from samples/das to das/samples [12:09] I think it would make it easier to move [12:09] I think it would make it easier if it was moved [12:10] ok, i can work on this [12:10] hi, i'm back now and watching this -- i haven't had a chance to come up with a proposal on samples inclusion yet [12:11] kgoodson: as you have recent experience, did moving the samples under sdo make cutting the branch easier? [12:11] i would have thought there would have been a maven pattern for this [12:11] as to ease, yes, a bit easier [12:11] and moving distro/sdo to sdo/distro helps too [12:12] lresende: should I do the same for das? [12:12] so the only thing now is having to treat spec and implementation separately, but we have gone through that and decided that the split is something that is worthwhile [12:13] (you need a committer to move things around :) ) [12:13] sure :
[jira] Resolved: (TUSCANY-689) Add vc7 build for BB sample
[ http://issues.apache.org/jira/browse/TUSCANY-689?page=all ] Andrew Borley resolved TUSCANY-689. --- Fix Version/s: Cpp-current Resolution: Fixed Fixed in r452485 > Add vc7 build for BB sample > --- > > Key: TUSCANY-689 > URL: http://issues.apache.org/jira/browse/TUSCANY-689 > Project: Tuscany > Issue Type: Bug > Components: C++ Build > Environment: XP MSVC7 2002 >Reporter: Simon Laws >Priority: Minor > Fix For: Cpp-current > > Attachments: bbvc7buildpatch.txt, bbvc7buildpatch.txt, > bbvc7codepatch.txt > > > Add a VC7 build to the samples/ides for Bing Bank > Patch attched. Apply to sca/samples/ides/devstudio7/projects -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Subversion property configuration
On Monday October 02 2006 2:05 am, Pete Robbins wrote: > Dan Kulp wrote a script to set the properties on all the files in a tree. I > haven't gort around to running that yet. I need to fix that script. It adds svn:executable to *.bat which then screws up "tab" completion on unix. Since Windows doesn't need them marked executable, they shouldn't be. I run the script periodically on the CXF code to make sure all the CXF commits have their autoprops setup correctly. If the script changes anything, someone has it setup wrong. I probably should move the script out of tuscany/java/etc and into the apache general commiters area of SVN. Dan > > On 02/10/06, Luciano Resende <[EMAIL PROTECTED]> wrote: > > I recall a discussion about this topic : > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg06338.html > > > > Did we ever made a template configuration available somewhere (e.g Wiki) > > ? > > > > - Luciano > > > > On 10/1/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > A number of text files under sca/samples/ contained Windows eol Ctrl+M > > > characters at the end of all lines (mostly in .composite, > > > .componentType, .wsdl, .py, .php and .rb files). I fixed them and > > > removed all the Ctrl+M characters. > > > > > > I think that these characters are there because some of our Windows > > > development environments may not use the correct Subversion > > > configuration. We need to tell Subversion how to handle file types in > > > the Subversion config file. Add this to $HOME/.subversion/config for > > > example: > > > > > > *.py = svn:eol-style=native;svn:keywords=Rev Date > > > > > > This tells Subversion to use the native eol style for Python files and > > > also support the Rev and Date Subversion keywords in these files. > > > > > > I checked in my Subversion config file, containing the correct > > > configuration for all the file types I've found under our source tree, > > > in cpp/etc/svn-config. Could you guys please take a look and make sure > > > your Subversion configuration includes these file types? Also if you > > > see other file types that need to be handled please fill free to add > > > them, this way people who come on board the project will be able to > > > pick up the correct Subversion configuration from there... > > > > > > Thanks! > > > > > > -- > > > Jean-Sebastien > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] -- Daniel Kulp [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] BigBank sample updated
Hi, I've updated the BigBank sample today to get it working on windows based on the new directory and deployment structure. One thing I had to do to get it all working was change all the component interfaces from using char* strings to std::string, as the changes to the binding.ws service and reference stuff that went in for r449433 means that using char* strings causes a crash. Was this the desired effect of the change? Do we want users to only use std::string in their component interfaces? Is there a way to accomodate both std::string and char*? Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-775) Web deployment broken
Hi Jeremy At 14:35 03/10/2006, Jeremy Boynes wrote: There seem to be a few changes mixed in here. All necessary to fix things :) The extension directory moves from /WEB-INF to /META-INF and that seems like an odd place to me. Is this what the plugin is doing? Well it used to be META-INF from the looks of things. But I don't particularly mind _as long as its consistent_ - these paths keeps getting changed without examples getting fixed. Registering the RuntimeInfo and WebappRuntimeInfo separately to work around an autowire issue seems hacky - I thought autowire had been fixed ages ago to support matching by assignablity rather than an exact match; if not, it should. I agree, but this _used to work_ and now it does not. I'm afraid I don't have the cycles to keep tracking down problems that others have introduced, I have already spent all day just getting this far. What do getInstallDirectory() and getApplicationRootDirecotry() do in a webapp environment that may not have any directories at all? The spring impl relies on these right now. Yes its a hack, but not my hack, its been there a while and I need something actually working. We can clean things up, but please lets get this working again. The webapp stuff really needs an end-to-end test to keep it clean. getScdlUrl() is looking up absolute paths in the classloader _ does that work? I thought classloaders needed paths that do not begin with '/' The docs say otherwise and it certainly works for me. Without this you have to install webapp.scdl in the app which is tacky. andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Updated: (TUSCANY-775) Web deployment broken
AFAIK, the plugin is still writing the extensions to WEB-INF/tuscany/extensions directory. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 03 October 2006 14:35 To: tuscany-dev@ws.apache.org Subject: Re: [jira] Updated: (TUSCANY-775) Web deployment broken There seem to be a few changes mixed in here. The extension directory moves from /WEB-INF to /META-INF and that seems like an odd place to me. Is this what the plugin is doing? Registering the RuntimeInfo and WebappRuntimeInfo separately to work around an autowire issue seems hacky - I thought autowire had been fixed ages ago to support matching by assignablity rather than an exact match; if not, it should. What do getInstallDirectory() and getApplicationRootDirecotry() do in a webapp environment that may not have any directories at all? getScdlUrl() is looking up absolute paths in the classloader _ does that work? I thought classloaders needed paths that do not begin with '/' -- Jeremy On Oct 3, 2006, at 4:25 AM, Andy Piper (JIRA) wrote: > [ http://issues.apache.org/jira/browse/TUSCANY-775?page=all ] > > Andy Piper updated TUSCANY-775: > --- > > Attachment: web.patch > > Fixes webapp issues generically and in spring. > >> Web deployment broken >> - >> >> Key: TUSCANY-775 >> URL: http://issues.apache.org/jira/browse/TUSCANY-775 >> Project: Tuscany >> Issue Type: Bug >> Components: Java SCA Core, Java SCA Samples >>Affects Versions: Java-M2 >>Reporter: Andy Piper >> Attachments: web.patch >> >> >> Web deployment is broken > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the > administrators: http://issues.apache.org/jira/secure/ > Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/ > software/jira > > > > - > 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] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release parent pom and buildtools for M2
Jeremy, I have to give it a -1 right now. Lately, the incubator PMC's have been requiring ALL artifacts to be properly digitally signed, including those going into the maven repository. Thus, you need to sign all the stuff you put up there and then add a KEYS file or similar into svn with the public keys. Unfortunately, at this point, maven won't do that for you automatically.When this is fixed, I'll change to a +1. I just don't think a +1 is warranted if we're pretty sure the incubator folks will object. Thanks! Dan On Monday October 02 2006 11:28 am, Jeremy Boynes wrote: > The parent pom and buildtools are pre-reqs for all other Java > projects in the M2 release. These are distributed through the maven > repo rather than as a end-user distribution. Please vote to approve > the release content: > > parent-pom > [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/java- > pom-parent/1 > [binary] http://people.apache.org/repo/m2-incubating-repository/org/ > apache/tuscany/parent/1-incubator/ > > buildtools > [tag]https://svn.apache.org/repos/asf/incubator/tuscany/tags/java- > buildtools/1.0-incubator-M2 > [binary] http://people.apache.org/repo/m2-incubating-repository/org/ > apache/tuscany/buildtools/1.0-incubator-M2/ > > Here's my +1 > -- > Jeremy > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Daniel Kulp [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-776) Creations of HTTP Session for components requiring session support.
Creations of HTTP Session for components requiring session support. --- Key: TUSCANY-776 URL: http://issues.apache.org/jira/browse/TUSCANY-776 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-M2 Reporter: Rick Rineholt Fix For: Java-M2 I don't currently see anything that will create an HTTP sessions for components requiring session support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-775) Web deployment broken
There seem to be a few changes mixed in here. The extension directory moves from /WEB-INF to /META-INF and that seems like an odd place to me. Is this what the plugin is doing? Registering the RuntimeInfo and WebappRuntimeInfo separately to work around an autowire issue seems hacky - I thought autowire had been fixed ages ago to support matching by assignablity rather than an exact match; if not, it should. What do getInstallDirectory() and getApplicationRootDirecotry() do in a webapp environment that may not have any directories at all? getScdlUrl() is looking up absolute paths in the classloader _ does that work? I thought classloaders needed paths that do not begin with '/' -- Jeremy On Oct 3, 2006, at 4:25 AM, Andy Piper (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-775?page=all ] Andy Piper updated TUSCANY-775: --- Attachment: web.patch Fixes webapp issues generically and in spring. Web deployment broken - Key: TUSCANY-775 URL: http://issues.apache.org/jira/browse/TUSCANY-775 Project: Tuscany Issue Type: Bug Components: Java SCA Core, Java SCA Samples Affects Versions: Java-M2 Reporter: Andy Piper Attachments: web.patch Web deployment is broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - 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-767) NPE in CompositeReference.java when service is defined using interface wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-767?page=all ] Ignacio Silva-Lepe updated TUSCANY-767: --- Attachment: OperationInvocationHandlersWithTestCase.patch Here's a new patch that also contains a test case. As soon as TUSCAY-768 is resolved I should be able to verify this patch with the inner.composite sample as well. > NPE in CompositeReference.java when service is defined using interface wsdl > --- > > Key: TUSCANY-767 > URL: http://issues.apache.org/jira/browse/TUSCANY-767 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: Rick Rineholt > Assigned To: Jim Marino >Priority: Blocker > Fix For: Java-M2 > > Attachments: OperationInvocationHandlers.patch, > OperationInvocationHandlersWithTestCase.patch > > > If a service is defined using interface wsdl the service contract does not > have an interface class this results in > org.apache.tuscany.core.implementation.composite.CompositeReference getting > an NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Indexing In Lucene
Hi, Can you tell me how indexing takes place in lucene(Depth).if document has 1n indices then which algorithm it uses,which information retrival model it uses... Thanks & Regards, Akil Ajani Cognizant Technology Solutions India Pvt. Ltd. Plot # 26, Rajiv Gandhi Infotech Park, MIDC Hinjewadi, Pune 411057 Tel: (91) (20) 40201100 ext 2825 Vnet: 22809 "Technical Skill is the mastery of complexity, while creativity is the mastery of simplicity." This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
Re: DataBinding: Is it a concern of Programming Model vs. Assembly?
On 10/2/06, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Jim and I had a discussion on IRC on the databinding to understand it should be a concern of "Programming Model" or "Assembly". Attached is the transcript. Please express your views. I agree with what Jim was suggesting, particularly: jmarino: most of the time nothing will need to be specified in SCDL or any application artifacts ...ant
[jira] Commented: (TUSCANY-773) Fix Property Value Loading from Component Definitions
[ http://issues.apache.org/jira/browse/TUSCANY-773?page=comments#action_12439472 ] Venkatakrishnan commented on TUSCANY-773: - Hi Raymond, I am not able to apply your patch. Here is what I did. I am working on eclipse and have all projects defined using mvn eclipse:eclipse, which I have then imported into the IDE. When I try to apply your patch in say project 'tuscany-core', I end up with directories sca/kernel/core/... and no changes to the code. This is probably because you did a diff from sca. Could you please help me with some info on how I can apply this. Thanks - Venkat > Fix Property Value Loading from Component Definitions > - > > Key: TUSCANY-773 > URL: http://issues.apache.org/jira/browse/TUSCANY-773 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: Venkatakrishnan > Attachments: rfeng.patch, Tuscany-kernel-core-02-Oct.diff, > Tuscany-kernel-spi-02-Oct.diff, Tuscany-spec-sca-02-Oct.diff > > > Currently property loading for application components does not work. There > is NPE exception thrown when creating a property instance factory based on > the property value defined in the Component Defn. > Also the property loading works only for simply types whose values can be > represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-775) Web deployment broken
[ http://issues.apache.org/jira/browse/TUSCANY-775?page=comments#action_12439456 ] Kenneth Tam commented on TUSCANY-775: - Thanks Andy -- I'll verify.. > Web deployment broken > - > > Key: TUSCANY-775 > URL: http://issues.apache.org/jira/browse/TUSCANY-775 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core, Java SCA Samples >Affects Versions: Java-M2 >Reporter: Andy Piper > Assigned To: Kenneth Tam > Attachments: web.patch > > > Web deployment is broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-775) Web deployment broken
[ http://issues.apache.org/jira/browse/TUSCANY-775?page=all ] Kenneth Tam reassigned TUSCANY-775: --- Assignee: Kenneth Tam > Web deployment broken > - > > Key: TUSCANY-775 > URL: http://issues.apache.org/jira/browse/TUSCANY-775 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core, Java SCA Samples >Affects Versions: Java-M2 >Reporter: Andy Piper > Assigned To: Kenneth Tam > Attachments: web.patch > > > Web deployment is broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-775) Web deployment broken
[ http://issues.apache.org/jira/browse/TUSCANY-775?page=all ] Andy Piper updated TUSCANY-775: --- Attachment: web.patch Fixes webapp issues generically and in spring. > Web deployment broken > - > > Key: TUSCANY-775 > URL: http://issues.apache.org/jira/browse/TUSCANY-775 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core, Java SCA Samples >Affects Versions: Java-M2 >Reporter: Andy Piper > Attachments: web.patch > > > Web deployment is broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-775) Web deployment broken
Web deployment broken - Key: TUSCANY-775 URL: http://issues.apache.org/jira/browse/TUSCANY-775 Project: Tuscany Issue Type: Bug Components: Java SCA Core, Java SCA Samples Affects Versions: Java-M2 Reporter: Andy Piper Web deployment is broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-774) Identifier HTTP_IDENTIFIER is null workContext resulting in NPE for components enabled for session support.
Identifier HTTP_IDENTIFIER is null workContext resulting in NPE for components enabled for session support. Key: TUSCANY-774 URL: http://issues.apache.org/jira/browse/TUSCANY-774 Project: Tuscany Issue Type: Bug Affects Versions: Java-M2 Reporter: Rick Rineholt Priority: Blocker Fix For: Java-M2 For components with scope of session support the HTTP_IDENTIFIER associated with http session is workcontext returns null. Resulting in NPE at org.apache.tuscany.core.component.scope.HttpSessionScopeContainer.getInstance(org.apache.tuscany.spi.component.AtomicComponent, java.lang.Object) line: 105 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-602) does not create correct many-valued properties
[ http://issues.apache.org/jira/browse/TUSCANY-602?page=all ] Pete Robbins closed TUSCANY-602. > does not create correct many-valued properties > > > Key: TUSCANY-602 > URL: http://issues.apache.org/jira/browse/TUSCANY-602 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Reporter: Pete Robbins > Assigned To: Pete Robbins > Fix For: Cpp-current > > > According to the SDO spec maxOccurs on a choice or sequence should result in > SDO properties for the enclosed elements being many-valued. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-501) Crash on SDOTypeNotFound exception
[ http://issues.apache.org/jira/browse/TUSCANY-501?page=all ] Pete Robbins closed TUSCANY-501. > Crash on SDOTypeNotFound exception > -- > > Key: TUSCANY-501 > URL: http://issues.apache.org/jira/browse/TUSCANY-501 > Project: Tuscany > Issue Type: Bug > Components: C++ SCA >Affects Versions: Cpp-current > Environment: Windows XP >Reporter: Simon Laws > Fix For: Cpp-current > > Attachments: TUSCANY-501.patch > > > When SDOTypeNotFound is thrown the runtime crashes rather than reporting the > error -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-587) WSDL XSD is read incorrectly.
[ http://issues.apache.org/jira/browse/TUSCANY-587?page=all ] Pete Robbins closed TUSCANY-587. > WSDL XSD is read incorrectly. > - > > Key: TUSCANY-587 > URL: http://issues.apache.org/jira/browse/TUSCANY-587 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: All platforms >Reporter: Geoff Winn > Assigned To: Pete Robbins > Fix For: Cpp-current > > > When SDO for C++ reads the WSDL XSD > (http://scemas.xmlsoap.org/wsdl/2003-02-11.xsd) some properties that are in > fact many valued are identified in the internal model as single valued. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-490) DataObjectPtr::getByte returns incorrect data
[ http://issues.apache.org/jira/browse/TUSCANY-490?page=all ]
Pete Robbins closed TUSCANY-490.
> DataObjectPtr::getByte returns incorrect data
> -
>
> Key: TUSCANY-490
> URL: http://issues.apache.org/jira/browse/TUSCANY-490
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-current
>Reporter: Andrew Borley
>Priority: Minor
> Fix For: Cpp-current
>
> Attachments: TUSCANY-490.patch
>
>
> Some xml like 123 where the byte element contains an xsd:byte
> type, is converted into a DataObject and then queried.
> // returns the correct data: "123"
> const char* cs = myDataObjectPtr->getCString("byte");
> // Returns incorrect data: '1' (Ox31) - looks like it's just taking the
> first character, rather than converting 123 to the character '{' (Ox7B)
> char c = myDataObjectPtr->getByte("byte");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-604) Exception thrown when sequenced type inherits from non-sequenced type
[ http://issues.apache.org/jira/browse/TUSCANY-604?page=all ] Pete Robbins closed TUSCANY-604. > Exception thrown when sequenced type inherits from non-sequenced type > - > > Key: TUSCANY-604 > URL: http://issues.apache.org/jira/browse/TUSCANY-604 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current >Reporter: Pete Robbins > Assigned To: Pete Robbins > Fix For: Cpp-current > > > The SDO spec states that the isSequenced should be the same on a base type > and it's descendents. In the C++ implementation an exception is thrown when > e.g. a sequenced type extends a non-sequenced type. This prevents schema such > as the wsdl schema(http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd) being > loaded. > In the current Java implementation isSequenced is inherited from the base > type, we should do the same in the C++ implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-561) SDO Sample build.cmd cannot find mspdb71.dll
[ http://issues.apache.org/jira/browse/TUSCANY-561?page=all ] Pete Robbins closed TUSCANY-561. > SDO Sample build.cmd cannot find mspdb71.dll > > > Key: TUSCANY-561 > URL: http://issues.apache.org/jira/browse/TUSCANY-561 > Project: Tuscany > Issue Type: Bug > Components: C++ Build, C++ SDO >Affects Versions: Cpp-current, Cpp-M1 > Environment: Windows >Reporter: Andrew Borley >Priority: Minor > Fix For: Cpp-current > > Attachments: TUSCANY-561.patch > > > SDO Sample build.cmd needs to call vcvars32 to set up the build environment -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-705) XMLHelperImpl::createDocument() gives invalid XML when the element has xsi:nil=true
[ http://issues.apache.org/jira/browse/TUSCANY-705?page=all ] Pete Robbins closed TUSCANY-705. > XMLHelperImpl::createDocument() gives invalid XML when the element has > xsi:nil=true > --- > > Key: TUSCANY-705 > URL: http://issues.apache.org/jira/browse/TUSCANY-705 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: WinXP >Reporter: Caroline Maynard >Priority: Critical > Fix For: Cpp-current > > Attachments: bug8506.patch, bug8506.patch, TUSCANY-705-pr.patch, > TUSCANY-705.patch > > > See http://pecl.php.net/bugs/bug.php?id=8506 for the test example. > The schema is: > http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://ConvertedStockQuote";> > > > > > > > > > When the ticker element's value is not nil, the output is: > > http://ConvertedStockQuote"; xsi:type="getQuote" > xmlns:tns="http://ConvertedStockQuote"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > IBM > > but when it is nil, my user gets: > > http://ConvertedStockQuote"; xsi:type="getQuote" > xmlns:tns="http://ConvertedStockQuote"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > http://ConvertedStockQuote"; xsi:nil="true"/> > > I've attached a proposed patch. I removed the namespace URI to be consistent > with the non-nil case, apologies if this is incorrect. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-698) First pass PHP extension for C++ SCA
[ http://issues.apache.org/jira/browse/TUSCANY-698?page=all ] Pete Robbins closed TUSCANY-698. > First pass PHP extension for C++ SCA > > > Key: TUSCANY-698 > URL: http://issues.apache.org/jira/browse/TUSCANY-698 > Project: Tuscany > Issue Type: Improvement > Components: C++ SCA >Affects Versions: Cpp-current > Environment: XP >Reporter: Simon Laws > Assigned To: Jean-Sebastien Delfino >Priority: Minor > Attachments: phpextension1patch.txt, > phpextensioncalculatorchangespatch.txt > > > A first pass at an extension for the PHP scripting language. This follows the > pattern layed down by Andy with the Python extension and has many limitations: >Services only. No references. >Basic input types only. No arrays or SDOs >Single valued return values only. No arrays or SDOs >C++ .h interface >Error handling is not properly tied into SCA > I used this as an exercise to understand what Pete/Andy had done. As such I > have taken the most basic approach to integrating with PHP possible. This is > not the way I recommend doing it in the long term. In the future I would want > to change at least the following. > The embed API needs to be replaced with the PHP SAPI > References should be supported using annotations and injection > SDO should be supported as a databinding > I would prefer to go to using WSDL interface descriptions > I have currently followed the pattern and gone with the following > implementation descriptions: > When the script just has functions module="DivideServiceImpl"/> > > When the script has classes and functionsmodule="DivideServiceImpl" class="DivideClass"/> > In the longer term though I think it may be sensible to ditch the function > only approach as it makes the reference handling less obvious. > I haven;t included the build file at present because we need to sort out the > windows build system and me adding yet another flavour of > dev studio will not help. > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-644) Choice group with duplicate element names in XSD schema leads to duplication of output from SDO
[ http://issues.apache.org/jira/browse/TUSCANY-644?page=all ] Pete Robbins closed TUSCANY-644. > Choice group with duplicate element names in XSD schema leads to duplication > of output from SDO > --- > > Key: TUSCANY-644 > URL: http://issues.apache.org/jira/browse/TUSCANY-644 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Windows XP >Reporter: Simon Laws > Assigned To: Pete Robbins > Fix For: Cpp-current > > > A PHP SDO user raised a bug (http://pecl.php.net/bugs/bug.php?id=8493) to the > effect that having read the XSD for WSDL1.1 and having created operation data > objects with input and output properties these properties are duplicated when > the SDO is written out to XML. > The symtom is caused because the WSDL schema in question contains a choice > group that repeats elements of the same name but just in a different order > (to represent different calling conventions in this case). SDO flattens the > choice but for some reasone fails to spot the duplicate type names and hence > the resulting data object property list has multiple properties of the same > name. This is not good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-506) Sequenced Open types are not being loaded via the sequence interface
[ http://issues.apache.org/jira/browse/TUSCANY-506?page=all ] Pete Robbins closed TUSCANY-506. > Sequenced Open types are not being loaded via the sequence interface > > > Key: TUSCANY-506 > URL: http://issues.apache.org/jira/browse/TUSCANY-506 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO > Environment: all >Reporter: Ed Slattery > Assigned To: Ed Slattery > > The parser used the dataObject interface to load open types, even if > sequenced, so sometimes the sequence of the object doesnt contain the full > list of properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-764) Replace SDOString with std::string
[ http://issues.apache.org/jira/browse/TUSCANY-764?page=all ] Pete Robbins closed TUSCANY-764. > Replace SDOString with std::string > -- > > Key: TUSCANY-764 > URL: http://issues.apache.org/jira/browse/TUSCANY-764 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO >Affects Versions: Cpp-current >Reporter: Pete Robbins > Assigned To: Pete Robbins > Fix For: Cpp-current > > Attachments: SDOString.patch, TUSCANY-764.patch > > > SDOString is unnecessary and adds no function over std::string > I'd like to propose we get rid of SDOString and just use std::string. > SDOString inherits from std::string but does not add any additional function. > The initial idea of having SDOString was to add an additional operator const > char*() so that when we changed public API return values from const char* to > SDOString a user would not have to ammend their code. However, this didn't > quite work so I believe SDOString is redundant. > > I experimented by typedef'ing SDOString to std::string and it won't be too > tricky to fix the few compile errors. I will hold off checking this in until > we have consensus that it is the right thing to do. > > Next, we have many duplicate methods that take parameters as string or char*. > I would like to remove all the methods that take char* as const string& will > work just as well without causing users problems. I realise that this is > currently being discussed by the spec group and the current spec has the > interfaces using char*, however for input paramters this proposal will still > support the methods as if they were passing char* so I think we should go for > it. I'm sure the spec group will get round to agreeing woth this ;-) > > Finally, and a bit later, we need to look at changing the public APIs that > return char* to return std::string but this can wait for the spec group to > decide if this is what they want. This will affect users as they will need to > use .c_str() on their return values if they require th char* string. > > Cheers, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-759) XPath test failure with compound queries
[ http://issues.apache.org/jira/browse/TUSCANY-759?page=all ] Pete Robbins closed TUSCANY-759. > XPath test failure with compound queries > > > Key: TUSCANY-759 > URL: http://issues.apache.org/jira/browse/TUSCANY-759 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: PHP 5.1.6, WinXP >Reporter: Caroline Maynard > Assigned To: Pete Robbins > Fix For: Cpp-current > > > Part of the SDO for PHP core unit tests uses a standard > company->departments[]->employees[] model and tests Xpath expressions. All > these tests worked with Tuscany C++ SDO revision level 431903. I recently ran > them with 436761 and there was a failure. I then reverted to 433676 and the > tests were successful. It's possible that the Tuscany-539 fix was the culprit. > The failing test is attempting to read > company["departments[name='ShoeDept']/employees[name='Jane Smith']"] > The values for name are both valid, but in the failing revision level an > exception was thrown with the message "Invalid path:" followed by the xpath > above. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-473) Exception thrown when serializing an element defined with sdo:name
[ http://issues.apache.org/jira/browse/TUSCANY-473?page=all ] Pete Robbins closed TUSCANY-473. > Exception thrown when serializing an element defined with sdo:name > -- > > Key: TUSCANY-473 > URL: http://issues.apache.org/jira/browse/TUSCANY-473 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current >Reporter: Pete Robbins > Assigned To: Pete Robbins > Fix For: Cpp-current > > > Attempting to serialise the element from an sca.module file we > get a Property not found exception thrown for "source.uri" > this element has been renamed in the xsd using sdo:name="sourceURI" so the > serialization code should not be using the name source.uri. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-486) Document deployment & use of Axis2C WS EntryPoint
[ http://issues.apache.org/jira/browse/TUSCANY-486?page=all ] Pete Robbins closed TUSCANY-486. > Document deployment & use of Axis2C WS EntryPoint > - > > Key: TUSCANY-486 > URL: http://issues.apache.org/jira/browse/TUSCANY-486 > Project: Tuscany > Issue Type: Task > Components: C++ SCA >Affects Versions: Cpp-M1 >Reporter: Andrew Borley > Assigned To: Pete Robbins > Fix For: Cpp-current > > Attachments: TUSCANY-486.patch, WS_ENTRYPOINT.txt > > > Need documentation explaining how to expose an SCA component as a WS > EntryPoint in Axis2C -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-510) Big Bank getQuote return type error
[ http://issues.apache.org/jira/browse/TUSCANY-510?page=all ] Pete Robbins closed TUSCANY-510. > Big Bank getQuote return type error > --- > > Key: TUSCANY-510 > URL: http://issues.apache.org/jira/browse/TUSCANY-510 > Project: Tuscany > Issue Type: Bug > Components: C++ SCA >Affects Versions: Cpp-current > Environment: windows XP >Reporter: Simon Laws > > StockQuoteExternalService.h/StockQuoteServiceImpl.cpp has incorrect return > type for getQuote const char * should be float. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-508) Big Bank GetQute signature
[ http://issues.apache.org/jira/browse/TUSCANY-508?page=all ] Pete Robbins closed TUSCANY-508. > Big Bank GetQute signature > -- > > Key: TUSCANY-508 > URL: http://issues.apache.org/jira/browse/TUSCANY-508 > Project: Tuscany > Issue Type: Bug > Components: C++ SCA >Affects Versions: Cpp-current > Environment: Windows XP >Reporter: Simon Laws > > ChangedGetQuote to getQuote in StockQuoteService_StockQuoteExternal_Proxy.cpp > and associated StockQuoteExternal files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-691) Paramater name "interface" appearc in the code which upsets VC7 2002
[ http://issues.apache.org/jira/browse/TUSCANY-691?page=all ] Pete Robbins closed TUSCANY-691. > Paramater name "interface" appearc in the code which upsets VC7 2002 > > > Key: TUSCANY-691 > URL: http://issues.apache.org/jira/browse/TUSCANY-691 > Project: Tuscany > Issue Type: Bug > Components: C++ SCA > Environment: XP MSVC7 2002 >Reporter: Simon Laws > Assigned To: Andrew Borley >Priority: Minor > Fix For: Cpp-current > > Attachments: scamodelvc7patch.txt > > > Changes "interface" to "anInterface" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-697) [C++ for SDO] Add remaining methods taking SDOString args rather than char*
[ http://issues.apache.org/jira/browse/TUSCANY-697?page=all ] Pete Robbins closed TUSCANY-697. > [C++ for SDO] Add remaining methods taking SDOString args rather than char* > --- > > Key: TUSCANY-697 > URL: http://issues.apache.org/jira/browse/TUSCANY-697 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO >Affects Versions: Cpp-current > Environment: All >Reporter: Geoff Winn > Fix For: Cpp-current > > Attachments: TUSCANY-697.patch > > > This fix provides all the remaining methods that take SDOString arguments > rather than char* arguments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-511) Big Bank memory error
[ http://issues.apache.org/jira/browse/TUSCANY-511?page=all ]
Pete Robbins closed TUSCANY-511.
> Big Bank memory error
> -
>
> Key: TUSCANY-511
> URL: http://issues.apache.org/jira/browse/TUSCANY-511
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SCA
>Affects Versions: Cpp-current
> Environment: Windows XP
>Reporter: Simon Laws
>
> Get memory error in the final leg of the big bank scneario. Was solved
> temoprarily bu commenting the follwong out.
> Axis2Client.cpp ln 149
> /*
> if (svc_client)
> {
> AXIS2_SVC_CLIENT_FREE(svc_client, env);
> svc_client = NULL;
> }
> */
> Needs futher detailed investigation to determine if this is causing memory
> corruption of something else is by, for example, freeing something twice
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-603) Attributes specified in xml instance doc are not validated against the schema definition
[ http://issues.apache.org/jira/browse/TUSCANY-603?page=all ] Pete Robbins closed TUSCANY-603. > Attributes specified in xml instance doc are not validated against the schema > definition > > > Key: TUSCANY-603 > URL: http://issues.apache.org/jira/browse/TUSCANY-603 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current >Reporter: Pete Robbins > Assigned To: Pete Robbins > Fix For: Cpp-current > > > When an instance document is loaded attributes on a type are set as > attributes even if the schema specifies that the property is an element. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-539) [SDO for C++] Augment client interface with methods taking SDOString parameters. Part 1
[ http://issues.apache.org/jira/browse/TUSCANY-539?page=all ] Pete Robbins closed TUSCANY-539. > [SDO for C++] Augment client interface with methods taking SDOString > parameters. Part 1 > --- > > Key: TUSCANY-539 > URL: http://issues.apache.org/jira/browse/TUSCANY-539 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Windows and Linux >Reporter: Geoff Winn >Priority: Minor > Fix For: Cpp-current > > Attachments: TUSCANY-539.patch > > > Continuing the process of migrating SDO to use C++ style strings. > Add methods that take const SDOString& parameters to supplement the ones that > take const char* parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-553) Add a static null SDOString to the SDOString class
[ http://issues.apache.org/jira/browse/TUSCANY-553?page=all ] Pete Robbins closed TUSCANY-553. > Add a static null SDOString to the SDOString class > -- > > Key: TUSCANY-553 > URL: http://issues.apache.org/jira/browse/TUSCANY-553 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Windows and Linux >Reporter: Geoff Winn >Priority: Minor > Fix For: Cpp-current > > Attachments: TUSCANY-553.patch > > > It is frequently necessary to create null strings as default parameters or to > represent enmpty return values. Where these values are read only they can be > references to a single class static. Add this static to the class for later > use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-455) patch for tuscany-443 using inline functions will not compile/work on Linux
[ http://issues.apache.org/jira/browse/TUSCANY-455?page=all ] Pete Robbins closed TUSCANY-455. > patch for tuscany-443 using inline functions will not compile/work on Linux > --- > > Key: TUSCANY-455 > URL: http://issues.apache.org/jira/browse/TUSCANY-455 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current >Reporter: Pete Robbins > Assigned To: Pete Robbins >Priority: Blocker > Fix For: Cpp-current > > > The methods in SDOString defined as inline in the .cpp are not accessable > from another library/exe. This can work on Windows as there is an MS only > way of exporting the function using dllexport. > You can inline the functions by defining the methods in the class declaration > in the header file. > Please build ALL changes on Linux as well as Windows -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-472) [SDO for C++] Build of SDO fails during post build copy out.
[ http://issues.apache.org/jira/browse/TUSCANY-472?page=all ] Pete Robbins closed TUSCANY-472. > [SDO for C++] Build of SDO fails during post build copy out. > > > Key: TUSCANY-472 > URL: http://issues.apache.org/jira/browse/TUSCANY-472 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Windows XP >Reporter: Geoff Winn > Assigned To: Pete Robbins > Fix For: Cpp-current > > > The post build step that copies many files to their target locations produces > numerous errrors reporting > "The system cannot find the path specified." > The first two files to be copied are OK, but the third fails, as do most of > the ones that follow. > The missing directory appears to be sdo\include. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-305) Test data files are confusingly located
[ http://issues.apache.org/jira/browse/TUSCANY-305?page=all ] Pete Robbins closed TUSCANY-305. > Test data files are confusingly located > --- > > Key: TUSCANY-305 > URL: http://issues.apache.org/jira/browse/TUSCANY-305 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO > Environment: Microsoft Visual Studio V7.1 running on Windows XP >Reporter: Geoff Winn > Assigned To: Ed Slattery >Priority: Minor > Attachments: TUSCANY-305.patch > > > The build_instructions.txt file includes the following paragraph. > "The test project runs in the projects directory, where in C6 it ran in the > Debug directory, > so all the test comparison files are in the wrong place. You can copy the > entire contents > of runtime/core/test/Debug to projects/tuscany_sdo/sdo_test" > The directory paths quoted are slightly inaccurate and the attached patch > corrects this text. However, more seriously, the directory structure that > contains the test data files is more complicated than this paragraph suggests > and a simple copy isn't sufficient. There are two exceptions. > 1. The sdo_test program at one point looks for ..\test\test\include3.xsd. > To comply with that, it is necessary to create a new "test" directory as a > sibling of tuscany\cpp\sdo\projects\tuscany_sdo\sdo_runtime and then copy the > test directory from tuscany\cpp\sdo\runtime\core\test into that newly created > directory. > 2. The sdo_test program also looks for ..\test2\includeother3.xsd > To comply with that, it is necessary to copy the test2 directory from > tuscany\cpp\sdo\runtime\core\test to be another sibling of > tuscany\cpp\sdo\projects\tuscany_sdo\sdo_runtime ie one level higher than you > get if you follow the simple copy instruction. > These latter two points could also be recorded in the build_instructions.txt > file, but it might be better in the long term to re-arrange the test data so > that it doesn't use such intricate paths. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-426) Null pointer exception loading schema with ref to already defined type
[ http://issues.apache.org/jira/browse/TUSCANY-426?page=all ] Pete Robbins closed TUSCANY-426. > Null pointer exception loading schema with ref to already defined type > -- > > Key: TUSCANY-426 > URL: http://issues.apache.org/jira/browse/TUSCANY-426 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current >Reporter: Pete Robbins > Assigned To: Pete Robbins > Fix For: Cpp-current > > > Bug in XSDHelperImpl handling reference to type not being defined in this > pass. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-211) MSVC build failure
[ http://issues.apache.org/jira/browse/TUSCANY-211?page=all ] Pete Robbins closed TUSCANY-211. > MSVC build failure > -- > > Key: TUSCANY-211 > URL: http://issues.apache.org/jira/browse/TUSCANY-211 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO > Environment: MSVC 7.0 >Reporter: Simon Laws > Assigned To: Pete Robbins >Priority: Minor > > Link failure. Add: > GroupEvent.cpp > GroupDefinition.cpp > to the sdo_runtime project and > utils.cpp > main.cpp > to the sdo_test project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-448) ElementWithSDOName fails on write
[ http://issues.apache.org/jira/browse/TUSCANY-448?page=all ] Pete Robbins closed TUSCANY-448. > ElementWithSDOName fails on write > - > > Key: TUSCANY-448 > URL: http://issues.apache.org/jira/browse/TUSCANY-448 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current > Environment: Windows XP >Reporter: Simon Laws > Fix For: Cpp-current > > > Reading > ElementWithSDOName > against schema > type="string"/> > and writing out again gives rise to a runtime failure -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-431) XSDHelper does not always create a DataFactory
[ http://issues.apache.org/jira/browse/TUSCANY-431?page=all ] Pete Robbins closed TUSCANY-431. > XSDHelper does not always create a DataFactory > -- > > Key: TUSCANY-431 > URL: http://issues.apache.org/jira/browse/TUSCANY-431 > Project: Tuscany > Issue Type: Bug > Components: C++ SDO >Affects Versions: Cpp-current >Reporter: Pete Robbins > Assigned To: Pete Robbins > Fix For: Cpp-current > > > It is possible to construct an XSDHelper which does not contain a DataFactory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
