Re: More problems with implementing servlet services

Grzegorz Kossakowski wrote:
> Joerg Heinicke pisze:
>> On 19.05.2007 14:28, Grzegorz Kossakowski wrote:
>>
>> One more reason to always put the service URL into the src attribute 
>> as you don't need to discuss and differentiate between GET and POST.

+1

> Yes I have to explain meaning of the "postData" parameter and its use. 
> Really, POST and GET are conceptually different beasts and I believe we 
> should not try to hide this differences anyhow.

I don't buy it. What about PUT? DELETE? TRACE? OPTIONS? HEAD? Is every method 
going to get its own syntax and its own generator type? GetGenerator, 
PostGenerator, DeleteGenerator? It does not make any sense to me. Request is a 
request is a request. Request method is just one single piece of information in 
the request and it is not making conceptual difference. Ideally all request 
method should be treated equally. In the case of this service generator, it just 
means it should take parameter specifying what request method to use... what 
headers to set... what data to include in the body (notice how I avoided the 
word 'post' here - cause it could be 'put', or any other method)... But the src 
attribute of generator is url of the service - everything else is an optional 
parameter: request method defaults to GET, request body by default is empty, etc.

Vadim

Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others

Reinhard Poetz wrote:
> I prepared another series of releases from trunk, see the list of all 43
> artifacts below. 
...
> You can find the staged versions of the modules (sources, binaries, 
> javadocs + checksums + gpg signatures) at http://people.apache.org/builds/cocoon/.

To produce a binding vote, I'd have to download each artifact and peek inside 
it. Given sheer number of files in the download location, it is practically 
impossible (short of mirroring the whole directory or creating .tar.bz2 by 
myself and downloading it). To simplify release checking process for all PMC 
members - can you create a single (or couple of - but not dozens!) download 
file? Thanks.

Without checking files, I'd have to vote -0.

Vadim

[jira] Commented: (COCOON-2071) Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)

    [
https://issues.apache.org/jira/browse/COCOON-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500580
] 

Carsten Ziegeler commented on COCOON-2071:
------------------------------------------

I like the idea, but there is an issue with your patch: the current pooling implementation does actually two
things, a) pooling (obviously) and b) it allows to use pooled components inside thread safe components by
using the proxy. The proxy ensures that each thread gets a different component for the pooled component.
Without this proxy all threads share the same instance which will not work. (Btw, this is no issue for
sitemap components as they are looked up on demand). So we need this proxy.
I think it would be great if I could turn on/off pooling on a per component base (just for fine-tuning), too.
Additing an additional attribute to the configuration and evaluating it should be fairly easy.

WDYT?

> Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)
> ---------------------------------------------------------------------------------------------
>
>                 Key: COCOON-2071
>                 URL: https://issues.apache.org/jira/browse/COCOON-2071
>             Project: Cocoon
>          Issue Type: Test
>          Components: - Components: Sitemap
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Alexander Klimetschek
>            Assignee: Carsten Ziegeler
>            Priority: Minor

Re: [vote] Releasing from trunk: Cocoon 2.2-RC1 & others

Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> I prepared another series of releases from trunk, see the list of all 43
>> artifacts below. 
> ...
>> You can find the staged versions of the modules (sources, binaries, 
>> javadocs + checksums + gpg signatures) at 
>> http://people.apache.org/builds/cocoon/.
> 
> To produce a binding vote, I'd have to download each artifact and peek 
> inside it. Given sheer number of files in the download location, it is 
> practically impossible (short of mirroring the whole directory or 
> creating .tar.bz2 by myself and downloading it). To simplify release 
> checking process for all PMC members - can you create a single (or 
> couple of - but not dozens!) download file? Thanks.

here you are: http://people.apache.org/builds/cocoon/cocoon-2.2RC1_staging.tar.gz

--

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Re: [test] Cocoon 2.2-RC1 & others

Reinhard Poetz wrote:
> Leszek Gawron wrote:
>> Reinhard Poetz wrote:
>>>
>>> The proposed release artifacts are available at
>>> http://people.apache.org/builds/cocoon/.
>>
>> Why is there no release of cocoon spring configurator?
> 
> because there has already been a final release 1.0.0 of it and there 
> haven't been any changes that would justify a 1.0.1.
> 
Hmm, there have been some changes and actually the 1.0.0 release is not 
100% correct as it contains 1.0.1 references :) So, it would be great to 
have a 1.0.1 release as well.

Carsten

[jira] Commented: (COCOON-2071) Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)

    [
https://issues.apache.org/jira/browse/COCOON-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500608
] 

Alexander Klimetschek commented on COCOON-2071:
-----------------------------------------------

Ah, I didn't see that thread-sharing feature. Good to know 

So when having a per-component option one would turn off pooling globally and then turn it on for certain
components that have to be thread-safe?

> Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)
> ---------------------------------------------------------------------------------------------
>
>                 Key: COCOON-2071
>                 URL: https://issues.apache.org/jira/browse/COCOON-2071
>             Project: Cocoon
>          Issue Type: Test
>          Components: - Components: Sitemap
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Alexander Klimetschek
>            Assignee: Carsten Ziegeler
>            Priority: Minor
>         Attachments: disable-pooling-config.patch
>
>
> This is a patch that makes the pooling of components/beans optional: by setting this in the applicationContext.xml
>   <!-- Activate Avalon Bridge -->

[jira] Commented: (COCOON-2071) Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)

    [
https://issues.apache.org/jira/browse/COCOON-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500623
] 

Carsten Ziegeler commented on COCOON-2071:
------------------------------------------

Hmm, not sure if are speaking about the same thing here :)

One thing is the proxy which makes components marked as poolable thread safe. This is a feature which should
be turned on by default and we could think about adding an additional configuration to not proxy these
components (I think I did this for the sitemap components, but I'm not sure if the code is still active).

The other thing is the pooling which if turned on, requires a proxy for automatic lookup/release. Here it
makes sense to have a global setting (on/off) which should default to on (= pooling), and a per component
configuration which either turns on/off the pooling for a specific component. So you can set the global
switch to off and turn on pooling for some components or vice versa.

> Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)
> ---------------------------------------------------------------------------------------------
>
>                 Key: COCOON-2071
>                 URL: https://issues.apache.org/jira/browse/COCOON-2071
>             Project: Cocoon
>          Issue Type: Test
>          Components: - Components: Sitemap
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Alexander Klimetschek
>            Assignee: Carsten Ziegeler

activate FOP

[jira] Commented: (COCOON-2071) Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)

    [
https://issues.apache.org/jira/browse/COCOON-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500656
] 

Alexander Klimetschek commented on COCOON-2071:
-----------------------------------------------

If I understand you right, the thread-safe stuff only applies to components that are pooled. If yes, I see no
problem with that if pooling is generally turned off. Or is the proxy needed for non-pooled components as well?

> Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)
> ---------------------------------------------------------------------------------------------
>
>                 Key: COCOON-2071
>                 URL: https://issues.apache.org/jira/browse/COCOON-2071
>             Project: Cocoon
>          Issue Type: Test
>          Components: - Components: Sitemap
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Alexander Klimetschek
>            Assignee: Carsten Ziegeler
>            Priority: Minor
>         Attachments: disable-pooling-config.patch
>
>
> This is a patch that makes the pooling of components/beans optional: by setting this in the applicationContext.xml
>   <!-- Activate Avalon Bridge -->
>   <avalon:bridge pooling="false"/>
> it is possible to turn off pooling completely. The idea is to start testing performance differences
between pooling and non-pooling. The default value for the "pooling" option is true, so existing
configurations without the attribute set will behave as before when this patch is applied.
> Pooling was introduced back then when creating a new object in Java was slow and re-using of existing
objects was faster. Since Java 1.4 this is no longer the case, creating new objects is said to be even faster
than malloc() in C. Because pooling needs a recycle() method (to reset internal stuff before reuse) and
more calls, including some AOP and Proxy class stuff to add pooling, it is worth to check what is faster nowadays.
> One thing that always annoys me during debugging is that the AOP stuff adds like 4-5 additional calls when
accessing a pooled component in the stacktrace - code that you cannot step into, because it has no java
source. Removing pooling completely would make the Cocoon architecture (especially the runtime
architecture) much simpler.
> My idea is that Cocoon users can test the performance difference on their various systems to get actual
results. WDYT?

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (COCOON-2071) Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)

    [
https://issues.apache.org/jira/browse/COCOON-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500661
] 

Carsten Ziegeler commented on COCOON-2071:
------------------------------------------

Yes, the thread safe stuff is required for components that are marked as pooled but actually are not pooled
as well. Otherwise a thread safe components is using the same instance which will result in problems.
However there are use cases where the "environment" = (the component using the poolable component) is
aware that the component is pooled (or at least not thread safe). This is the case in the pipeline/sitemap
stuff. Therefore in these cases no proxy is needed.

> Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)
> ---------------------------------------------------------------------------------------------
>
>                 Key: COCOON-2071
>                 URL: https://issues.apache.org/jira/browse/COCOON-2071
>             Project: Cocoon
>          Issue Type: Test
>          Components: - Components: Sitemap
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Alexander Klimetschek
>            Assignee: Carsten Ziegeler
>            Priority: Minor
>         Attachments: disable-pooling-config.patch
>
>
> This is a patch that makes the pooling of components/beans optional: by setting this in the applicationContext.xml
>   <!-- Activate Avalon Bridge -->
>   <avalon:bridge pooling="false"/>
> it is possible to turn off pooling completely. The idea is to start testing performance differences
between pooling and non-pooling. The default value for the "pooling" option is true, so existing
configurations without the attribute set will behave as before when this patch is applied.
> Pooling was introduced back then when creating a new object in Java was slow and re-using of existing
objects was faster. Since Java 1.4 this is no longer the case, creating new objects is said to be even faster
than malloc() in C. Because pooling needs a recycle() method (to reset internal stuff before reuse) and
more calls, including some AOP and Proxy class stuff to add pooling, it is worth to check what is faster nowadays.
> One thing that always annoys me during debugging is that the AOP stuff adds like 4-5 additional calls when
accessing a pooled component in the stacktrace - code that you cannot step into, because it has no java
source. Removing pooling completely would make the Cocoon architecture (especially the runtime
architecture) much simpler.
> My idea is that Cocoon users can test the performance difference on their various systems to get actual
results. WDYT?

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.