The ActiveMQ, ServiceMix and WADI projects have been proposed as sub
projects of Geronimo. The proposals are here...
http://wiki.apache.org/incubator/ActiveMqProposal
http://wiki.apache.org/incubator/ServiceMixProposal
http://wiki.apache.org/incubator/WadiProposal
The Geronimo project has vote
On 12 Aug 2005, at 20:57, Sanjiva Weerawarana wrote:
On behalf of Blue Titan, Infravio, Sonic Software and WSO2 I'd like to
make a proposal to start a new incubator project to build an ESB/
broker.
For details see:
http://wiki.apache.org/incubator/SynapseProposal
Any feedback on the propos
Attached is a patch which adds Spring-style dependency injection to the
configuration of Nodes/Tasks in the Agila XML using a
element.
e.g.
123
Here are the new DAO classes from the previous patch (I've finally
realised, sending them as a .zip tends to get bounced., DOH! :)
/**
*
* Copyright 2003-2004 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file exce
Here's a few proposals rolled into one which are simple to implement
but make the Agila XML much more useful and powerful...
Configuring Tasks/Nodes
I'd be really cool to be able to have reusable tasks for Agila then
configure them on a per workflow basis. e.g. lots of task
On 9 Nov 2004, at 14:54, Jeremy Boynes wrote:
[EMAIL PROTECTED] wrote:
On 8 Nov 2004, at 18:53, Jeremy Boynes wrote:
I think we may be in violent agreement here :-)
I think we should add some type of collective entity, I just
hesitate to call it a Group as that tends to be associated with a
speci
Currently without this change, any attempt to change an instance
actually changes the status of all instances! :)
Index: JDBCUtil.java
===
--- JDBCUtil.java (revision 56926)
+++ JDBCUtil.java (working copy)
@@ -395,7 +395
Similarly, agila.engine.Instance looks close to
agila.services.InstanceInfo. Could the latter implement the former?
On 9 Nov 2004, at 11:51, [EMAIL PROTECTED] wrote:
So far they contain most of the same information; but all their
properties are of different names (getBusinessProcessID() versus
Shouldn't this method be renamed to getInstanceInfos() or something to
match more the naming conventions of the rest of the API - such as
BusinessProcessService?
James
---
http://radio.weblogs.com/0112098/
-
To unsubscrib
So far they contain most of the same information; but all their
properties are of different names (getBusinessProcessID() versus
getId()) and getName() versus getProcessName().
Firstly can we be a bit more consistent in naming things. Secondly how
about implementing the same interface for these
I'm working on a project using Agila and Tapestry and have created a
few small classes for integrating the two together (e.g.
TapestryRenderer, TapestryRsponseHandler) and I could extract a couple
of fairly simple helper classes for binding responses into Tapestry
pages/events.
Would there be
On 8 Nov 2004, at 18:53, Jeremy Boynes wrote:
I think we may be in violent agreement here :-)
I think we should add some type of collective entity, I just hesitate
to call it a Group as that tends to be associated with a specific
model ( a relatively static set of users and other groups). Call it
On 8 Nov 2004, at 15:58, Jeremy Boynes wrote:
[EMAIL PROTECTED] wrote:
Its very common with people workflow to assign a task to a group of
users (or a role) rather than assigning it to a specific individual
user. Then a user sees a list of all available tasks they could
perform - they then grab
Its very common with people workflow to assign a task to a group of
users (or a role) rather than assigning it to a specific individual
user. Then a user sees a list of all available tasks they could perform
- they then grab one ('locking it') and then execute the task or
releasing it back into
In an attempt to comprehend what the bindings are and how they work for
static versus EL types (static appears to be read-only, rather than a
static expression) I hacked up this extra test case which might be
interesting for others...
Index: NodeContextImplTestCase.java
I've attached a patch which fixes up the Task insert so that when you
assign a task to a user you can capture the TaskID for the task.
It also avoids the hacky try/catch solution to try update first and
only insert if that fails.
Index: TaskServiceImpl.java
=
16 matches
Mail list logo
