[
http://issues.apache.org/jira/browse/TUSCANY-135?page=comments#action_12371656
]
Rick Rineholt commented on TUSCANY-135:
---
There is a bit of a dilemma here. Should these always reflect the HEAD in sub
version? The last release, or in our incubator
Frank,
> There may be a requirement to make the SDO project itself 1.4
> compliant. If so we need to fix a few places in the code that are
> currently using generics, etc., and then do this in the SDO pom files
> as well. You haven't been changing any of the SDO code to make it more
> 1.5 dependen
Sorry GMail was delaying sending this. I've already spoken with
Jeremy on this and I think we're o.k. with Jeremy's proposed change -
siblings can be wired together but not cousins.
Jim
Begin forwarded message:
From: Jim Marino <[EMAIL PROTECTED]>
Date: March 22, 2006 2:26:56 PM PST
To:
Samples setup is wrong on website
-
Key: TUSCANY-135
URL: http://issues.apache.org/jira/browse/TUSCANY-135
Project: Tuscany
Type: Bug
Components: Website
Reporter: Jeremy Boynes
Assigned to: Rick Rineholt
I have been told t
I just started looking into this again. I think the idea of
autowiring between two components with a common parent may get very
messy, particularly in the situation where two child components
implement the same service interface. Granted this can be messy for
two entry points, but it is lik
[ http://issues.apache.org/jira/browse/TUSCANY-122?page=all ]
Jeremy Boynes reassigned TUSCANY-122:
-
Assign To: Kevin Williams (was: Jeremy Boynes)
> Modifications to 1:1 relationships not recognized by ChangeSummarizer
> ---
[ http://issues.apache.org/jira/browse/TUSCANY-122?page=all ]
Jeremy Boynes reassigned TUSCANY-122:
-
Assign To: Jeremy Boynes (was: Kevin Williams)
> Modifications to 1:1 relationships not recognized by ChangeSummarizer
> ---
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 th
[ http://issues.apache.org/jira/browse/TUSCANY-126?page=all ]
Kevin Williams closed TUSCANY-126:
--
Verified with DAS CompanyWeb sample against version 388278
> Compilation error in DAS companyweb sample
> --
>
>
[ http://issues.apache.org/jira/browse/TUSCANY-134?page=all ]
Jeremy Boynes reassigned TUSCANY-134:
-
Assign To: Rick Rineholt
Assigning to Rick as he provided the SNAPSHOT we are using
> Upgrade to WS Commons Policy 1.0
> ---
Upgrade to WS Commons Policy 1.0
Key: TUSCANY-134
URL: http://issues.apache.org/jira/browse/TUSCANY-134
Project: Tuscany
Type: Task
Components: Java SCA Axis Integration
Reporter: Jeremy Boynes
--
This message is automati
[ http://issues.apache.org/jira/browse/TUSCANY-133?page=all ]
Jeremy Boynes reassigned TUSCANY-133:
-
Assign To: Rick Rineholt
Assigning to Rick as he provided the SNAPSHOT we are currently using
> Upgrade to AXIOM 0.95
> -
>
>
Upgrade to AXIOM 0.95
-
Key: TUSCANY-133
URL: http://issues.apache.org/jira/browse/TUSCANY-133
Project: Tuscany
Type: Task
Components: Java SCA Axis Integration
Reporter: Jeremy Boynes
--
This message is automatically generated by JIR
Raymond, others,
Please feel free to poke around Axis2's JMS stuff [1] (experimental)
that was tested using ActiveMQ
thanks,
dims
[1] http://marc.theaimsgroup.com/?l=axis-dev&m=113392334526832&w=2
On 3/23/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
> I meant JMS transport backed by ActiveMQ at
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 ar
[ http://issues.apache.org/jira/browse/TUSCANY-126?page=all ]
Kevin Williams resolved TUSCANY-126:
Resolution: Fixed
> Compilation error in DAS companyweb sample
> --
>
> Key: TUSCANY-126
>
[ http://issues.apache.org/jira/browse/TUSCANY-126?page=all ]
Kevin Williams reassigned TUSCANY-126:
--
Assign To: Kevin Williams
I do not see compilation problems with either the maven build or in Eclipse.
But, you are right, the package name shoul
I meant JMS transport backed by ActiveMQ at the beginning.
I also realized that it makes sense to have an async binding framework which
supports pluggable implementation backed by different async providers. The
framework should capture the common things and leave the protocol-specific
work (fo
Can you take a look at mine too and let me know what you think -
Perhaps we could put your use cases in that context? I'm happy to
work the other way around but figured it may be easier with we also
start taking a stab at ordering.
Jim
On Mar 23, 2006, at 1:23 PM, Jeremy Boynes wrote:
J
[ http://issues.apache.org/jira/browse/TUSCANY-132?page=all ]
Daniel Kulp updated TUSCANY-132:
Attachment: pom.xml
> Change source compliance level for plugin to 1.4
>
>
> Key: TUSCANY-132
>
Change source compliance level for plugin to 1.4
Key: TUSCANY-132
URL: http://issues.apache.org/jira/browse/TUSCANY-132
Project: Tuscany
Type: Improvement
Components: Java SCA Tools
Reporter: Daniel Kulp
Pr
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
[ http://issues.apache.org/jira/browse/TUSCANY-131?page=all ]
Daniel Kulp updated TUSCANY-131:
Attachment: sca.model.patch
> Fix eclipse warnings for sca/model
> --
>
> Key: TUSCANY-131
> URL: http://issu
Fix eclipse warnings for sca/model
--
Key: TUSCANY-131
URL: http://issues.apache.org/jira/browse/TUSCANY-131
Project: Tuscany
Type: Improvement
Components: Java SCA Model
Reporter: Daniel Kulp
Priority: Minor
Fix eclipse
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?
Jim
On Mar 23, 2006, at 12:28 PM, Jeremy Boynes wrote:
I think the loading discussion has been getting
There has been a lot of discussion on this topic and Jeremy's point
brings up an issue I think needs to be fleshed out. Specifically,
what are the requirements and priorities for loading configuration.
Could we perhaps take the following approach?
1. Agree on the requirements and their prio
Resending since this didn't go through...
Begin forwarded message:
From: Jim Marino <[EMAIL PROTECTED]>
Date: March 23, 2006 11:53:12 AM PST
To: tuscany-dev@ws.apache.org
Subject: Re: Framework for StAX-based model loading
There has been a lot of discussion on this topic and Jeremy's point
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
I was thinking ActiveMQ may be the transport mechanism. There's a lot
more to the programming model that would be part of Tuscany.
Jim
On Mar 23, 2006, at 12:38 PM, Raymond Feng wrote:
Is ActiveMQ binding also candidate to support async PM? It seems
that Celtix's JMS transport is based on
Is ActiveMQ binding also candidate to support async PM? It seems that
Celtix's JMS transport is based on Active MQ.
Thanks,
Raymond
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 23, 2006 12:22 PM
Subject: Re: A release for JavaOne?
[
http://issues.apache.org/jira/browse/TUSCANY-130?page=comments#action_12371637
]
James M Snell commented on TUSCANY-130:
---
Yeah, the problem is that we forgot to implement the
create/convertXXXFromString() methods in ModelFactoryImpl. I'll take a l
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 tes
[snip]
Other than that I think it would be good to find ways to
show how Tuscany plans to be more than just another platform for Java
web
services.
Yes, I agree with that. We may have different reasons why we agree. My
reasoning is based on SCA, which is intended to be more than "another
p
[ http://issues.apache.org/jira/browse/TUSCANY-107?page=all ]
Frank Budinsky resolved TUSCANY-107:
Resolution: Fixed
fixed in revision 387577
> get/setXMLVersion in XMLDocumentIMPL needs to be implemented
> -
[ http://issues.apache.org/jira/browse/TUSCANY-20?page=all ]
Frank Budinsky resolved TUSCANY-20:
---
Resolution: Fixed
fixed in revision 387960
> Default SDO 2 types not available or working correctly
> --
[ http://issues.apache.org/jira/browse/TUSCANY-58?page=all ]
Frank Budinsky resolved TUSCANY-58:
---
Resolution: Fixed
fixed in revision 387960
> SDO2 name of the anonymous type the doesn't conform to the spec
> -
IllegalArgumentException is thrown when XMLHelper loads the XML document with
string value for xsd:anySimpleType
-
Key: TUSCANY-130
URL: http://issues.apache.org/jira
Venkata Krishnan wrote:
Hello Everybody,
I would like to contribute to Tuscany Java implementation (runtime and
tools). To start with I would like to help with some Tool Development.
Looking up the Jira I found an item "Add Java2WSDL Tools" - (
https://issues.apache.org/jira/browse/TUSCANY-1
Daniel Kulp wrote:
Jeremy,
I did not apply the fix to CallbackType as the test is checking that
annotations on private fields are accessible. The spec allows this even
though it can be annoying when IDEs report (correctly) that the field
is not being used.
Can we add a protected method like:
[ http://issues.apache.org/jira/browse/TUSCANY-129?page=all ]
Jeremy Boynes closed TUSCANY-129:
-
Resolution: Fixed
Patch applied - thanks
> Fix for test failures in container.java
> ---
>
> Key: TUSCANY-
[ http://issues.apache.org/jira/browse/TUSCANY-129?page=all ]
Jeremy Boynes reassigned TUSCANY-129:
-
Assign To: Jeremy Boynes
> Fix for test failures in container.java
> ---
>
> Key: TUSCANY-129
>
Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/23/2006 02:02:00 PM:
> I think we need to be careful to distinguish the needs we have for
> loading our configurations from the needs users have of SDO in general.
> I think the SCA schemas have things in them that are atypical: lots of
> extensibil
I think we need to be careful to distinguish the needs we have for
loading our configurations from the needs users have of SDO in general.
I think the SCA schemas have things in them that are atypical: lots of
extensibility, many namespaces, custom data types, few
attributes/properties and so f
Hi Russell,
I think that this is a great idea for an environment/framework that
could be built around the RDB DAS much like - this may be a stretch -
the Ruby Rails framework is built around ActiveRecord. In this new
framework, the DAS could be employed to read Database schema information
Raymond Feng wrote:
Hi, Frank.
I think I fully agree with you. An efficient databinding is what we're
looking for.
Ideally, if SDO later on supports lazy-loading (create the DataObject
skeleton first and pull in properties as they're assessed) from
XMLStreamReader, I assume we'll take advan
Definitely don't think we need two ways.
If most of the XML config is going to be simple 1 attribute type stuff then
StAX seems much simpler. If a reasonable amount of config XML is more
complicated then maybe we need a data binding.
I guess when trying to decide between these two approaches then
On Mar 22, 2006, at 11:53 PM, ant elder wrote:
Sure ok, but I think I have a slightly different and less main stream
perspective on whats important/interesting to do :-) So for this
release I'd
rather fit in with what others want which is why i'm asking for
specific
suggestions.
O.K. but
Hi, Frank.
I think I fully agree with you. An efficient databinding is what we're
looking for.
Ideally, if SDO later on supports lazy-loading (create the DataObject
skeleton first and pull in properties as they're assessed) from
XMLStreamReader, I assume we'll take advantage of the benifits
[ http://issues.apache.org/jira/browse/TUSCANY-128?page=all ]
Jeremy Boynes closed TUSCANY-128:
-
Resolution: Fixed
Patch applied - thanks
> Fix eclipse warnings for sca/common
> ---
>
> Key: TUSCANY-128
>
I stand by my statement that the EMF problem is short term pain for long
term gain :-) I think that in the long term using the SDO generator will
be the best and easiest way to do this. Yes I am biased, but I've seen it
before - avoiding reuse/dependencies works nicely at first, but as things
g
Hi Ant,
I'm having trouble figuring out where you are coming down on this -
maybe I'm just brain-dead this morning. You mention at the beginning
that you are starting to be persuaded by the SDO approach but then
you give the Axis example at the end which seems to say either "keep
things s
Jeremy,
> I did not apply the fix to CallbackType as the test is checking that
> annotations on private fields are accessible. The spec allows this even
> though it can be annoying when IDEs report (correctly) that the field
> is not being used.
Can we add a protected method like:
public Obj
Fix for test failures in container.java
---
Key: TUSCANY-129
URL: http://issues.apache.org/jira/browse/TUSCANY-129
Project: Tuscany
Type: Bug
Components: Java SCA POJO Container
Reporter: Daniel Kulp
Attachments: container
[ http://issues.apache.org/jira/browse/TUSCANY-127?page=all ]
Jeremy Boynes closed TUSCANY-127:
-
Resolution: Fixed
Applied fix for the changes to CurrentModuleContext
I did not apply the fix to CallbackType as the test is checking that
annotations
[ http://issues.apache.org/jira/browse/TUSCANY-129?page=all ]
Daniel Kulp updated TUSCANY-129:
Attachment: container.java.patch
> Fix for test failures in container.java
> ---
>
> Key: TUSCANY-129
> U
On Mar 23, 2006, at 12:51 AM, ant elder wrote:
On 3/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Mar 22, 2006, at 9:53 AM, ant elder wrote:
Thought about it a little bit, and in some offline discussion a
while ago
Jeremy was also interested in that. I think there does need to be a
bal
It's definitely due to improper/non-existent teardowns and the
ContextClassloader. I'll have a patch ready shortly.
For everyones information, do NOT ever do:
Setup:
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
Teardown:
Thread.currentThread().setContextClassLoad
I'm also +1 on the release for JavaOne idea.
Here are my thoughts on SDO work that I think we should try to finish for
the release. Sadly, the list of things that I think can realistically be
done in this short timeframe, is pretty small. Please let me know if
anybody else can think of importan
Daniel Kulp wrote:
Ick... OK. Another set of tests that only fail on my machine. (like
the rhino ones)
I just did a fresh checkout into a completely new directory, deleted my
~/.m2/repository dir, and rebuilt and I'm still seeing the failures.
Probably some more teardown methods th
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
ant elder wrote:
Are we any closer to deciding on this now? How about just keeping what we
have right now in SVN but adding bindings and containers folders to sca and
moving all the binding and container impls there (and the same for policys,
services, etc when we have some of those)?
...ant
On 3/23/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
As the binding itself uses JAXB2 (though it may change in
> the future), I have to include all eclipse dependencies and SDO stuff,
> just to load the system configuration files :(
>From the discussion I'm starting to be persuaded by some
hi Jeremy,
has somebody captured the current version of the logical model in UML.
thanks,
Michael
On 3/22/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> Frank Budinsky wrote:
> > Now back to the issue of whether or not to use SDO for the SCDL model.
> > Personally, I think that the main issue J
Ick... OK. Another set of tests that only fail on my machine. (like
the rhino ones)
I just did a fresh checkout into a completely new directory, deleted my
~/.m2/repository dir, and rebuilt and I'm still seeing the failures.
Probably some more teardown methods that need to be imple
I do really like the StaX based loader for binding, which are really
simple to write for simple
bindings. The jbi binding is quite the same as the axis2 one, so that
there is only one attribute on
the binding element. Having to auto-generate a number of classes for
that is quite painful.
If
Jeremy Boynes <[EMAIL PROTECTED]> wrote on 03/22/2006 09:41:46 PM:
> Jean-Sebastien Delfino wrote:
> >
> > The logical model is actually pretty close to the model generated from
> > the XMLSchema. If you take the model generated from the schema and add
a
> > few derived /calculated relationships
svn st and svn up say I'm current and mvn clean, mvn for container.java are
successful for me.
...ant
On 3/23/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:
>
> Hi Dan,
>
> Are the container.java tests run as part of "mvn" from the root? I can run
> "mvn clean" and then "mvn" from the tuscany/j
Hello Everybody,
I would like to contribute to Tuscany Java implementation (runtime and
tools). To start with I would like to help with some Tool Development.
Looking up the Jira I found an item "Add Java2WSDL Tools" - (
https://issues.apache.org/jira/browse/TUSCANY-103) in the context of Java
Hi Dan,
Are the container.java tests run as part of "mvn" from the root? I can run
"mvn clean" and then "mvn" from the tuscany/java directory and everything
works fine for me.
Could somebody else please confirm that they are also having problems like
Dan?
Thanks,
Frank.
Daniel Kulp <[EMA
Are we any closer to deciding on this now? How about just keeping what we
have right now in SVN but adding bindings and containers folders to sca and
moving all the binding and container impls there (and the same for policys,
services, etc when we have some of those)?
...ant
On 3/18/06, Jeremy
On 3/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
>
> On Mar 22, 2006, at 9:53 AM, ant elder wrote:
>
> > Thought about it a little bit, and in some offline discussion a
> > while ago
> > Jeremy was also interested in that. I think there does need to be a
> > balance
> > so as to not lose the sim
71 matches
Mail list logo
