Ralph Goers wrote:
I don't think so. I really don't want to have two files with system
properties in them. As I said, we have an XML file that contains iniital
logging configuration along with system properties. We use this same
file (well, the contents might be different) in
Carsten Ziegeler wrote:
Ah, I think now I get it (sorry, early in the morning I sometimes need
to wakeup):
You're right. It is very early in the morning - a quarter to 1am to be
exact. About time for bed since I have to be up at 5:30am.
The plugin component we are talking about will in
Carsten Ziegeler wrote:
Ok a first version is there which is a base to continue the discussion -
for some reason I don't know I named it PropertyProvider
which is a simple interface with just one method.
If such a property is set, an instance of the class is created and invoked.
Now I can
Ralph Goers wrote:
Would I even be able to get a source resolver? You haven't read
cocoon.xconf yet.
Yes :) Cocoon itself uses a simple bootstrap source resolver which is
able to do relative resolving and supports the context and resource
protocol. So, we could pass this to your component.
Carsten Ziegeler wrote:
Ralph Goers wrote:
Would I even be able to get a source resolver? You haven't read
cocoon.xconf yet.
Yes :) Cocoon itself uses a simple bootstrap source resolver which is
able to do relative resolving and supports the context and resource
protocol. So, we
Ralph Goers wrote:
First, I'm assuming this is the code you spoke of a while ago to move
values outside of Cocoon.xconf and the sitemap so that things like
database ports, etc can be defined outside the webapp?
Yepp.
Well, basically I would need to be able to do whatever you are doing
Sylvain Wallez wrote:
Wow. That would actually be a lot of backporting IMO, meaning the 2.1
branch wouldn't be very different from the trunk!
This feature alone will make people jump to 2.2 once we release it, even
as a beta. So I agree with Upayavira: let's release a 2.2 without OSGi
Let's move this into a different thread :)
Daniel Fagerstrom wrote:
I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after
the GetTogether.
+1
When the OSGi stuff are changed to R4 and is usefull enough we can start
to include it within 2.2.x releases for early adaptors.
Carsten Ziegeler wrote:
Let's move this into a different thread :)
Daniel Fagerstrom wrote:
I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after
the GetTogether.
+1
When the OSGi stuff are changed to R4 and is usefull enough we can start
to include it within 2.2.x
Carsten Ziegeler wrote:
Ok, the current solution is property based (name - value pairs). If we
would make this pluggable, would this work for you? For example, we
could convert an XML file into properties.
Carsten
I think making it pluggable is what I requested in the first place. But
I
Ralph Goers wrote:
Carsten Ziegeler wrote:
Ok, the current solution is property based (name - value pairs). If we
would make this pluggable, would this work for you? For example, we
could convert an XML file into properties.
Carsten
I think making it pluggable is what I requested in
Carsten Ziegeler wrote:
Carsten Ziegeler wrote:
Let's move this into a different thread :)
Daniel Fagerstrom wrote:
I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after
the GetTogether.
+1
When the OSGi stuff are changed to R4 and is usefull enough we
Carsten Ziegeler wrote:
Let's move this into a different thread :)
Daniel Fagerstrom wrote:
I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after
the GetTogether.
+1
When the OSGi stuff are changed to R4 and is usefull enough we can start
to include it within
Carsten Ziegeler wrote:
Ok, I understand this of course, the question is, how do you want to get
the information? Currently you can get all properties read from Cocoon
in your own component/code. If we make the reading pluggable, we also
need a way to deliver this information to the
Ralph Goers wrote:
Carsten Ziegeler wrote:
Let's move this into a different thread :)
Daniel Fagerstrom wrote:
I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after
the GetTogether.
+1
When the OSGi stuff are changed to R4 and is usefull enough we can start
to
Carsten Ziegeler wrote:
Ralph Goers wrote:
How much do we know about the directory structure required by Maven? I
know that OSGi R3 requires a directory structure, R4 doesn't.
Don't understand the comment (from Upayavira) about directory structure,
R3 and R4, care to explain?
However,
Daniel Fagerstrom wrote:
At least for OSGi R3, each block (bundle) must export a unique set of
packages. It would be nice if we could move all classes and interfaces
so this is the case and deprecate the block classes and interface with
non unique packages before we release 2.2.0 final.
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
Ralph Goers wrote:
How much do we know about the directory structure required by Maven?
I know that OSGi R3 requires a directory structure, R4 doesn't.
Don't understand the comment (from Upayavira) about directory structure,
R3 and R4,
On Monday 05 September 2005 23:52, Upayavira wrote:
In R4 (or rather in Oscar 2.0Alpha) you can specify exports such as
o.a.c.transformation.*Generator. This would be enough for us to avoid
having to rename packages. However, it would likely lead to some complex
wildcard expressions, so I
Daniel Fagerstrom wrote:
So, let us stop the branching madness and work towards having only
*one* common branch (the trunk), that we do the releases from.
+1
Best Regards,
Antonio Gallardo
Ralph Goers wrote:
Currently, all the code that needs access to that file goes through a
single component. That component uses a system property to specify where
the file is. But in this case, you can dream up pretty much anything
that works. I'm presuming that putting them in
Carsten Ziegeler wrote:
Hmm, you can put your own properties file into WEB-INF/properties
directory. All these properties are available using the Settings object.
You can inject the Cocoon core object into one of your Spring
components, access the settings object from there and get your
Niclas Hedhman wrote:
On Sunday 04 September 2005 23:10, Carsten Ziegeler wrote:
Hmm, for a) I more and more think we should move the whole ECM++ stuff
from 2.2
to 2.1.x (readd the support for Composable and Instrumentable) and be
able to use
all the nice little things from 2.2 *today*
Niclas Hedhman wrote:
On Sunday 04 September 2005 23:10, Carsten Ziegeler wrote:
Hmm, for a) I more and more think we should move the whole ECM++ stuff
from 2.2
to 2.1.x (readd the support for Composable and Instrumentable) and be
able to use
all the nice little things from 2.2 *today*
That
Carsten Ziegeler wrote:
Ralph Goers wrote:
I haven't looked at the code for this, but a) I'd love it in 2.1 and b)
is it pluggable? We already have an XML file with some configuration in
it including some system properties that need to be set. It would be
nice if I could leverage the
Upayavira wrote:
I couldn't agree more. Personally I'd be -1 on porting ECM++ back to
2.1.x. 2.1.x should be a _maintenance_ branch, and unless we can focus
on getting 2.2 out in some form, we risk some serious geopardy for our
community, I think.
So, let's release 2.2, make that the
Ralph Goers wrote:
Upayavira wrote:
I couldn't agree more. Personally I'd be -1 on porting ECM++ back to
2.1.x. 2.1.x should be a _maintenance_ branch, and unless we can focus
on getting 2.2 out in some form, we risk some serious geopardy for our
community, I think.
So, let's release
Upayavira wrote:
...
I couldn't agree more. Personally I'd be -1 on porting ECM++ back to
2.1.x. 2.1.x should be a _maintenance_ branch, and unless we can focus
on getting 2.2 out in some form, we risk some serious geopardy for our
community, I think.
+1
So, let's release 2.2, make that
Carsten Ziegeler wrote:
Ralph Goers wrote:
I haven't looked at the code for this, but a) I'd love it in 2.1 and b)
is it pluggable? We already have an XML file with some configuration in
it including some system properties that need to be set. It would be
nice if I could leverage the same
Upayavira wrote:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
I couldn't agree more. Personally I'd be -1 on porting ECM++ back to
2.1.x. 2.1.x should be a _maintenance_ branch, and unless we can
focus on getting 2.2 out in some form, we risk some serious geopardy
for our community, I
Done.
I think we should move all sitemap components, even the core ones into
included files. This allows to have your application specific sitemap
without worrying how to merge this when you update Cocoon.
I'll try to minimize the need for patching the web.xml in the next days
as well.
Carsten
Carsten Ziegeler wrote:
Done.
Cool!
Thinking about it, shouldn't it be COB-INF (or did we decide BLOCK-INF?)
rather than WEB-INF, in the blocks. The sitemap-additions and conf will
be part of real blocks as well AFAICS.
I think we should move all sitemap components, even the core ones
Daniel Fagerstrom wrote:
Thinking about it, shouldn't it be COB-INF (or did we decide BLOCK-INF?)
rather than WEB-INF, in the blocks. The sitemap-additions and conf will
be part of real blocks as well AFAICS.
Hmm, currently we have one WEB-INF directory where all configs are added
to (in
Carsten Ziegeler wrote:
Done.
I think we should move all sitemap components, even the core ones into
included files. This allows to have your application specific sitemap
without worrying how to merge this when you update Cocoon.
I'll try to minimize the need for patching the web.xml in the
Upayavira wrote:
On that note, we shouldn't store application configuration in web.xml.
web.xml is an environment specific configuration file. The only config
that goes there is environment specific configuration.
We should store the config that is currently in there in some
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Thinking about it, shouldn't it be COB-INF (or did we decide BLOCK-INF?)
rather than WEB-INF, in the blocks. The sitemap-additions and conf will
be part of real blocks as well AFAICS.
Hmm, currently we have one WEB-INF directory where
Daniel Fagerstrom wrote:
I have something like this in mind:
/myblock
pom.xml
/META-INF
Manifest.mf
/COB-INF
block.xml
/xconf
...
/sitemap-aditions
...
/java
...
/webapp
sitemap.xmap
...
For the compile time blocks the
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
I have something like this in mind:
/myblock
pom.xml
/META-INF
Manifest.mf
/COB-INF
block.xml
/xconf
...
/sitemap-aditions
...
/java
...
/webapp
sitemap.xmap
...
For the compile time blocks the content
Carsten Ziegeler wrote:
Done.
I think we should move all sitemap components, even the core ones into
included files. This allows to have your application specific sitemap
without worrying how to merge this when you update Cocoon.
Great!
I'll try to minimize the need for patching the
Sylvain Wallez wrote:
I'll try to minimize the need for patching the web.xml in the next days
as well.
How do you plan to do this? We cannot add ourselves an include mechanism
in web.xml :-)
Oh, yes we *can* - we simply take Geronimo and require all users to use
that and then we can
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I'll try to minimize the need for patching the web.xml in the next days
as well.
How do you plan to do this? We cannot add ourselves an include mechanism
in web.xml :-)
Oh, yes we *can* - we simply take Geronimo and require all
Sylvain Wallez wrote:
That was the point. We have a property lookup path, what we need now is
this path to be able to include a dynamic set of property files, e.g.
WEB-INF/block-*.properties.
Exactly - I'll do this either today or tomorrow.
Carsten
--
Carsten Ziegeler - Open Source
Daniel Fagerstrom wrote:
I have something like this in mind:
/myblock
/COB-INF
block.xml
/sitemap-aditions
/webapp
sitemap.xmap
The block A which depends on block B will have access to:
* Exported Java classes of block A
* Components of block A
* Sitemap components of block
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
I have something like this in mind:
/myblock
/COB-INF
block.xml
/sitemap-aditions
/webapp
sitemap.xmap
The block A which depends on block B will have access to:
* Exported Java classes of block A
* Components of block A
*
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
snips everywhere/
The block A which depends on block B will have access to:
* Sitemap components of block A
Given the above, what is the point of 'sitemap-additions'?
Components are included in the cocoon.xconf and sitemap components in
Vadim Gritsenko wrote:
I suggest the revers: put everything from block's xconf into its xmap :-)
If there is no technical reasons that speak against it, I would really welcome
this merge. (... and people that like to have two files, can use the include
mechanism)
--
Reinhard Pötz
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
...
I agree with you that we should skip the sitemap additions and put
everything in the blocks xconf.
I suggest the revers: put everything from block's xconf into its xmap :-)
Then all blocks both such that has a sitemap and such that only
Daniel Fagerstrom wrote:
What I propose is that the block descriptor block.xml contains both a
sitemap path (as it has today) and a component configuration path(s) (a
new addition) both optional.
This makes sense - now I also remember that you've already explained this to me
in Stuttgart
I haven't looked at the code for this, but a) I'd love it in 2.1 and b)
is it pluggable? We already have an XML file with some configuration in
it including some system properties that need to be set. It would be
nice if I could leverage the same file for this.
Ralph
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
What I propose is that the block descriptor block.xml contains both a
sitemap path (as it has today) and a component configuration path(s) (a
new addition) both optional. Then a block with a component configuration
path will create a root component manager where
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Can't this be handled by wildcard inclusion from component
configurations in some catalog, so that we get rid of the snippet
insertions.
SNIP/
We can use wildcard inclusion in the main sitemap as well.
So what do others think? Do we want to
Carsten Ziegeler wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Can't this be handled by wildcard inclusion from component
configurations in some catalog, so that we get rid of the snippet
insertions.
SNIP/
We can use wildcard inclusion in the main sitemap as well.
Le 31 août 05, à 08:51, Carsten Ziegeler a écrit :
...I think we should add an include statement for the main sitemap
that includes additional sitemap components from some directory in the
WEB-INF dir, like WEB-INF/sitemap-components/*.xconf..
agreed, and it would be good to have debug
Carsten Ziegeler wrote:
So what do others think? Do we want to get away of patching the main
sitemap? I think we should add an include statement for the main sitemap
that includes additional sitemap components from some directory in the
WEB-INF dir, like WEB-INF/sitemap-components/*.xconf
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Can't this be handled by wildcard inclusion from component
configurations in some catalog, so that we get rid of the snippet
insertions.
SNIP/
We can use wildcard inclusion in the
55 matches
Mail list logo
