is there any reason behind the fact that when I do cocoon:deploy all
application blocks are unpacked under 'blocks' directory while running
cocoon:deploy-war creates 'apps' directory?
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager
On 11 Aug 2006, at 20:34, Peter Hunsberger wrote:
On 8/11/06, Jorg Heymans <[EMAIL PROTECTED]> wrote:
I felt that my current involvement in cocoon is not big enough to
warrant a veto, hence the -0 here. WLS 8.1 was just an example
from my
past experience, but technically you're right ofcours
On 8/10/06, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
> If there are other use cases that require Java 1.4 you should seriously
> consider if Simones proposal of using the Retroweaver would be enough.
This works only as long as you don't use extensions made to the JDK
classes. Different JDK vers
On 8/11/06, Jorg Heymans <[EMAIL PROTECTED]> wrote:
Daniel Fagerstrom wrote:
>>> -0, because this means eliminating cocoon 2.2 on "older" application
>>> servers eg weblogic 8.1.
> IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the use
> of servlet 2.4 to make this a valid point
On 8/10/06, David Crossley <[EMAIL PROTECTED]> wrote:
Good points Peter and Antonio. However please do such
over in the Vote or discussion threads. This thread is
about the policy of dealing with a -1 vote.
Yes, I understand, that's why I posted: we need to decide what kind
of vote is needed
Jorg Heymans escribió:
Daniel Fagerstrom wrote:
-0, because this means eliminating cocoon 2.2 on "older" application
servers eg weblogic 8.1.
IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the use
of servlet 2.4 to make this a valid point.
I felt that my cur
***
* *
* Cocoon GetTogether 2006 *
* *
* October 2nd to 4th *
* *
* Amsterdam, The Netherlands *
*
Daniel Fagerstrom wrote:
>>> -0, because this means eliminating cocoon 2.2 on "older" application
>>> servers eg weblogic 8.1.
> IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the use
> of servlet 2.4 to make this a valid point.
>
I felt that my current involvement in cocoon is n
1. what version of javaflow?
2. what version of jci?
We're working with the trunk version : 1.0-SNAPSHOT for jci-core and
javaflow
Then we tried to integrate the FilesystemAlterationMonitor with the
cocoon classloader configuration, in order to automatically reload
and enhance the Javaflo
The rewrite method of the BCEL enhancer checks all the bytecode, and
when it find an INVOKE (or INVOKEVIRTUAL, still studying bytecode) to an
enhanced class (and there are other conditions) it writes the push and
pop instructions, so that if that class suspends the continuation, the
system will
Torsten Curdt wrote:
>> IIUC the core of the instrumentation is done into the rewrite method,
>> that parses the bytecode operations and decides what to do; adding a
>> block that identifies the invoke operation and adds a method call
>> would work; we tried unluckily to implement it, maybe someon
11 matches
Mail list logo
