/2005 12:42 PM
Please respond to
tuscany-dev
To
tuscany-dev@ws.apache.org
cc
Subject
Re: Eclipse dependencies
cool - thx
Jim Marino wrote:
My understanding is that the SDO implementation that is being used by
the Java runtime requires EMF. That implementation is in the
process
Our mechanism is mostly a pluggable reader if I understand you
correctly. This is somewhat in a bit of flux at the moment but the
best place to start is the model project. There is an SDO
implementation currently which can be extended to allow for new
component types. I also have a fairly
This also brings up a couple of more general issues about unit tests
and the functioning of the model. For unit tests, I think we should
avoid loading of external resources such as side files. This will
get around these types of issues as well as maintain a shorter run
time for the unit
I started to do a very high level write-up of how the runtime and
Contexts work in general and checked it into my sandbox. It's
intended to be a very broad overview (I wanted to have a series of
other more detailed documents on specific aspects). Also, its
very,very rough since I just
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 Proxies (perhaps with
codegen
:
I built and ran the unit tests successfully on OS X about a month
ago with no problems; not recently though. Can you provide the
last 38 lines of the stack trace? Is there any chance that a
previous execution of the build had not completed?
--Kevin
Jim Marino wrote:
When I run maven
Jeremy's suggestion?
Thanks,
--Kevin
Jeremy Boynes wrote:
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
On Jan 28, 2006, at 10:22 AM, Jean-Sebastien Delfino wrote:
I think that a test suite that simulates an end user interacting with
our basic samples and verifies that they behave like expected is
extremely valuable. If I'm new to Tuscany and want to understand
what it
does, the first thing
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 following:
1. Unit
On Jan 30, 2006, at 3:23 PM, [EMAIL PROTECTED] wrote:
Jim wrote:
1. Unit tests
[snip]
2. Integration tests
[snip]
3. Function tests
- Exercise end-user scenarios
- May access external resources
- Includes/organized by deployment platform-specific tests,
e.g. J2SE,
,
--Kevin
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
On Jan 31, 2006, at 10:59 AM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
On Jan 28, 2006, at 10:22 AM, Jean-Sebastien Delfino wrote:
I think that a test suite that simulates an end user interacting
with
our basic samples and verifies that they behave like expected is
extremely
Hi Sebastien,
Nice write-up - thanks a lot for doing this.
I'm generally o.k. with these with a few caveats:
1. We'll need to scope because I think there is a lot more here than
we can accomplish
2. As a pre-req to do this, I think we need to have the following in
place. My view is that
that a scoping effort should take place first. Is the scoping
effort currently under way? Jean-Sebastien also mentions a Tuscany/
Java
milestone, is there something posted on
http://incubator.apache.org/tuscany/index.html that speaks to
milestones?
Lance
On 2/3/06, Jim Marino [EMAIL PROTECTED
Boynes wrote:
Jim Marino wrote:
I am in the process of making some early changes to the proxy
configuration mechanism so that we can switch over to the new
context
infrastructure. These are early changes that will need a lot of
refactoring so I am attempting to do this in parallel
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
unit test
Yea I agree on the hell cross-references would introduce. Most of the
stuff I had in mind depends on the model project. We probably should
just live with cut-and-paste.
Jim
On Feb 9, 2006, at 8:50 AM, Jeremy Boynes wrote:
Jim Marino wrote:
Cases are coming up where it would be useful
One of the key things about a module is that a module defines the
boundary of visibility. In other words, components in a module cannot
directly reference out and cannot be directly referenced by
*components* in other modules. All references go through entry points
and external services
.
Jim
On Feb 9, 2006, at 12:26 PM, [EMAIL PROTECTED] wrote:
Jim Marino wrote:
There is some documentation on the design in my sandbox
although I realize this needs to be beefed up a lot. We
definitely want it to be easy for you to ramp up (my apologies
for the project being somewhat in a state
Looks like you need to point to SDO 2.1.0, not 2.0, since the
signature is different. This raises a question of which is correct,
i.e. which version we are targeting? Could one of the people working
on SDO comment and I can change the impl if required?
Jim
On Feb 14, 2006, at 7:39 AM, ant
/SDOType is based on the SDO 1.0 version of
Type, so
it would need to be moved up to 2.0 - or replaced with the SDO Type
implementation class from the SDO project.
Frank.
Jim Marino [EMAIL PROTECTED] wrote on 02/14/2006 11:23:13 AM:
Looks like you need to point to SDO 2.1.0, not 2.0, since
Thanks Sebastien. I think this looks good so far.
Jim
On Feb 15, 2006, at 6:26 PM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
I maybe wasn't clear. I don't think we should force this through
Axis2. I was just thinking it would be good to have an additional
binding to SOAP/Axis2
Over the next several days, we are going to begin the cut-over to the
new bootstrap and proxy mechanism. I realize the documentation has
been lacking and it is difficult for people to get up to speed on the
changes. I hope to correct this as soon as possible. In the
meantime, a few
Hi Hung,
I'm not quite sure I follow...
On Feb 17, 2006, at 12:09 PM, hung tran wrote:
Hi Tuscans,
I had previously posted a question regarding dynamic invocation,
which i believe i didn't word clearly enough.
I would like to build a test tool, with a runtime piece sitting as
part of
On Feb 20, 2006, at 8:56 AM, hung tran wrote:
Hi Jim,
I hope this makes it clearer, otherwise i'll give it another shot :)
From: Jim Marino [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: dynamic invocation...again
Date: Fri, 17 Feb 2006 14
with just say.
...ant
On 2/21/06, Jim Marino [EMAIL PROTECTED] wrote:
I have a bunch of changes to the js container to support the proxying
infrastructure that is being put in place. Ant, would you want to
work together on this? I plan to check in once I get the compile and
unit test issues
Hi,
I just synced to 379874 and am getting the following NPE when I mvn:
java.lang.NullPointerException
at org.apache.tuscany.sdo.plugin.GeneratorMojo.execute
(GeneratorMojo.java:69)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPluginManager.java:432)
O.K. the problem was I didn't sync SDO first. It works now after I
synced that project and built.
Jim
On Feb 22, 2006, at 12:33 PM, Jim Marino wrote:
Hi,
I just synced to 379874 and am getting the following NPE when I mvn:
java.lang.NullPointerException
We've recovered to a state where the build and unit tests are working
except for binding.axis in the Java runtime (the samples are still
down). Or next steps are to get the new runtime bootstrap in place,
which Sebastien and I are going to work on tomorrow. Also, I plan to
write some
Sebastien and I got wiring working so HelloWorldMC is back online.
Stepping through the testcase is a good way to see how the runtime is
bootrapped and invocation chains work. Various pieces of the runtime
are now contributed as system components contained in special
aggregate contexts
We are starting to run into the situation where we are duplicating a
lot of test code (e.g. the mock factories that create logical
models for testing) between projects. We discussed this in a previous
mail and Jeremy mentioned the problem with circular dependencies
between projects. Does
On Feb 26, 2006, at 2:47 AM, ant elder wrote:
Back on the 22nd Jim suggest people may not want to sync up till
all the
projects are back online after all the latest refactorings, whats
the status
with that?
What should/shouldn't be working?
Everything in the main set of projects except
Yea it appears wrong. The builder should set the parent of the
source. Currently, this is set in SystemAggregateContextImpl (line
302). I'm wondering if the new builder component is setting its
parent as opposed to the source parent?
Jim
On Feb 27, 2006, at 6:48 PM, Jeremy Boynes wrote:
Hi Jason,
To build Eclipse .project files, run mvn eclipse:eclipse from the
command line. These files will be configured with the proper
dependencies and you can import them into you environment.
Let us know if you have any further questions.
Jim
On Feb 28, 2006, at 7:50 AM, Jason
As a hack would setting the module component implementation to null
work? If this worked, I think it should only be temporary and we
should do the recursion solution since others will run into this.
Jim
On Feb 28, 2006, at 11:02 AM, Jeremy Boynes wrote:
Jeremy Boynes wrote:
There is a
It sounds like we should just fix the visitor. What do you think?
On Feb 28, 2006, at 11:42 AM, Jeremy Boynes wrote:
Jim Marino wrote:
As a hack would setting the module component implementation to null
work? If this worked, I think it should only be temporary and we
should
do
Any luck with converting the visitor stuff? Let me know if you want
me to do some of it.
Jim
On Feb 28, 2006, at 11:51 AM, Jim Marino wrote:
It sounds like we should just fix the visitor. What do you think?
On Feb 28, 2006, at 11:42 AM, Jeremy Boynes wrote:
Jim Marino wrote
On Feb 28, 2006, at 10:20 PM, Jeremy Boynes wrote:
Jim Marino wrote:
Any luck with converting the visitor stuff? Let me know if you
want me
to do some of it.
I got distracted looking at the Tomcat stuff again.
I ran into a wall with the visitor trying to figure out how to recurse
Can we open this discussion? My inclination is to agree that most
processing flow, as opposed to configuration, code should not
rely on model objects (I'm assuming builders are configuration
code). It may be useful though to provide a management interface that
exposes the model, but this
After talking with Sebastien the other day, it appears Axis1 uses
reflection to make invocations, requiring entry points to return
proxies implementing the exposed service (Axis2 appears different).
So, I changed getInstance(..) to return a generated proxy - if you
don't need a proxy, get
sense?
--
Jeremy
Jim Marino wrote:
After talking with Sebastien the other day, it appears Axis1 uses
reflection to make invocations, requiring entry points to return
proxies implementing the exposed service (Axis2 appears
different). So,
I changed getInstance(..) to return a generated proxy
This is great Sebastien!
On Mar 4, 2006, at 5:21 AM, Jean-Sebastien Delfino wrote:
After some bring-up work today - and a number of bug fixes :) - I
think that we have reached a stable state with all of our end to
end scenarios working fine (including the Bigbank scenario) with
our new
On Mar 6, 2006, at 4:14 AM, ant elder wrote:
Now that we have the WS binding going using Axis2 can we come up
with a list
of what improvements we need to make to it in the nearish future.
If we can
come up with a list of task, prioritize it, see who volunteers for
what,
then we'll know
On Mar 5, 2006, at 8:09 AM, Jeremy Boynes wrote:
Jim Marino (JIRA) wrote:
[
http://issues.apache.org/jira/browse/TUSCANY-63?
page=comments#action_12368832
]
Jim Marino commented on TUSCANY-63:
---
We may have to think about a general eventing mechanism
Jeremy mentioned that intra-aggregate system component wires were not
working. I check some test cases in that exercise functionality that
was already in place. I'm probably missing something here so can
someone let me know? I may be incorrectly generating the model in
MockFactory or
The error message in the SystemEntryPointBuilder is not the most
helpful. I'm fixing wiring to List types now so I'll go in and
provide a more descriptive error as well.
Jim
On Mar 7, 2006, at 9:32 AM, ant elder wrote:
Ok, forget this. Brain dead coding in the scdl module loader.
On
Does anyone know if we can get Jira to generate emails with the sub-
project or even component part of the subproject embedded in the
subiject so we can filter issues?
Jim
On Mar 10, 2006, at 5:08 PM, Jeremy Boynes wrote:
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
since I can't commit any of the changes
that fix the broken HelloWorld.
Jim
On Mar 10, 2006, at 6:43 PM, Jean-Sebastien Delfino wrote:
Jeremy Boynes wrote:
Jim Marino wrote:
Jeremy,
I'm in the process of trying to check in changes for multiplicity
but some of the changes you just
PM, Jeremy Boynes wrote:
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
+1
On Mar 11, 2006, at 9:51 AM, 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
I'm currently doing work on allowing arbitrarily deep registration of
aggregate contexts. As part of this work, I need to make autowiring
complete lazily. So, if you need to make changes in these areas,
please coordinate with me so we don't step on one another.
Jim
Hi,
I made an extensive rename of RuntimeConfiguration to ContextFactory
and RuntimeConfigurationBuilder to ContextFactoryBuilder since it is
more descriptive of what those classes actually do. This forced a
number of renames upstream and hence the rather large commit I just
did. Sorry
I committed another round of changes to allow registration of
arbitrarily deep aggregate hierarchies. Prior to this, we had to do
the following:
1. Register a module component with an empty module
2. Register the module component's module
3. Locate the context associated with the module
I believe they based the integration on what was there prior to the
introduction of the new core architecture, including aggregates and
builders. If I recall correctly, TuscanyModuleComponentContextImpl
was used, which no longer exists. The best place to start may be to
look at some of
Hi,
I wanted to raise the issue of how projects are promoted to the
core set of projects in the Java SCA runtime. IMO adding a project
to java/sca is a commitment by the community for long-term support.
Because of this, I would like to propose that prior to promoting a
project to
Yes, RUNNING is set when the module scope event starts (see onEvent
(int type, Object key) ). This may be a bit confusing, in which case
we could change the name.
Jim
On Mar 15, 2006, at 10:04 AM, rick rineholt wrote:
Looking through parts of the code and I notice
On Mar 15, 2006, at 3:37 PM, Jeremy Boynes wrote:
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
Jeremy did you start this or do you want me to do it?
Jim
On Mar 8, 2006, at 1:53 PM, Jeremy Boynes wrote:
I'm not quite sure what the autowire algorithm is but the best I've
figured out is:
* The root RuntimeContext autowires to itself for services it provides
and if not found delegates
On Mar 20, 2006, at 11:45 PM, ant elder wrote:
On 3/21/06, James F Marino [EMAIL PROTECTED] wrote:
snip/
3. I would like to see a process where contributions first go into a
sandbox and are worked on for some time prior to being put in
extensions. It would be good to have a discussion (not
thread :-)
Yes that's another issue we need to tackle
--
Jeremy
Jim Marino wrote:
I have an additional question. If I have a custom complex type,
say Foo
(:-)) what steps do I need to take to have that bound into a
component
property for the StAX and SDO approaches e.g.:
public class
This seems interesting but I have a few questions, which are not
really important but arise from curiosity:
I'm curious if you thought about making this look more like SCA
Client Implementation specs? For example, it may be convenient to
have the APIs look more like the Java CI spec such
On Mar 22, 2006, at 9:32 AM, Jeremy Boynes wrote:
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
On Mar 22, 2006, at 10:10 AM, Jim Marino wrote:
On Mar 22, 2006, at 9:32 AM, Jeremy Boynes wrote:
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
My recollection - Frank let me know if this is incorrect - was that
the SDO impl would not necessarily be EMF-free but that it would
hide implementation details. For the Java runtime, the goal was to be
EMF-free from the perspective that the runtime would not contain
direct dependencies on
On Mar 22, 2006, at 10:27 AM, Jean-Sebastien Delfino wrote:
ant elder wrote:
+1 to having a release from me. Having to build Tuscany themselves
does put
people off trying it - first installing maven and svn and
downloading all
the dependencies etc - having a binary download would help a
I think having multiple bindings is a good thing for JavaOne and
perhaps we will get lucky and be able to show some interop. Let's
see how things go next week.
Jim
On Mar 22, 2006, at 1:22 PM, Daniel Kulp wrote:
Jim,
4. Additional bindings to Axis through integration with Celtix,
-level interception so I imagine this
would be theoretically possible in Java/ECMAScript.
...ant
On 3/22/06, Jim Marino [EMAIL PROTECTED] wrote:
This seems interesting but I have a few questions, which are not
really important but arise from curiosity:
I'm curious if you thought about
That's great. Perhaps we could look at that as part of the Axis
cleanup work which needs to be done?
Jim
On Mar 22, 2006, at 1:59 PM, Davanum Srinivas wrote:
Jim,
Axis2+Sandesha has already been thru WS-Addressing Interop and WS-RM
Interop using both SOAP 1.1 and SOAP 1.2 (specifically
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
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
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
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
I'm forwarding this due to problems with my GMail setup...
Jim
Begin forwarded message:
From: Jim Marino [EMAIL PROTECTED]
Date: March 24, 2006 10:31:20 AM PST
To: tuscany-dev@ws.apache.org
Subject: Re: Framework for StAX-based model loading
I think there may be some issues uncovered
to be a typical example of someone who wants
to extend the container and has a bunch of questions :-)
We really are just trying to leverage the Tuscany generator to do
XML binding here ... our config loader does not need to be a fully
compliant SDO application.
Thanks,
Frank.
Jim Marino [EMAIL
On Mar 24, 2006, at 4:21 PM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
[snip]
Thanks Frank for answering these questions. I have a few more that
maybe you or others could offer opinions on.
On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
I don't know much about how the sca
On Mar 28, 2006, at 7:20 AM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
On Mar 24, 2006, at 4:21 PM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
[snip]
Thanks Frank for answering these questions. I have a few more
that maybe you or others could offer opinions on.
On Mar
This sounds like a good idea although we should probably state all of
the warnings about not using the Java runtime for anything serious
yet :-) BTW, this reminds me, I remember there was a thread on
getting WIKI docs up. I don't want to cross threads here, but I
thought they were related
In the SCA Java runtime, we've implemented a logging approach where a
class that needs to perform logging requests a monitor that
implements a particular interface. This interface has methods for
logging that are strongly typed, i.e. serverStartError(InitException
e). The runtime is
+1 too
On Apr 5, 2006, at 11:17 AM, Jean-Sebastien Delfino wrote:
Jeremy Boynes wrote:
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
On Apr 5, 2006, at 6:45 PM, rick rineholt wrote:
I may have missed it but what is our error and
exception handling strategy in
java Tuscany? Working on some of the demos I can say
that we really need to
strive hard to provide the context that these happen.
As an end user I think
I'd really
Yea I think you're right. I didn't even notice it - I'll fix them now.
On Apr 7, 2006, at 7:36 AM, Jeremy Boynes wrote:
Jim
I think you said you recently switched to IDEA and I think that
resulted
in some import ...*; declarations creeping in during your refactor.
I thought this came
Jim Marino wrote:
In the SCA Java runtime, we've implemented a
logging approach where a
class that needs to perform logging requests a
monitor that
implements a particular interface. This interface
has methods for
logging that are strongly typed, i.e.
serverStartError(InitException
In case this didn't get through gmail...
Begin forwarded message:
From: Jim Marino [EMAIL PROTECTED]
Date: April 7, 2006 10:02:21 AM PDT
To: tuscany-dev@ws.apache.org
Subject: Re: Does SDO 2.0 have logging capability such as JSR47?
I agree we need to add more logging (but not too much imo
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 logging requests a
monitor that
implements a particular interface. This interface
has methods for
logging
Yea for some reason it was set at 5 and it nicely changed things
for me. I cleaned the stuff up and gave IntelliJ a good trout-slapping.
Jim
On Apr 7, 2006, at 7:36 AM, Jeremy Boynes wrote:
Jim
I think you said you recently switched to IDEA and I think that
resulted
in some import
I generally tend to prefer the last option as well. The second is
kind of bad in my opinion as it ties an application to the internal
implementation of the runtime. The first requires the runtime to
have knowledge for every type. As an alternative, what if we
supported @Resource from
Hi,
I had a quick question about this class: why does it throw
IllegalArgumentException on lines 49 and 52 as opposed to another
type of exception?
Jim
On Apr 12, 2006, at 12:07 AM, [EMAIL PROTECTED] wrote:
Author: antelder
Date: Wed Apr 12 00:07:23 2006
New Revision: 393402
URL:
Hi,
I had a quick question about this class: why does it throw
IllegalArgumentException on lines 49 and 52 as opposed to another
type of exception?
Jim
On Apr 12, 2006, at 12:07 AM, [EMAIL PROTECTED] wrote:
Author: antelder
Date: Wed Apr 12 00:07:23 2006
New Revision: 393402
URL:
In case this didn't go through again...
Begin forwarded message:
From: Jim Marino [EMAIL PROTECTED]
Date: April 13, 2006 9:47:07 AM PDT
To: tuscany-dev@ws.apache.org
Subject: Re: What are some good samples for Tuscany?
A couple of comments:
- I like the demos vs. samples since that kind
The following info may be somewhat related to this discussion
For the recursive proposal under consideration in the spec, there is
a way to specify a composite property which can be a complex type.
Child components may have properties configured using an XPath
expression that point to
On the BigBank issue, I don't think we should replace that sample as
the spec group will continue to evolve it and I believe it is useful
to have the spec define a standard sample app. For people that have
not participated in the spec work, it is recognized that the existing
version does
On Apr 13, 2006, at 7:18 PM, Jeremy Boynes wrote:
ant elder wrote:
Here are some specific ideas to kick around:
1) how about calling business samples 'demos' and technology
samples just
'samples'
I tend to agree with Simon that there could be a perception that
demos
are just
yea I do - we had some stuff on a loan approval process. Let me
check on the legal issues and perhaps we can post it here.
Jim
On Apr 13, 2006, at 7:38 PM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
On the BigBank issue, I don't think we should replace that sample
as the spec group
are didactic in nature.
On 4/13/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jim Marino wrote:
On the BigBank issue, I don't think we should replace that sample as
the spec group will continue to evolve it and I believe it is useful
to have the spec define a standard sample app. For people
are didactic in nature.
On 4/13/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jim Marino wrote:
On the BigBank issue, I don't think we should replace that sample as
the spec group will continue to evolve it and I believe it is useful
to have the spec define a standard sample app
are didactic in nature.
On 4/13/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jim Marino wrote:
On the BigBank issue, I don't think we should replace that sample as
the spec group will continue to evolve it and I believe it is useful
to have the spec define a standard sample app
I believe so. +1 from me too.
Jim
On Apr 14, 2006, at 12:10 PM, Jean-Sebastien Delfino wrote:
Jeremy Boynes wrote:
The default scope for system components currently matches that
from the
Java CI spec as being INSTANCE
All the components we have are MODULE scoped and need to specify
On Apr 14, 2006, at 7:44 AM, Jeremy Boynes wrote:
ant elder wrote:
Moving some of the testing discussion out of the samples thread...
Its not completely clear to me what the distinction is between
'technology
samples' and functional tests. There are some JavaScript samples
in the
I don't think we use this anymore either. I think I originally put
this in there as a convenience method when registering a bunch of
things. +1 to remove.
This reminds me we are going to need to figure out how to dynamically
add bunch of things as a unit of work, but I guess we can deal
1 - 100 of 1205 matches
Mail list logo
