implementation.spring seems to look for the application context in the wrong location

2007-11-25 Thread Niklas Gustavsson

Hi

When setting the location on an implementation.spring to a JAR file, the 
current Tuscany implementation first looks for the Spring-Context 
attribute in the manifest (which looks okay). However, if that is not 
found, it tries to load the application context from 
application-context.xml in the root of the JAR.


Reading the spec, I find this section:
"If there is no MANIFEST.MF file or no Spring-Context header within
that file, then the default behaviour is to build an application context 
using all the *.xml files in the META-INF/spring directory."


Being pretty much a Tuscany n00b I don't know if this is a conscious 
decision or a bug. If you think its a bug I'll open a JIRA and attempt 
creating a patch. Since the implementation currently works by returning 
a URL which is later loaded using URL.getInputStream() (which wouldn't 
work all that well for all *.xml in a directory) this patch might get 
complicated. Suggestions welcome :-)


/niklas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[Policy Fwk Specs Relalted] Operations Inheritance

2007-11-25 Thread Venkata Krishnan
Hi,

Looking at getting the policies working on operations of services I am
missing out on what is to be done for the following: -

- For operations on composite services when operations are defined in the
component service that is being promoted by this composite service.  Right
now, I aggregate the operations in the component service over to the
composite service.  Where the composite service specifies an operation
already specified in the component service, I have aggregated the intents
and policysets from the component service operations over to the composite
services'.  The same has been done for references as well.  Is this a right
thing to do ?

If somebody has better clarity on this please help.

Thanks

- Venkat


Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

2007-11-25 Thread Venkata Krishnan
All that sounds sense to me, especially the thought of turning our samples
to simple contribution jars.   That will align better with what application
developers would actually do.

- Venkat

On Nov 22, 2007 8:21 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Nov 22, 2007 1:57 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> >
> > Jean-Sebastien Delfino wrote:
> >
> > > [snip]
> > > Simon Nash wrote:
> > >
> > >> Samples are very important for beginning users.  For users who have
> > >> moved beyond that stage and are doing real development using Tuscany,
> > >> samples are not very important.  If people in this category do want
> > >> samples, they are likely to just want to refer to samples source code
> > >> to cut and paste snippets as necessary.  Having pre-built sample
> > binaries
> > >> isn't important for these users, and having the main lib directory
> > >> polluted/bloated by samples dependencies is a positive nuisance
> because
> > >> there's no easy way for them to find and remove the redundant files.
> > >
> > >
> > > I didn't think we were polluting the lib directory with sample
> > > dependencies, do you have a concrete example?
> > >
> > I thought this thread was discussing the case of a sample having a
> > dependency that the runtime does not have.  If there are no such cases
> > at present, then the issue doesn't arise.  However, there could be
> > such cases in the future as we add more "application-style" samples,
> > and it would be good to have an idea about how such dependencies would
> > be handled.
> >
> > >>
> > >> Having these files in Tuscany's lib directory isn't just wasting a
> few
> > >> bits on the disk.  It can be a problem if their version levels
> conflict
> > >> with other versions of the same code that the user has installed.
> > >> For "genuine" Tuscany dependencies, such conflicts are a real issue
> > >> that must be handled carefully in order to get Tuscany to co-exist
> with
> > >> their other software.  For sample dependencies, there is no actual
> > >> conflict unless the user needs to run the specific sample that pulled
> > >> in the dependency,
> > >
> > >
> > > Like I said earlier in the initial thread about sample dependencies, I
> > > don't think that samples should bring dependencies that are not
> genuine
> > > Tuscany dependencies.
> > >
> > OK, we are agreed about this.  But what if an application-style sample
> > does have a non-Tuscany dependency?  This is certainly possible.  Would
> > the Tuscany distro include the dependency, or leave it up to the user
> > to download it as a prereq to running the sample?
> >
> > > but it might take them some time to figure out why
> > >
> > >> putting the Tuscany lib directory on the classpath is causing other
> > >> code in their application to break.
> > >>
> > >> I'd suggest structuring the binary distribution as follows:
> > >>
> > >> 1. Tuscany runtime in "modules" and its dependencies in "lib".
> > >
> > >
> > > +1
> > >
> > >>At the moment we have separate copies of the Tuscany runtime in
> > >>"modules" and "lib" and I'm not quite sure why.
> > >
> > >
> > > Which JARs are you talking about?
> > >
> > I'm talking about the tuscany-sca-all.jar in the lib directory, which
> > is a combination of the contents of the jars in the modules directory.
> > The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar
> > as well as referring to all the jars in the modules directory, which
> > seems somewhat redundant.
> >
> > >
> > >> 2. Tuscany samples source, READMEs and build files in "samples".
> > >
> > >
> > > +1
> > >
> > >> 3. Tuscany samples binaries in "modules/samples",
> > >
> > >
> > > I prefer to have the binaries under samples as well, with their
> source.
> > >
> > Having them there is more convenient but makes it harder to see how
> > much space they are consuming.  I did some investigation, and it
> > turns out that these binaries are causing a huge expansion in the
> > size of the "samples" directory.
> >
> > In the 1.0.1 binary distro, the source under the "samples" directory
> > occupies around 2.3 MB.  The total size of source plus binaries under
> > this directory is 49.5 MB.  This extra 47 MB for samples binaries is
> > almost half the total size of the Tuscany binary distro.  I think we
> > need to either remove these binaries or separate them out into a
> > samples download so that we can get the Tuscany binary distro down
> > to a reasonable size.
> >
> > > with their
> > >
> > >>dependencies in "lib/samples".
> > >
> > >
> > > Again samples should not bring additional dependencies in the first
> > place.
> > >
> > I hope this is true.  I don't know how to check that nothing in
> > this category has been included in lib.
> >
> > >>
> > >> By doing this we solve the conflict problems and it becomes a distro
> > >> size issue to decide whether 3 should be in the main binary distro
> > >> or available separately.
> > >
> > >
> > > IMO the samples should be small and not cause a

Method names in SCADomain* and SCANode* APIs

2007-11-25 Thread Simon Nash

The following method names in domain-api and node-api include a
reference to either a domain or a node:
 SCADomain.addToDomainLevelComposite()
 SCADomain.removeFromDomainLevelComposite()
 SCADomain.getDomainLevelComposite()
 SCADomainFactory.createSCADomain()
 SCADomainFinder.getSCADomain()
 SCANode.getDomain()
 SCANode.addToDomainLevelComposite()
 SCANodeFactory.createSCANode()
 SCANodeFactory.createNodeWithComposite()

Of these 9 method names, 3 of them refer to "SCADomain" or "SCANode"
and 6 of them refer to plain "Domain" or "Node".

I would like to remove the "SCA" from the 3 method names that
include it.  Since the SCADomain* and SCANode* class names already
include "SCA" to disambiguate them from other kinds of node and
domain, I don't think there is a need to repeat the "SCA" in the
method names as well.

What do others think about this?

  Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Resolved: (TUSCANY-1359) New SDOUtil: Upper and lower bound on properties where 'isMany' is true

2007-11-25 Thread Amita Vadhavkar (JIRA)

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-1359.
--

Resolution: Fixed

Marking resolved based on Rev 597652.

> New SDOUtil: Upper and lower bound on properties where 'isMany' is true
> ---
>
> Key: TUSCANY-1359
> URL: https://issues.apache.org/jira/browse/TUSCANY-1359
> Project: Tuscany
>  Issue Type: Wish
>  Components: Java SDO Tools
>Reporter: Christian Landbo Frederiksen
>Assignee: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: 1359.patch
>
>
> Can be implemented like this:
>  public static int getUpperBound(Property property) {
> return ((EStructuralFeature) property).getUpperBound();
>  }
>public static int getLowerBound(Property property) {
>return ((EStructuralFeature) property).getLowerBound();
>}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]