Why do you need to implement an interface as opposed to extend an
abstract class when most of the methods are simple getters/setter
pairs? This is a very common pattern in found in Servlets, Struts,
WebWork, Srping and Hibernate, to name just a few. It allows people
to progressively buy
I've come across difficulties related to this in the work I've done with
extensions:
- I tried adding another interface type a while back in M1 to have an
interface.smd to support the Dojo Simple Method Description for the AJAX
binding (http://dojo.jot.com/SMD). I couldn't get it to work as the
I'm trying to implement the sample ruby extension and running into some
issues.
I'm implementing an AtomicComponentContext (with the code in the head
stream) and also trying the equivalent AtomicComponent with some of the
code in the sandbox. I want to be able to implement my extension class
+1
Where are you doing this and how can we start helping? A long time ago I had
a go at something like this for the JavaScript component, the interfaces it
had were along the lines of the ones below. probably a bit old now with all
the other changes. One thing I found hard was having a nice way
Jim Marino wrote:
I think you missed something. With core2, most people will extend from
the helper abstract classes in the SPI extension package (this was
also the case with the previous core). For example:
I didn't miss this class, as I said that's exactly what I'm trying to
avoid. I want
In the new core2 API, component factory is no longer needed.
AtomicComponent contains the invocation chains and and is responsible
for creating invokers. Related to having WSDL or Java interface
types, one of the things we also did was separate proxy creation from
the wire so now you can
and java annotation is just a
convenient way to supply the value?
Thanks,
Raymond
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, June 21, 2006 2:08 AM
Subject: Re: Tuscany SPI interfaces
Jim Marino wrote:
I think you
2:08 AM
Subject: Re: Tuscany SPI interfaces
Jim Marino wrote:
I think you missed something. With core2, most people will extend
from the helper abstract classes in the SPI extension package
(this was also the case with the previous core). For example:
I didn't miss this class, as I said
Raymond Feng wrote:
Hi,
I guess one of the concerns is that some of the base classes create
additional contracts which are not captured by the interfaces. It ends
up that the extension developers have to understand more.
I agree that that would be a concern. That wasn't the intention
by wildcards against QNames
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, June 21, 2006 3:03 PM
Subject: Re: Tuscany SPI interfaces
Raymond Feng wrote:
Hi,
I guess one of the concerns is that some
Raymond Feng wrote:
Hi, Jeremy.
Thanks for the clarification.
For the SDO loader, I have posted a patch before (
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03792.html ).
Please review and apply.
Thanks - I remember the type scoping discussion that followed and forgot
the
[snip]
ant elder wrote:
+1
Where are you doing this and how can we start helping? A long time ago
I had
a go at something like this for the JavaScript component, the
interfaces it
had were along the lines of the ones below. probably a bit old now
with all
the other changes. One thing I
-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, June 21, 2006 7:10 PM
Subject: Re: Tuscany SPI interfaces
[snip]
ant elder wrote:
+1
Where are you doing this and how can we start helping? A long time ago I
had
a go at something like this for the JavaScript
13 matches
Mail list logo
