Re: composite reconfiguration
Hi Valerio, Some comments and questions inline. Valerio Schiavoni wrote: Hello Jean-Sebastian, On 4/6/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: - add/update/remove SCA contributions (packages containing composites and component implementation artifacts) to/from the SCA domain - add/update/remove deploymentComposites, declaring the top-level components active in the SCA domain These operations are described in the SCA assembly spec - chapter 1.10.4 - Operations on SCA contributions. Doing this will update the configuration of components, including the configuration of their properties, bindings, and references (by rewiring them to other components). Do you have any specific re-configuration use cases in mind that we should support? In particular, I was thinking about binding re-configuration at first. Reading at the specs: "this functionality makes it possible for the deployer to create a composite with final configuration and wiring decisions and add it to an installed contribution without having to modify the contents of the root contribution." As you said, updating a contribution will update also declared bindings. You'll need to restart the components contributed by that contribution to get the updated bindings. How does it work when updating binding.java to a different one ? The wires, binding selection etc. should be re-evaluated when the impacted components get restarted. Did you mean binding.sca? Can you point me somewhere within the core module ? There is really no special processing for handling updates of a contribution. Updating a contribution is very similar to contributing it the first time. Here are a few pointers to code along the contribution and start path: - in the contribution module, o.a.t.contribution.service.ContributionService is used to add or update a contribution - in the assembly-xml module, o.a.t.assembly.xml.CompositeProcessor reads a Composite and populates the assembly model in memory, describing composites, components, services, bindings etc. - in the core module, o.a.t.core.deployer.DeployerImpl walks the assembly model and triggers runtime Builders which create runtime context objects for components, services with bindings etc. - these runtime context objects (for example o.a.t.implementation.java.context.JavaComponent) implement o.a.t.spi.Lifecycle (defined in module core-spi), and their start() method is called Would you be interested in helping with some of this work? I would be interested, but as I'm already working on the fractal contribution: https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/fractal/ Cool. Do you already have a patch to contribute? If you want to submit a JIRA issue with a patch, we can contribute it to the sandbox first, and everybody can take a look at it and help you, let you know when we make changes that will affect your code etc. and even better at some point integrate your extension in the trunk... i guess it'd be difficult for me to productive. Also, I'm trying to figure out what's changed in 1.0 for extensions.. We have made a number of changes to extensions recently, in particular to how SCA assembly XML (.composite files etc.) are loaded, and also to the model interfaces representing SCA assemblies. Feel free to ask any questions, we'll try to help as much as possible. There are sample extensions under samples/implementation-crud, samples/echo-binding and samples/echo-databinding. We're also looking for feedback on the SPIs and suggestions for improvement. Would you mind giving us a short summary of how you are extending Tuscany and integrating with Fractal? A little more context on what you're doing will probably help us help you better :) Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Require more context for URLArtifactProcessorExtension.read()
Raymond Feng wrote: Hi, I was refering to artifact URI instead of contribution URI. For example, if a jar contribution is deployed, the URI of a class named a.b.MyClass in the jar will be "a/b/MyClass.class". ContributionContext is one way to pass more context to the processors. But I don't think it will go through injection. It should be on the method signature of the SPI. Thanks, Raymond - Original Message - From: "Luciano Resende" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 17, 2007 1:43 PM Subject: Re: Require more context for URLArtifactProcessorExtension.read() Hi Raymond I'm not sure if the Contribution URI will really work for your requirements, as of today, the URL that the artifactProcessor receives is the actual artifact URL location, and it's not based on the Contribution URI and also can be normalized based on the contribution package type (e.g jar will have a jar URL). Thinking on the second requirement, if we create a contribution context with some basic contribution information (e.gcontribution uri, contribution base location, normalized contribution base location, and the contribution classloader) and "inject" it on the processor, then you would have the necessary information to perform the necessary actions you need? Once we agree on a solution, I can get it implemented. Thoughts ? On 4/17/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, I think you already got it right. I want to contribute a processor to scan the classes to figure out available generated SDO factory interface/class. During the "read" phase, the processor will capture the classname by a naming pattern. The class will be loaded during "resolve" phase and the factory will be registered with a HelperContext. I see two requirements here: 1) read: Pass in the URI of the artifact which can be used to derive the class name 2) resolve: Pass in a contribution classloader which can be used to resolve java classes Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 17, 2007 11:22 AM Subject: Re: Require more context for URLArtifactProcessorExtension.read() > Raymond Feng wrote: >> Hi, >> >> When I try to add a URLArtifactProcessorExtension to introspect java >> classes, I found it impossible to get the class name as only the URL >> of >> the class file is passed to the read() method. To provide such >> context, I >> suggest that we pass in the DeployedArtifact (which contains the URL) >> instead of URL to the read() method. >> >> Do you agree or do you have a better way? >> >> Thanks, >> Raymond >> > > Could you give more context as well? :) and describe what you're trying to > do? > > Are you trying to derive a class name from the file name? Are you going to > load or read the class file and could you find the class name from its > contents then? > > It's a little difficult to try to answer without more context, but in > general I would prefer for ArtifactProcessors not to have to know the > structure of the Contribution or the DeployedArtifacts that represent it. > If you need to know the base URL of the contribution and the path of > the > given Artifact inside it, then maybe we could pass these two parameters to > the read() method, it would be better than passing the whole > DeployedArtifact and have the read() method dig into it. > > But again, before we do that, could you describe your use case? and > then > hopefully we can find a good solution for it. Thanks. > > -- > 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] -- Luciano Resende http://people.apache.org/~lresende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] A few thoughts: - You need the URI of an artifact inside the SCA contribution. - I indicated before that I needed input/outputStreams as well. - I think it's useful to have the URL of the contribution to have a base URL to load artifacts (for example for WSDLs and XSDs if they do ... location="/aFile.xsd or /aFile.wsdl">). So I suggest read/write(URL contributionURL, String artifactURI, Input/OutputStream input/outputStream). In most cases you just use the input/outputStream, sometimes you need to know the contributionURL, and if you want to know the artifact URL you do new URL(contributionURL, artifactURI). I was thinking that Class loading would be the responsibility of the ArtifactResolver. So, we wouldn't need a ClassLoader, we would call ArtifactResolver.resolve() to get the Class, like for all other artifacts resolved in an SCA c
Re: [DISCUSS] Next version - What should be in it
Davanum Srinivas wrote: Folks, Let's keep the ball rolling...Can someone please come up with a master list of "extensions, bindings, services, samples" which can then help decide what's going to get into the next release. Please start a wiki page to document the master list. Once we are done documenting the list. We can figure out which ones are MUST, which ones are nice to have, which ones are out of scope. Then we can work backwards to figure out How tightly or loosely coupled each piece is/should be and how we could decouple them if necessary using interfaces/spi/whatever... Quote from Bert Lamb: "I think there should be a voted upon core set of extensions, bindings, services, samples, whatever that should be part of a monolithic build." http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html Quote from Ant Elder: The specifics of what extensions are included in this release is left out of this vote and can be decided in the release plan discussion. All this vote is saying is that all the modules that are to be included in this next release will have the same version and that a top level pom.xml will exist to enable building all those modules at once. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16155.html Thanks, dims Hi all, I think we have made good progress since we initially started this discussion. We have a simpler structure in trunk with a working top-down build. Samples and integration tests from the integration branch have been integrated back in trunk and most are now working. We have a more modular runtime with a simpler extension mechanism. For example we have separate modules for the various models, the core runtime and the Java component support. SPIs between the models and the rest of the runtime have been refactored and should become more stable. We need to do more work to further simplify the core runtime SPIs and improve the core runtime but I think this is going in the right direction. I'm also happy to see better support for the SCA 1.0 spec, with support for most of the SCA 1.0 assembly XML, and some of the SCA 1.0 APIs. It looks like extensions are starting to work again in the trunk, including Web Services, Java and scripting components. It shouldn't be too difficult to port some of the other extensions - Spring, JMS, JSON-RPC - to the latest code base as well. So, the JavaOne conference is in three weeks, would it make sense to try to have a Tuscany release by then? We could integrate in that release what we already have working in trunk, mature and stabilize our SPIs and our extensibility story, and this would be a good foundation for people to use, embed or extend. On top of that, I think it would be really cool to do some work to: - Make it easier to assemble a distributed SCA domain with components running on different runtimes / machines. - Improve our scripting and JSON-RPC support a little and show how to build Web 2.0 applications with Tuscany. - Improve our integration story with Tomcat and also start looking at an integration with Geronimo. - Improve our Spring-based core variant implementation, as I think it's a good example to show how to integrate Tuscany with other IoC containers. - Maybe start looking at the equivalent using Google Guice. - Start looking again at some of the extensions that we have in contrib or sandboxes (OSGI, ServiceMix, I think there's a Fractal extension in sandbox, more databindings etc). - ... I'm not sure we can do all of that in the next few weeks :) but I'd like to get your thoughts and see what people in the community would like to have in that next release... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Performance / API / Spec
Hey Frank,
Frank Budinsky wrote:
Hi Ole,
I found out today that it will take 2-3 months before the OASIS SDO
charter will be finalized and the discussions can begin. I'm involved with
the charter, so I can tell you that both of the issues you mentioned are
in scope for SDO 3, so they will be discussed once things get started.
Great.
For DataGraph.setRootObject(), the proposal is to either deprecate the
DataGraph interface entirely or to make DataGraph also be a DataObject.
Either way, you would set the root object using DataObject.set(). The root
object would be an open content property so you could set it by simply
calling something like this: dataGraph.set("company", myCompany).
Ah - I see.
DataGraph and DataObject do seem very closely related, like one is not
really needed.
I really like the EMF API here and wish the SDO API would do the same,
with a Resource (Which seems like a really good metaphor) containing a
graph of objects, and a ResourceSet containing many Resources. Then
start and stop logging could be called at the ResourceSet, Resource, and
DataObject levels, which seems like a clean way to cut it.
Anyways I'm jumping ahead :-)
I'll just collect ideas, and wait until the Charter gets finalized.
Thanks,
- Ole
Frank.
Ole Ersoy <[EMAIL PROTECTED]> wrote on 04/18/2007 01:41:53 PM:
Hi Frank,
I looked around osoa.org to sign up for a account,
but could not find a signup
page. Do you know if it's up yet?
Also, I noticed that there is no
setRootDataObject() method on the
DataGraph interface, but there is one on the
implementation.
It seems like it should be in the interface as well.
Do you know whether there is a "Whiteboard" somewhere,
where we can post SDO API suggestions? Should I perhaps
JIRA these in the Java Spec API section?
Thanks,
- Ole
Frank Budinsky wrote:
Hi Ole,
I'm not sure what reasoning was to justify the ChangeSummary API which
requires you to iterate over the one list returned by
getChangedDataObjects() and then call isCreated(), isModified(), or
isDeleted() to see if it was a C, U, or D.
If you look at class ChangeSummaryImpl, you'll notice that in Tuscany
we
actually implement this with three separate lists under the covers.
The
isDeleted() method, for example, looks like this:
public boolean isDeleted(DataObject dataObject)
{
return getCachedDeletedObjects().contains(dataObject);
}
I know that there is a proposed SDO 3 work item to revisit
ChangeSummary
to see if the API could be improved. Perhaps you'd like to get
involved in
the spec discussion on this issue, when it begins? Now that it's
moving to
OASIS (http://osoa.org/display/Main/News+about+SCA+and+SDO), SDO
design
discussions will be open to everyone.
Frank.
Ole Ersoy <[EMAIL PROTECTED]> wrote on 04/17/2007 12:27:58 PM:
Hi Guys,
I have a few performance related
questions with respect to change
summary processing (Really spec related - hope it's ok that I float
it
here).
I just looked at the Change
summary API and it looks like
the DataGraph sets the
isDeleted and isCreated
flags on each DataObject instance
that it creates or deletes, and
then it adds them to the change summary.
It seems like change summary
processing would perform better
if the Change summary had CUD lists.
So one list for:
- Created DataObjects
- Deleted DataObjects
- Update DataObjects
Then these lists could be processed directly by the
DAS and it would not have to check what type CUD
was done for each object.
Then the DataGraph only adds objects to these lists
and does not need to set any flags, which means that
during processing the flags don't need to be checked
in order to perform the right type of processing.
I'm still getting my feet wet here, but I thought I'd throw this out
there, since to me it seems like it's simpler and more light weight.
Thoughts?
Thanks,
- Ole
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 1.0 compliance questions
Rashmi Hunt wrote: >Yes it is supported. By default we add o.a.t.assembly.SCABinding objects >to promoted references and services, we do this in the last metadata >processing phase - CompositeProcessor.wire() - after SCA assembly XML >files have been read. Does this mean Tuscany loads just the model object which is o.a.t.assembly.SCABinding, eliminating the loader part for default binding? However binding implementation specific classes like xxxTargetInvoker, xxxServiceBinding, xxxReferenceBinding and builder which builds xxxServiceBinding and xxReferenceBinding are still required in binding implementation. Is this a correct assumption? -Rashmi Yes, exactly. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Hi, I created a prototype to play with aop-based logging and tracing. The annotation-style aspect development seems to be simpler as it doesn't require the aspectj compiler. You can see the code at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/rfeng/aop-logging You can download aspectj 1.5.3 from http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/aspectj-1.5.3.jar and then run the prototype using "test.bat" in the root of the project. Thanks, Raymond - Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 18, 2007 10:49 AM Subject: Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions) Hi, Please see my comments below. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 18, 2007 3:51 AM Subject: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions) On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I found our current Monitor stuff difficult to follow as well. I suggest that we start a new discussion thread to discuss monitoring in general, and try to come up with something that will be more usable and easier to adopt through our whole runtime. Starting the new thread for you... I agree we should improve monitoring and logging in the runtime. I've used AOP before for this type of thing, its cool, but it does add yet another new thing to know about which could be off putting for new developers. How about just using one of the existing logging packages that most people are already completely familiar with? Commons Logging looks like its coming to its end, no one really likes java.util.logging, so how about SLF4J, its really easy and nice to use? I personally don't like the Commons Logging approach very much due to the fact that conflicting versions are used by many 3rd party artifacts. With regard to AOP, do we really need to have all the developers learn how to use it? I assume we can put together some logging aspects in a separate module to take care of most of the logging/monitoring concerns. Other modules are not even aware of the existence of the AOP. Isn't it the objective of AOP to address the cross-cutting concerns without poluting the code? I also think exception handling could be improved, I don't find the current exception formatter design easy to use, and most times stack traces end up missing the important bit of information you need. How about just using the traditional way of putting everything in the exception message and using properties files to allow for I18N? I think we might be able to improve the ExceptionFormatter by providing a default formatter which could dump out all the information in the exception object. We already have a similar function in "org.apache.tuscany.assembly.util.PrintUtil" and we could further enhance it. To support I18N, we could adopt a pattern for the exception so that a getter or a field can be recoginzed as the message id. One thing I've wondered about was having a release specifically targeting these RAS type features. So once we've worked out the strategy for logging, exceptions, internationalization etc we have a release where a big focus is on implementing/fixing/testing all these RAS things. +1. Enabling RAS is a big effort. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Website: Download Page question
Hi, As I walk through Download links on the website I see that we are not consistent with the type of information we are providing and with where this information is stored. For example, SDO C++ Download page [1]: contains Download information for both SDO Java and SDO C++ SDO Java Download page [2]: contains Download information for only SDO Java I see the following options for fixing this: 1) A Download page for SCA (Java and native), A download page for SDO (Java and native) and a Download page for all DAS Types? 2) A spearate Download page for SCA/Java, SCA/native, SDO/Java, SDO/native, DAS 3) A download page per implementation language, meaning a Java Download, a native Download and under each page one would find links to all subprojects. 4) One Download page for all the projects with an index for all projects. My preference is option 1. If there is no strong objection, I'll go ahead and make it consistent based on option1. In addition to the above inconsistency, some of the links point to the old website. For example, the home page SCA Download link points to [3]. I am assuming that all download information should reside on cwiki now. Is this right? If so, I'll move all information to the Wiki. [1]: http://cwiki.apache.org/confluence/display/TUSCANY/SDO+Java+Download [2] http://cwiki.apache.org/confluence/display/TUSCANY/SDO+Java+Download [3] http://incubator.apache.org/tuscany/sca_downloads.html Haleh
Re: Website - Feedback please
These are done now: 1) Using SDO Java could move to 'user guide' on this page. +1 2) Code structure can move to get involved or even to the architecture doc +1 to moving to "get involved" On 4/17/07, kelvin goodson <[EMAIL PROTECTED]> wrote: I replied to this thread on the tuscany-user list On 12/04/07, haleh mahbod <[EMAIL PROTECTED]> wrote: > > Kelvin, > Thanks for your review. You mentioned that scopes should be the same when > on a given page. > I agree. I fixed it. We now have a sdo cpp FAQ and a sdo Java FAQ. I > also moved text from some of the mentioned threads to the FAQ. The ones I > did not is because I did not know how to net it down to a question and an > answer. > > You mentioned General heading can be called Tuscany or SDO General > heading. The General heading is more a collection of things that I couldn't > find a good title for on that page :) It is not intended to be general for > Tuscany. > > Some suggestion for the SDO Java page: > > 1) Using SDO Java could move to 'user guide' on this page. > 2) Code structure can move to get involved or even to the architecture doc > > If there is agreement, I go ahead and make the changes. > Haleh > > > On 4/12/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > Haleh, > > > > thanks for addressing these issues. One concern I have after a quick > > look > > is that on arriving at a pages such as > > http://cwiki.apache.org/TUSCANY/sdo-java.html some of the links on the > > left > > under a given heading go off to a scope that is not intuitive from the > > page > > that you were on. E.g. under the "General" sidebar heading, the FAQ > > link > > for Java SDO goes to a page that I think is intended to contain generic > > cross language SDO questions, i.e. up one level of abstraction from the > > page > > heading. It's been that way since version 3 of the file, and I can't > > work > > out whether it's intended that way, or just a result of copying the > > content > > from an existing C++ page. > > > > The next sidebar heading below FAQ --- "Downloads" --- relates to > > downloading SDO Java (i.e. at the same level of abstraction of the > > current > > page). I think it would be good if the sidebar headings grouped links > > at > > the same level of abstraction and made this clear from the heading name > > - > > e.g. "Tuscany General", or "SDO General" > > > > > > BTW, FWIW, this prompted me to just catalogue the set of tuscany-dev > > notes > > that I have put an "FAQ" label against when reading the list. I had the > > intention of reviewing this list to see what was worth refining into > > well > > formed info snippets some time, but haven't got to it yet. Maybe we > > can > > divide and conquer to add to the website's FAQ set. Does anyone else > > have > > anything like this? > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00469.html > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13291.html > > Ron Gavlin's response to tuscany-user of 5th of Jan (cant find a very > > good > > archive URL for this one) > > My response to Alexander Pankov of the 26th of Jan on t-user > > (again URL > > not readily found) > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00560.html > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00610.html > > The thread started by Adriano Crestani on 15th Feb "mvn problem?" > > Unanswered thread from Ignacio on 16th Feb > > Frank's responses to Murtaza Goga in the thread started 20th March > > > > http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200703.mbox/[EMAIL PROTECTED] > > The thread entitled "Root property that is not containment" started 29th > > of > > Jan > > The thread entitled "Getting started with Tuscany databinding" started > > on > > 10th April > > > > Regards, Kelvin. > > > > > > > > > > > > > > > > > > On 12/04/07, haleh mahbod < [EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > As mentioned in [1] I started working on the website and the first > > phase > > > is > > > ready for review. > > > > > > My first attempt ended up with something other than what I had > > originally > > > planned; which was to move content. Instead, I worked on the > > readability > > > of > > > the website. > > > I have tried to use a consistent look and feel across the pages to > > make > > > it > > > easier to find information. In addition, I tried to make > > the information > > > available progressively ( allowing the user to decide if they want to > > > learn > > > more). > > > > > > Here is the layout at a high level for the Tuscany Website ( > > > http://cwiki.apache.org/TUSCANY/) > > > > > >- Home page - On this page you will find the general stuff that > > apply > > >to the whole Tuscany as well as links to each subproject and > > Downloads. > > > - Each subproject has an overview page, for example SCA overview > > or > > >DAS overview. On the overview page you find a brief introduction to > > the > > >subproject and links to re
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Is SLF4J a better route than Log4j? If so, I wonder if we should convert over the RDB DAS. On 4/18/07, ant elder <[EMAIL PROTECTED]> wrote: On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I found our current Monitor stuff difficult to follow as well. I suggest > that we start a new discussion thread to discuss monitoring in general, > and try to come up with something that will be more usable and easier to > adopt through our whole runtime. Starting the new thread for you... I agree we should improve monitoring and logging in the runtime. I've used AOP before for this type of thing, its cool, but it does add yet another new thing to know about which could be off putting for new developers. How about just using one of the existing logging packages that most people are already completely familiar with? Commons Logging looks like its coming to its end, no one really likes java.util.logging, so how about SLF4J, its really easy and nice to use? I also think exception handling could be improved, I don't find the current exception formatter design easy to use, and most times stack traces end up missing the important bit of information you need. How about just using the traditional way of putting everything in the exception message and using properties files to allow for I18N? One thing I've wondered about was having a release specifically targeting these RAS type features. So once we've worked out the strategy for logging, exceptions, internationalization etc we have a release where a big focus is on implementing/fixing/testing all these RAS things. ...ant
Re: SCA 1.0 compliance questions
>Yes it is supported. By default we add o.a.t.assembly.SCABinding objects >to promoted references and services, we do this in the last metadata >processing phase - CompositeProcessor.wire() - after SCA assembly XML >files have been read. Does this mean Tuscany loads just the model object which is o.a.t.assembly.SCABinding, eliminating the loader part for default binding? However binding implementation specific classes like xxxTargetInvoker, xxxServiceBinding, xxxReferenceBinding and builder which builds xxxServiceBinding and xxReferenceBinding are still required in binding implementation. Is this a correct assumption? -Rashmi
Ability to use default binding across top-level-Composites?
Sorry, I don't have all the new code set up so let me just ask. Is it possible with the code in trunk today to, over the default binding, invoke a service that was deployed in a separate top-level-Composite? That is, say, to deploy a component in Composite A that invokes a component service which is deployed in a separate top-level-Composite, Composite B? Maybe what I'm asking is to what extent we've integrated the default binding with a concept of a Tuscany "domain". Thanks Scott
Re: SCA 1.0 compliance questions
Sebastien, I'm curious why we only add the o.a.t.assembly.SCABinding objects only to PROMOTED references and services. My understanding (which could be wrong) is that you'd only promote a ref/srvc to the Composite level if you intended to use this Composite as an impl of another component. So wouldn't we need to add the o.a.t.assembly.SCABinding (default binding) to the component level reference, at least if it were a component in a top-level-Composite. Sorry that some of my understanding and terminology might be a bit outdated. Scott
Re: [DAS] Performance / API / Spec
Hi Ole,
I found out today that it will take 2-3 months before the OASIS SDO
charter will be finalized and the discussions can begin. I'm involved with
the charter, so I can tell you that both of the issues you mentioned are
in scope for SDO 3, so they will be discussed once things get started.
For DataGraph.setRootObject(), the proposal is to either deprecate the
DataGraph interface entirely or to make DataGraph also be a DataObject.
Either way, you would set the root object using DataObject.set(). The root
object would be an open content property so you could set it by simply
calling something like this: dataGraph.set("company", myCompany).
Frank.
Ole Ersoy <[EMAIL PROTECTED]> wrote on 04/18/2007 01:41:53 PM:
> Hi Frank,
>
> I looked around osoa.org to sign up for a account,
> but could not find a signup
> page. Do you know if it's up yet?
>
> Also, I noticed that there is no
> setRootDataObject() method on the
> DataGraph interface, but there is one on the
> implementation.
>
> It seems like it should be in the interface as well.
>
> Do you know whether there is a "Whiteboard" somewhere,
> where we can post SDO API suggestions? Should I perhaps
> JIRA these in the Java Spec API section?
>
> Thanks,
> - Ole
>
>
>
> Frank Budinsky wrote:
> > Hi Ole,
> >
> > I'm not sure what reasoning was to justify the ChangeSummary API which
> > requires you to iterate over the one list returned by
> > getChangedDataObjects() and then call isCreated(), isModified(), or
> > isDeleted() to see if it was a C, U, or D.
> >
> > If you look at class ChangeSummaryImpl, you'll notice that in Tuscany
we
> > actually implement this with three separate lists under the covers.
The
> > isDeleted() method, for example, looks like this:
> >
> > public boolean isDeleted(DataObject dataObject)
> > {
> > return getCachedDeletedObjects().contains(dataObject);
> > }
> >
> > I know that there is a proposed SDO 3 work item to revisit
ChangeSummary
> > to see if the API could be improved. Perhaps you'd like to get
involved in
> > the spec discussion on this issue, when it begins? Now that it's
moving to
> > OASIS (http://osoa.org/display/Main/News+about+SCA+and+SDO), SDO
design
> > discussions will be open to everyone.
> >
> > Frank.
> >
> >
> > Ole Ersoy <[EMAIL PROTECTED]> wrote on 04/17/2007 12:27:58 PM:
> >
> >> Hi Guys,
> >>
> >> I have a few performance related
> >> questions with respect to change
> >> summary processing (Really spec related - hope it's ok that I float
it
> >> here).
> >>
> >> I just looked at the Change
> >> summary API and it looks like
> >> the DataGraph sets the
> >> isDeleted and isCreated
> >> flags on each DataObject instance
> >> that it creates or deletes, and
> >> then it adds them to the change summary.
> >>
> >> It seems like change summary
> >> processing would perform better
> >> if the Change summary had CUD lists.
> >>
> >> So one list for:
> >> - Created DataObjects
> >> - Deleted DataObjects
> >> - Update DataObjects
> >>
> >> Then these lists could be processed directly by the
> >> DAS and it would not have to check what type CUD
> >> was done for each object.
> >>
> >> Then the DataGraph only adds objects to these lists
> >> and does not need to set any flags, which means that
> >> during processing the flags don't need to be checked
> >> in order to perform the right type of processing.
> >>
> >> I'm still getting my feet wet here, but I thought I'd throw this out
> >> there, since to me it seems like it's simpler and more light weight.
> >>
> >> Thoughts?
> >>
> >> Thanks,
> >> - Ole
> >>
> >>
> >>
> >>
> >>
> >>
> >> -
> >> 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: SCA 1.0 compliance questions
Answers inline. Rashmi Hunt wrote: 1) As per 1.0 spec, bindings can be defined on a component. Component service can be promoted to be composite service as shown in below example. Question: Can current Tuscany's binding's loader/builder framework be able to load bindings which are defined under component? Is this currently supported? This is supported by our new assembly model and artifact processors (replacing the old loaders). We'll have to double check that the connect logic in the runtime deployer implements this correctly as well, i.e. establishes the correct invocation chain using that binding instead of the binding specified on the promoted reference of a nested composite. .. 2) As per 1.0 spec, "A service or reference definition with no binding element specified uses the SCA/default binding" Concrete sample is outlined below where there are no bindings defined under a service. Tuscany binding's extension framework is based on loader/builder framework which looks for in order to build Service and Reference. Question: Given this example how does Tuscany can build default binding, without defined? Is it currently supported? Yes it is supported. By default we add o.a.t.assembly.SCABinding objects to promoted references and services, we do this in the last metadata processing phase - CompositeProcessor.wire() - after SCA assembly XML files have been read. .. binding, which is binding.sca > Help is appreciated Regards Rashmi -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS config file thorwable
Tank you... 2007/4/18, Luciano Resende <[EMAIL PROTECTED]>: The ConnectionProperties as defined in config.xsd expect a field "userName" Could you please try that and let me know if it works for you ? Also, if you have any issues connecting with MySQL, I have a post [1] with some specific information on configuring DAS and MySQP together. [1] http://lresende.blogspot.com/2006/11/configuring-mysql-datasource-in-tomcat.html On 4/18/07, Paulo Henrique Trecenti <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm try using DAS and I want connect with MySQL without an Datasource and > the config file dosn't have a config for "UserName" and "Passowrd" when I > try use this > > > -->user="database" > -->password="database" > driverClass="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" > databaseURL="jdbc:mysql://localhost:3306/database" > loginTimeout="60"/> > > > the ConfigUtil dosn't read that. > I just can used that, setting the "UserName" and "Password" in the code. > > -- > Paulo Henrique Trecenti > -- Luciano Resende http://people.apache.org/~lresende -- Paulo Henrique Trecenti
Re: DAS config file thorwable
The ConnectionProperties as defined in config.xsd expect a field "userName" Could you please try that and let me know if it works for you ? Also, if you have any issues connecting with MySQL, I have a post [1] with some specific information on configuring DAS and MySQP together. [1] http://lresende.blogspot.com/2006/11/configuring-mysql-datasource-in-tomcat.html On 4/18/07, Paulo Henrique Trecenti <[EMAIL PROTECTED]> wrote: Hi, I'm try using DAS and I want connect with MySQL without an Datasource and the config file dosn't have a config for "UserName" and "Passowrd" when I try use this user="database" -->password="database" driverClass="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" databaseURL="jdbc:mysql://localhost:3306/database" loginTimeout="60"/> the ConfigUtil dosn't read that. I just can used that, setting the "UserName" and "Password" in the code. -- Paulo Henrique Trecenti -- Luciano Resende http://people.apache.org/~lresende
DAS config file thorwable
Hi, I'm try using DAS and I want connect with MySQL without an Datasource and the config file dosn't have a config for "UserName" and "Passowrd" when I try use this user="database" -->password="database" driverClass="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" databaseURL="jdbc:mysql://localhost:3306/database" loginTimeout="60"/> the ConfigUtil dosn't read that. I just can used that, setting the "UserName" and "Password" in the code. -- Paulo Henrique Trecenti
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Hi, Please see my comments below. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 18, 2007 3:51 AM Subject: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions) On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I found our current Monitor stuff difficult to follow as well. I suggest that we start a new discussion thread to discuss monitoring in general, and try to come up with something that will be more usable and easier to adopt through our whole runtime. Starting the new thread for you... I agree we should improve monitoring and logging in the runtime. I've used AOP before for this type of thing, its cool, but it does add yet another new thing to know about which could be off putting for new developers. How about just using one of the existing logging packages that most people are already completely familiar with? Commons Logging looks like its coming to its end, no one really likes java.util.logging, so how about SLF4J, its really easy and nice to use? I personally don't like the Commons Logging approach very much due to the fact that conflicting versions are used by many 3rd party artifacts. With regard to AOP, do we really need to have all the developers learn how to use it? I assume we can put together some logging aspects in a separate module to take care of most of the logging/monitoring concerns. Other modules are not even aware of the existence of the AOP. Isn't it the objective of AOP to address the cross-cutting concerns without poluting the code? I also think exception handling could be improved, I don't find the current exception formatter design easy to use, and most times stack traces end up missing the important bit of information you need. How about just using the traditional way of putting everything in the exception message and using properties files to allow for I18N? I think we might be able to improve the ExceptionFormatter by providing a default formatter which could dump out all the information in the exception object. We already have a similar function in "org.apache.tuscany.assembly.util.PrintUtil" and we could further enhance it. To support I18N, we could adopt a pattern for the exception so that a getter or a field can be recoginzed as the message id. One thing I've wondered about was having a release specifically targeting these RAS type features. So once we've worked out the strategy for logging, exceptions, internationalization etc we have a release where a big focus is on implementing/fixing/testing all these RAS things. +1. Enabling RAS is a big effort. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Performance / API / Spec
Hi Frank,
I looked around osoa.org to sign up for a account,
but could not find a signup
page. Do you know if it's up yet?
Also, I noticed that there is no
setRootDataObject() method on the
DataGraph interface, but there is one on the
implementation.
It seems like it should be in the interface as well.
Do you know whether there is a "Whiteboard" somewhere,
where we can post SDO API suggestions? Should I perhaps
JIRA these in the Java Spec API section?
Thanks,
- Ole
Frank Budinsky wrote:
Hi Ole,
I'm not sure what reasoning was to justify the ChangeSummary API which
requires you to iterate over the one list returned by
getChangedDataObjects() and then call isCreated(), isModified(), or
isDeleted() to see if it was a C, U, or D.
If you look at class ChangeSummaryImpl, you'll notice that in Tuscany we
actually implement this with three separate lists under the covers. The
isDeleted() method, for example, looks like this:
public boolean isDeleted(DataObject dataObject)
{
return getCachedDeletedObjects().contains(dataObject);
}
I know that there is a proposed SDO 3 work item to revisit ChangeSummary
to see if the API could be improved. Perhaps you'd like to get involved in
the spec discussion on this issue, when it begins? Now that it's moving to
OASIS (http://osoa.org/display/Main/News+about+SCA+and+SDO), SDO design
discussions will be open to everyone.
Frank.
Ole Ersoy <[EMAIL PROTECTED]> wrote on 04/17/2007 12:27:58 PM:
Hi Guys,
I have a few performance related
questions with respect to change
summary processing (Really spec related - hope it's ok that I float it
here).
I just looked at the Change
summary API and it looks like
the DataGraph sets the
isDeleted and isCreated
flags on each DataObject instance
that it creates or deletes, and
then it adds them to the change summary.
It seems like change summary
processing would perform better
if the Change summary had CUD lists.
So one list for:
- Created DataObjects
- Deleted DataObjects
- Update DataObjects
Then these lists could be processed directly by the
DAS and it would not have to check what type CUD
was done for each object.
Then the DataGraph only adds objects to these lists
and does not need to set any flags, which means that
during processing the flags don't need to be checked
in order to perform the right type of processing.
I'm still getting my feet wet here, but I thought I'd throw this out
there, since to me it seems like it's simpler and more light weight.
Thoughts?
Thanks,
- Ole
-
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] Resolved: (TUSCANY-826) Containment cycle should result in Exception
[ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-826. Resolution: Fixed resolved at revision 530092 by committing Brian's patch whereby circularities of containment are spotted when building XPaths during serialization by identifying a root object and detecting revisiting that root > Containment cycle should result in Exception > > > Key: TUSCANY-826 > URL: https://issues.apache.org/jira/browse/TUSCANY-826 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Windows XP, both Sun and IBM JVMs >Reporter: Brian Murray > Fix For: Java-SDO-Mx > > Attachments: 826.patch, 826.zip, ContainmentCycle.patch, > ContainmentCycleError.java, ContainmentTest.zip, Updated826.zip, > Updated826.zip, Updated826.zip > > > Near the bottom of page 19 in the 2.0.1 specification it is stated that > "Containment cannot have cycles. If a set or add would create a containment > cycle an exception is thrown." > However, I have found that no such exception is thrown. I will attach a test > case showing the creation of (and the potential to infinitely loop through) a > containment cycle. -- 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]
Improve/simplify the runtime further
Hi, I'm thinking of improving and simplifying the runtime further in the following directions: 1. Have the Tuscany runtime to maintain the SCA domain composite and refactor the DeployerImpl into the Domain service. 2. Simplify the relationship between runtime metadata (o.a.t.spi.Component/Service/Reference) for the invocations and model (o.a.t.assembly.*). 3. Improve the Wire/InvocationChain to support dynamic style invocation (in cases that we don't know or don't care about the interface/operation until runtime) in addtion to the operation-based invocation chain. 4. Implement the CallableReference/ServiceReference/CallbackReference. The list is not meant to be complete. Please feel free to add your ideas. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-826) Containment cycle should result in Exception
[ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Murray updated TUSCANY-826: - Attachment: Updated826.zip Updated the headers in the statically generated files. > Containment cycle should result in Exception > > > Key: TUSCANY-826 > URL: https://issues.apache.org/jira/browse/TUSCANY-826 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Windows XP, both Sun and IBM JVMs >Reporter: Brian Murray > Fix For: Java-SDO-Mx > > Attachments: 826.patch, 826.zip, ContainmentCycle.patch, > ContainmentCycleError.java, ContainmentTest.zip, Updated826.zip, > Updated826.zip, Updated826.zip > > > Near the bottom of page 19 in the 2.0.1 specification it is stated that > "Containment cannot have cycles. If a set or add would create a containment > cycle an exception is thrown." > However, I have found that no such exception is thrown. I will attach a test > case showing the creation of (and the potential to infinitely loop through) a > containment cycle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-826) Containment cycle should result in Exception
[ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489811 ] Kelvin Goodson commented on TUSCANY-826: Hi Brian, could you please change the headers in the static files for Apache License headers, thanks. > Containment cycle should result in Exception > > > Key: TUSCANY-826 > URL: https://issues.apache.org/jira/browse/TUSCANY-826 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Windows XP, both Sun and IBM JVMs >Reporter: Brian Murray > Fix For: Java-SDO-Mx > > Attachments: 826.patch, 826.zip, ContainmentCycle.patch, > ContainmentCycleError.java, ContainmentTest.zip, Updated826.zip, > Updated826.zip > > > Near the bottom of page 19 in the 2.0.1 specification it is stated that > "Containment cannot have cycles. If a set or add would create a containment > cycle an exception is thrown." > However, I have found that no such exception is thrown. I will attach a test > case showing the creation of (and the potential to infinitely loop through) a > containment cycle. -- 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]
SCA 1.0 compliance questions
1) As per 1.0 spec, bindings can be defined on a component. Component service can be promoted to be composite service as shown in below example. Question: Can current Tuscany's binding's loader/builder framework be able to load bindings which are defined under component? Is this currently supported? .. 2) As per 1.0 spec, "A service or reference definition with no binding element specified uses the SCA/default binding" Concrete sample is outlined below where there are no bindings defined under a service. Tuscany binding's extension framework is based on loader/builder framework which looks for in order to build Service and Reference. Question: Given this example how does Tuscany can build default binding, without defined? Is it currently supported? .. Help is appreciated Regards Rashmi
[jira] Assigned: (TUSCANY-1215) Support of property override with recursive scdl files
[ https://issues.apache.org/jira/browse/TUSCANY-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkatakrishnan reassigned TUSCANY-1215: Assignee: Venkatakrishnan > Support of property override with recursive scdl files > -- > > Key: TUSCANY-1215 > URL: https://issues.apache.org/jira/browse/TUSCANY-1215 > Project: Tuscany > Issue Type: Improvement >Affects Versions: Java-SCA-M2 > Environment: All >Reporter: Hasan Muhammad > Assigned To: Venkatakrishnan > > We were trying this scenario out where we have a section in the default scdl > as follows: > > > > MySimpleServiceInRecursiveAnother/MyServiceNew1 > > > > > > Durham > 2009 > > We have the two properties newLocation and newYear defined in > mySimpleService.scdl as follows: > > > MyServiceComponentNew/MyService > > Raleigh > 2008 > > > > > > When we try to get the property of location through MySimpleServiceAnother, > it gives back the value "Raleigh". It should give "Durham", In other words > during runtime, the original value must be overwritten with the new one that > we provided in the default.scdl under the component > "MySimpleServiceInRecursiveAnother". This feature of property override needs > to be supported. > Hasan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Account signup
Twas me, was just tidying JIRA things, no malicious intent :) Its just a place holder userid just for its user name "Tuscany Developers" for our JIRA project. Its not actually used for anything and isn't subscribed to anything so shouldn't cause duplicate notifications. ...ant On 4/18/07, kelvin goodson <[EMAIL PROTECTED]> wrote: Is this intentional on somebody's part or is it malicious in some way. I can't see that it would be particularly malicious, but I imagine that anyone subscribed to tucany-dev will now get JIRA notifications twice. Can whoever has done this please explain why? Thanks, Kelvin. On 18/04/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > You have signed up for a JIRA account at: > >https://issues.apache.org/jira > > Here are the details of your account: > - > Username: tuscany-dev@ws.apache.org >Email: tuscany-dev@ws.apache.org >Full Name: Tuscany Developers > Password: ant8pies > (You can always retrieve these via the "Forgot Password" link on the > signup page) > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [jira] Account signup
Is this intentional on somebody's part or is it malicious in some way. I can't see that it would be particularly malicious, but I imagine that anyone subscribed to tucany-dev will now get JIRA notifications twice. Can whoever has done this please explain why? Thanks, Kelvin. On 18/04/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: You have signed up for a JIRA account at: https://issues.apache.org/jira Here are the details of your account: - Username: tuscany-dev@ws.apache.org Email: tuscany-dev@ws.apache.org Full Name: Tuscany Developers Password: ant8pies (You can always retrieve these via the "Forgot Password" link on the signup page) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Account signup
You have signed up for a JIRA account at: https://issues.apache.org/jira Here are the details of your account: - Username: tuscany-dev@ws.apache.org Email: tuscany-dev@ws.apache.org Full Name: Tuscany Developers Password: ant8pies (You can always retrieve these via the "Forgot Password" link on the signup page) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Ant Replies in line On 4/18/07, ant elder <[EMAIL PROTECTED]> wrote: On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I found our current Monitor stuff difficult to follow as well. I suggest > that we start a new discussion thread to discuss monitoring in general, > and try to come up with something that will be more usable and easier to > adopt through our whole runtime. Starting the new thread for you... I agree we should improve monitoring and logging in the runtime. I've used AOP before for this type of thing, its cool, but it does add yet another new thing to know about which could be off putting for new developers. How about just using one of the existing logging packages that most people are already completely familiar with? Commons Logging looks like its coming to its end, no one really likes java.util.logging, so how about SLF4J, its really easy and nice to use? Simple is good. I've not done much with Aspects but we could really do with keeping down the complexity quotient I think. I'm keen that whatever information we put out can be transported to whatever management solution is used in the future so having a facade for accepting logged information sounds good. We can start off with a simple console logger and migrate to more complex distributed managment/logging solutions if required in the future. I also think exception handling could be improved, I don't find the current exception formatter design easy to use, and most times stack traces end up missing the important bit of information you need. How about just using the traditional way of putting everything in the exception message and using properties files to allow for I18N? I agree that I find the current exception messages lacking but I have to admit to not having studied how they are implemented so I'll go take a look and come back on this one. One thing I've wondered about was having a release specifically targeting these RAS type features. So once we've worked out the strategy for logging, exceptions, internationalization etc we have a release where a big focus is on implementing/fixing/testing all these RAS things. +1 I'm stringly in favour of this and would very much like to help out. Even if it's not all of the community if a few of us can take a sweep through the code and get the level of error reporting/logging up a notch then that's going to improve our usability no end. People don't expect the software to be perfect but if it fails and doesn't give any clues in lots of cases that that gives a bad impression. This is particulalry the case when the failure is down to user input. So we need to be really careful about loading the assembly model and loading extensions to report any detected inconsistencies in a easy to understand manner. ...ant Simon
Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I found our current Monitor stuff difficult to follow as well. I suggest that we start a new discussion thread to discuss monitoring in general, and try to come up with something that will be more usable and easier to adopt through our whole runtime. Starting the new thread for you... I agree we should improve monitoring and logging in the runtime. I've used AOP before for this type of thing, its cool, but it does add yet another new thing to know about which could be off putting for new developers. How about just using one of the existing logging packages that most people are already completely familiar with? Commons Logging looks like its coming to its end, no one really likes java.util.logging, so how about SLF4J, its really easy and nice to use? I also think exception handling could be improved, I don't find the current exception formatter design easy to use, and most times stack traces end up missing the important bit of information you need. How about just using the traditional way of putting everything in the exception message and using properties files to allow for I18N? One thing I've wondered about was having a release specifically targeting these RAS type features. So once we've worked out the strategy for logging, exceptions, internationalization etc we have a release where a big focus is on implementing/fixing/testing all these RAS things. ...ant
[jira] Commented: (TUSCANY-1217) Loading nested includes.
[
https://issues.apache.org/jira/browse/TUSCANY-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489687
]
Simon Laws commented on TUSCANY-1217:
-
This is discussed on the list in this thread:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16698.html
And is currently demonstrated in the databinding itest.
> Loading nested includes.
> -
>
> Key: TUSCANY-1217
> URL: https://issues.apache.org/jira/browse/TUSCANY-1217
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Kernel
>Affects Versions: Java-SCA-Next
> Environment: All
>Reporter: Simon Laws
>Priority: Minor
>
> Lest we forget...
> Currently there is code in WSDLDocumentProcessor.read() (the two lines with
> the comment above them).
> // Read inline schemas
> Types types = definition.getTypes();
> if (types != null) {
> wsdlDefinition.getInlinedSchemas().setSchemaResolver(new
> URIResolverImpl());
> for (Object ext : types.getExtensibilityElements()) {
> if (ext instanceof Schema) {
> Element element = ((Schema)ext).getElement();
> // TODO: temporary fix to make includes in imported
> // schema work. The XmlSchema library was
> crashing
> // because the base uri was not set. This
> doesn't
> // affect imports.
> XmlSchemaCollection schemaCollection =
> wsdlDefinition.getInlinedSchemas();
>
> schemaCollection.setBaseUri(((Schema)ext).getDocumentBaseURI());
> wsdlDefinition.getInlinedSchemas().read(element,
> element.getBaseURI());
> }
> }
> }
> Which sets the base dir against which included XSD files are loaded. However
> this seems to mean that in the scenario:
> WSDL1 import---> XSD1 inlcude.---> XSD2
>
> Then XSD2 has to be included relative to the location of WSDL1 which doesn't
> sound right.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1217) Loading nested includes.
Loading nested includes.
-
Key: TUSCANY-1217
URL: https://issues.apache.org/jira/browse/TUSCANY-1217
Project: Tuscany
Issue Type: Bug
Components: Java SCA Kernel
Affects Versions: Java-SCA-Next
Environment: All
Reporter: Simon Laws
Priority: Minor
Lest we forget...
Currently there is code in WSDLDocumentProcessor.read() (the two lines with
the comment above them).
// Read inline schemas
Types types = definition.getTypes();
if (types != null) {
wsdlDefinition.getInlinedSchemas().setSchemaResolver(new
URIResolverImpl());
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
// TODO: temporary fix to make includes in imported
// schema work. The XmlSchema library was crashing
// because the base uri was not set. This doesn't
// affect imports.
XmlSchemaCollection schemaCollection =
wsdlDefinition.getInlinedSchemas();
schemaCollection.setBaseUri(((Schema)ext).getDocumentBaseURI());
wsdlDefinition.getInlinedSchemas().read(element,
element.getBaseURI());
}
}
}
Which sets the base dir against which included XSD files are loaded. However
this seems to mean that in the scenario:
WSDL1 import---> XSD1 inlcude.---> XSD2
Then XSD2 has to be included relative to the location of WSDL1 which doesn't
sound right.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of HelperContext to indetify SDO databinding?
On 4/16/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Simon.
I think you hit the point. We still need to flush out the complete design
on
how to scope SDO metadata and how to provide access to the SCA components.
At this moment, I register the SDO types with the default helper context
too
(HelperProvider.getDefaultContext()). Please let me know which test case I
can use to further investigate.
Thanks,
Raymond
- Original Message -
From: "Simon Laws" <[EMAIL PROTECTED]>
To: "tuscany-dev"
Sent: Monday, April 16, 2007 2:04 PM
Subject: Use of HelperContext to indetify SDO databinding?
> Static SDO used in the databinding tests with the Axis2 binding are not
> being successfully identified as SDOs.
> In SDODataBinding.introspect() one of the tests use to identify and SDO
> from
> a Java type is as follows
>
>HelperContext context = HelperProvider.getDefaultContext();
>
>...
>
>// FIXME: We need to access HelperContext
>Type type = context.getTypeHelper().getType(javaType);
>if (type == null) {
>return false;
>}
>
> However when the ImportSDO functionality runs it associates the importer
> with a HelperContext from the helperContextRegistry.
>
> helperContext = helperContextRegistry.getHelperContext(id);
>
> This doesn't look right to me as I expect different HelperContexts will
be
> used. I can't work out how to get to the helperContextRegistry from the
> SDODataBinding (and it's getting late) but if someone who knows
> databindings
> could take a look and confirm or not whether this is an issue I can take
a
> look tomorrow.
>
> Regards
>
> Simon
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Raymond
Sorry about the delay, I had to go do something else yesterday. Anyhow I
tracked down the problem this morning. The CompositeProcessor resolves the
artifacts in the composite in the wrong order. I.e. it resolves components
before it has resolves the extensions, e.g. SDO imports, that the components
depend on.
Moving the extension processing loop above the component processing loop in
CompositeProcessor.resolve works for me. Am just testing my build etc. to
make sure there are no detrimental effects but will check this in when done.
Regards
Simon
Re: Intermittent failures in tests using the HTTP services
On 4/18/07, ant elder <[EMAIL PROTECTED]> wrote: I get intermittent build failures when running the build in the testcases which use the HTTP service, the error is pasted in below, is anyone else seeing this? Its really easy (in my environment) to recreate, change into sca\modules\binding-ws-axis2 and run mvn, around 50% of the time one of the testcases will fail. This looks just like the problem some of us were seeing with testcases in the integration branch, that did seem to be a Windows only problem, but I'm not sure we ever got to the bottom of it. ...ant Caused by: java.net.BindException: Address already in use: bind at sun.nio.ch.Net.bind(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind( ServerSocketChannelImpl.java:119) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java :59) at org.mortbay.jetty.nio.SelectChannelConnector.open( SelectChannelConnector.java:198) at org.mortbay.jetty.AbstractConnector.doStart( AbstractConnector.java:251) at org.mortbay.jetty.nio.SelectChannelConnector.doStart( SelectChannelConnector.java:233) at org.mortbay.component.AbstractLifeCycle.start( AbstractLifeCycle.java:40) at org.mortbay.jetty.Server.doStart(Server.java:221) at org.mortbay.component.AbstractLifeCycle.start( AbstractLifeCycle.java:40) at org.apache.tuscany.http.jetty.JettyServer.addServletMapping( JettyServer.java:175) Ant I'm on windows but not seeing this at the moment. The only time I have seen the message is when I've had another app open on 8080 by accident (A VOIP app as it happens with took me by surprise a little). I'll keep an eye out and report back here if I start to see it. Simon
RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase
Hi Kelvin,
Robbie's main concern seems to be the ability to run the tests within a
J2EE or service container and he mentions "classloader hierarchy" issues
in his description. I'm guessing that the junit test runner uses a
custom class loader that caused problems when used within a J2EE
container. Now that we have established that the test cases themselves
can be invoked using reflection it seems that users should be able to
write code that calls the tests directly from their own, or from some
other testing framework, without any dependency on the junit test
runner.
Thanks,
Andy.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of kelvin goodson
Sent: 17 April 2007 16:59
To: Andy Grove
Cc: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase
Andy,
that's really helpful. I guess my problem was, and still is to some
extent, knowing whether reliance upon the junit.jar is acceptable to the
set of people we are trying to cater for. I think your example has made
something clear to me though, which is that our prime aim would be to
cater for the junit harness or anyone's home grown harness, but not
necessarily another 3rd party harness. Do you think this is what the
original intention of the meaning of "harness agnostic" is?
Regards, Kelvin.
On 17/04/07, Andy Grove <[EMAIL PROTECTED]> wrote:
To better understand this myself, I just put a simple test case
together
using junit 4.1 with annotations and made use of the junit
assertion
calls e.g.
public class MyTest {
@Test
public void testSomething() {
// this test will fail
assertEquals( "numbers are same", 1, 2 );
}
}
I then wrote a simple test harness to load the test class using
reflection and invoke any methods starting with "test".
public static void main(String[] args) throws Exception {
Class testClass = Class.forName( "test.MyTest" );
Object testObject = testClass.newInstance();
Method method[] = testClass.getMethods();
for (int i = 0; i < method.length; i++) {
if (method[i].getName().startsWith("test")) {
System.out.println("Running " +
method[i].getName());
try {
method[i].invoke( testObject );
} catch (Throwable th) {
th.printStackTrace();
}
}
}
}
This ran the above test method and caught the following
exception:
java.lang.AssertionError: numbers are same expected:<1> but
was:<2>
For me, this seems to demonstrate that using junit 4.1 style
tests will
allow people to call their tests from their own test harnesses
without
requiring junit-users to have to go to any special effort. The
junit
Assert.* methods simply check some criteria and then call fail()
if that
criteria is false. The fail() method simply throws an
AssertionError.
Writing the CTS tests using junit with annotations (rather than
extending TestCase) does seem to provide everything required to
allow
users to run the tests outside of junit, albeit with a
dependency on
junit.jar but I don't see why that would be a problem for
anyone? We
could write our own versions of the assert* methods but they
would do
exactly the same thing as the junit implementation so this seems
rather
pointless.
My conclusion is that we should continue writing SDO CTS tests
using
junit, but ensure we use the annotation pattern rather than
extending
TestCase. Is everyone happy with this?
Thanks,
Andy.
-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: 17 April 2007 14:53
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp
when
classes don't inherit from TestCase
Yes, I was about to write to the list on this subject. I'd like
to
understand more of how the test harness agnosticism was
intended, and
whether its really practical. As it stands there is still junit
through
and through, in particular, each test method still references
junit
assertion calls. Even if we could do assertions from
annotations (as
per JML pre and post conditions), we still have all the junit
imports.
If that were possible, then I guess each of the test methods
could be
invoked by something other than the junit test harness, but
they would
Intermittent failures in tests using the HTTP services
I get intermittent build failures when running the build in the testcases which use the HTTP service, the error is pasted in below, is anyone else seeing this? Its really easy (in my environment) to recreate, change into sca\modules\binding-ws-axis2 and run mvn, around 50% of the time one of the testcases will fail. This looks just like the problem some of us were seeing with testcases in the integration branch, that did seem to be a Windows only problem, but I'm not sure we ever got to the bottom of it. ...ant Caused by: java.net.BindException: Address already in use: bind at sun.nio.ch.Net.bind(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind( ServerSocketChannelImpl.java:119) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) at org.mortbay.jetty.nio.SelectChannelConnector.open( SelectChannelConnector.java:198) at org.mortbay.jetty.AbstractConnector.doStart( AbstractConnector.java:251) at org.mortbay.jetty.nio.SelectChannelConnector.doStart( SelectChannelConnector.java:233) at org.mortbay.component.AbstractLifeCycle.start( AbstractLifeCycle.java:40) at org.mortbay.jetty.Server.doStart(Server.java:221) at org.mortbay.component.AbstractLifeCycle.start( AbstractLifeCycle.java:40) at org.apache.tuscany.http.jetty.JettyServer.addServletMapping( JettyServer.java:175)
RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase
Frank,
You're absolutely right. I guess I'd forgotten that you could override a
protected method and make it public.
In that case, it doesn't seem to matter if we use "old-style" junit or
annotations - it should still be possible to call the tests without
using the junit test runners.
Andy.
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: 17 April 2007 18:01
To: tuscany-dev@ws.apache.org
Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase
Hi Andy,
Java allows you make something more visible in a derived class than in
the base, so declaring setUp() public in MyTest wouldn't seem to be a
problem.
Frank
"Andy Grove" <[EMAIL PROTECTED]> wrote on 04/17/2007 12:19:37 PM:
> Hi Frank,
>
> The TestCase class defines setUp and tearDown as protected methods,
> forcing the child class to also declare them as protected methods and
> this means they can't be loaded using reflection.
>
> Using junit 4.1 means we can declare the methods as public.
>
> Thanks,
>
> Andy.
>
> -Original Message-
> From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> Sent: 17 April 2007 17:03
> To: tuscany-dev@ws.apache.org
> Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes don't inherit from TestCase
>
> Hi Andy,
>
> Maybe this is a stupid question (my junit ignorance showing through
:-),
> but couldn't you have run your simple test harness (main) even if
MyTest
> extended from TestCase? Is there something about having the base class
> that prevents you from simply invoking the test methods directly?
>
> Frank.
>
> "Andy Grove" <[EMAIL PROTECTED]> wrote on 04/17/2007 11:21:49 AM:
>
> >
> > To better understand this myself, I just put a simple test case
> > together using junit 4.1 with annotations and made use of the junit
> > assertion calls e.g.
> >
> > public class MyTest {
> > @Test
> > public void testSomething() {
> > // this test will fail
> > assertEquals( "numbers are same", 1, 2 );
> > }
> > }
> >
> > I then wrote a simple test harness to load the test class using
> > reflection and invoke any methods starting with "test".
> >
> > public static void main(String[] args) throws Exception {
> > Class testClass = Class.forName( "test.MyTest" );
> > Object testObject = testClass.newInstance();
> > Method method[] = testClass.getMethods();
> > for (int i = 0; i < method.length; i++) {
> > if (method[i].getName().startsWith("test")) {
> > System.out.println("Running " +
method[i].getName());
> > try {
> > method[i].invoke( testObject );
> > } catch (Throwable th) {
> > th.printStackTrace();
> > }
> > }
> > }
> > }
> >
> > This ran the above test method and caught the following exception:
> >
> > java.lang.AssertionError: numbers are same expected:<1> but was:<2>
> >
> > For me, this seems to demonstrate that using junit 4.1 style tests
> > will allow people to call their tests from their own test harnesses
> > without requiring junit-users to have to go to any special effort.
The
>
> > junit
> > Assert.* methods simply check some criteria and then call fail() if
> > that criteria is false. The fail() method simply throws an
> AssertionError.
> >
> > Writing the CTS tests using junit with annotations (rather than
> > extending TestCase) does seem to provide everything required to
allow
> > users to run the tests outside of junit, albeit with a dependency on
> > junit.jar but I don't see why that would be a problem for anyone? We
> > could write our own versions of the assert* methods but they would
do
> > exactly the same thing as the junit implementation so this seems
> > rather pointless.
> >
> > My conclusion is that we should continue writing SDO CTS tests using
> > junit, but ensure we use the annotation pattern rather than
extending
> > TestCase. Is everyone happy with this?
> >
> > Thanks,
> >
> > Andy.
> >
> >
> > -Original Message-
> > From: kelvin goodson [mailto:[EMAIL PROTECTED]
> > Sent: 17 April 2007 14:53
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> > classes don't inherit from TestCase
> >
> > Yes, I was about to write to the list on this subject. I'd like to
> > understand more of how the test harness agnosticism was intended,
and
> > whether its really practical. As it stands there is still junit
> > through and through, in particular, each test method still
references
>
> > junit assertion calls. Even if we could do assertions from
> > annotations (as per JML pre and post conditions), we still have all
> the junit imports.
> > If that were possible, then I guess each of the test methods could
be
> > invoked by something other than the junit test harness, but they
> > would h
Re: Problem (?) in sdo2om databinding test case
On 4/17/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Did you run with "mvn clean install"? It seems that you have some obsolete classes in the target folder. Thanks, Raymond - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: "tuscany-dev" Sent: Tuesday, April 17, 2007 10:15 AM Subject: Problem (?) in sdo2om databinding test case > Just doing a complete build from scratch (repo clean etc.) and I go the > following in the maven build > > Running org.apache.tuscany.databinding.sdo2om.DataObject2OMElementTestCase > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.011sec > <<< FA > ILURE! > testTransform( > org.apache.tuscany.databinding.sdo2om.DataObject2OMElementTestCase > ) Time elapsed: 0.891 sec <<< ERROR! > java.lang.NoSuchFieldError: > org/apache/tuscany/databinding/sdo2om/DataObject2OME > lementTestCase.context >at > org.apache.tuscany.databinding.sdo2om.DataObject2OMElementTestCase.te > stTransform(DataObject2OMElementTestCase.java:32) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl. > java:64) >at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAcces > sorImpl.java:43) >at java.lang.reflect.Method.invoke(Method.java:615) >at junit.framework.TestCase.runTest(TestCase.java:168) >at junit.framework.TestCase.runBare(TestCase.java:134) >at junit.framework.TestResult$1.protect(TestResult.java:110) >at junit.framework.TestResult.runProtected(TestResult.java:128) >at junit.framework.TestResult.run(TestResult.java:113) > > Is anyone else seeing this or should I be looking to start from scratch > again? > > Regards > > Simon > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Raymond. Your are of course right. Coming back with a fresh eye this morning it all builds OK. Thanks Simon
