Daniel Fagerstrom wrote:
After you made the Settings object available on its own the Core doesn't
seem to be used much anymore. So it seem like a good idea to remove it.
The only remaining use seem to be as a shielding of the
EnvironmentHelper. What is your plan for that functionality?
I
Reinhard Poetz schrieb:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
As I wrote to you directly, the problem is that
cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
mvn clean install
from the project's base directory should solve the problem.
I had to do this twice
Carsten Ziegeler schrieb:
Reinhard Poetz schrieb:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
As I wrote to you directly, the problem is that
cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
mvn clean install
from the project's base directory should solve the problem.
Carsten Ziegeler wrote:
Carsten Ziegeler schrieb:
Reinhard Poetz schrieb:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
As I wrote to you directly, the problem is that
cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
mvn clean install
from the project's base
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
After you made the Settings object available on its own the Core doesn't
seem to be used much anymore. So it seem like a good idea to remove it.
The only remaining use seem to be as a shielding of the
EnvironmentHelper. What is your plan for
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
After you made the Settings object available on its own the Core doesn't
seem to be used much anymore. So it seem like a good idea to remove it.
The only remaining use seem to be as a shielding of the
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
...
IMO the use of both application contexts and service managers in the
tree processor is not such a good idea. It makes the code really hard to
follow, we should avoid mixed models in the same piece of code.
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten, can you call it again and add a few parameters:
mvn cocoon:simple-deploy -e -X stacktrace.txt
and send me the file? Thank you!
Sure, I'll send it to you directly (because of the size)
As I wrote to you directly, the problem is that
Reinhard Poetz wrote:
As I wrote to you directly, the problem is that
cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
mvn clean install
from the project's base directory should solve the problem.
I had to do this twice (strange), but now it works. Thanks!
Carsten
--
Carsten Ziegeler schrieb:
Daniel Fagerstrom schrieb:
For your questions about creating Core and Settings I use a
o.a.c.servlet.CoreUtil from cocoon-core that has reduced functionality
and flexibility compared to the ordinary one, it just use the servlet
config as input. It is used within
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
As I wrote to you directly, the problem is that
cocoon-deployer-core-1.0-SNAPSHOT.jar isn't up to date. Calling
mvn clean install
from the project's base directory should solve the problem.
I had to do this twice (strange), but now it works.
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
...
IMO the use of both application contexts and service managers in the
tree processor is not such a good idea. It makes the code really hard to
follow, we should avoid mixed models in the
Carsten Ziegeler skrev:
Daniel Fagerstrom schrieb:
For your questions about creating Core and Settings I use a
o.a.c.servlet.CoreUtil from cocoon-core that has reduced functionality
and flexibility compared to the ordinary one, it just use the servlet
config as input. It is used within the
The problem here is that our snapshot repository isn't updated anymore.
Jorg automated snapshots:
http://marc.theaimsgroup.com/?t=11371020925r=1w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113785932205693w=2
But as can be seen in
Carsten Ziegeler skrev:
Carsten Ziegeler schrieb:
Daniel Fagerstrom schrieb:
For your questions about creating Core and Settings I use a
o.a.c.servlet.CoreUtil from cocoon-core that has reduced functionality
and flexibility compared to the ordinary one, it just use the servlet
config as
Daniel Fagerstrom skrev:
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
...
Of course we need to create the container somewhere. But that code
should be isolated, we should really avoid having dependencies on
heavy weight containers all other the place.
I absolutely agree; I think we
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
The users are not the only stakeholders the developers are at least as
important, especially in an open source community. One of the recurring
themes in all the NG discussions is that people are deeply frustrated
with not being able to try
Daniel Fagerstrom wrote:
Made some work in that direction. Now only the SitemapLanguage has a
direct dependency on XmlWebApplicationContext. I'll see if I can find a
way to make that dependency stricter as well.
Great
I introduced a NameForAliasAware interface in the process. Didn't know
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
I'm sorry for that. Of course this was not my intention. Where exactly
are your problems? For me at least everything compiles.
My testcases:
Carsten Ziegeler wrote:
Ok, I start to see your point; may be we should forget about the whole
application context and just use the bean factory. I'll see if this
works out.
I'm currently refactoring the core to just use a bean factory and remove
some
of the dependencies between the tree
Reinhard Poetz wrote:
AFAIU the initialization of Cocoon has changed from within the blocks-fw.
IIUC
CoreUtil is never initialized and therefore the settings object isn't
initialized either.
I get a NullPointException in line 174 of the ApplicationContextFactory:
final File logSCDir =
I cleaned up the implementation: we now just depend on a
ConfigurableBeanFactory - we can make use of the ConfigurableBeanFactory
as it supports kind of a shutdown functionality.
Now, I think the next step should really be to separate the container
creation for a sitemap from creating the
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
...
IMO the use of both application contexts and service managers in the
tree processor is not such a good idea. It makes the code really hard to
follow, we should avoid mixed models in the same piece of code.
Absolutely; remember :) this is
I don't understand why you get these problems. When I run the test cases
in the cocoon-blocks-fw-servlet-impl, I first got problems with setting
up a logger that depended on a Settings object in the BlocksServlet. I
replaced the logger with a ServletLogger, to get further.
The next (and worse
Carsten Ziegeler wrote:
Could somebody of you have a look at this? If you want to reproduce this
exception, go into
.\cocoon\trunk\cocoon-block-deployer\cocoon-deployer-plugin-demo and call
mvn cocoon:simple-deploy jetty6:run
I can't get this running; I get a NoSuchMethodError in the
I'm trying to get the blocks fw working again after the switch to
Spring. It doesn't seem to be particularly easy as the tree processor
now is sprinkled with concrete references to
CocoonXmlWebApplicationContext which in turn extends the
Daniel Fagerstrom wrote:
I'm trying to get the blocks fw working again after the switch to
Spring. It doesn't seem to be particularly easy as the tree processor
now is sprinkled with concrete references to
CocoonXmlWebApplicationContext which in turn extends the
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
...
I'm completely against having the treeprocessor hardwired to that freak
class. The treeprocessor should depend on a (small) interface that
describe what it actually need from its container.
Yeah, sure. The tree processor has a long history
28 matches
Mail list logo
