Re: Next steps?
> So, if I don’t hear anything else within the next 72h, I’ll initiate the >> Git migration. >> >> > +1 > +1 Torsten >
Re: AW: Developer Survey Results
> > During the past years, I always felt it was somehow my duty as chair to > write reports, ensure someone answers to incoming requests, etc... > So yes it is formally a simple secretarial role, but as a someone only > involved in a now-retired-version (2.1), I think it'd be good for the > project that the chair is actually involved in the current live branch. > > So good news if you're willing to take the hat :) > +1 to all of that
Developer Survey Results
The Developer survey is now open for 9 days. We have received 10 responses. 5 were from PMC members. Here are the results https://app.edkimo.com/results/ewevipve My takeaways: - 7 disagree to retire - only 10 responses is discouraging - but 6 say they can make time and imagine to continue work on Cocoon - I really hope the person that can imagine to be PMC chair will step forward - 2.1 is still the most widely used version (and I am curious how this can be merged into a single path forward) cheers, Torsten
Re: [IMPORTANT] Developer Survey on the State of Cocoon
> So, what’s the status of this? > I haven’t started the Git migration as I thought it might make more sense > to wait for the end of this. > I tried to wait as long as possible - but there ain't more responses coming in I guess. Let me send the results... >
[IMPORTANT] Developer Survey on the State of Cocoon
The PMC wants to gather feedback on the state of the project. If you can, please spend the 2 minutes answering our quick survey. The survey is anonymous. https://app.edkimo.com/feedback/ewevipve This is for EVERYONE on the dev list - not just committers! Even if you have already participated in the PMC survey, please also answer this one. Thanks! cheers, Torsten In behalf of the Cocoon PMC
Re: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
> I guess as there were no objections, I’ll go forward with this. > +1
Re: [VOTE] Release Cocoon 2.1.13
Ah, OK. Better!
gpg: Signature made Fr 17 Jul 20:05:16 2020 CEST
gpg:using RSA key F9E031E290C9797C7F4CC02576ABEF9A6CDA1E88
gpg: Good signature from "Cédric Damioli (CODE SIGNING KEY) <
cdami...@apache.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
That said - we probably need to get your key some trust.
Someone close by for a quick key signing party? :)
But I don't believe that's a blocker.
I didn't find the time to get an old JDK and run and build the release.
But from the sources/diffs the release looks good.
So I am giving my +1
If SOME OTHER PEOPLE want to have a look at it ;)
svn diff -r {2013-03-20}:{2020-08-01}
https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/
svn log -r {2013-03-20}:{2020-08-01} --diff
https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/
Thanks Cédric!
On Mon, Jul 20, 2020 at 11:32 AM Cédric Damioli wrote:
> Hi Torsten,
>
> I actually added my code signing key in
> https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/KEYS
>
> I wasn't aware of https://downloads.apache.org/cocoon/KEYS. I'll add my
> key to this file when uploading release artifacts.
>
> Is it ok for you ?
>
> Cédric
>
>
> Le 19/07/2020 à 19:18, Torsten Curdt a écrit :
>
> I did a
>
> gpg --import KEYS.txt
>
> just to make sure, but I am still getting
>
> gpg --verify cocoon-2.1.13-src.tar.gz.asc cocoon-2.1.13-src.tar.gz
> gpg: Signature made Fr 17 Jul 20:05:16 2020 CEST
> gpg:using RSA key
> F9E031E290C9797C7F4CC02576ABEF9A6CDA1E88
> gpg: Can't check signature: No public key
>
> Is your key maybe missing from https://downloads.apache.org/cocoon/KEYS
>
> cheers,
> Torsten
>
> On Sat, Jul 18, 2020 at 7:08 AM Francesco Chicchiriccò <
> ilgro...@apache.org> wrote:
>
>> On 17/07/20 20:40, Cédric Damioli wrote:
>> > Hi,
>> >
>> > More than 7 years after the 2.1.12 release, I'm glad to propose to
>> release Apache Cocoon 2.1.13 !
>> >
>> > Proposed releases artifacts are located at
>> https://dist.apache.org/repos/dist/dev/cocoon/
>> >
>> > Please check the files, verify checksums, build and run samples, and
>> cast your votes.
>>
>> +1
>> Thanks Cédric!
>>
>> Regards.
>>
>> --
>> Francesco Chicchiriccò
>>
>> Tirasa - Open Source Excellence
>> http://www.tirasa.net/
>>
>> Member at The Apache Software Foundation
>> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
>> http://home.apache.org/~ilgrosso/
>>
>>
> --
> Cédric Damioli
> CMS - Java - Open Sourcewww.ametys.org
>
>
Re: [VOTE] Release Cocoon 2.1.13
I did a gpg --import KEYS.txt just to make sure, but I am still getting gpg --verify cocoon-2.1.13-src.tar.gz.asc cocoon-2.1.13-src.tar.gz gpg: Signature made Fr 17 Jul 20:05:16 2020 CEST gpg:using RSA key F9E031E290C9797C7F4CC02576ABEF9A6CDA1E88 gpg: Can't check signature: No public key Is your key maybe missing from https://downloads.apache.org/cocoon/KEYS cheers, Torsten On Sat, Jul 18, 2020 at 7:08 AM Francesco Chicchiriccò wrote: > On 17/07/20 20:40, Cédric Damioli wrote: > > Hi, > > > > More than 7 years after the 2.1.12 release, I'm glad to propose to > release Apache Cocoon 2.1.13 ! > > > > Proposed releases artifacts are located at > https://dist.apache.org/repos/dist/dev/cocoon/ > > > > Please check the files, verify checksums, build and run samples, and > cast your votes. > > +1 > Thanks Cédric! > > Regards. > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/ > >
[jira] [Commented] (COCOON-2368) Impossible to read MP4 file in Safari (desktop and IOS) with Cocoon 2.1.12
[ https://issues.apache.org/jira/browse/COCOON-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970448#comment-16970448 ] Torsten Curdt commented on COCOON-2368: --- You are thinking way too high level. mitmproxy, fiddler, charles proxy or even wireshark/tcpdump/tcpflow allow you to record http request response flows. You want to see the http headers of all communications - and then compare the two scenarios. > Impossible to read MP4 file in Safari (desktop and IOS) with Cocoon 2.1.12 > -- > > Key: COCOON-2368 > URL: https://issues.apache.org/jira/browse/COCOON-2368 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core, Blocks: (Undefined) >Affects Versions: 2.1.12 >Reporter: Modou Dia >Priority: Major > > Hello, > I try to load a MP4 File with a Cocoon Reader. It works well in all major > browsers except Safari (desktop and IOS). > Referring to this thread : > https://stackoverflow.com/questions/30199261/why-wont-safari-play-file-without-extension-in-video/51901198#51901198, > I overloaded the default Reader' by forcing cocoon to add a Byte Range > header (and 206 status code) ... It still does not work. > For being sure to avoid encode problems, I have tried the same mp4 file > directly and only with an Apache Server. It is loaded well in Safari and all > other browsers. > Last point, if the reader pipeline is cached or not (or if the browser cache > is empty or not) the behaviour is completely different following browser > used. In all cases, with Safari it never works. > Thank you for you helps . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COCOON-2368) Impossible to read MP4 file in Safari (desktop and IOS) with Cocoon 2.1.12
[ https://issues.apache.org/jira/browse/COCOON-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970162#comment-16970162 ] Torsten Curdt commented on COCOON-2368: --- You should provide the full request response flow (without the body) for both cases. Working and not working. > Impossible to read MP4 file in Safari (desktop and IOS) with Cocoon 2.1.12 > -- > > Key: COCOON-2368 > URL: https://issues.apache.org/jira/browse/COCOON-2368 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core, Blocks: (Undefined) >Affects Versions: 2.1.12 >Reporter: Modou Dia >Priority: Major > > Hello, > I try to load a MP4 File with a Cocoon Reader. It works well in all major > browsers except Safari (desktop and IOS). > Referring to this thread : > https://stackoverflow.com/questions/30199261/why-wont-safari-play-file-without-extension-in-video/51901198#51901198, > I overloaded the default Reader' by forcing cocoon to add a Byte Range > header (and 206 status code) ... It still does not work. > For being sure to avoid encode problems, I have tried the same mp4 file > directly and only with an Apache Server. It is loaded well in Safari and all > other browsers. > Last point, if the reader pipeline is cached or not (or if the browser cache > is empty or not) the behaviour is completely different following browser > used. In all cases, with Safari it never works. > Thank you for you helps . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COCOON-2368) Impossible to read MP4 file in Safari (desktop and IOS) with Cocoon 2.1.12
[ https://issues.apache.org/jira/browse/COCOON-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970091#comment-16970091 ] Torsten Curdt commented on COCOON-2368: --- For the record $ curl -I http://test-v4.pleade.com/functions/ead/detached/docs/test.mp4 HTTP/1.1 200 OK Date: Fri, 08 Nov 2019 11:17:23 GMT Server: Apache X-Cocoon-Version: 2.1.10 Set-Cookie: JSESSIONID=43554C2D80E2A947FA8015821E611385; Path=/; HttpOnly Accept-Ranges: bytes Last-Modified: Fri, 08 Nov 2019 10:18:43 GMT access-control-allow-origin: * ETag: 1 cache-control: max-age=31536000 Content-Type: video/mp4 Content-Length: 589052 $ curl -I http://test-v4.pleade.com/test.mp4 HTTP/1.1 200 OK Date: Fri, 08 Nov 2019 11:17:39 GMT Server: Apache Last-Modified: Tue, 29 Oct 2019 14:54:19 GMT ETag: "8fcfc-5960dca7db96d" Accept-Ranges: bytes Content-Length: 589052 Content-Type: video/mp4 But this is not enough information for debugging this. You need at the full request response flow. And the ETag header with "1" looks fishy as is. While we will try to help as good as we can you need to provide more information or hire someone to do the debugging for you. > Impossible to read MP4 file in Safari (desktop and IOS) with Cocoon 2.1.12 > -- > > Key: COCOON-2368 > URL: https://issues.apache.org/jira/browse/COCOON-2368 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core, Blocks: (Undefined) >Affects Versions: 2.1.12 >Reporter: Modou Dia >Priority: Major > > Hello, > I try to load a MP4 File with a Cocoon Reader. It works well in all major > browsers except Safari (desktop and IOS). > Referring to this thread : > https://stackoverflow.com/questions/30199261/why-wont-safari-play-file-without-extension-in-video/51901198#51901198, > I overloaded the default Reader' by forcing cocoon to add a Byte Range > header (and 206 status code) ... It still does not work. > For being sure to avoid encode problems, I have tried the same mp4 file > directly and only with an Apache Server. It is loaded well in Safari and all > other browsers. > Last point, if the reader pipeline is cached or not (or if the browser cache > is empty or not) the behaviour is completely different following browser > used. In all cases, with Safari it never works. > Thank you for you helps . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COCOON-2368) Impossible to read MP4 file in Safari (desktop and IOS) with Cocoon 2.1.12
[ https://issues.apache.org/jira/browse/COCOON-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torsten Curdt updated COCOON-2368: -- Priority: Major (was: Blocker) > Impossible to read MP4 file in Safari (desktop and IOS) with Cocoon 2.1.12 > -- > > Key: COCOON-2368 > URL: https://issues.apache.org/jira/browse/COCOON-2368 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core, Blocks: (Undefined) >Affects Versions: 2.1.12 >Reporter: Modou Dia >Priority: Major > > Hello, > I try to load a MP4 File with a Cocoon Reader. It works well in all major > browsers except Safari (desktop and IOS). > Referring to this thread : > https://stackoverflow.com/questions/30199261/why-wont-safari-play-file-without-extension-in-video/51901198#51901198, > I overloaded the default Reader' by forcing cocoon to add a Byte Range > header (and 206 status code) ... It still does not work. > For being sure to avoid encode problems, I have tried the same mp4 file > directly and only with an Apache Server. It is loaded well in Safari and all > other browsers. > Last point, if the reader pipeline is cached or not (or if the browser cache > is empty or not) the behaviour is completely different following browser > used. In all cases, with Safari it never works. > Thank you for you helps . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COCOON-2368) Impossible to read MP4 file in Safari (desktop and IOS) with Cocoon 2.1.12
[ https://issues.apache.org/jira/browse/COCOON-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970022#comment-16970022 ] Torsten Curdt commented on COCOON-2368: --- What I would suggest is to record the HTTP flow between a working and a non-working scenario. Then you can deduce what feature is missing for supporting Safari. Everything else is a bit like stabbing in the dark. Given it works on all major browsers but Safari this certainly is not a blocker in Cocoon. I will hence reduce the severity. > Impossible to read MP4 file in Safari (desktop and IOS) with Cocoon 2.1.12 > -- > > Key: COCOON-2368 > URL: https://issues.apache.org/jira/browse/COCOON-2368 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core, Blocks: (Undefined) >Affects Versions: 2.1.12 >Reporter: Modou Dia >Priority: Blocker > > Hello, > I try to load a MP4 File with a Cocoon Reader. It works well in all major > browsers except Safari (desktop and IOS). > Referring to this thread : > https://stackoverflow.com/questions/30199261/why-wont-safari-play-file-without-extension-in-video/51901198#51901198, > I overloaded the default Reader' by forcing cocoon to add a Byte Range > header (and 206 status code) ... It still does not work. > For being sure to avoid encode problems, I have tried the same mp4 file > directly and only with an Apache Server. It is loaded well in Safari and all > other browsers. > Last point, if the reader pipeline is cached or not (or if the browser cache > is empty or not) the behaviour is completely different following browser > used. In all cases, with Safari it never works. > Thank you for you helps . -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Meet Cocoon CLI
*My* issue - that induced me on the XML format - is that via CLI, expressing a pipeline would be not so easy :/ Indeed Moreover, using my beloved commons-digester allowed me having a working PoC in less than one day. Anyway, I agree that something different from XML should be provided to our users, my other issue is that I don't have good background on JavaCC/AnTLR to write a DSL... and haven't taken a look yet on XText... would you recommend it? So far I have only used ANTLR. Happy to help out with it. XText looks intriguing though. About packaging: I use the Application Assembler Maven Plugin[1] to create the application - it generates even the scripts for both linux/windows, so not so hard to manage. Interesting. That's not so bad then. Personally still prefer java -jar way though. cheers, Torsten
Re: Meet Cocoon CLI
So, what I did today is replicating the Apache Ant/Maven behavior, I mean, cocoon-cli is a console application that takes in input an XML pipeline descriptor - called c3p.xml by default - that looks like very similar to ant build.xml file: ...which is not necessarily is a good thing :) I just had to think of an old thread about an even older discussion http://markmail.org/message/mxivpqxli5rcbffu I think many people have come to terms with XML in the sense that it is just not great for humans to write. C3 could be perfect to come up with just a DSL To package it, it is enough launching `mvn package` under /cocoon-cli[1], its execution will produce .tar.gaz and .zip packages under /cocoon-cli/target, that contain a multi-platform application which directories tree looks like the Maven one: . ├── README ├── bin │ ├── c3pipe │ └── c3pipe.bat ├── lib ├── cocoon-cli-3.0.0-beta-1-SNAPSHOT.jar ├── cocoon-pipeline-3.0.0-beta-1-SNAPSHOT.jar ├── cocoon-sax-3.0.0-beta-1-SNAPSHOT.jar ├── cocoon-util-3.0.0-beta-1-SNAPSHOT.jar ├── cocoon-xml-2.0.2.jar ├── commons-beanutils-1.8.3.jar ├── commons-digester3-3.1.jar ├── jcl-over-slf4j-1.6.1.jar ├── jcommander-1.17.jar ├── logback-classic-0.9.29.jar ├── logback-core-0.9.29.jar └── slf4j-api-1.6.1.jar I would just use the maven shade plugin and make it a runnable jar. Makes it much easier to handle. WDYT? Feedbacks are needed and of course participation is open, everybody interested is welcome! :) Go go go Simone! :) cheers, Torsten
Re: Cocoon GetTogether?
And that leads me to ask, what are the possibilities of a Cocoon GetTogether this year? next year? (The sooner the better, as far as I'm concerned!) AFAIK the last GT was in 2005? The hackathon sounded very productive. GT have always been great events but do we have enough people that would bother to come? ...and especially sponsors that see it worthwhile? cheers, Torsten
Re: [proposal] cocoonstuff.org
Hmm... /snip +1 sharing these thoughts Also, a separate environment comes with additional time spent in administrative stuff (look at your long task list!) that could probably be used more wisely to build a stable C3. +1 So if the purpose is to lower the barrier for contribution, then why not just having a contrib directory in SVN, clearly showing that these aren't core modules, but still under the oversight of the PMC and the ASF at large? I fear that's not really lowering the barrier of entry. Still committers are the gate keepers Of course, managing Git pull requests would be more convenient than applying patches in Jira, but still, at this point, this is probably easier than having a completely separate infrastructure. but after all there is already... https://github.com/apache/cocoon if we could accept pull requests from people with ICLAs on file - that would be a great step forward to lower the barrier for contributions. cheers, Torsten
Re: is possible to use jquery in coccon
This is rather a question suited for the users list. jquery is for the client side. Cocoon is for the server side and can generate pretty much all you want. So the answer to your question should be yes ...unless I misunderstood what you are trying to do. cheers -- Torsten On Fri, Apr 30, 2010 at 14:37, neotello neote...@hotmail.com wrote: i am new in cocoon my question is possibly stupid, but i not found the response in google... is possible to use jquery's elements in cocoon?? thank... -- View this message in context: http://old.nabble.com/is-possible-to-use-jquery-in-coccon-tp28411753p28411753.html Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: Problems with JavaFlow
1. since Cocoon is Maven, based I sort of dislike the option of falling back
to ant.
Can't say I'd like it ...but it would get the job done quickly.
2. Wouldn't this ad a dependency to JavaFlow to cocoon itself?
No - only to JCI. And that's already there.
But as it looks all that is required is already supported with the
RCL. At least from the configuration options it looks like.
3. At the moment I think I would like this option a lot ... even if my
gut-feeling tells me in your next mail you're going to say cool ... write
it
Yepp! :)
... I guess I would need more detailed information about JavaFlow for
this
No you really don't! You need some maven knowledge on how to write a mojo.
Check out the ant task. All it does is
foreach class in classes {
if (matches(class)) {
oldClassFile = input.read()
newClassFile = transformer.transform(oldClassFile)
output.write(newClassFile)
} else {
IOUtils.copy(input, output)
}
}
You could probably even leave out the matching for now.
... maybe you're going to drop by near Frankfurt someday ;-)
I am in Frankfurt until mid Jan.
One thing I like about this, is that I would get pre-instrumented JavaFlow
classes form my flows. The downside is that It might need some kind of
Eclipse plug-in to accompany it since Eclipse would replace the instrumented
class with a non instrumented one as soon as someone changes it ...
As said: The development/deployment approach worked very well for me
with eclipse.
4. Ok ... this one sounds a little more complex. In some projects I am
currently working on, we are using the eclipse compiler instead of the
ordinary maven-one since the default Jdk compiler seems to have some
problems dealing with some Java 1.6 features (strange thing that suns
compiler seems to have problems with suns features) ... this would rob me of
this option.
Indeed it is a little more complex. But the maven jci plugin would
support all sorts of compilers.
I would propose that a solution of 2 + 3 sounds safest from my point of
view. Writing a plug-in for the RCL (assuming there is something like that).
In addition creating a Maven plug-in doing the instrumentation would be
great. Both could work together:
Actually I think all is needed is such a maven instrumentation plugin.
The Maven could set some kind of mark in the instrumented classes to
indicate the RCL-plug-in that this class was already instrumented. In this
case the RCL simply relays the class. If the flag is not set it instruments
the class.
Actually that's something that could be added to the class transformer
itself. If there already is a dependency to the javaflow runtime
classes it's not instrumented again. That would make the whole think
quite fool proof. Easy to implement as well.
This would make development a lot easier and boost the default
performance of production builds.
Here you lost me again :)
Every time I say, that I would gladly contribute, Murphy comes along and
steals all my free time, so let me say, that if the information I need sort
of pops up in my Mail-Folder, and Murphy left over some time, I will gladly
try to do something with this information ... even if it is only printing it
and throwing paper balls at Murphy ;-)
:-)
cheers
--
Torsten
Re: Javaflow in C2.2
Hm ... guess it's time for some debugging. I'll try maybe during AC ... but no promises. cheers -- Torsten
Re: Javaflow in C2.2
Eclipse offers much information in debugging mode. Are the addresses the right information? Indeed. [EMAIL PROTECTED]/[EMAIL PROTECTED] Means it's instance 16273041 of CalculatorFlow in WebappClassLoader instance 20085762. If you try to cast a CalculatorFlow to a CalculatorFlow that was loaded by anything else but [EMAIL PROTECTED] you will see a CCE. In fact it means you are then dealing with two different versions (not instances) of the same class. HTH cheers -- Torsten
Re: Javaflow in C2.2
Uh ... that's not good. The samples should be working. You should raise an issue in jira. I tried to locate the error via remote debugging. So, I started Tomcat with debugging support and stepped through the classes using eclipse debugging perspective. However, when I stepped into Invoker.java, I got a message com.sun.jdi.InternalExcpetion: Got error code in reply: 35 occurred retrieving 'this' from stack frame. I think this is a result of instrumenting Invoker.class by commons/javaflow. So, I can't locate the error exactly. Hm ... usually instrumenting should not hamper debugging. After sendPageAndWait these are the stacks: - Integer Stack 0: 8 1: 0 2: 2 - Object stack: 0: CalculatorFlow 1: a 2: page/calculator-a 3: hello world 4: CalculatorFlow 5: Invoker 6: ClassT (org.apache.cocoon.samples.flow.java.CalculatorFlow) 7: CalculatorFlow - Reference stack: 0: CalculatorFlow 1: CalculatorFlow I don't know, if these stacks are correct. However, several pop actions happen now: 1. Reducing iTop to 2 2. Reducing oTop to 5 3. Reducing rTop to 1 After this pops, the error occurs. I get an class exception error. I don't know what caused the error and how to get more information. Do you have any idea? More important than what listed above is the actual classloader that loaded the class on the stack. I you must be dealing with two different versions of CalculatorFlow or Invoker. (Different in being loaded by different classloaders) Check the .getClass().getClassLoader() for those and compare them with where the CCE occurs. cheers -- Torsten
Re: Javaflow in C2.2
Hey ok, CFormsFlow is wrong, so I started to run CalculatorFlow from the cocoon-javaflow-sample block. I got similar error messages. So, I think my setup is wrong. Uh ... that's not good. The samples should be working. You should raise an issue in jira. Since I didn't instrument any classes I got the error message that Invoker.class is not instrumented. That's still not included in the build yet? Hm Do you have any idea? Frankly speaking last time I looked into javaflow (especially the cocoon integration) is already a few years ago. And many things have changed. Maybe someone using javaflow today could help out? I would try to get class reloading working first. Both are using a similar mechanism. cheers -- Torsten
Re: Javaflow in C2.2
Hey Rainer, CFormsFlow seems to be the culprit - not the invoker. It's hard to tell more without knowing your setup. cheers -- Torsten On Sep 18, 2008, at 23:09, Rainer Heesen wrote: Many thanks for you help. It sounds interesting. I tried a grep of the log file to identify the Invoker.class instances. grep Invoker log4j.log says I think there is only one instance of the Invoker.class mentioned in the log file. Do you have any suggestion for points to check? Kind regards Rainer Am Donnerstag 18 September 2008 schrieb Torsten Curdt: org.apache.commons.javaflow.bytecode.StackRecorder - org.cocoontest.javaflow.CFormsFlow java.lang.ClassCastException: org.cocoontest.javaflow.CFormsFlow at org.apache.cocoon.components.flow.java.Invoker.run(Invoker.java) This is the interesting bit. There is somehow a classloader screwup. CFormsFlow is on the stack and there are different versions of it. Somehow it's using the wrong one. But I can't say much more from here. HTH anyway. cheers -- Torsten log4j.zip
Re: Javaflow in C2.2
org.apache.commons.javaflow.bytecode.StackRecorder - org.cocoontest.javaflow.CFormsFlow java.lang.ClassCastException: org.cocoontest.javaflow.CFormsFlow at org.apache.cocoon.components.flow.java.Invoker.run(Invoker.java) This is the interesting bit. There is somehow a classloader screwup. CFormsFlow is on the stack and there are different versions of it. Somehow it's using the wrong one. But I can't say much more from here. HTH anyway. cheers -- Torsten
Re: RCL plug-in and different classloaders issues
On Aug 17, 2008, at 14:14, Grzegorz Kossakowski wrote: Torsten Curdt pisze: Well, the only thing I could think of right now: Define a common interface that is loaded by parent. Delegate to an implementation of that from EXTENSION. That should work. But if you want to extend something that is changing (and not has a fix interface) you will have to load it from the RSCL. Yes, that could work but there is another problem. Once EXTENSION obtains ApplicationContext and tries to load some beans ClassCastExceptions will be thrown because EXTENSION holds references to interface classes loaded by parent and ApplicationContext holds references to interfaces loaded by RCL. In short: a mess. Not entirely sure that really is the case like that ...but anyway. Well, the RCL currently is pointed to a folder of class files. It should not be too hard to also have it monitor a directory of jars. I know that's its not hard when it comes to modifying the code but I was wondering if it's a good idea in general to load everything using ReloadingClassLoader. It was not done in the first time so I thought that someone had a good reason to do that. Well, the question is what does change - transitively. In this case you extending something that is (potentially) changing. Anyway, I decided to rewrite 3RDPARTY the way that I can inject my own extensions so I could get rid of static class completely. God bless open source 3RDPARY dependencies ;-) Hehehe :) If anyone else is reading this thread: Lesson for everyone - static classes and variables are not so static when you use different classloaders. Moreover, they are not a good idea in any case. +1 :) cheers -- Torsten
Re: RCL plug-in and different classloaders issues
Well, if you think about it: with this setup there is no other way around to have the parent classloader know of the static class to have this problem resolved. As you can't (?) modify the parent classloader your only chance is to have the EXTENSION loaded by the RSCL as well. But how this can be enforced? I mean, 3RDPARTY is loaded by parent and 3RDPARTY, when tries to create a new instance of EXTENSION uses it's own classloader thus uses parent. The only solution I can see here is that I load 3RDPARTY using classloader coming from JCI so then EXTENSION will be loaded with this classloader as well. Am I missing something? No, I was trying to say the same thing :) I would take a step back and re-think the situation. This static stuff smells like wants to be replaced ;-) If I knew how to do it, I would go with that direction immediately. :-P :-) Basically, the problem is that one wants to access Spring's application context within EXTENSION's constructor. Any suggestion how to do it without using static class? Well, the only thing I could think of right now: Define a common interface that is loaded by parent. Delegate to an implementation of that from EXTENSION. That should work. But if you want to extend something that is changing (and not has a fix interface) you will have to load it from the RSCL. However, that would mean that one needs to modify commons-jci project. Why? How? I was thinking to enforce ResourceStoreClassLoader to load everything but I know that it's not the best idea... Well, the RCL currently is pointed to a folder of class files. It should not be too hard to also have it monitor a directory of jars. cheers -- Torsten
Re: RCL plug-in and different classloaders issues
In brief, following steps are performed: 1. Class from my block is loaded using ResourceStoreClassLoader. Let's call this class MAIN. 2. This class accesses some static method of another class loaded by ResourceStoreClassLoader (because this class comes from my block as well) and sets some value on static field. Let's call this class STATIC Just a quick comment: static + classloader == evil ;-) 3. Then another class (3RDPARTY) is being loaded which is not part of my block, it's from third-party jar. It's loaded by parent classloader to ResourceStoreClassLoader. As part of configuration of this class I pass a name of class which is some kind of extension point and is implemented by class coming from my block; let's call this class EXTENSION. 4. 3RDPARTY creates new instance of EXTENSION class (and this class is again not loaded by ResourceStoreClassLoader but by parent), but in EXTENSION class one tries to access field set in STATIC. 5. While EXTENSION tries to access STATIC, STATIC is being loaded again, using parent classloader. The value in STATIC is gone, obviously. So the basic problem is that, this STATIC class is loaded by two different classloaders. I'm wondering if there is any kind of general solution to such problems. The only one I can think of is to enforce loading of 3RDPARTY class by ResourceStoreClassLoader so everything stays within one classloader and even reflection tricks are not dangerous. Well, if you think about it: with this setup there is no other way around to have the parent classloader know of the static class to have this problem resolved. As you can't (?) modify the parent classloader your only chance is to have the EXTENSION loaded by the RSCL as well. I would take a step back and re-think the situation. This static stuff smells like wants to be replaced ;-) However, that would mean that one needs to modify commons-jci project. Why? How? cheers -- Torsten
Re: Find a new name for Corona
Guy, just my 2 cents. We had this renaming game with CForms IIRC. And it was more confusing than it helped. I guess that was so long ago that some people don't remember. I think Corona is a great name. Everyone uses it. People already know it by now. Let's officially call it Apache Cocoon (Project) Corona. Everyone will call it Corona anyway. Will that really be a problem? (Sorry if I missed that thread/post) And once things are there we can think of a migration strategy and migrate it to Cocoon 3.0. But that is still a long way. cheers -- Torsten
Re: [Corona] PIpeline API
On Jul 15, 2008, at 18:33, Carsten Ziegeler wrote: Peter Hunsberger wrote: On Tue, Jul 15, 2008 at 5:42 AM, Reinhard Pötz [EMAIL PROTECTED] wrote: Are you talking about passing the input parameters as parameters of the setup() method? void setup(MapString, Object inputParameters) I'd be fine by this. I hate seeing Maps used as dumping grounds for randomly typed objects. Could you use something that gives a little more strong typing? Perhaps more like a ServletContext though I don't think I'd go that far in this case? I agree that strong typing would be great - but the pipeline api does not define any concrete key/object for the map. So this is use- case specific. Therefore I think a map is the best we can come up. The question if those configuration are needed in a generic form in the API. (I doubt it) As I would expect them to be implementation specific a configuration callback that sets up the pipeline might be a way around this? Just my 2 cents cheers -- Torsten
Re: test
We'll hunt you in your dreams ;) [EMAIL PROTECTED] does not work for you? On May 21, 2008, at 16:24, Prabhpreet Singh wrote: Jeroen, I want to get rid of cocoon related mails. Do you know how can I do that? Regards, Prabhpreet 2008/5/21 Jeroen Reijn [EMAIL PROTECTED]: Please ignore Regards, Jeroen
Re: [OT] Mac OS X and Java development
On May 9, 2008, at 05:35, Joerg Heinicke wrote: On 08.05.2008 05:39, Lally Singh wrote: What missing Java sources? They are in /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/ src.jar Hmm, not for me. Directory exists, but no src.jar inside. So where to get it from? Came preinstalled on my mac. Did you install the dev tools? No dev tools. Are they only available for Leopard? No ...I also had them on Tiger. I'm still on Tiger - and would rather switch to Linux than spending money for Leopard ;) Oh boy. Just the time searching and fiddling around with alternative approaches may be more expensive. But whatever rocks your boat. Huh, I didn't realize people still run such older versions of MacOS. Tiger? Leopard is only out since 1/2 year, so what ... And I'm not willing to pay for it. Java 6 is the first time apple's drug their feet for any real amt of time like this. Java 5 was a few weeks after the general release, but nothing like this. Why a completely separated version after all? I can see the point of a native lookfeel, but beyond that ... With all due respect guys ...this getting way beyond OT for this list. It's really that simple. If you think about java6 on OSX... ...shell out the 100 bucks for leopard (if you got a 64-bit Intel machine) ...use the freebsd port if you don't need a UI ...stay on java5 ...or install linux It's really that simple. cheers -- Torsten
Re: javaflow / URL of jar
Hey Torsten! Hey Gabriel I have been watching the mailinglist for the last year or so to see changes in javaflow in 2.2 which I would love to use. There weren't many ;) It seems that you are the only one with the complete knowledge to finish javaflow in 2.2... I am sure there are others around which would like to help to get the job done. but my feeling so far is that it would be only minimum effort for you compared to all the others who have given up so far on this job... Indeed as one of the main authors of javaflow and being a cocoon old timer ...that could be right :) another option would be if you could lay out your plan for implementation and some other interested comitters could do it? I surely can try. WDYT? I would love to use javaflow and i would love to help too if i can... What needs to be done can be split into 3 parts 1. The Cocoon side of things 1.1 Last time I checked the continuation management infrastructure in Cocoon needs an overhaul. While the recent thread on javaflow scalability was 2.1 I am sure this still holds true for 2.2. I has been a few years so please bear with my memory ...but I think the following problems need to be addressed: 1.1.1 WebContinuation is a class but should be an interface. Javaflow and flowscript would be a possible implentation. 1.1.2 Just like sessions there needs to be a hard limit for the number of continuations that is enforced on continuation creation time 1.2 IIRC there currently is only one script allowed per sitemap. There is no real good reason for that. 1.3 Support for flows in sub pipelines. This is more a special case that mainly needs to addressed in javaflow - not i Cocoon land. But it's a special case that has come up only in Cocoon. Javaflow currently uses thread locals to store information. Maybe it would be better to store that information in a context ...another option to look into would be to use a stack. I'd prefer the context approach though. 2. Javaflow over in commons 2.1 Javaflow currently has two implementations. The original one is BCEL. The new one is ASM. It would be great to switch to ASM for various reasons. But it seems the ASM implementation is even less robust than the current BCEL one. Still I think is essential to focus on just the one. And surely ASM is the way to go. That would also make the current weird testcase approach simpler in javaflow. 2.2 There are a couple of byte code level things that need to be fixed. This surely is the trickiest part. o fix unintialized objects for method/constructor calls o inner classes o try/catch/finally o synchronized(obj) o accessing .class o new Object() without assignment see http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/TODO?revision=560660view=markup There was some discussion in joining forces with Geer from RIFE. The RIFE continuations work a little bit differently though and impose some restrictions onto how you need to write the flow. Plus it's LGPL but Geer sounded flexible about that when we talked. We also tried to start a JSR for continuation support in the JVM - but that was shut down. (Even Apache - whoever was responsible for it - voted for no) 2.3 Continuation branching should be re-evaluated. Cloning? Serialization? 3. Build integration 3.1 Writing a maven plugin to instrument the resulting artifact should probably just a few hours job. The initial goal was to replace the maven compiler plugin with a maven jci plugin but... can't hurt to be a bit more pragmatic on that one. I don't see maven really adopting JCI for that anytime soon. ...that's how I remember it at least :) Of course documentation is needed. And I also expect that the examples need some love. I bet there is more :) Unfortunately I don't really have the time and enthusiasm working on this at the moment. Would be great to get this finished up and released though. If someone else has the time and motivation - I am certainly happy to give comments/advice. cheers -- Torsten
Re: javaflow / URL of jar
On Apr 16, 2008, at 12:18, Saskia Heesen wrote: Hello everybody! I would like to use javaflow from Cocoon 2.2 since javaflow offers more ways to test the code than flowscript. When I run the example I get the error message: 2008-04-16 11:18:13,839 ERROR http-8080-Processor25 org.apache.commons.javaflow.bytecode.StackRecorder - stack corruption. Is class org.apache.cocoon.components.flow.java.Invoker instrumented for javaflow? java.lang.IllegalStateException: stack corruption. Is class org.apache.cocoon.components.flow.java.Invoker instrumented for javaflow? I think the main difference between Cocoon 2.1 and Cocoon 2.2 regarding javaflow is that javaflow is now based on commons.javaflow. commons.javaflow needs an enhancement of these classes, that are part of the continuation. So, we can't use the default system class loader. However, commons.javaflow provides an appropriate ContinuationClassLoader. JavaInterpreter.java as part of cocoon-javaflow-impl still uses the default system class loader: final Class clazz = Thread.currentThread().getContextClassLoader().loadClass(clazzName); My idea is to replace it by ContinuationClassLoader That's not a really good idea. In 2.2 javaflow basically works hand in hand with the RCL from JCI. The idea is that you can basically point cocoon to your eclipse environment and JCI will pickup the class file changes whenever you change a class through eclipse ...and it will instrument it. This is for development. For deployment the idea is that you should include the instrumentation phase into your build process. Unfortunately there is still only an ant task for it. The idea was to write a maven jci compiler plugin that would essentially replace the original maven one. Being more flexible and supporting things like instrumentations on compile time. But as I don't see that happen in the near future it might be easier to just turn the ant task into a very simple maven javaflow plugin ...or call the ant task from maven. Important thing to note is that in 2.2 the instrument/don't instrumentation is handled via class separation - not a marker interface. So essentially you have one jar with your custom classes and one jar with your flow that should have been instrumented. HTH cheers -- Torsten
Re: Javaflow - major memory issue
On Mar 30, 2008, at 09:43, Joerg Heinicke wrote: On 28.03.2008 04:55, Torsten Curdt wrote: The output I showed pointed to org.apache.cocoon.components.flow.java.Continuation which only seems to exist in Cocoon 2.1. Nothing unsets the context there. Hah - well spotted! Having a look into the code continuations are only handled by JavaInterpreter. There are two methods callFunction(..) and handleContinuation(..) calling Continuation.registerThread() and deregisterThread() in a finally block. From a brief look I have no idea if I can just unset the ContinuationContext there as well. You might know more about it. We should add a try/finally block in Continuation.suspend() that clears the context after a suspend. That should fix it. Unfortunately, it is not possible to unset the ContinuationContext completely. It's needed in JavaInterpreter.handleContinuation(..) when a child continuation is created: Continuation parentContinuation = (Continuation) parentwk.getContinuation(); ContinuationContext parentContext = (ContinuationContext) parentContinuation.getContext(); ContinuationContext context = new ContinuationContext(); context.setObject(parentContext.getObject()); context.setMethod(parentContext.getMethod()); There is no need to really obtain that value from the parent. If handleContinuation would have also the function parameter it could use the same initialization as in callFuntion. Actually a way of fixing this would be to add two Strings to the Continuation class. One holding the classname, the other holding the method name. And then do context.setObject(userScopes.get(parentContinuation.getScopeName())); context.setMethod(methods.get(parentContinuation.getFunctionName())); in handleContinuation. Then the cleaning of the context should be fine. Without completely rewriting it the only thing I did was to remove the data in the ContinuationContext that is not necessary. I do this by an extra call to ContinuationContext.onSuspend() in AbstractContinuable since Continuation is not aware of the implementation of its context (it's just an Object). Please review my changes [1] because I'm not really sure about them. Not a fan of the Collections.synchronizedMap(new HashMap()) change - but other than that they look OK on the first glance :) They work for the normal case, but what happens in an error case? I can't see what's really going on except that the method is left on Continuation.suspend() ... It was very interesting to debug it when AbstractContinuable.sendPageAndWait(..) was actually hit twice. :) ...what error case do you mean? I guess this handling is different in 2.2. There a clean ContinuationContext is created on both callFunction(..) and handleContinuation(..). Indeed ...that would be another fix ...porting it from 2.2 :) Thanks for looking into that. cheers -- Torsten
Re: Javaflow - major memory issue
Without completely rewriting it the only thing I did was to remove the data in the ContinuationContext that is not necessary. I do this by an extra call to ContinuationContext.onSuspend() in AbstractContinuable since Continuation is not aware of the implementation of its context (it's just an Object). Please review my changes [1] because I'm not really sure about them. Not a fan of the Collections.synchronizedMap(new HashMap()) change - but Just curious, any reason for this? Is it not as optimized? Well, of course you pay a runtime penalty for another method invocation unless the hotspots is able to optimize that away. Not sure. But it's less about optimization - more about keeping the synchronization more visible. But as long as the access to the hashmap is simple like it is right now I would not argue about it :) other than that they look OK on the first glance :) They work for the normal case, but what happens in an error case? I can't see what's really going on except that the method is left on Continuation.suspend() ... It was very interesting to debug it when AbstractContinuable.sendPageAndWait(..) was actually hit twice. :) ...what error case do you mean? Not sure, originally you proposed to put it into a try finally block. Just to have it as post condition. You never know. I guess this handling is different in 2.2. There a clean ContinuationContext is created on both callFunction(..) and handleContinuation(..). Indeed ...that would be another fix ...porting it from 2.2 :) That's really beyond what I want to do ;-) Let's leave the good stuff for 2.2. +1 Thanks for looking into that. It was really interesting to see how a Java method is cut into two pieces. Suddenly the debugger stops stepping, but just leaves the methods. And on the next call it just jumps to the appropriate places in the code. Once you get used to it it's easy to debug. I have never tried it before but now I like it better than flowscript. Yeah, it's interesting isn't it? :) cheers -- Torsten
Re: Meeting in Amsterdam
On Mar 29, 2008, at 21:04, Bertrand Delacretaz wrote: On Fri, Mar 28, 2008 at 12:08 PM, Torsten Curdt [EMAIL PROTECTED] wrote: Bertrand Delacretaz wrote: how about having dinner together somewhere on Monday night? ...keep in mind there is also the BarCamp on Monday night Right, forgot about that. I don't have precise info but it's planned at the end of the Hackathon day on Monday, time and place will be announced on site I guess. See Message-ID: [EMAIL PROTECTED] on [EMAIL PROTECTED] for more info. I suggest meeting at that BarCode event then, and we can still have dinner after if needed. +1 -- Torsten
Re: Javaflow - major memory issue
On Mar 28, 2008, at 04:29, Joerg Heinicke wrote: On 27.03.2008 10:33, Torsten Curdt wrote: Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? Ah, getting closer :) It's the Continuation that holds the ContinuationContext [1]: Hm... it should set clear the reference in 'finally'. See the execute method http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/StackRecorder.java?revision=560660view=markup The output I showed pointed to org.apache.cocoon.components.flow.java.Continuation which only seems to exist in Cocoon 2.1. Nothing unsets the context there. Hah - well spotted! Having a look into the code continuations are only handled by JavaInterpreter. There are two methods callFunction(..) and handleContinuation(..) calling Continuation.registerThread() and deregisterThread() in a finally block. From a brief look I have no idea if I can just unset the ContinuationContext there as well. You might know more about it. We should add a try/finally block in Continuation.suspend() that clears the context after a suspend. That should fix it. cheers -- Torsten
Re: Meeting in Amsterdam
On Mar 28, 2008, at 11:04, Reinhard Poetz wrote: Is there anybody who is going to attend the ApacheCon in Amsterdam? I'll be there at the two Hackathon days (Mon full day, Tue till 3pm) and would love to have some discussions about Corona. Will someone actually bring Corona? :-D I will be around! ...speaking of which. I still need a place to stay :) Anyone willing to share a room for Sunday and Monday? ...or at least Monday? cheers -- Torsten
Re: Meeting in Amsterdam
On Mar 28, 2008, at 11:57, Reinhard Poetz wrote: Bertrand Delacretaz wrote: how about having dinner together somewhere on Monday night? great. Count me in! ...keep in mind there is also the BarCamp on Monday night. cheers -- Torsten
Re: Javaflow - major memory issue
On Mar 27, 2008, at 05:31, Joerg Heinicke wrote: On 18.03.2008 03:07, footh wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor $TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? What do you mean by environment ...it's not like the whole jvm is stored but only the flow. External resources should be injected (vs stored) as much as possible. cheers -- Torsten
Re: Javaflow - major memory issue
On Mar 27, 2008, at 13:18, Joerg Heinicke wrote: On 27.03.2008 04:39, Torsten Curdt wrote: Sure, here is the hierarchy from bottom to top. At this point, I ran the test for about five minutes (running longer would increase the percentage) and the retained size of the one ContinuationsManagerImpl object is 58% of the total. The BufferedOutputStream is 50% of the total, so the other 8% is consumed by the objects in between. org.apache.cocoon.util.BufferedOutputStream secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment env of org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor $TreeProcessorRedirector redirector of org.apache.cocoon.components.flow.java.ContinuationContext What I was so much concerned about here was the fact of storing the whole environment in the continuation, especially since we have this non-flushing BufferedOutputStream at the end. Is there any point in storing the environment? Do we get anything useful out of it after continueing the continuation? What do you mean by environment ...it's not like the whole jvm is stored but only the flow. External resources should be injected (vs stored) as much as possible. Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? (Let's stop cross posting and move over to the dev list) cheers -- Torsten
Re: Javaflow - major memory issue
On Mar 27, 2008, at 15:13, Joerg Heinicke wrote: Torsten Curdt tcurdt at apache.org writes: Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? Ah, getting closer :) It's the Continuation that holds the ContinuationContext [1]: Hm... it should set clear the reference in 'finally'. See the execute method http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/StackRecorder.java?revision=560660view=markup Weird...
Re: Javaflow - major memory issue
On Mar 27, 2008, at 15:33, Torsten Curdt wrote: On Mar 27, 2008, at 15:13, Joerg Heinicke wrote: Torsten Curdt tcurdt at apache.org writes: Just have a look at the quote from the original. It gives the object relationships in the memory. BufferedOutputStream takes 50% and is hold in HttpEnvironment which is hold in TreeProcessorRedirector which is hold in ContinuationContext. I wondered why it is there. Ah ...well, the ContinuationContext should be short living. Maybe there is a dangling reference to it? Ah, getting closer :) It's the Continuation that holds the ContinuationContext [1]: Hm... it should set clear the reference in 'finally'. See the execute method http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/src/java/org/apache/commons/javaflow/bytecode/StackRecorder.java?revision=560660view=markup Weird... What cocoon version are we talking about anyway?
Re: Exploring Corona
On Mar 27, 2008, at 19:14, Carsten Ziegeler wrote: Intersting stuff - thanks Reinhard and Steven for starting this and sharing it with us. Finally I had time to have a *brief* look at it and I have some remarks :) I think the pipeline api and sitemap api should be separate things. +1 So the invocation should rather be in the pipeline api as the base of executing pipelines. We could than split this into two modules. I'm not sure if actions belong to the pipeline api; i think they are rather sitemap specific. All they do wrt to the pipeline is to change the invocation perhaps. So this could also be done before starting the pipeline and get the action stuff out of the pipeline api. +1 cheers -- Torsten
Re: Layered software designs
On Mar 26, 2008, at 14:44, Ralph Goers wrote: Reinhard Poetz wrote: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? Just lurking but I am with you guys. Appealing? yes. Actually implementable in Java so that it isn;t even more complicated than what we have? I don't know. IMO this would simplify a lot as it separates concerns and the inner guts can be used in other projects without the pain of dependencies we have right now. People have been asking for this for years. I really think think this is the right direction. cheers -- Torsten
Re: Micro-Cocoon ... Corona
On 13.03.2008, at 18:11, Vadim Gritsenko wrote: On Mar 13, 2008, at 11:40 AM, Reinhard Poetz wrote: . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) . the pipeline API and the sitemap interpreter are useable from within *plain Java code* (- no dependency on the Servlet API) -- if it is used outside of a web container, the user has to make sure that there is no component that uses the servlet API Speaking of which, I had intention to make a clear separation between pipeline assembly stage - which is currently done by tree processor - and pipeline execution stage - which is currently sometimes is done from within tree processor itself, in case of 'external pipelines', or out of tree processor for 'internal pipelines'. I have done a prototype work - and had it working after ~ 1 day effort. When we had the whole 'cocoon is dead - let's rewrite it' discussion that was exactly one of the thing I was thinking of. To some extend the sitemap should be just a factory creating pipelines. The pipelines should be a completely separate stand alone API that is just used by the sitemap. cheers -- Torsten
Re: Rename cocoon:rcl to cocoon:wrap-block
On 20.02.2008, at 15:50, Reinhard Poetz wrote: Vadim Gritsenko wrote: On Feb 16, 2008, at 11:44 AM, Torsten Curdt wrote: What about cocoon:webapp-loader cocoon:reloader (shorter), or cocoon:webapp-reloader (more descriptive) That this goal supports the usage of a reloading classloader is just a feature but (at least in trunk) configureable. Hence I'm not that enthusiastic about loader or reloader. ... or am I too picky? No ...I was thinking the same :) ...which is why I would think 'cocoon:loader' (not reloader) would be OK. On the other hand this looks quite consistent: mvn cocoon:run jetty:run It might be technically not really correct but looks nice and straight forward. Think users might like that. cheers -- Torsten
Re: Rename cocoon:rcl to cocoon:wrap-block
On 16.02.2008, at 17:12, Reinhard Poetz wrote: After having seen quite a few people wonder what 'cocoon:rcl' means, I propose to change it to some better name. The general idea is that this Maven goal creates a web application which wraps the block and makes it runable as a 'normal' web application in a web container. Additionally it enables the usage of the reloading classloader (commons-jci) which made me name it 'cocoon:rcl'. I propose to use 'cocoon:wrap-block' instead. Though it's longer I think it's closer to the actual meaning and hence less confusing. If we want to keep the name short, we could even add a shortcut 'cocoon:wb'. wrap-block ??? Hm ...I cannot really see how that is much better - sorry ;) What about cocoon:webapp-loader cheers -- Torsten
Re: New expression language usage
On 28.01.2008, at 00:53, Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
can you help me with following (simple) pipeline:
map:pipeline
map:match pattern=matching/*
map:generate src=sax-pipeline/[???].xml/
map:serialize type=xml/
/map:match
/map:pipeline
What do I have to put instead of [???] if I want ro refer to the
first
match of
the wildcard matcher?
snip type=complicated expressions/
Have my cocoon skills gone so rusty or did I just not get the
question? What's wrong with the good old ways to referring to first
match?
map:match pattern=matching/*
map:generate src=sax-pipeline/{1}.xml/
map:match pattern=matching/*
map:generate src=sax-pipeline/{\1}.xml/
map:match pattern=matching/* name=root
map:generate src=sax-pipeline/{#root:1}.xml/
cheers
--
Torsten
Re: GSoC final report
On 21.08.2007, at 23:56, Reinhard Poetz wrote: Daniel Fagerstrom wrote: You have done an excellent work Grzegorz. +1 snip/ While I have lot of expeience in teaching, coaching and mentoring IRL, this is the first time I have mentored someone that I never have met IRL, over email. I'm supprised that it has worked so well. An important factor is that you have written so much on the list so that I have been able to see what is going on. I also want to stress that your communication with the rest of the community was excellent and I don't think that you failed in this regard. Without having had the time to activly participate in every discussion, I think I have a good understanding of what you did and I want to thank you for it! +1 cheers -- Torsten
spring webflow
I really, really want to integrate Cocoon with Spring WebFlow as I feel that that is a much more workable solution than trying to build applications using flowscript or javaflow and this only really makes sense with 2.2 since it is Spring based. You brought this already a couple of times. Years and years ago (when I was still working at dff) we developed a xml based flow engine way before what we call flow these days existed. It was so horrible to maintain that we dropped it. Maybe just the lack of tools ...or maybe just the lack of resources writing those tools ...but I am still afraid when ever someone pushes into a similar direction. There was also a talk at FOSDEM about such an approach and I only barely could hold back to comment during his talk ...he was so excited and convinced about the solution. For us just a minimal flow resulted in so much xml ...bah! Make sure you evaluate it's what you really want before you go down that road. Just my 2 cents cheers -- Torsten
Re: spring webflow
On 16.07.2007, at 15:35, Carsten Ziegeler wrote: Torsten Curdt wrote: I really, really want to integrate Cocoon with Spring WebFlow as I feel that that is a much more workable solution than trying to build applications using flowscript or javaflow and this only really makes sense with 2.2 since it is Spring based. You brought this already a couple of times. Years and years ago (when I was still working at dff) we developed a xml based flow engine way before what we call flow these days existed. It was so horrible to maintain that we dropped it. Maybe just the lack of tools ...or maybe just the lack of resources writing those tools ...but I am still afraid when ever someone pushes into a similar direction. There was also a talk at FOSDEM about such an approach and I only barely could hold back to comment during his talk ...he was so excited and convinced about the solution. For us just a minimal flow resulted in so much xml ...bah! Make sure you evaluate it's what you really want before you go down that road. Just my 2 cents To be honest I'm not sure if javascript is better than xml :) ...it's just less verbose :) Though I don't like both of them when it comes to describing a flow, Spring Webflow as imho to big plus points: a visual editor and it's well known outside of Cocoon. This doesn't imply that it's really better or better usable. I guess those were also the two things that we were missing those days :) cheers -- Torsten
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 others (take 2)
All of maven-metadata.xml files have no license header either. Dejavu? We had that on commons already ;) IMO not required to have a license in there. cheers -- Torsten
Re: FYI: Ohloh.net is evolving
On 27.06.2007, at 16:03, Peter Hunsberger wrote: On 6/27/07, Ralph Goers [EMAIL PROTECTED] wrote: Click on Managing your details. Basically, you need to create a file in committers/info as apacheid.rdf where apacheid is your apache userid. You can look at other people's files there or you can use the tool at http://people.apache.org/foaf/foafamatic.html. I do have a FOAF file that has been committed. The more challenging part seems to be how to determine longitude and latitude for a location... Ehm? Google Maps/Earth? ;) cheers -- Torsten
Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 others (take 2)
All of maven-metadata.xml files have no license header either. Do we really have to add our license header to those files? AFAICS nobody does it. Do they really contain (enough) protectable intellectual property? I don't think so. Me neither. I think that's nitpicking. It's more than questionable and it would have to be fixed by the maven guys. cheers -- Torsten
[ANNOUNCEMENT] release of common jci 1.0
Jakarta Commons JCI 1.0 is now available! http://jakarta.apache.org/commons/jci/ JCI is a java compiler interface. It can be used to either compile java (or any other language that can be compiled to java classes like e.g. groovy or javascript) to java. It is well integrated with a FAM (FilesystemAlterationMonitor) that can be used with the JCI compiling/ reloading classloader. All the currently supported compilers (even javac before java6) feature in-memory compilation. It currently supports compilers like eclipse, janino, groovy, rhino and javac. Apache Jakarta Commons JCI is available in either binary or source form from the JCI downloads page or your favorite maven repository mirror. http://jakarta.apache.org/site/downloads/downloads_commons-jci.cgi
Re: Discussion about Maven
3. We cannot put milestones that depend on snapshot versions on central. It means that we can't upload following artifacts: org.apache.cocoon:cocoon-maven-plugin:1.0.0-M1 org.apache.cocoon:cocoon-rcl-spring-reloader:1.0.0-M1 org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1 If there are people who can vote over on jakarta land ...please do so! The vote for commmons jci rc3 is still open ...but so far I only got only one +1 (that makes two +1s with mine) ...at least not -1s so far. I'd assume that would also help with the release of the above artifacts. A frustrated... -- Torsten
Re: [Solved] JavaFlow and SuggestionLists
Hm... sounds a bit hack'ish (and even worse) more work that it should be. What version of cocoon/javaflow are you talking about? cheers -- Torsten On 11.05.2007, at 10:10, Christofer Dutz wrote: Hi, For th last two weeks I was dealing with the problem, that SuggestionLists didn't work with JavaFlow anymore. In addition to this, also my Pipelines for saving form-data stopped workling. I could track both of them down to the problem, that the JavaInterpreter class constructs a ContinuationContext obejct and coppies the data of the WebContinuation Context. When assigning a FormInstance to the Continuation everything works fine as long as the form is shown by sendPageAndWait (ok ok ... form.show() too, but that just uses sendPageAndWait). Since there is no link between WebContinuation and ContinuationContext, when loosing the reference to the temporary ContinuationContext it is gone for ever. I solved my problem by adapting the ContinuationContext and the JavaInterpreter class so they provide a ContinuationContext.getParentWebContinuation() method. If I use this to manually set the FormInstance to this, my form is available for my modified SuggestionListGenerator. I would gladly provide a patch, if this solution is nice-enough to be accepted. Without it I can see no way of beeing able to use any AJAX widget using IFrames (SuggestionList, Upload, ...) Chris
Re: SuggestionLists and JavaFlow
On 09.05.2007, at 15:56, Christofer Dutz wrote: Hi, I am currently having some problems with JavaFlow and SuggestionLists. My application used to generate dynamic suggestion lists in the _cocoon/forms/suggest pipeline. Unfortunately the FormsGenerator, SuggestionListGenerator, JXGenerator and Transformer and my custom Generator seem to be unable to get the form instance. I think this might be a result of the way JavaFlow deals with Continuations (GetContext beeing implemented using Thread.currentThread()) as the SuggestionList pipeline is served by a different Thread. It's been a while and I would have to dig into the code but are you sure the other pipeline is served by a different thread? A known limitation is when you use a continuation in one pipeline and use the cocoon protocol to a pipeline that also provides creates continuations. That aint work as you (atm) only can have one continuation per thread. (Not that complicated to change though) A soltuion I thought about was using some sort of Singleton for storing form instance data ... but would really like to avoid this. Yeah ...that sounds ugly. cheers -- Torsten
Re: 2.2 failing to build: cocoon-javaflow
Ok, I've added it there and it seems to allow the build to succeed. Can others more informed on javaflow check there's no problems? I haven't checked javaflow against the RC1 of jci yet Index: blocks/cocoon-javaflow/cocoon-javaflow-impl/pom.xml === --- blocks/cocoon-javaflow/cocoon-javaflow-impl/pom.xml (revision 529180) +++ blocks/cocoon-javaflow/cocoon-javaflow-impl/pom.xml (working copy) @@ -77,5 +77,10 @@ artifactIdcommons-jci-fam/artifactId version1.0-SNAPSHOT/version You also might want to change the above to RC1 cheers -- Torsten
Re: [GT2007] [VOTE] Conference location + time
On 11.04.2007, at 15:08, Arje Cahn wrote: Hi all, Please cast your votes on both the location and the time for this year's Cocoon GetTogether conference: A) The Netherlands, Amsterdam +0 B) Italy, Rome / Milano +10 C) England, London / Norwich -1 A) Late september B) Beginning of October (between the holidays season and ApacheCon) C) End of October don't care so +0 cheers -- Torsten
Re: svn commit: r522901 - in /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main: java/org/apache/cocoon/caching/impl/CacheImpl.java resources/META-INF/cocoon/spring/cocoon-pipeline-impl-
On 28.03.2007, at 20:14, Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
-public class CacheImpl
-extends AbstractLogEnabled
-implements Cache, ThreadSafe, Serviceable, Disposable,
Parameterizable {
+public class CacheImpl implements Cache {
+private Log logger = LogFactory.getLog(getClass());
Is there a reason why logger can not be static?
http://wiki.apache.org/jakarta-commons/Logging/StaticLog
cheers
--
Torsten
Re: ReloadingClassLoader
On 21.03.2007, at 20:58, Reinhard Poetz wrote: Torsten Curdt wrote: I am currently developing a cocoon application using java-flow. One of the really annoying things is, that I have to reload the entire context when changing the class file containing the flow. You are aware of the reloading classloader plugin for cocoon? :) It is using JCI to do the reloading see http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html ...and can auto-instrument the javaflow classes. @Thorsten: What needs to be done that Javaflow classes get reloaded using the RCL plugin AND are being instrumented? Torsten!! ;) And what configuration is necessary for production so that classes are only instrumented? For javaflow all you need is to use this store. For both - compiling or reloading. Of course it would be good to configure the packages that should be instrumented. I can add that to that store directly if you want. http://jakarta.apache.org/commons/sandbox/javaflow/apidocs/org/ apache/commons/javaflow/stores/JavaflowResourceStore.html Could be there was such a store already in Cocoon though. Need to check. cheers -- Torsten
Re: ReloadingClassLoader
And what configuration is necessary for production so that classes are only instrumented? For javaflow all you need is to use this store. For both - compiling or reloading. Of course it would be good to configure the packages that should be instrumented. I can add that to that store directly if you want. http://jakarta.apache.org/commons/sandbox/javaflow/apidocs/org/ apache/commons/javaflow/stores/JavaflowResourceStore.html sorry, I'm a confused. What do you mean by this and that store. The current implementation is org.apache.commons.jci.listeners.ReloadingListener rl = new CocoonReloadingListener(); rl.addReloadNotificationListener(classloader); fam.addListener(directory, rl); and if I look into CocoonReloadingListener() which extends org.apache.commons.jci.listeners.ReloadingListener I find that it creates stores of type MemoryResourceStore. Am I right that, in order to support instrumentation for Javaflow, I have to override the default behaviour and create stores of type JavaflowResourceStore instead? Correct! ...or we always use a javaflow store and work that out via configuration. This brings me to my other question: The cocoon-rcl-plugin is only useful at development time. What options to instrument Javaflow classes for production use do we have? There is an ant task for it in javaflow atm, the maven-jci-compiler plugin will support that (but that's still a way to go) and we could write a quick and easy maven plugin for that. These are all options I see. ..or just use a FileResourceStore or serialize the MemoryResourceStore ;) cheers -- Torsten
Re: ReloadingClassLoader
On 22.03.2007, at 11:03, Reinhard Poetz wrote: Torsten Curdt wrote: And what configuration is necessary for production so that classes are only instrumented? For javaflow all you need is to use this store. For both - compiling or reloading. Of course it would be good to configure the packages that should be instrumented. I can add that to that store directly if you want. http://jakarta.apache.org/commons/sandbox/javaflow/apidocs/org/ apache/commons/javaflow/stores/JavaflowResourceStore.html sorry, I'm a confused. What do you mean by this and that store. The current implementation is org.apache.commons.jci.listeners.ReloadingListener rl = new CocoonReloadingListener(); rl.addReloadNotificationListener(classloader); fam.addListener(directory, rl); and if I look into CocoonReloadingListener() which extends org.apache.commons.jci.listeners.ReloadingListener I find that it creates stores of type MemoryResourceStore. Am I right that, in order to support instrumentation for Javaflow, I have to override the default behaviour and create stores of type JavaflowResourceStore instead? Correct! ...or we always use a javaflow store and work that out via configuration. I think that I understand the scope of the problem now. For now I will concentrate on the release of cocoon-rcl-plugin without Javaflow support. It can be added at any time later. I won't have much available time over the next weeks (and no use case that would justify to change my priorities) but if somebody else wants to integrate it into cocoon-rcl, I'm available for dicussing it on this list. The only question is where and how to configure what is meant to be instrumented. ...well and how people envision this to happen for non-dev mode. The original implementation just defined the store class to use per directory that is getting monitored. See http://cocoongt.hippo12.castaserver.com/cocoongt/torsten-curdt-rapid- app-development.pdf cheers -- Torsten
Re: [GT2007] It's that time of the year again...
On 21.03.2007, at 05:20, Ralph Goers wrote: Torsten Curdt wrote: Well, good old memories of ApacheCon EU 2000 in London ...but I would love Rome!!! Too bad you're not still in Australia. That would have been fun! Well, David, Marcus and Michael still are :)
Re: ReloadingClassLoader
I am currently developing a cocoon application using java-flow. One of the really annoying things is, that I have to reload the entire context when changing the class file containing the flow. You are aware of the reloading classloader plugin for cocoon? :) It is using JCI to do the reloading ...and can auto-instrument the javaflow classes. While having a look at the available class loaders I couldn’t find any one that could do „reloading“ of classes. http://jakarta.apache.org/commons/sandbox/jci/xref/org/apache/commons/ jci/ReloadingClassLoader.html cheers -- Torsten
Re: [GT2007] It's that time of the year again...
On 20.03.2007, at 20:36, Andrew Savory wrote: Hey, On 20 Mar 2007, at 17:29, Arje Cahn wrote: Gianugo replied: stuff-I-might-regret-soon *cough* Italy? *cough* :-) /stuff-I-might-regret-soon Oh boy.. You *are* going to regret this! :=D Thanks for stepping up, Gianugo! It's good to see that there are more options. Maybe there are others that would like to step forward as this year's Cocoon GetTogether host? Right now, the options are: A) The Netherlands, Amsterdam B) Italy, Rome (or Milano?) C) London, England (or Norwich!) Well, good old memories of ApacheCon EU 2000 in London ...but I would love Rome!!! cheers -- Torsten
Re: Status of javaflow block in 2.2
On 19.03.2007, at 10:07, Bart Molenkamp wrote: Hi, Can someone tell me how to get the Javaflow block working? For example, how to get the javaflow samples working? Javaflow is tied to the reloading classloader in that sense that JCI is being used for the rewriting. Not sure what shape the examples are in atm. Maybe Simone and Maurizio have more details on this? What patches do I need to apply? (the mail below says that these are commented out, but where? I can't find anything commented out in the code) I have build commons-javaflow and commons-jci myself (svn checkouts), so I have builds of the latest versions of those in my local repo. That's a good start :) cheers -- Torsten
Re: [GT2007] It's that time of the year again...
On 16.03.2007, at 16:38, Gianugo Rabellino wrote: On 3/16/07, Reinhard Poetz [EMAIL PROTECTED] wrote: Daniel Fagerstrom wrote: Arje Cahn skrev: Hi all, (quoting Joerg quoting the Cocoon analysis report that Daniel found:) Over the last twelve months, Cocoon (Apache) has seen a substantial increase in activity... Good news! What about a Cocoon GetTogether 2007? +1! stuff-I-might-regret-soon *cough* Italy? *cough* :-) /stuff-I-might-regret-soon Italy!! :-D
Re: javaflow block not building on trunk
Got it working again ...was my working copy
On 10.03.2007, at 02:44, Torsten Curdt wrote:
Just noticed this
[INFO] [compiler:compile]
[INFO] Compiling 8 source files to /Users/tcurdt/Development/cocoon/
trunk/blocks/cocoon-javaflow/cocoon-javaflow-impl/target/classes
[INFO]
--
--
[ERROR] BUILD FAILURE
[INFO]
--
--
[INFO] Compilation failure
/Users/tcurdt/Development/cocoon/trunk/blocks/cocoon-javaflow/
cocoon-javaflow-impl/src/main/java/org/apache/cocoon/components/
flow/java/JavaflowResourceStore.java:[7,37] cannot find symbol
symbol : class PatternMatcherResourceStore
location: package org.apache.cocoon.classloader
/Users/tcurdt/Development/cocoon/trunk/blocks/cocoon-javaflow/
cocoon-javaflow-impl/src/main/java/org/apache/cocoon/components/
flow/java/JavaflowResourceStore.java:[8,37] cannot find symbol
symbol : class WildcardMatcherHelper
location: package org.apache.cocoon.classloader
/Users/tcurdt/Development/cocoon/trunk/blocks/cocoon-javaflow/
cocoon-javaflow-impl/src/main/java/org/apache/cocoon/components/
flow/java/JavaflowResourceStore.java:[24,46] cannot find symbol
symbol: class PatternMatcherResourceStore
public class JavaflowResourceStore implements
PatternMatcherResourceStore, ResourceStore, Transactional {
/Users/tcurdt/Development/cocoon/trunk/blocks/cocoon-javaflow/
cocoon-javaflow-impl/src/main/java/org/apache/cocoon/components/
flow/java/JavaflowResourceStore.java:[60,31] cannot find symbol
symbol : variable WildcardMatcherHelper
location: class
org.apache.cocoon.components.flow.java.JavaflowResourceStore
/Users/tcurdt/Development/cocoon/trunk/blocks/cocoon-javaflow/
cocoon-javaflow-impl/src/main/java/org/apache/cocoon/components/
flow/java/JavaflowResourceStore.java:[69,31] cannot find symbol
symbol : variable WildcardMatcherHelper
location: class
org.apache.cocoon.components.flow.java.JavaflowResourceStore
So...
shodan:~/Development/cocoon/trunk tcurdt$ find . -name
PatternMatcherResourceStore.java
./core/cocoon-bootstrap/src/main/java/org/apache/cocoon/classloader/
PatternMatcherResourceStore.java
./core/cocoon-sitemap/cocoon-sitemap-api/src/main/java/org/apache/
cocoon/classloader/reloading/PatternMatcherResourceStore.java
shodan:~/Development/cocoon/trunk tcurdt$ find . -name
WildcardMatcherHelper.java
./core/cocoon-util/src/main/java/org/apache/cocoon/util/
WildcardMatcherHelper.java
Is the block missing some deps?
cheers
--
Torsten
javaflow block not building on trunk
Just noticed this
[INFO] [compiler:compile]
[INFO] Compiling 8 source files to /Users/tcurdt/Development/cocoon/
trunk/blocks/cocoon-javaflow/cocoon-javaflow-impl/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/Users/tcurdt/Development/cocoon/trunk/blocks/cocoon-javaflow/cocoon-
javaflow-impl/src/main/java/org/apache/cocoon/components/flow/java/
JavaflowResourceStore.java:[7,37] cannot find symbol
symbol : class PatternMatcherResourceStore
location: package org.apache.cocoon.classloader
/Users/tcurdt/Development/cocoon/trunk/blocks/cocoon-javaflow/cocoon-
javaflow-impl/src/main/java/org/apache/cocoon/components/flow/java/
JavaflowResourceStore.java:[8,37] cannot find symbol
symbol : class WildcardMatcherHelper
location: package org.apache.cocoon.classloader
/Users/tcurdt/Development/cocoon/trunk/blocks/cocoon-javaflow/cocoon-
javaflow-impl/src/main/java/org/apache/cocoon/components/flow/java/
JavaflowResourceStore.java:[24,46] cannot find symbol
symbol: class PatternMatcherResourceStore
public class JavaflowResourceStore implements
PatternMatcherResourceStore, ResourceStore, Transactional {
/Users/tcurdt/Development/cocoon/trunk/blocks/cocoon-javaflow/cocoon-
javaflow-impl/src/main/java/org/apache/cocoon/components/flow/java/
JavaflowResourceStore.java:[60,31] cannot find symbol
symbol : variable WildcardMatcherHelper
location: class
org.apache.cocoon.components.flow.java.JavaflowResourceStore
/Users/tcurdt/Development/cocoon/trunk/blocks/cocoon-javaflow/cocoon-
javaflow-impl/src/main/java/org/apache/cocoon/components/flow/java/
JavaflowResourceStore.java:[69,31] cannot find symbol
symbol : variable WildcardMatcherHelper
location: class
org.apache.cocoon.components.flow.java.JavaflowResourceStore
So...
shodan:~/Development/cocoon/trunk tcurdt$ find . -name
PatternMatcherResourceStore.java
./core/cocoon-bootstrap/src/main/java/org/apache/cocoon/classloader/
PatternMatcherResourceStore.java
./core/cocoon-sitemap/cocoon-sitemap-api/src/main/java/org/apache/
cocoon/classloader/reloading/PatternMatcherResourceStore.java
shodan:~/Development/cocoon/trunk tcurdt$ find . -name
WildcardMatcherHelper.java
./core/cocoon-util/src/main/java/org/apache/cocoon/util/
WildcardMatcherHelper.java
Is the block missing some deps?
cheers
--
Torsten
Re: Reloading Classloader Plugin
On 08.03.2007, at 07:48, Reinhard Poetz wrote:
Reinhard Poetz wrote:
Yesterday I did a svn up on commons-jci and get errors of type
ClassDefNotFoundError. After reloading it again, the error
disappears. After testing commons-jci built on Sunday afternoon,
everything works as expected.
Once again ;-)
Yesterday I did a svn up on commons-jci and now I get errors of
type ClassDefNotFoundError when the reloading classloader is used (-
doing a page refresh) right after a change. After a second page
refresh, the error is gone.
Uh! That is weird! ClassDefNotFoundError of what? Can you give me log
output for that (having org.apache.commons.jci on DEBUG)?
I just did a
svn diff -r {2007-03-03}:HEAD https://svn.apache.org/repos/asf/
jakarta/commons/sandbox/jci/trunk
and really the only bigger change is properly closing InputStreams
and handling paths correctly. Windows was complaining.
After reverting to commons-jci which was built on Sunday afternoon,
everything works as expected (except that I still need to run it in
debug mode which causes problems because the hot code replace
mechanism of Eclipse interfers.)
Yeah ...we need to look into that debug problem.
Any clue?
Maybe I'm doing something wrong in http://svn.apache.org/repos/asf/
cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/src/main/
java/org/apache/cocoon/servlet/ReloadingClassloaderManager.java?
That code looks fine to me.
cheers
--
Torsten
Re: Reloading Classloader Plugin
On 05.03.2007, at 07:31, Reinhard Poetz wrote: Torsten Curdt wrote: On 04.03.2007, at 18:40, Reinhard Poetz wrote: Torsten Curdt wrote: On 04.03.2007, at 17:59, Reinhard Poetz wrote: Grzegorz Kossakowski wrote: Reinhard Poetz napisał(a): Just a warning, AFAICS it's not a drop-in replacement because of some API changes. Thanks for fixing this. Unfortunately, nothing changed after replacing jci with the current trunk. Still class reloading does not work while running outside the Eclipse and still there is problem with Scheme change not implemented. I hope that Torsten will find some time to help us as soon as jci got released. Sure will try ...actually adopting to the API changes would be good to do before the release of jci. already done Seriously? That would be awesome! :) It wasn't that difficult because the API became cleaner and much easier to understand :-) Cool :) cheers -- Torsten
Re: Reloading Classloader Plugin
On 04.03.2007, at 17:59, Reinhard Poetz wrote: Grzegorz Kossakowski wrote: Reinhard Poetz napisał(a): Just a warning, AFAICS it's not a drop-in replacement because of some API changes. Thanks for fixing this. Unfortunately, nothing changed after replacing jci with the current trunk. Still class reloading does not work while running outside the Eclipse and still there is problem with Scheme change not implemented. I hope that Torsten will find some time to help us as soon as jci got released. Sure will try ...actually adopting to the API changes would be good to do before the release of jci. cheers -- Torsten
Re: Reloading Classloader Plugin
On 03.03.2007, at 19:53, Grzegorz Kossakowski wrote: Torsten Curdt napisał(a): Definitely! ...please use latest trunk! No problem. Howver, root pom of commons-jci is broken, you have jci as artifactId but it should be commons-jci. Well, broken ;) ...as the groupId is now using the maven2 scheme the commons is already included in there. But I will bring that up on commons dev to see how we will handle this. I had to disable tests because many of them fail. Is it known issue? All tests work for me. What (sub)projects are failing? What operating system are you using? What filesystem? Can you send me the outputs? cheers -- Torsten
Re: Reloading Classloader Plugin
Well, broken ;) ...as the groupId is now using the maven2 scheme the commons is already included in there. But I will bring that up on commons dev to see how we will handle this. I agree but now eveywhere else commons- prefix is used in artifact ids so you have to change it everywhere or nowhere. The reason for that is that we inherited the group id for the projects in proper. This should not be *required* for new project getting released. But I would really prefer to use the maven2 group scheme. Again - that's a topic for commmons-dev and not cocoon-dev. ..plus changing this that is probably the least work that is still to be done ;) Now build is just broken because jci-core cannot find parent pom... Works just fine for me. Did you check out the whole sandbox? (Or checkout the parent pom and mvn install it) All tests work for me. What (sub)projects are failing? What operating system are you using? What filesystem? Can you send me the outputs? I attach full Maven output so you can gather from it answers to most of your questions: Well, some of them ...could you please send me (off list) the test outputs from the target dir? G:\asf\commons-jcimvn clean install Windows - I somehow expected to see some problem there ;) --- T E S T S --- Running org.apache.commons.jci.CompilingClassLoaderTestCase Exception in thread Thread-1 java.lang.RuntimeException: cannot handle resource jci\Extended.java OK ...that needs to be jci/Extended.java. Easy to fix. Everything tested on WinXP SP2 with Java 1.6.0 installed and ran with Maven 2.0.4. OK Is FilesystemAlterationMonitorTestCase supposed to take so long (about 1 minute)? Yes, that's expected. Unfortunately the resolution for last-modified information differs from filesystem to filesystem. So we have to use some sleeps to make it work across platforms. This is just a testing issue though. cheers -- Torsten
Re: Reloading Classloader Plugin
On 04.03.2007, at 18:40, Reinhard Poetz wrote: Torsten Curdt wrote: On 04.03.2007, at 17:59, Reinhard Poetz wrote: Grzegorz Kossakowski wrote: Reinhard Poetz napisał(a): Just a warning, AFAICS it's not a drop-in replacement because of some API changes. Thanks for fixing this. Unfortunately, nothing changed after replacing jci with the current trunk. Still class reloading does not work while running outside the Eclipse and still there is problem with Scheme change not implemented. I hope that Torsten will find some time to help us as soon as jci got released. Sure will try ...actually adopting to the API changes would be good to do before the release of jci. already done Seriously? That would be awesome! :) cheers -- Torsten
Re: Reloading Classloader Plugin
BTW, where did you get the commons-jci dependency from? Did you build it from SVN? Huh? Am I supposed to do this? I just fired mvn install and got this: Downloading: http://people.apache.org/repo/m2-snapshot-repository/ org/apache/commons/commons-jci-core/1.0-SNAPSHOT/commons-jci- core-1.0-20061102.202514-6.pom Downloading: http://people.apache.org/repo/m2-snapshot-repository/ org/apache/commons/commons-jci/1.0-SNAPSHOT/commons- jci-1.0-20061102.202514-6.pom Downloading: http://people.apache.org/repo/m2-snapshot-repository/ org/apache/commons/commons-jci-fam/1.0-SNAPSHOT/commons-jci- fam-1.0-20061102.202514-4.pom Downloading: http://people.apache.org/repo/m2-snapshot-repository/ org/apache/commons/commons-jci-core/1.0-SNAPSHOT/commons-jci- core-1.0-20061102.202514-6.jar Downloading: http://people.apache.org/repo/m2-snapshot-repository/ org/apache/commons/commons-jci-fam/1.0-SNAPSHOT/commons-jci- fam-1.0-20061102.202514-4.jar Should I use newer version? Definitely! ...please use latest trunk! cheers -- Torsten
Re: Reloading Classloader Plugin
On 02.03.2007, at 21:31, Reinhard Poetz wrote: Joerg Heinicke wrote: We only have to ensure that the samples blocks (e.g. cocoon-forms- samples) works with the reloading classloader plugin so that cforms developers can easily continue their work. ?? Using the reloading-classloader-plugin you can run a block as the plugin creates a default Cocoon webapp and deploys the block into it. And, as the blocks name conveys, it takes care that you can work on Cocoon resources and Java sources while they get reloaded transparently. (http://cocoon.zones.apache.org/daisy/cdocs-rcl- plugin/g1/1295.html) I would also be interested in some feedback as I want to release it as soon as Torsten has finished a Commons JCI release. Some news from this side: all the last API changes are in. So it would be well worth also getting the Cocoon part adjusted. so I can slip in last changes if required. The 1.0 release should feature support for eclipse, janino and groovy. Just recently I've added support for javac and javascript compilation. Both are still very new and probably need some more testing though. More compilers plugins in the works - but no promises yet :) cheers -- Torsten
Re: [graphics] Artwork for cocoon.apache.org - final4
The only issue left now (AFAICK) is Peter Hunsberger's mentioning of the pastel colors of the blocks in the masthead. I prefer the pastel colors cheers -- Torsten
Re: [graphics] Artwork for cocoon.apache.org - final4
The only issue left now (AFAICK) is Peter Hunsberger's mentioning of the pastel colors of the blocks in the masthead. I prefer the pastel colors cheers -- Torsten
Re: [graphics] Artwork for cocoon.apache.org - final4
The only issue left now (AFAICK) is Peter Hunsberger's mentioning of the pastel colors of the blocks in the masthead. I prefer the pastel colors Hey, no fair voting twice using different e-mails ;-p Sorry, thought the other one would bounce. Seriously, how do you know you wouldn't like bolder colors better? We never never seen any alternatives... ...well, use your imagination :) But seriously - I am old to know my preferences ;) ...plus I find pastel less distracting from the real content. Although the design is really nice do not forget that the focus of the site should be the content. My 2 cents -- Torsten
Re: Status of javaflow block in 2.2
On 31.01.2007, at 03:20, Simone Gianni wrote: Hi Bart, I haven't been much active recently, but me and Maurizio worked a lot to have Javaflow working in 2.2 last summer. The 2.2 javaflow block is based on the new common javaflow made by Torsten Curdt (http://jakarta.apache.org/commons/sandbox/javaflow/ ). This uses JCI to load classes and instrument them at runtime, while there is an ant task to instrument them at build time. The problem, back in september, was that Torsten didn't have time to release a new version of JCI, so the patch applied to have javaflow working was commented out waiting for a new release with JCI patches. I still have a rather old version of 2.2 with all patches applied, a patched version of JCI, and javaflow, with real time reloading and re-instrumenting of classes, mostly working on it. Torsten, any news? :D Was on vacation but working on the jci release right now. A few changes are coming up. Some to the API (mostly renaming and nitpicking), some code restructuring and testcase organization etc. But I want to call a RC in 1-2 weeks from now. cheers -- Torsten
Re: getComponent with JavaFlow 2.1.9
Is the version of Java Flow in 2.1.10 an updated version? No, I don't think anyone bothered backporting. Is the updated version only in 2.2.0? If so can it be back ported to 2.1.10? Yes, 2.2 has the current version. cheers -- Torsten
Re: getComponent with JavaFlow 2.1.9
Can someone give some input as to what would be involved in back porting the Java Flow code to the 2.1.10 code base? For my project at least 2.2 is worlds away. Well, in 2.2 we use a different approach in regards to the integration. (via jci) For various reasons the rewriting is not done by the classloader anymore. (but via jci) So the javaflow classes themself can probably stay untouched ...but in 2.2 this is all integrated with the auto-reloading. So basically you would have to backport that as well to get the same behavior and features. What should be possible is to just use the commons javaflow library with the old integration though. Should be reasonable simple. I would have to dig into the code to work out some action items though. Has been ages since I last looked at 2.1. cheers -- Torsten
Re: getComponent with JavaFlow 2.1.9
Please note that javaflow in 2.1.9 is a quite old version
...unless I missed that someone updated it.
cheers
--
Torsten
On 12/13/06, Bart Molenkamp [EMAIL PROTECTED] wrote:
I've had problems with JavaFlow and classes compiled with debug information (in
Eclipse). You could try to compile without debug information, and see if it
works.
Bart.
-Oorspronkelijk bericht-
Van: Nicolas BOUSSUGE [mailto:[EMAIL PROTECTED]
Verzonden: woensdag 13 december 2006 10:00
Aan: dev@cocoon.apache.org
Onderwerp: getComponent with JavaFlow 2.1.9
Hello,
The users list was maybe not the appropriate list to post my message.
This seems to be a known bug of JavaFlow, according to the TODO.txt I
saw in the javaflow source.
Have the mentionned patches been applied to the jakarta-bcel project in
the 2.1.10 upcoming release ?
Is there a trick to get it to work with the current version ?
Thanks a lot
Best Regards,
Nicolas
Nicolas BOUSSUGE a écrit :
Hello,
I got the following problem in JavaFlow (Cocoon 2.1.9) when trying to
lookup a custom component :
Instruction GETSTATIC constraint violated: Class
'com.test.service.ManagementService' is referenced, but cannot be
loaded and resolved: 'VERIFIED_REJECTED Number of LocalVariableTable
attributes of Code attribute 'CODE' (method 'static void
clinit()') exceeds number of local variable slots '0' ('There may be
no more than one LocalVariableTable attribute per local variable in
the Code attribute.'). '. InstructionHandle: 1: getstatic[178](3) 15
Execution Frame: Local Variables: 0: com.test.flow.java.AdminFlow 1:
unknown object 2: unknown object 3: unknown object 4: unknown
object OperandStack: Slots used: 1 MaxStack: 4.
com.test.flow.java.AdminFlow (Size: 1) Execution flow: 0: aload_0
[InstructionContext] 1: getstatic 15 [InstructionContext]
Then I replaced the lookup as suggested by Torsten in a message on the
mailing list (use a literal String instead of the ROLE), which results
in the following exception :
Instruction CHECKCAST constraint violated: Class
'com.test.service.ManagementService' is referenced, but cannot be
loaded and resolved: 'VERIFIED_REJECTED Number of LocalVariableTable
attributes of Code attribute 'CODE' (method 'static void
clinit()') exceeds number of local variable slots '0' ('There may be
no more than one LocalVariableTable attribute per local variable in
the Code attribute.'). '. InstructionHandle: 6: checkcast[192](3) 21
Execution Frame: Local Variables: 0: com.test.flow.java.AdminFlow 1:
unknown object 2: unknown object 3: unknown object 4: unknown
object OperandStack: Slots used: 1 MaxStack: 4. java.lang.Object
(Size: 1) Execution flow: 0: aload_0 [InstructionContext] 1: ldc 15
[InstructionContext] 3: invokevirtual 17 [InstructionContext] 6:
checkcast 21 [InstructionContext]
Is that a known bug of JavaFlow ? Or did I do something wrong ?
My webapp is running under Tomcat 5.5.20.
Thanks a lot.
Regards,
Nicolas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] Debugging and inplace editing
Things have changed since my presentation in 2005. [1] ...but Reinhard worked on this lately. cheers -- Torsten [1] http://www.cocoongt.org/archive/2005/Slides-and-recordings.html On 12/13/06, Bart Molenkamp [EMAIL PROTECTED] wrote: Hi, I found three tutorials on the internet about how to debug Maven web applications in Eclipse. All three seem to work to debug Cocoon 2.2 in Eclipse as well (first very basic tests). Here are the links, maybe it's worth linking to them from the Cocoon 2.2 documentation. http://docs.codehaus.org/display/JETTY/Debugging+with+the+Maven+Jetty+Pl ugin+inside+Eclipse http://docs.codehaus.org/display/MAVENUSER/Dealing+with+Eclipse-based+ID E http://mahertb.blogspot.com/2006/08/debugging-maven-web-application-with .html I'm also wondering if there is a way for the jetty plugin to work on the webapp source directory directly (src/main/resources/COB-INF) instead of copying stuff to target/my-block-1.0.0-SNAPSHOT/. For me, it's not really an option to stop/rebuild/start for every sitemap change, flowscript change, etc. Changing sources under target/my-block-1.0.0-SNAPSHOT and copying them back to the source directory isn't really an option for me either. Does someone have a good idea about how to do this? Thanks, Bart.
Re: Javaflow/JCI dependencies
introduced two SNAPSHOT dependencies that are in NO repository yet!!! (to compile you need to compile jci and javaflow trunk ...will try to fix that soon ...or whoever has more time to fix that), How can we fix that? I guess we need a release of jci and javaflow, right? Well, that would be the best case. But for javaflow I am waiting for a proper working surefire plugin as the testcase are only working from within eclipse. (surefire does not like the classloader stuff in the tests) ...while we still have a few improvements to get fixed in javaflow I think the interfaces are stable and we could do a release and fix the outstanding things in the next release. For jci that's a different story. I have been wasting most of my time with the build setup - which is no fun ...and I am still not happy. There are changes (even on the interfaces) required in order to fix an eclipse compiler bug and support dependency aware removal of classes. ...so there is a bit more that needs to be fixed. But there are already a few projects waiting for a release (sorry!) Are you (we) allowed to do releases of _sandboxed_ Jakarta commons projects at all? No ...that requires a vote from the jakarta PMC the only thing we could do is get a snaphot out into a repository ...or get some people help over in jakarta land (hint!) ;-) cheers -- Torsten
building
Just doing a mvn clean I get ... [INFO] [clean:clean] [INFO] Deleting directory /Users/tcurdt/Development/cocoon/trunk/tools/cocoon-block-deployer/cocoon-deployer-plugin/target [INFO] Deleting directory /Users/tcurdt/Development/cocoon/trunk/tools/cocoon-block-deployer/cocoon-deployer-plugin/target/classes [INFO] Deleting directory /Users/tcurdt/Development/cocoon/trunk/tools/cocoon-block-deployer/cocoon-deployer-plugin/target/test-classes [INFO] [INFO] Building Cocoon-samples-style-default [INFO]task-segment: [clean] [INFO] Downloading: http://www.apache.org/~reinhard/m2-snapshot-repository/org/apache/cocoon/cocoon-deployer-plugin/1.0.0-M2-SNAPSHOT/cocoon-deployer-plugin-1.0.0-M2-SNAPSHOT.jar [WARNING] Unable to get resource from repository reinhard-m2-snapshot-repository (http://www.apache.org/~reinhard/m2-snapshot-repository) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.cocoon -DartifactId=cocoon-deployer-plugin \ -Dversion=1.0.0-M2-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.cocoon:cocoon-deployer-plugin:maven-plugin:1.0.0-M2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), reinhard-m2-snapshot-repository (http://www.apache.org/~reinhard/m2-snapshot-repository) org.apache.cocoon:cocoon-deployer-plugin:maven-plugin:1.0.0-M2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), reinhard-m2-snapshot-repository (http://www.apache.org/~reinhard/m2-snapshot-repository) Does it work for others? cheers -- Torsten
building
While I found it strange that a mvn clean complains about a missing plugin that should be built through maven itself, a mvn install seems to get me further ...but obviously now our xreporter and daisy deps are gone. Downloading: http://repo1.maven.org/maven2/xreporter/xreporter-expression/r683/xreporter-expression-r683.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Downloading: http://people.apache.org/repo/m2-snapshot-repository/xreporter/xreporter-expression/r683/xreporter-expression-r683.jar [WARNING] Unable to get resource from repository apache.snapshot (http://people.apache.org/repo/m2-snapshot-repository) Downloading: http://people.apache.org/repo/m1-snapshot-repository/xreporter/jars/xreporter-expression-r683.jar [WARNING] Unable to get resource from repository apache-cvs (http://people.apache.org/repo/m1-snapshot-repository) Downloading: http://repo1.maven.org/maven2/com/ibm/icu/icu4j/3.4.4/icu4j-3.4.4.jar 3157K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/outerj/daisy/daisy-util/1.4.1/daisy-util-1.4.1.jar [WARNING] Unable to get resource from repository apache.snapshot (http://people.apache.org/repo/m2-snapshot-repository) Downloading: http://people.apache.org/repo/m1-snapshot-repository/org.outerj.daisy/jars/daisy-util-1.4.1.jar [WARNING] Unable to get resource from repository apache-cvs (http://people.apache.org/repo/m1-snapshot-repository) cheers -- Torsten
Re: Reloading Classloader patch
On 10/30/06, Reinhard Poetz [EMAIL PROTECTED] wrote: Torsten Curdt wrote: On 10/15/06, Reinhard Poetz [EMAIL PROTECTED] wrote: Because of a lot of work on our open Jira issues (thanks guys!) you might have overlooked it: Maurizio provided a patch that enables Torsten's reloading classloader in trunk (again)[1]. I think we should apply it so that it gets part of cocoon-core-2.2M2. I would do it myself but unfortunatly I won't have much time within the next two weeks. It would be great if someone was faster than me ... ;-) I've already applied it on my machine and can do the commit ...but I think Maurizio also did another update to it to re-enable the component reloading as well. Maurizio? ...also think it would be really worth having that in ASAP could you apply the patch before we release cocoon-core-2.2M2 - would be great to have it within the release. Trying to get hold of the most recent patch. Could not find it in JIRA. Maurizio, can you send me the link please? cheers -- Torsten
Re: isolate the pipeline component from rest of cocoon
I am willing to dig around in SVN, however it would help a lot with a few pointers. I could not find anything beyond 2.1.x on the wiki/official site. Do you have any pointers to things I should look at in SVN, or even if what I am asking for is remotely possible? There have been discussions around this very topic now and then.But there is not much to point to. You know were the classes are ..just something that needs to be done. MO this would be more than useful!. cheers - Torsten
Re: isolate the pipeline component from rest of cocoon
It is possible to use pipelines directly, it would look something like: ...setup container... Sorry, but please without that ;-) cheers -- Torsten
Re: Reloading Classloader patch
On 10/15/06, Reinhard Poetz [EMAIL PROTECTED] wrote: Because of a lot of work on our open Jira issues (thanks guys!) you might have overlooked it: Maurizio provided a patch that enables Torsten's reloading classloader in trunk (again)[1]. I think we should apply it so that it gets part of cocoon-core-2.2M2. I would do it myself but unfortunatly I won't have much time within the next two weeks. It would be great if someone was faster than me ... ;-) I've already applied it on my machine and can do the commit ...but I think Maurizio also did another update to it to re-enable the component reloading as well. Maurizio? ...also think it would be really worth having that in ASAP cheers -- Torsten
trying with latest cocoon trunk
Let's say it has been a while that I've last looked into trunk. So instead of spending hours finding my way through how things are suppossed to work I came across a few questions. o I have some resources in myBlock/src/main/resources/COB-INF ...why don't they appear in target/myBlock? o Do we really need to print INFO org.apache.cocoon.core.container.spring.CocoonBeanFactory - Pre-instantiating singletons in factory [org.apache.cocoon.core.container.spring.CocoonBeanFactory defining beans [... cluttering the log on the jetty based startup? o WTF is going on with the spring downloads? Seems like there is no pom available, but it works anyway... Downloading: http://mirrors.dotsrc.org/maven2/org/springframework/spring-core/2.0-rc2/spring-core-2.0-rc2.pom [WARNING] Unable to get resource from repository central (http://ibiblio.org/maven2) Downloading: http://svn.apache.org/maven-snapshot-repository/org/springframework/spring-core/2.0-rc2/spring-core-2.0-rc2.pom ... cheers -- Torsten
Re: Re: Logging in 2.2
snip/ But in this case Cocoon would end up with two log files - one is regular core.log (created, say, by good old LogKit) and another one from the log4j from 'new code'... agree - ugly! I'd prefer commons-logging over log4j for reasons: * it supports all of them - LogKit, Java logging, log4j; * it seems to be already used in many (most?) libraries throughout Apache; That is assuming that any class loading issues can be resolved. The latest release should have fixed most issues. Drop a mail to Simon on commons-dev he would be the one that knows the details. FYI the JCL plan is to make fancy discovery mechansim completely optional. Instead working around it might be worth spending the time fixing this in JCL directly and make the whole world happy ;-) cheers -- Torsten
Re: Re: [Vote] Java 5 as minimum JDK requirement
If one does not view a veto as valid then one has to challenge it. To do otherwise would not be taking your position as a committer seriously. His veto was challenged. A reason was stated. Now if the reason for the veto was the moon is not in alignment with the stars it would be reasonable to state that the reason isn't valid. But the reason given was nothing of the kind. That doesn't mean you can't try to convince him to change his mind using the two paragraphs that followed. But the implication of the statement is that you don't recognize his -1 as being valid, when in fact it is. You simply don't agree with it. I think you are simplifying this situation a bit... Let's say I am working for company A. Company A has a policy to only use really stable and proven software. Don't change if you don't have to. Basically they are still using JDK 1.3. I am a PMC member of an OS project the company is using. Now is the non-upgrade policy of that company A a valid reason for the individual PMC member to veto the upgrade of the JDK requirement for the OS project? ...now I am curious cheers -- Torsten
Re: Re: [Vote] Java 5 as minimum JDK requirement
...now I am curious Well, one implication of where you are going with this is, Is it appropriate to vote according to your employer's needs. My answer to that is, yes. In fact, I'm certain that it happens all the time. Oh boy! ...I probably should better stop participating in this thread then. IMO PMC members should vote in the best interest of the project - not in the best interest of their employers. If you are a consultant who works for various people at various times you will continually be adding features each of your employer's needs. I see nothing wrong in using your real world experience to influence your votes. What is not OK is for you to be directed by your employer on how to vote on issues. There is a difference in adding and blocking stuff. snip/ OTOH, what if the statement is It is OK to upgrade when BEA and IBM both have versions that support version nnn of XYZ and those versions have been available for at least a year? I would argue that this moves from the category of voting on code modification to voting on procedure, in which case majority rules and the veto can be ignored if the majority does not agree. ...interesting! So do I dare to ask: what is the veto statement in our case then? cheers -- Torsten
