headers
Sylvain Wallez | 1 May 11:51
Picon
Favicon

Re: Cocoon and Sling

dynnamitt wrote:
> Out of curiosity : 
>
> Why didn't you use XMLCalabash ? 
> ( A pure Xproc impl in java )
>   

Before any technical analysis of the product, the fact that it is GPL 
simply forbids its use in an Apache project.

It also has an "interesting" (not!) feature [1] that collects anonymous 
usage data and send it who knows where for who knows what! Beyond 
privacy and security concerns, it also leads to some operational 
concerns. What happens if the "home" site is down, or if you have a busy 
website that floods it? Will it crash your own server?

Sylvain

[1] http://xmlcalabash.com/docs/phonehome.html

--

-- 
Sylvain Wallez - http://bluxte.net
Permalink | Reply | 5 comments |
headers
dynnamitt | 1 May 12:58
Picon
Gravatar

Re: Cocoon and Sling


Thanks man, I didn't know about that Phone-home feat.

I did not however see GPL as an issue since the JVM(7) itself soon becomes a
member.
Does this mean that all apache apps will be stuck in JVM6 land ??

regards,
dynnamitt.

Sylvain Wallez wrote:
> 
> dynnamitt wrote:
>> Out of curiosity : 
>>
>> Why didn't you use XMLCalabash ? 
>> ( A pure Xproc impl in java )
>>   
> 
> Before any technical analysis of the product, the fact that it is GPL 
> simply forbids its use in an Apache project.
> 
> It also has an "interesting" (not!) feature [1] that collects anonymous 
> usage data and send it who knows where for who knows what! Beyond 
> privacy and security concerns, it also leads to some operational 
> concerns. What happens if the "home" site is down, or if you have a busy 
> website that floods it? Will it crash your own server?
> 
> Sylvain
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sylvain Wallez | 1 May 13:45
Picon
Favicon

Re: Cocoon and Sling

dynnamitt wrote:
> Thanks man, I didn't know about that Phone-home feat.
>
> I did not however see GPL as an issue since the JVM(7) itself soon becomes a member.
> Does this mean that all apache apps will be stuck in JVM6 land ??
>   

The GPL is "imposed freedom", in that it states that any derived works 
of a GPL'ed product should also be GPL licensed itself, and thus that 
its source code should be distributed with the product.

When your product (or Cocoon for that matter) uses classes from 
XMLCalabash, it becomes a derived product and thus must be GPL'ed. This 
is why any GPL library is a big no-no at Apache, since the Apache 
license is much more liberal and allows proprietary usage.

The case of the JVM is different, because a Java application is not a 
derived work of the JVM, and only relies on the Java specification and 
the .class file format. You can then run your program on any virtual 
machine that understands this class file format.

And by the way, Apache has an Apache-licensed virtual machine: 
http://harmony.apache.org/

Sylvain

--

-- 
Sylvain Wallez - http://bluxte.net
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ralph Goers | 1 May 21:01
Favicon

Re: Cocoon and Sling


On May 1, 2009, at 4:45 AM, Sylvain Wallez wrote:

> dynnamitt wrote:
>> Thanks man, I didn't know about that Phone-home feat.
>>
>> I did not however see GPL as an issue since the JVM(7) itself soon  
>> becomes a member.
>> Does this mean that all apache apps will be stuck in JVM6 land ??
>>
>
> The GPL is "imposed freedom", in that it states that any derived  
> works of a GPL'ed product should also be GPL licensed itself, and  
> thus that its source code should be distributed with the product.
>
> When your product (or Cocoon for that matter) uses classes from  
> XMLCalabash, it becomes a derived product and thus must be GPL'ed.  
> This is why any GPL library is a big no-no at Apache, since the  
> Apache license is much more liberal and allows proprietary usage.
>
> The case of the JVM is different, because a Java application is not  
> a derived work of the JVM, and only relies on the Java specification  
> and the .class file format. You can then run your program on any  
> virtual machine that understands this class file format.
>
> And by the way, Apache has an Apache-licensed virtual machine: http://harmony.apache.org/
>
Actually, this isn't quite accurate. Java applications are "derivitive  
works" (by the GPL definition) of the Java Library. However, OpenJDK  
uses GPL with the classpath exception for the library. The classpath
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sylvain Wallez | 2 May 09:44
Picon
Favicon

Re: Cocoon and Sling

Ralph Goers wrote:
>
> On May 1, 2009, at 4:45 AM, Sylvain Wallez wrote:
>
>> dynnamitt wrote:
>>> Thanks man, I didn't know about that Phone-home feat.
>>>
>>> I did not however see GPL as an issue since the JVM(7) itself soon 
>>> becomes a member.
>>> Does this mean that all apache apps will be stuck in JVM6 land ??
>>
>> The GPL is "imposed freedom", in that it states that any derived 
>> works of a GPL'ed product should also be GPL licensed itself, and 
>> thus that its source code should be distributed with the product.
>>
>> When your product (or Cocoon for that matter) uses classes from 
>> XMLCalabash, it becomes a derived product and thus must be GPL'ed. 
>> This is why any GPL library is a big no-no at Apache, since the 
>> Apache license is much more liberal and allows proprietary usage.
>>
>> The case of the JVM is different, because a Java application is not a 
>> derived work of the JVM, and only relies on the Java specification 
>> and the .class file format. You can then run your program on any 
>> virtual machine that understands this class file format.
>>
>> And by the way, Apache has an Apache-licensed virtual machine: 
>> http://harmony.apache.org/
>
> Actually, this isn't quite accurate. Java applications are "derivitive 
> works" (by the GPL definition) of the Java Library. However, OpenJDK
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jasha Joachimsthal (JIRA | 3 May 17:15
Picon
Favicon

[jira] Issue Comment Edited: (COCOON-2257) Missing modCount attribute in JCR sample content


    [
https://issues.apache.org/jira/browse/COCOON-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705424#action_12705424
] 

Jasha Joachimsthal edited comment on COCOON-2257 at 5/3/09 8:14 AM:
--------------------------------------------------------------------

Added modCount to sample content. Sample is still not working 100% but at least Cocoon is able to run.

      was (Author: jashajoachimsthal):
    Added modCount to sample content. Sample is still not working 100%

> Missing modCount attribute in JCR sample content
> ------------------------------------------------
>
>                 Key: COCOON-2257
>                 URL: https://issues.apache.org/jira/browse/COCOON-2257
>             Project: Cocoon
>          Issue Type: Bug
>          Components: Blocks: JCR
>    Affects Versions: 2.1.11
>            Reporter: Jasha Joachimsthal
>            Assignee: Jasha Joachimsthal
>            Priority: Minor
>             Fix For: 2.1.12-dev (Current SVN)
>
>
> The JCR sample content was probably written before the JCR-1.0 spec was released. In the final release a
modCount attribute was expected in org.apache.jackrabbit.core.state.xml.XMLPersistenceManager.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jasha Joachimsthal (JIRA | 3 May 17:15
Picon
Favicon

[jira] Commented: (COCOON-2257) Missing modCount attribute in JCR sample content


    [
https://issues.apache.org/jira/browse/COCOON-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705424#action_12705424
] 

Jasha Joachimsthal commented on COCOON-2257:
--------------------------------------------

Added modCount to sample content. Sample is still not working 100%

> Missing modCount attribute in JCR sample content
> ------------------------------------------------
>
>                 Key: COCOON-2257
>                 URL: https://issues.apache.org/jira/browse/COCOON-2257
>             Project: Cocoon
>          Issue Type: Bug
>          Components: Blocks: JCR
>    Affects Versions: 2.1.11
>            Reporter: Jasha Joachimsthal
>            Assignee: Jasha Joachimsthal
>            Priority: Minor
>             Fix For: 2.1.12-dev (Current SVN)
>
>
> The JCR sample content was probably written before the JCR-1.0 spec was released. In the final release a
modCount attribute was expected in org.apache.jackrabbit.core.state.xml.XMLPersistenceManager. 

--

-- 
This message is automatically generated by JIRA.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juan José Vázquez Delgado | 4 May 09:52
Picon

Re: Cocoon and Sling

>> Out of curiosity :
>> Why didn't you use XMLCalabash ? ( A pure Xproc impl in java )
>>
>
> Before any technical analysis of the product, the fact that it is GPL simply
> forbids its use in an Apache project.
>
> It also has an "interesting" (not!) feature [1] that collects anonymous
> usage data and send it who knows where for who knows what! Beyond privacy
> and security concerns, it also leads to some operational concerns. What
> happens if the "home" site is down, or if you have a busy website that
> floods it? Will it crash your own server?

On the other hand, It would not be easy to integrate XMLCalabash with
Sling as it is designed. XMLCalabash is intended to work alone and I
don´t find out a natural strategy in order to get both working
together.

BR,

Juanjo.

> [1] http://xmlcalabash.com/docs/phonehome.html
Permalink | Reply | 0 comments |
headers
Andreas Pinter (JIRA | 5 May 21:13
Picon
Favicon

[jira] Commented: (COCOON3-34) Attaching an aspect to "org.apache.cocoon.sitemap.node.Sitemap" leads to a ClassCastException


    [
https://issues.apache.org/jira/browse/COCOON3-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706164#action_12706164
] 

Andreas Pinter commented on COCOON3-34:
---------------------------------------

for my specific case it works now. 
No unexpect Exception any more

> Attaching an aspect to "org.apache.cocoon.sitemap.node.Sitemap" leads to a ClassCastException
> ---------------------------------------------------------------------------------------------
>
>                 Key: COCOON3-34
>                 URL: https://issues.apache.org/jira/browse/COCOON3-34
>             Project: Cocoon 3
>          Issue Type: Bug
>          Components: cocoon-sitemap
>            Reporter: Andreas Pinter
>            Assignee: Reinhard Poetz
>            Priority: Minor
>         Attachments: cocoon.log
>
>
> I tried to attach an around-aspect for every node: 
> @Around("execution(* invoke(..)) && within(org.apache.cocoon.sitemap.node.*)")
> This led to a ClassCastException for the first sitemap. (see attached logfile)
> After excluding sitemap from my aspect, everything works just fine:
> @Around("execution(* invoke(..)) && within(org.apache.cocoon.sitemap.node.* && !org.apache.cocoon.sitemap.node.Sitemap)")
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reinhard Pötz | 5 May 21:35
Picon
Favicon

Re: [c3-monitoring] Logging reconfiguration.

Dariusz Łuksza wrote:
> 2009/4/25 Dariusz Łuksza <dariusz.luksza <at> gmail.com
> <mailto:dariusz.luksza <at> gmail.com>>:
>> I'm not quite sure what should I do witch "old"
>> cocoon-configuration-api and cocoon-spring-configurator. Should I :
>>  [1] add dependency to cocoon-monitoring on cocoon-configuration-api
>> or cocoon-spring-configurator,
>>  [2] create another solution based on cocoon-spring-configurator
>>  [3] integrate both project and add it to c3
>> ?
>  
> For now I've decided that I'll user directly LogRepository log4j to
> achieve reconfiguration of logging level for single class or package.
>  
> First milestone in logging reconfiguration via JMX would be adding
> possibility of (permanent or temporal) change log level for single
> package or class.
>  
> To achieve that I implemented two class (Log4JReconfigure and
> RestoreLoggingConfiguration) and added cocoon-monitoring.xml for
> spring-jmx configuration.
>  
> So first class (Log4JReconfigure) is an MBean that would be exposed on
> JXM service. It has 3 public methods :
> * getLoggers - returns all configured loggers with their logging level
> * setLoggingLevel - this method set logging level for permanent (if
> logger already exist it will only change logging level in other case it
> will create logger with that level)
> * setLoggingTempoporalLevel - change logging level or single class or
> package only some time and then log level is set back to old value
(Continue reading)

Permalink | Reply | 7 comments |

Gmane