Simon, There shouldn't be any visible effect because of the classloading changes to the Tuscany runtime (at least that was the goal). It enables Tuscany to be run in a multi-classloader environment including inside OSGi. By default, Tuscany continues to run using a single CLASSPATH-based classloader.
Contribution classloading was also modified. As a result, contributions no longer need to be in the CLASSPATH. All import/export dependencies across contributions should be explicitly specified (as described in the spec). Earlier, classes from contributions were loaded using the thread context classloader (typically using CLASSPATH), and import/export statements did not have any effect. Thank you... Regards, Rajini On 12/18/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > On Dec 13, 2007 1:37 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > On Dec 13, 2007 12:16 PM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > On Dec 12, 2007 10:03 AM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > > > > > On Dec 12, 2007 9:45 AM, Luciano Resende < [EMAIL PROTECTED]> > > > wrote: > > > > > > > > > Following Ant's question, after you cut the first RC, development > > > > > would continue on trunk or on a branch ? Based on the timeframe > and > > > > > considering we would still work on issues on the week of Jan 7th, > > > I'd > > > > > recommend continue on trunk until sometime around end of year. > > > > > > > > > > On Dec 12, 2007 12:22 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > I don't think the tomcat deep integration, JMS, or distribution > > > > > structure > > > > > > changes would all be done by next week. Haven't seen much > > > happening > > > > with > > > > > > jsonrpc references recently either. We do have all of the rest > of > > > this > > > > > year > > > > > > to continue development though right? > > > > > > > > > > > > ...ant > > > > > > > > > > > > > > > > > > On Dec 11, 2007 10:59 PM, Simon Laws < [EMAIL PROTECTED] > > > > > > wrote: > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > Following on from the JIRA tidy up note here are a few high > > > level > > > > > areas > > > > > > > that > > > > > > > I've seen activity on over the last few weeks and so may be > > > ready to > > > > > go > > > > > > > for > > > > > > > release 1.1. > > > > > > > > > > > > > > Deep tomcat integration > > > > > > > Better JMS support > > > > > > > JAXB based POJO transformations. > > > > > > > More policy function > > > > > > > Modeling of client side java script components > > > > > > > JSONRPC reference binding > > > > > > > Better support for doman API suggested by assembly spec > > > > > > > Domain based and standalone node operation > > > > > > > Domain lookup for remote access to domain services. > > > > > > > Transactions > > > > > > > JPA > > > > > > > Class loading and OSGI > > > > > > > BPEL fixes > > > > > > > Distribution structure changes > > > > > > > > > > > > > > Can you fill in the detail and tell me what we can get in, > > > > i.e.addwhat is > > > > > > > missing from the list, add details to what is on the list, > > > indicate > > > > > what > > > > > > > shouldn't be on the list. Think of this as forming the CHANGES > > > text > > > > so > > > > > it > > > > > > > should look like [1]. Even better go and update the CHANGES > > > doc:-) > > > > > > > > > > > > > > As a reminder here is the timeline I'm working to. I'm > planning > > > on > > > > > > > spending > > > > > > > next week working on the first RC. Building the distribution, > > > fixing > > > > > > > samples, READMES, licenses etc. The objective being to have a > > > > release > > > > > > > candidate before I go away for the holidays for people to > review > > > at > > > > > their > > > > > > > leisure. This means that when everyone is back we can spend > the > > > week > > > > > > > beginning 7th Jan knocking it into shape until we get an RC we > > > can > > > > > vote > > > > > > > on. > > > > > > > The following week, beginning 14th would also be taken up by > > > voting > > > > > with a > > > > > > > view to releasing the week beginning 21st (or earlier if we > get > > > > done). > > > > > > > > > > > > > > Does that still sound reasonable to everyone. Are there pieces > > > of > > > > > function > > > > > > > that must be in 1.1. that can't be done in this timescale? > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Simon > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/distribution/src/main/release/CHANGES > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Luciano Resende > > > > > Apache Tuscany Committer > > > > > http://people.apache.org/~lresende< > http://people.apache.org/%7Elresende> > > > <http://people.apache.org/%7Elresende>< > > > > http://people.apache.org/%7Elresende> > > > > > http://lresende.blogspot.com/ > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > If people are agreed that any work that gets committed to trunk > over > > > the > > > > Christmas holidays is related to fixing up the content of the > release > > > > candidate contents we finalize next week then I'm happy to keep that > > > > effort > > > > going on trunk with a view to cutting the branch including all of > the > > > > fixes > > > > people have made when I get back on the 2nd Jan. We could hope to > use > > > this > > > > "RC0" to catch 90% of the release issues and reduce the pain a > little > > > for > > > > this 90% by allowing the fixes to happen in just one place. > > > > > > > > If people have other projects in mind that take the trunk in a > > > different > > > > direction then I'll take a branch next week. > > > > > > > > Simon > > > > > > > > > > Doing it next year sounds good to me, i've no plans to start on new > > > stuff > > > not related to 1.1 over the break but i would find it useful to have > > > that > > > time to finish things off. > > > > > > ...ant > > > > > I do want to get an RC done next week (from the trunk) which we can all > > test with and which I hope shows what we intend to release in 1.1. From > > past experience we know that the first time we try to get it all > together > > there will be many things to fix and things to finish. I wouldn't expect > > that to include, for example, inclusion of new modules that we haven't > > discussed here or material changes to the structure of the release. The > > point of this being that we shouldn't be in 1.1. development mode when > > January comes round and that we are focused on getting 1.1 through the > > release votes with all the fixing and fiddling we know that entails. > > > > Simon > > > I'm planning to spend the next 3 days working on getting the mechanics of > the release in place for 1.1 and working on bug fixes. From the initial > list > that I postulated at the start of this and peoples subsequent replies I > believe we can expect these pieces of work. > > > - Better JMS support > - What level of support are we now expecting? > - JAXB based POJO transformations. > - More policy function including JAAS and better designed policy > handlers > - Modeling of client side java script components > - JSONRPC reference binding > - Can someone comment is this is actually done? > - Better support for doman API suggested by assembly spec including a > standalone node and nodes running connected together in a domain. > - Class loading and OSGI improvements > - Support for BPEL references > > > Please check the accuracy of this and let me know what is missing. In > particular I want more detail on what we can expect for > > JMS - for example > Point to point, XML messages, Callbacks? > JSONRPC references > Is this done now? > Class loading and OSGI improvements > What new features/behaviour will people see in the release? > > Regards > > Simon >
