You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2004/11/23 09:58:20 UTC
Kernel classloading
Pier,
IIUC a block declares in a descriptor file all components that it wants to
provide to other blocks by their interfaces. External blocks can then lookup
those components because they are provided by the classloader.
Is it still true that a block can have a "block-public.jar" and a
"block-private.jar"? The block-private.jar is shielded and only available within
the block and the block-public.jar contains all classes (including the
interfaces of publicly available components + other public available classes)
that will be publicly available?
I'm asking because the whiteboard/block-builder is based on a separation of
public and private classes (--> JARs). This ensures that block A, that depends
on block B, is compiled only by using block B's public JAR. (... and the eclipse
.classpath also contains only block B's public JAR).
--
Reinhard
Re: Kernel integration in 2.2?
Posted by Reinhard Poetz <re...@apache.org>.
Stefano Mazzocchi wrote:
> Only one thing is missing: you need a "linkrewriter" in place because
> one block does not now where the other block's URLs are mounted.
Thanks. Added to the Wiki page.
--
Reinhard
Re: Kernel integration in 2.2?
Posted by Stefano Mazzocchi <st...@apache.org>.
Reinhard Poetz wrote:
> Pier Fumagalli wrote:
>
>> On 29 Nov 2004, at 17:32, Reinhard Poetz wrote:
>>
>>> Pier Fumagalli wrote:
>>>
>>>> On 23 Nov 2004, at 10:58, Reinhard Poetz wrote:
>>>>
>>>>> Pier,
>>>>>
>>>>> IIUC a block declares in a descriptor file all components that it
>>>>> wants to provide to other blocks by their interfaces. External
>>>>> blocks can then lookup those components because they are provided
>>>>> by the classloader.
>>>>>
>>>>> Is it still true that a block can have a "block-public.jar" and a
>>>>> "block-private.jar"? The block-private.jar is shielded and only
>>>>> available within the block and the block-public.jar contains all
>>>>> classes (including the interfaces of publicly available components
>>>>> + other public available classes) that will be publicly available?
>>>>>
>>>>> I'm asking because the whiteboard/block-builder is based on a
>>>>> separation of public and private classes (--> JARs). This ensures
>>>>> that block A, that depends on block B, is compiled only by using
>>>>> block B's public JAR. (... and the eclipse .classpath also contains
>>>>> only block B's public JAR).
>>>>
>>>>
>>>> Sorry, been on holiday for the last couple of weeks...
>>>> No, in the new version of the kernel, all JARs are "public"... I
>>>> simply noticed that "private" classes to a block were becoming
>>>> (after writing 20 or so blocks) a major pain in the a**... And at
>>>> the end of the day, I found them quite counterproductive.
>>>> Developing I found myself in the position of moving classes from
>>>> "private" to "public" when extending blocks, and ending up with
>>>> having nothing private and everything public most of the times...
>>>> So, to keep the story short, no, there's no more difference,
>>>> everything is public.
>>>> There is (though) an implied "local.jar" that doesn't need to be
>>>> declared in the deployment descriptor but is simply a jar file that
>>>> (if it exists) gets loaded... Look at the build script, it'll create
>>>> this jar for each block containing sources and the kernel will use
>>>> it even if not declared...
>>>> Pier
>>>
>>>
>>>
>>> Thank you.
>>> Yesterday, Sylvain and I talked on ICQ about block implementation but
>>> without considering requirements coming from the kernel
>>> implementation. I summarized it and will put it into our wiki as soon
>>> as it is finished.
>>
>>
>>
>> Thanks,
>> as I said, I've been on holiday for 2 weeks (Egypt, no internet
>> access) and I'm having a hard time catching up... Any summary will be
>> good cuz I'm running through thousands of emails in one go and the
>> brain is bubbling away! :-P
>>
>> Pier
>
>
>
> find the summary at http://wiki.apache.org/cocoon/22BlockImplementation
> --> any feedback would be *very* appreciated to get a clear todo list on
> what we have to change/implement at the existing Cocoon core
> implementation in trunk
Only one thing is missing: you need a "linkrewriter" in place because
one block does not now where the other block's URLs are mounted.
--
Stefano.
Kernel integration in 2.2?
Posted by Reinhard Poetz <re...@apache.org>.
Pier Fumagalli wrote:
> On 29 Nov 2004, at 17:32, Reinhard Poetz wrote:
>
>> Pier Fumagalli wrote:
>>
>>> On 23 Nov 2004, at 10:58, Reinhard Poetz wrote:
>>>
>>>> Pier,
>>>>
>>>> IIUC a block declares in a descriptor file all components that it
>>>> wants to provide to other blocks by their interfaces. External
>>>> blocks can then lookup those components because they are provided by
>>>> the classloader.
>>>>
>>>> Is it still true that a block can have a "block-public.jar" and a
>>>> "block-private.jar"? The block-private.jar is shielded and only
>>>> available within the block and the block-public.jar contains all
>>>> classes (including the interfaces of publicly available components +
>>>> other public available classes) that will be publicly available?
>>>>
>>>> I'm asking because the whiteboard/block-builder is based on a
>>>> separation of public and private classes (--> JARs). This ensures
>>>> that block A, that depends on block B, is compiled only by using
>>>> block B's public JAR. (... and the eclipse .classpath also contains
>>>> only block B's public JAR).
>>>
>>> Sorry, been on holiday for the last couple of weeks...
>>> No, in the new version of the kernel, all JARs are "public"... I
>>> simply noticed that "private" classes to a block were becoming (after
>>> writing 20 or so blocks) a major pain in the a**... And at the end of
>>> the day, I found them quite counterproductive.
>>> Developing I found myself in the position of moving classes from
>>> "private" to "public" when extending blocks, and ending up with
>>> having nothing private and everything public most of the times...
>>> So, to keep the story short, no, there's no more difference,
>>> everything is public.
>>> There is (though) an implied "local.jar" that doesn't need to be
>>> declared in the deployment descriptor but is simply a jar file that
>>> (if it exists) gets loaded... Look at the build script, it'll create
>>> this jar for each block containing sources and the kernel will use it
>>> even if not declared...
>>> Pier
>>
>>
>> Thank you.
>> Yesterday, Sylvain and I talked on ICQ about block implementation but
>> without considering requirements coming from the kernel
>> implementation. I summarized it and will put it into our wiki as soon
>> as it is finished.
>
>
> Thanks,
> as I said, I've been on holiday for 2 weeks (Egypt, no internet
> access) and I'm having a hard time catching up... Any summary will be
> good cuz I'm running through thousands of emails in one go and the brain
> is bubbling away! :-P
>
> Pier
find the summary at http://wiki.apache.org/cocoon/22BlockImplementation
--> any feedback would be *very* appreciated to get a clear todo list on what we
have to change/implement at the existing Cocoon core implementation in trunk
--
Reinhard
Re: Kernel classloading
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 29 Nov 2004, at 17:32, Reinhard Poetz wrote:
> Pier Fumagalli wrote:
>> On 23 Nov 2004, at 10:58, Reinhard Poetz wrote:
>>> Pier,
>>>
>>> IIUC a block declares in a descriptor file all components that it
>>> wants to provide to other blocks by their interfaces. External
>>> blocks can then lookup those components because they are provided by
>>> the classloader.
>>>
>>> Is it still true that a block can have a "block-public.jar" and a
>>> "block-private.jar"? The block-private.jar is shielded and only
>>> available within the block and the block-public.jar contains all
>>> classes (including the interfaces of publicly available components +
>>> other public available classes) that will be publicly available?
>>>
>>> I'm asking because the whiteboard/block-builder is based on a
>>> separation of public and private classes (--> JARs). This ensures
>>> that block A, that depends on block B, is compiled only by using
>>> block B's public JAR. (... and the eclipse .classpath also contains
>>> only block B's public JAR).
>> Sorry, been on holiday for the last couple of weeks...
>> No, in the new version of the kernel, all JARs are "public"... I
>> simply noticed that "private" classes to a block were becoming (after
>> writing 20 or so blocks) a major pain in the a**... And at the end of
>> the day, I found them quite counterproductive.
>> Developing I found myself in the position of moving classes from
>> "private" to "public" when extending blocks, and ending up with
>> having nothing private and everything public most of the times...
>> So, to keep the story short, no, there's no more difference,
>> everything is public.
>> There is (though) an implied "local.jar" that doesn't need to be
>> declared in the deployment descriptor but is simply a jar file that
>> (if it exists) gets loaded... Look at the build script, it'll create
>> this jar for each block containing sources and the kernel will use it
>> even if not declared...
>> Pier
>
> Thank you.
> Yesterday, Sylvain and I talked on ICQ about block implementation but
> without considering requirements coming from the kernel
> implementation. I summarized it and will put it into our wiki as soon
> as it is finished.
Thanks,
as I said, I've been on holiday for 2 weeks (Egypt, no internet
access) and I'm having a hard time catching up... Any summary will be
good cuz I'm running through thousands of emails in one go and the
brain is bubbling away! :-P
Pier
Re: Kernel classloading
Posted by Reinhard Poetz <re...@apache.org>.
Pier Fumagalli wrote:
> On 23 Nov 2004, at 10:58, Reinhard Poetz wrote:
>
>> Pier,
>>
>> IIUC a block declares in a descriptor file all components that it
>> wants to provide to other blocks by their interfaces. External blocks
>> can then lookup those components because they are provided by the
>> classloader.
>>
>> Is it still true that a block can have a "block-public.jar" and a
>> "block-private.jar"? The block-private.jar is shielded and only
>> available within the block and the block-public.jar contains all
>> classes (including the interfaces of publicly available components +
>> other public available classes) that will be publicly available?
>>
>> I'm asking because the whiteboard/block-builder is based on a
>> separation of public and private classes (--> JARs). This ensures that
>> block A, that depends on block B, is compiled only by using block B's
>> public JAR. (... and the eclipse .classpath also contains only block
>> B's public JAR).
>
>
> Sorry, been on holiday for the last couple of weeks...
>
> No, in the new version of the kernel, all JARs are "public"... I simply
> noticed that "private" classes to a block were becoming (after writing
> 20 or so blocks) a major pain in the a**... And at the end of the day, I
> found them quite counterproductive.
>
> Developing I found myself in the position of moving classes from
> "private" to "public" when extending blocks, and ending up with having
> nothing private and everything public most of the times...
>
> So, to keep the story short, no, there's no more difference, everything
> is public.
>
> There is (though) an implied "local.jar" that doesn't need to be
> declared in the deployment descriptor but is simply a jar file that (if
> it exists) gets loaded... Look at the build script, it'll create this
> jar for each block containing sources and the kernel will use it even if
> not declared...
>
> Pier
>
Thank you.
Yesterday, Sylvain and I talked on ICQ about block implementation but without
considering requirements coming from the kernel implementation. I summarized it
and will put it into our wiki as soon as it is finished.
--
Reinhard
Re: Kernel classloading
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 23 Nov 2004, at 10:58, Reinhard Poetz wrote:
> Pier,
>
> IIUC a block declares in a descriptor file all components that it
> wants to provide to other blocks by their interfaces. External blocks
> can then lookup those components because they are provided by the
> classloader.
>
> Is it still true that a block can have a "block-public.jar" and a
> "block-private.jar"? The block-private.jar is shielded and only
> available within the block and the block-public.jar contains all
> classes (including the interfaces of publicly available components +
> other public available classes) that will be publicly available?
>
> I'm asking because the whiteboard/block-builder is based on a
> separation of public and private classes (--> JARs). This ensures that
> block A, that depends on block B, is compiled only by using block B's
> public JAR. (... and the eclipse .classpath also contains only block
> B's public JAR).
Sorry, been on holiday for the last couple of weeks...
No, in the new version of the kernel, all JARs are "public"... I simply
noticed that "private" classes to a block were becoming (after writing
20 or so blocks) a major pain in the a**... And at the end of the day,
I found them quite counterproductive.
Developing I found myself in the position of moving classes from
"private" to "public" when extending blocks, and ending up with having
nothing private and everything public most of the times...
So, to keep the story short, no, there's no more difference, everything
is public.
There is (though) an implied "local.jar" that doesn't need to be
declared in the deployment descriptor but is simply a jar file that (if
it exists) gets loaded... Look at the build script, it'll create this
jar for each block containing sources and the kernel will use it even
if not declared...
Pier