Kenneth Tam wrote:
+1 for this, but I don't think the two layouts are actually in conflict.
I completely agree SDO and SCA should build/test/package/potentially
ship separately, and the directory structure should support that. I
think:
cpp/sca/
cpp/sdo/
java/sca/
java/sdo/
is the
Trieloff, Carl wrote:
How does SCA integrate with JMX/ and deal with dynamic configuration? Does it
define a model
or is it up to the implementer?
To my knowledge this is an area the spec has not yet addressed although
a common management model would seem to be a good idea (not just for
Thanks!
Guillaume Nodet wrote:
FYI, i asked the maven team to upload all needed eclipse dependencies on
ibiblio.
See http://www.ibiblio.org/maven2/org/eclipse/
Cheers,
Guillaume Nodet
The default JIRA permission setup has a few different types of users:
* anyone, basically anonymous, who can view things
* jira-user, people who have accounts, who can create issues
and add information to them
* tuscany-developers who can modify issues, assign them, close them
for the Tuscany
Pete Robbins wrote:
ok, I'm fine with that. Under branch/ would you expect to see partial trees,
e.g. myBranhName/cpp/sdo?
I think so, where the partial tree would be the code associated with the
specific branch. So if we decided that it was time to branch for version
1.2 of the C++ SDO
I would prefer we remove them from the main trunk and if possible remove
them all together. This emphasizes the canon that the one true build is
using the build system.
Having said that, having them available makes it easier for many people
to get started so there should be an easy way to get
FYI
Original Message
Subject: tuscany-dev added to Gmane
Date: Thu, 12 Jan 2006 11:50:06 -0600
From: admin_at_m.gmane.org (Gmane Administrator)
Organization: Mail To News -- http://gmane.org/
To: [EMAIL PROTECTED]
We have received a request for adding the
Tarek Hammoud wrote:
Hello,
This looks like a very promising project. Thanks for all the effort.
Will it be possible for some kind soul to put up a binary distribution
of the SDO implementation for us mere mortals that just want to use this
stuff. There are too many maven/emf and other
Pete Robbins wrote:
How do I create new Components in Jira for Tuscany. I'd like:
cpp Build
cpp SCA
cpp SDO
Created. I used C++ instead of cpp as there are no issues with characters.
--
Jeremy
Frank Budinsky wrote:
Ultimately though it would be good if people could use SDO2 without
needed to generate any code at all. Wouldn't it be possible to provide
implementations of user interfaces using Java Proxies (perhaps with
codegen using ASM or something to boost performance)?
Well, a
08:34:34 PM:
On Jan 18, 2006, at 3:14 PM, Jeremy Boynes wrote:
Frank Budinsky wrote:
Ultimately though it would be good if people could use SDO2
without
needed to generate any code at all. Wouldn't it be possible to
provide
implementations of user interfaces using Java
On 1/19/06, Jim Marino [EMAIL PROTECTED] wrote:
When I run maven from 'java', I get the following failure on OS X.
Is this something people know about?
No. I built this morning on WinXP for the first time in a while and
did not have any issues.
Derby used to have problems on OSX. There was a
I was chatting with one of the Maven guys at ApacheCon and was told
that although it is early days they have done some C++ projects.
Although it might be atypical for a C++ project, it may make the
integration with the Java project easier (e.g. when we want to host
C++ components in Java or Java
Jim Marino wrote:
The problem was the issue Jeremy pointed to (http://issues.apache.org/
jira/browse/DERBY-1). I ran into this problem on two separate OS X
machines. A workaround is to set the command line option -
Dderby.storage.fileSyncTransactionLog=true when running Maven. Ideally,
we
On 1/24/06, Kevin Williams [EMAIL PROTECTED] wrote:
That is good news! I can take care of the upgrade but I wonder if we
should wait until derby 10.1.2.1 is available on ibiblio? Jeremy, do
you have an opinion?
I can add derby to the mini-repo on my homepage and start the process
of getting
Any news on running the acceptance tests with m2?
--
Jeremy
ant elder wrote:
As a way to learn more about how the Tuscany Java code works I've been
trying to extend it with a new component implementation type for invoking
JavaScript scripts. This mostly works now, scripts are invoked using Mozilla
Rhino and can be configured in the usual SCA way with
ant elder wrote:
Also be good having another Synapsian ...
Does that make us Tuscan?
--
Jeremy
Lance Waterman wrote:
This is the exact process I am using to understand the implementation. One
thing I have been struggling with is the developer workflow around web
services. I can see these generated SDO classes in the samples however, I'm
a novice to SDO and don't really understand the
Lance Waterman wrote:
Thanks - I'll take a look at the new SDO2 implementation. I think an m2
plugin that generates the sample classes would help articulate the web
services workflow nicely. I'm not sure what you mean by ... does not merge
with any existing Java classes ...? If I am starting
Jim Marino wrote:
Hi, wanted to continue this in a separate thread based on Sebastien's
comments:
3. Start a separate discussion on our test strategy
- decide the test suites that we want to have (unit / build verification
/ function / integration tests)
For starters we could have the
On 1/31/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Yes, we shouldn't allow anonymous users to raise issues, we got the same
recommendation from Paul who ran into problems with this in the Synapse
project, but logged on users should be able to work with the issues they
create.
Do the
I would like to upload a presentation I did to the RTP WUG to the
Tuscany site - is there a good location on the site to post it to and
in what format? Currently I have a PPT file.
Thanks
--
Jeremy
I can't but help sense a disconnect, specifically over what a unit test is.
Quoting the oracle, OK http://en.wikipedia.org/wiki/Unit_testing
a unit test is a procedure used to verify that a particular module of
source code is working properly They are of use to *developers* to
check a specific
On 2/1/06, Frank Budinsky [EMAIL PROTECTED] wrote:
I took a look at the code and think this is very cool. There are actually
two independent (but most often used together) things being demonstrated
in the prototype:
1) extracting the SDO metamodel from an annotated Java interface.
2) runtime
To subscribe please send a mail to [EMAIL PROTECTED]
Chidanandan Theyancheri wrote:
On 2/2/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jeremy Boynes wrote:
On 2/2/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Yes there is a disconnect here. Thanks for educating us on what a unit
test is, but somebody is going to have to explain to me how we test
Tuscany
I was looking to add a JavaHelper for the Tuscany implementation to help
build up SDO types from Java interfaces but ran into a couple of issues.
Can someone point me in the right direction?
The HelperProvider factory constructs the implementation in a static
initializer using:
static
[EMAIL PROTECTED] wrote:
Hello, Suraksha. The timeout error seems to be an intermittent
problem, in my experience. It's not always the same dependency,
and it some times happens more than once in the course of doing
a full build from scratch, at least for me. I have not yet found
the
Frank Budinsky wrote:
My observation is that 2 seems to be a/the common approach. If I'm wrong
can somebody who knows better please correct me.
In circumstances like this, 2) works for me assuming there is an
associated JIRA issue that highlights the failing tests so they don't
get forgotten
[EMAIL PROTECTED] wrote:
Charles Rineholt wrote:
This used to ge t kicked off by the acceptance tests set up tomcat
and exercise the end user scenarios. I think somone is still
looking into that ?
Hi Rick. There are a sequence of patches uploaded to the TUSCANY-1 JIRA
entry concerning
Jim Marino wrote:
Cases are coming up where it would be useful to be able to share mock
objects or convenience classes between unit tests in different
projects, e.g. o.a.t.core and o.a.t.container.java. Do people feel it
is appropriate to allow references in the Maven project files between
hung tran wrote:
hello all,
i'm wondering if dynamic invocation of components is possible.
As I've been only testing Tuscany on Tomcat, it currently seems that i
would need to be in the same webapp as the component i'm trying to invoke.
What i would like to do is be able to invoke any
ant elder wrote:
If an sca.module file defines an external service and I call ModuleContext
locateService with the external service name it throws a
ServiceNotFoundException. Page 15 of the SCA Client and Implementation
model for Java makes it sound like locateService should find external
ant elder wrote:
Does there have to be a wire?
No, there doesn't - note to self, drink coffee before doing email.
An example is something like:
sca.module:
module xmlns=http://www.osoa.org/xmlns/sca/0.9;
xmlns:v=http://www.osoa.org/xmlns/sca/values/0.9;
I refactored the implementation of the runtime context to move it from
the system package up to a separate package in the root of the core
module. This keeps the implementation of the bootstrap and runtime
environment separate from the infrastructure for the system contexts.
--
Jeremy
The lifecycle of a module scope is split into two parts: the scope
context itself has a start method which basically does nothing, the
scope does not really start until it is sent a MODULE_START event.
For things like session scope this makes sense as the lifetime of the
scope container is longer
Jim Marino wrote:
In our POMs, we have the following dependency:
dependency
groupIdorg.eclipse.emf/groupId
artifactIdcommonj-sdo/artifactId
version2.1.0/version
/dependency
So does 2.1.0 refer to the eclipse version, not the spec jar?
I know there is a lot going on but please can we be a bit more
descriptive when commiting changes. Recent log messages have included:
some cleanup
more external service work
Fixed a bug in wiring
which are a lot less informative than others such as
Fixed a bug with AnyDataObject returning Ecore
I have been having issues with trying to get a reference between two
system components in the same module working (see Tuscany-43, 45 and
46). I've worked around most but I am now seeing a problem when it tries
to resolve the reference:
org.apache.tuscany.core.context.TargetException: Component
Jim and I looked through this and we believe there is a problem with the
way in which the model is being built. When the module component (mc) is
registered, the builder visits the model recursively descending into all
child elements. However, when it recurses, it does not update the
intended
Jason Henley wrote:
Ok, last question then. For the Java piece, do I need to build
/contrib/java/trunk/* AND /java/* or just one of them?
The answer to this is probably somewhere in the archive so I apologize now.
Just /java/** - the contrib was just the initial contribution and is now
It's not working yet - I can do that once things are.
--
Jeremy
Jean-Sebastien Delfino wrote:
Jeremy,
Could you please send a brief description of how to configure Tomcat to
use your new bootstrap code? I'm not sure what kind of listeners are
required and in which Tomcat config file they
Jeremy Boynes wrote:
There is a quick fix we can do for this if we are prepared to assume
that we only have a single level of composition. In that case, we can
register the module component first with no implementation, then
register and build it's implementation (the module element
Frank Budinsky wrote:
You're right about the problem. If the SDO loader can't find/load the
metadata it will
dynamically load it as an ANY type instance. Since it's a generated model,
the metadata
is supposed to be getting registered by a call to
on the Thread in the form of the TCCL. As a user, we already
defined the XML-SDO-Java mapping by calling registerStaticTypes so why
do we need to implicitly pass a classloader on each call?
--
Jeremy
Jeremy Boynes wrote:
Frank Budinsky wrote:
You're right about the problem. If the SDO loader can't find
ant elder (JIRA) wrote:
[ http://issues.apache.org/jira/browse/TUSCANY-49?page=all ]
ant elder closed TUSCANY-49:
Resolution: Fixed
Applied fix
Did anyone get a commit message from this?
I didn't which has me wondering if there may be
Jim Marino wrote:
Are we going to run into problems with Serializable if we put things in
the servlet context?
I would not expect so as that is the context for the application rather
than a session. Certainly no more so than if we put it in JNDI ;-)
We may have an issue if a container
I seem to remember an offline discussion a long time ago where we
thought about extending InstanceContext to provide access to the head of
the interceptor chain and head of the handler chains.
This would seem to be more flexible than going to the InvocationHandler
especially as we would like to
Please take Ant's comment to heart - it is very hard to review something
if the actual change is buried amongst a mass of code reformatting.
Patches like that are often rejected out of hand.
Digging through this one I have concerns about what it is doing. The
Axis servlet is now going to the root
Raymond Feng wrote:
Hi,
I meant to help instead of a trouble-maker.
Thanks - your help is appreciated. Perhaps the comments were a little
harsh but the mixture of reformatting and a functional change makes it
hard for people to review understand a change before applying it, which
will
I changed the From address for our JIRA project from [EMAIL PROTECTED]
to [EMAIL PROTECTED] to match other projects and so that reply
works is you reply to a mail that it sent.
If there are any concerns with this please let me know.
--
Jeremy
In WebServiceEntryPointServlet:
private static SessionContext
getSessionContext(HttpServletRequest httpServletRequest) {
HttpSession httpSession = httpServletRequest.getSession(true);
This forces a session to be created so that a Axis2 SessionContext
object can be associated
ant elder wrote:
Should it be possible to have an entryPoint using the WS binding without a
pre-generated WSDL document?
Yes :-)
Axis2 has the ability to automatically generate a WSDL document at runtime
based on the service interface, so if the entryPoint is using
interface.javainstead
The integration tests in the tomcat module are a little different from
other in our build. Although they use JUnit they are not unit tests. The
JUnit framework is used because it is natively understood by Maven so
these tests are easily integrated into the build - they just run, no
special setup
Jim Marino wrote:
Jeremy,
I'm in the process of trying to check in changes for multiplicity but
some of the changes you just did impacted me. I need to create
references between components and set the multiplicity value. Can you
explain how this works for the two MockFactory classes in
Raymond Feng wrote:
---
Battery: org.apache.tuscany.model.assembly.tests.SCDLAssemblyLoaderTestCase
---
Tests run: 1, Failures: 0,
Jim Marino wrote:
O.K. My stuff is completely broke because I'm assuming there is one
configured reference with multiple target configured services and
that's how I originally had the mock factories. I think this is
correct. Jeremy is that not what you were thinking? We'll need to solve
As of 385092 this should now be supported by the loaders. To make this
work I needed to have them merge the target into the an existing
configured reference if it existed and to support that I converted the
set of configured references for a component from a List to a Map so
that existing ones can
As part of r385092 I made the following change to the SourceImpl test
components:
---
incubator/tuscany/java/sca/container.java/src/test/java/org/apache/tuscany/container/java/mock/components/SourceImpl.java
(original)
+++
I forgot to mention that the helpers also changed to support a list of
targets so you can write:
factory.createConfiguredReference(refName, target1, target2);
Jeremy Boynes wrote:
As of 385092 this should now be supported by the loaders. To make this
work I needed to have them merge the target
This directory contains the seed code from BEA and IBM. Things have
moved on quite a bit since then so I would like to suggest we remove
this code from the tree - old versions can still be found in the SVN
history if needed. This tree has been modified so no longer represents
the original
Jeremy Boynes wrote:
I checked in a framework for a StAX-based configuration loader for the
SCA core. It is based on a set of element handlers that generate a model
object from a element in the XML stream; handlers for the core and
system schemas are in the core module, handlers for extensions
Better to have them there than not but in the spirit of openness would
it be possible to convert them into an open format?
--
Jeremy
Kevin Williams wrote:
I am using ms word docs as the source for the PDF documents associated
with the DAS (sample readmes, etc). Did we decide whether to store
Kevin Williams wrote:
Jeremy Boynes wrote:
Better to have them there than not but in the spirit of openness would
it be possible to convert them into an open format?
Any suggestions?
xdoc as used by Maven which should ease inclusion into the website
DITA as used by Apache Derby
http
Jeremy Boynes wrote:
This directory contains the seed code from BEA and IBM. Things have
moved on quite a bit since then so I would like to suggest we remove
this code from the tree - old versions can still be found in the SVN
history if needed. This tree has been modified so no longer
Guillaume Nodet wrote:
Thanks, that was exactly what I was looking for. I bet the line
SDOUtil.registerStaticTypes(ScdlFactory.class);
will save me :)
The code is available at
http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-sca/
but as Jim just said, it is based
Mike Edwards wrote:
I really would like to make a distinction here between source form
documents and final form documents.
I agree that anything placed on the website as a final form document
should be in a generally acceptable open form. HTML, Maven Xdoc,
PDF, for example. Word documents
A couple of us had an offline chat about what the format of data would
be exchanged on the wire during an interaction between a client and a
provider. The spur for this was the JSON binding Ant was working on
which has no obvious affinity to XML.
Another issue related to this has been about
Jim Marino wrote:
Jeremy did you start this or do you want me to do it?
I have not started yet - if you have time that would be great.
--
Jeremy
Guillaume Nodet wrote:
I have just tested that with svn head and I have the following exception:
org.apache.tuscany.core.context.DuplicateNameException:
org.apache.tuscany.core.loader.assembly.ComponentLoader
This was a problem due to skew with Jim's changes yesterday - should be
fixed now.
--
Daniel Kulp wrote:
(I apologize in advance for the length of this email... After meeting
with Jim and Sebastien for the last two days, there are a LOT of thoughts
swirling around in my head)
One of the questions that came up in the discussions was something along
the lines of if a
Rick has moved the templates into the website.
I have now removed this tree as of revision 386856.
--
Jeremy
Jeremy Boynes wrote:
Jeremy Boynes wrote:
This directory contains the seed code from BEA and IBM. Things have
moved on quite a bit since then so I would like to suggest we remove
One theme that came out of the recent project promotion thread was a
need to establish what our project structure should be. Part of that
also is the level of support between parts of that project structure.
I'd like to propose a strawman, not only of the structure but also of
the rules.
A
I would like to propose a binding that will allow a component to bind a
management interface to JMX allow it to be controlled by and send events
to external management systems.
We would do this by providing a binding.jmx extension that allowed
service interfaces provided/used by the component to
Daniel Kulp wrote:
+1 to all of this (although it's scopetest/scope)
:-)
Having an axis/axiom dependency on the test phase is possibly OK
(although not ideal). Making the actual runtime depend on it is not OK.
We will need test
Frank Budinsky wrote:
SDO 2 uses XMLHelper for marshalling/unmarshalling to XML. The fact
that it's in a helper is the way that the spec has made it an
optional part of SDO - only needed by SDO users that want to
serialize/deserialize their objects as XML. An SDO user that doesn't
need XML
The answer to that will depend on how the data for this will be
represented in the XML and what binding technology you wish to use to
deserialize it.
With the StAX approach, it can be any deserialization approach that can
read a XMLStreamReader. That could be SDO (after Raymond's work),
although
Jean-Sebastien Delfino wrote:
snip/
My main question remains: Is anybody volunteering to take
responsibility for this code?
Perhaps a more pertinent question is: which code do we as a community
choose to take responsibility for?
Seriously, you, I or anyone else may for many reasons be
We have been having a series of discussions recently about project
structure, APIs, extensions, policies for plugins, distributions and so
on. I think this is a sign that we have started to move beyond the code
the core like crazy phase to a how do people add stuff phase.
However, although we
Jim Marino wrote:
A couple of us have started to discuss this as well in relation to
Celtix...My main concerns, which there appears to be agreement, are:
1. We are not instituting a canonical form model similar to JBI in the
runtime. I think Jeremy stated this is not the case
Having trouble
Raymond Feng wrote:
Sorry, the attachment cannot go through. I added it to the wiki page @
http://wiki.apache.org/ws/Tuscany/DataMediation.
The mailing lists eat most attachements, I assume for a combination of
anti-virus, anti-spam, keep-it-open, keep-traffic-controlled reasons.
Attching
Raymond, please accept my apologies for the typo in your name.
--
Jeremy
[EMAIL PROTECTED] wrote:
Author: jboynes
Date: Wed Mar 22 17:44:06 2006
New Revision: 387996
URL: http://svn.apache.org/viewcvs?rev=387996view=rev
Log:
apply patch for TUSCANY-106 from Raymong Feng for invalid
Michael Beisiegel wrote:
hi Jeremy,
has somebody captured the current version of the logical model in UML.
I don't think so - should be easy for someone with access to a reverse
engineering tool :-)
--
Jeremy
I think the loading discussion has been getting confused because we
don't have a clear set of requirements defined. In an attempt to clarify
this, here are the ones I have in mind:
* We need to be able to configure Tuscany in a test environment to
support programmatic unit and integration
Do you mean an ActiveMQ transport or a JMS transport backed by ActiveMQ
(realizing that there is more to ActiveMQ than just JMS)?
Some async stuff I think can be handled by a simple work manager (in the
general sense, not the JSR-237 sense although that could be an
implementation) - does that
Jim Marino wrote:
I had a bunch of additional things and organized slightly differently.
Do you think it would make sense to create a set of requirements in
absolute priority order and fold these into that?
Ordering would be good - let's just get a list :-)
--
Jeremy
Combination of Jim's mail and mine...
I didn't have an ordering in mine so I took his.
1a Users must be able to provide custom data values for configuration
properties and references using any Java Object.
1b Users must be able to provide mechanisms that construct those Objects
from XML
Raymond Feng wrote:
Do we want to differentitate the Threading-based async and
Messaging-based async?
From a component programming model I don't think there's a need to
differentiate. I mean, the component should not be aware of what
transport is being used. The component would specify
Frank Budinsky (JIRA) wrote:
[
http://issues.apache.org/jira/browse/TUSCANY-137?page=comments#action_12372330
]
Frank Budinsky commented on TUSCANY-137:
Jeremy, since these are all? changes to files you added, could you
please let me know if
Frank and I had a quick dicussion offline about adding a helper API to
SDO to support loading/saving DataObjects from/to StAX streams. I've
checked a strawman of an API for this so we can all discuss.
Raymond Feng wrote:
Hi,
I have a question about the save methods. Is the output to
XMLStreamWriter consumable by another databinding which takes
XMLStreamReader as the input? If not, I would like to see something like:
XMLStreamReader getXMLStreamReader(XMLDocuement doc);
I could not
Raymond Feng wrote:
Hi,
Should we allow the XMLStreamReader to be at START_DOCUMENT position for
the following method? In this case, the root DataObject will be returned.
/**
* Create a DataObject from an element in a XML stream.
* The reader must be positioned on a START_ELEMENT event.
mvn -o clean; mvn -o
worked for me. Have you rebuilt the testcases? The signature for this
changed a couple of days ago.
--
Jeremy
Rashmi Hunt (JIRA) wrote:
Error during mvn build - failure in running testcase -
ComponentLoaderTestCase
We should not be writing things to stdout/stderr - we should be logging
to Tomcat and let it direct the messages where appropriate.
We should also not rewrap unchecked Exceptions in RuntimeException. I
would hope Tomcat logged unchecked Exceptions from listeners; if it
isn't we should log them to
[EMAIL PROTECTED] wrote:
Author: jboynes
Date: Tue Apr 4 15:47:29 2006
New Revision: 391434
URL: http://svn.apache.org/viewcvs?rev=391434view=rev
Log:
error logging for Tomcat listener
The first time I ran testing/tomcat after this change I got a Error from
the runtime; this did show
After the issues last night with Tomcat, I feel like trout-slapping
anyone who even mentions clogging.
Just needed to get that off my chest - sorry for the noise.
--
Jeremy
Jim Marino wrote:
In the SCA Java runtime, we've implemented a logging approach where a
class that needs to perform
Jim Marino wrote:
On Apr 5, 2006, at 10:56 AM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
I think this this is a really good approach and will give us a great
binding/extension story for Tuscany. Two comments on the statement
that the model may look a little different than what we
Where are we with the Axis1 binding - are we still keeping it around or
should we remove it?
--
Jeremy
There are several places in the core runtime where components need to
create XMLStreamReader's in order to read XML documents. Currently they
are doing it by instantiating an XMLInputFactory using its newInstance()
default factory.
It would be better if these components could have the
1 - 100 of 1236 matches
Mail list logo
