You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Patrick Heiden <pa...@gmx.de> on 2008/04/09 01:14:45 UTC
RCL goal refactorings / acegi
Hello together!
Why is the acegi example still out-of-order? I've read [1] from Reinhard Poetz (back in Jun 2007) and there he mentioned trouble with ApplicationContext access due to the fact it seems to get closed when integrating acegi. I am able to reproduce the exception with baby-fresh trunk few minutes ago.
Are there solutions / hints for this one?
Best greetings,
Patrick
[1]http://www.mail-archive.com/dev@cocoon.apache.org/msg52282.html
Grzegorz: if you read this 'accidentally': Is it alright for you, when I send you my MainController-Tutorial and ask for comments as soon as I finished that thing? Thanks...
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Reinhard Poetz <re...@apache.org>.
Patrick Heiden wrote:
> Hello!
>
>> Sure. The Maven 2 plugin can be found at
>> http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-maven-plugin/. It
>> contains all the stuff that creates a small web application for a block so
>> that it becomes runnable in a servlet container.
>>
>> The integration of the RCL is done by intercepting all requests (servlets,
>> servlet filters, listeners) and replacing the classloader with a reloading
>> classloader implementation. This code can be found at
>> http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/.
>>
>>
>> The third module is the spring reloader
>> (http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-spring-reloader/)
>> that wraps a Spring context and performs the restarts of the Spring
>> application context whenever necessary.
>
> This could be good starting point, because my error-messages are talking
> about missing refresh-calls to springs appCtx. I will look...
>> Another hint that might help: When a class or an interface, that is loaded
>> by the RCL, is proxied or rewritten by Spring AOP, this leads to exceptions
>> after the first reload. I guess this is a problem with the RCL
>> implementation (Apache Commons JCI) but I haven't had time to write a test
>> case that proves this statement.
>>
>> Apart from problems with Spring Security and Spring AOP, the third known
>> issue is session handling. If you put an object that is loaded by the
>> reloading classloader into the session, you will run into a class cast
>> exception after the first reload occured because the instance of the
>> reloading classloader has changed.
>>
>> If you want to route around these problems, create a module that contains
>> all those classes that should not be loaded by the reloading classloader
>> and add it as a dependency to your module.
>>
>> HTH
>
> Yes, I would guess ;) But besides RCL, how would this
What does "this" refer to? If it refers to the list of know issues, then you
don't have to worry. The RCL stuff is only used when cocoon:rcl is invoked for a
Cocoon block. This Maven goal creates a web application that loads the block and
integrates a reloading classloader.
Using cocoon:deploy doesn't do any of these classloading magic. The only
exception is a shielding classloader that reverses the classloader hierarchy
(the web app context classloader becomes the first one) but it is turned off by
default.
> look within a (e.g.)
> Tomcat deployment, where RCL is not in scope. (I would love to test, but as
> you can see at [1], I've actually got deployment troubles with Tomcat)
You could try to switch to the shielding classloader
(http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/deploy-mojo.html
and http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1262_1_1.html)
which would load Xerces/Xalan of WEB-INF/lib with a higher priority those loaded
by the shared classloader of Tomcat or the application classloader.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Patrick Heiden <pa...@gmx.de>.
Hello!
> Sure. The Maven 2 plugin can be found at
> http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-maven-plugin/.
> It
> contains all the stuff that creates a small web application for a block so
> that
> it becomes runnable in a servlet container.
>
> The integration of the RCL is done by intercepting all requests (servlets,
> servlet filters, listeners) and replacing the classloader with a reloading
> classloader implementation. This code can be found at
> http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/.
>
> The third module is the spring reloader
> (http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-spring-reloader/)
> that wraps a Spring context and performs the restarts of the Spring
> application
> context whenever necessary.
This could be good starting point, because my error-messages are talking about missing refresh-calls to springs appCtx. I will look...
>
> Another hint that might help:
> When a class or an interface, that is loaded by the RCL, is proxied or
> rewritten
> by Spring AOP, this leads to exceptions after the first reload. I guess
> this is
> a problem with the RCL implementation (Apache Commons JCI) but I haven't
> had
> time to write a test case that proves this statement.
>
> Apart from problems with Spring Security and Spring AOP, the third known
> issue
> is session handling. If you put an object that is loaded by the reloading
> classloader into the session, you will run into a class cast exception
> after the
> first reload occured because the instance of the reloading classloader has
> changed.
>
> If you want to route around these problems, create a module that contains
> all
> those classes that should not be loaded by the reloading classloader and
> add it
> as a dependency to your module.
>
> HTH
Yes, I would guess ;) But besides RCL, how would this look within a (e.g.) Tomcat deployment, where RCL is not in scope. (I would love to test, but as you can see at [1], I've actually got deployment troubles with Tomcat)
Best regards,
Patrick
[1] http://www.nabble.com/deploy-Tomcat-to16577585.html
>
> --
> Reinhard Pötz Managing Director, {Indoqa} GmbH
> http://www.indoqa.com/en/people/reinhard.poetz/
>
> Member of the Apache Software Foundation
> Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
> _________________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Reinhard Poetz <re...@apache.org>.
Patrick Heiden wrote:
> Could you give a hint on where to dig inside cocoons code to have a look for
> myself meanwhile? Would be nice.
Sure. The Maven 2 plugin can be found at
http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-maven-plugin/. It
contains all the stuff that creates a small web application for a block so that
it becomes runnable in a servlet container.
The integration of the RCL is done by intercepting all requests (servlets,
servlet filters, listeners) and replacing the classloader with a reloading
classloader implementation. This code can be found at
http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/.
The third module is the spring reloader
(http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-spring-reloader/)
that wraps a Spring context and performs the restarts of the Spring application
context whenever necessary.
Another hint that might help:
When a class or an interface, that is loaded by the RCL, is proxied or rewritten
by Spring AOP, this leads to exceptions after the first reload. I guess this is
a problem with the RCL implementation (Apache Commons JCI) but I haven't had
time to write a test case that proves this statement.
Apart from problems with Spring Security and Spring AOP, the third known issue
is session handling. If you put an object that is loaded by the reloading
classloader into the session, you will run into a class cast exception after the
first reload occured because the instance of the reloading classloader has changed.
If you want to route around these problems, create a module that contains all
those classes that should not be loaded by the reloading classloader and add it
as a dependency to your module.
HTH
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Patrick Heiden <pa...@gmx.de>.
Could you give a hint on where to dig inside cocoons code to have a look for myself meanwhile? Would be nice.
Best Greetings,
Patrick
-------- Original-Nachricht --------
> Datum: Wed, 09 Apr 2008 10:13:35 +0200
> Von: Reinhard Poetz <re...@apache.org>
> An: users@cocoon.apache.org
> Betreff: Re: RCL goal refactorings / acegi
> Patrick Heiden wrote:
> > Hello together!
> >
> > Why is the acegi example still out-of-order? I've read [1] from Reinhard
> > Poetz (back in Jun 2007) and there he mentioned trouble with
> > ApplicationContext access due to the fact it seems to get closed when
> > integrating acegi. I am able to reproduce the exception with baby-fresh
> trunk
> > few minutes ago.
> >
> > Are there solutions / hints for this one?
>
> I had a brief look into this issue and wasn't able to solve it at that
> time.
> Maybe somebody else with more time can have a look.
>
> --
> Reinhard Pötz Managing Director, {Indoqa} GmbH
> http://www.indoqa.com/en/people/reinhard.poetz/
>
> Member of the Apache Software Foundation
> Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
> _________________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Reinhard Poetz <re...@apache.org>.
Patrick Heiden wrote:
> Hello together!
>
> Why is the acegi example still out-of-order? I've read [1] from Reinhard
> Poetz (back in Jun 2007) and there he mentioned trouble with
> ApplicationContext access due to the fact it seems to get closed when
> integrating acegi. I am able to reproduce the exception with baby-fresh trunk
> few minutes ago.
>
> Are there solutions / hints for this one?
I had a brief look into this issue and wasn't able to solve it at that time.
Maybe somebody else with more time can have a look.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Giacomo Pati pisze:
>
>
> Patrick Heiden wrote:
> | Hello together!
> |
> | Why is the acegi example still out-of-order? I've read [1] from
> Reinhard Poetz (back in Jun 2007)
> and there he mentioned trouble with ApplicationContext access due to the
> fact it seems to get
> closed when integrating acegi. I am able to reproduce the exception with
> baby-fresh trunk few
> minutes ago.
> |
> | Are there solutions / hints for this one?
>
> Current Acegi doesn't play well with RCL but upcomming one (2.0) will.
> Unfortunate there aren't any
> snapshots available for Maven users and thus it waits for such to appear.
Not entirely true, see this repo:
http://s3browse.com/explore/maven.springframework.org/milestone/org/springframework/security
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Patrick Heiden wrote:
| Hello together!
|
| Why is the acegi example still out-of-order? I've read [1] from Reinhard Poetz (back in Jun 2007)
and there he mentioned trouble with ApplicationContext access due to the fact it seems to get
closed when integrating acegi. I am able to reproduce the exception with baby-fresh trunk few
minutes ago.
|
| Are there solutions / hints for this one?
Current Acegi doesn't play well with RCL but upcomming one (2.0) will. Unfortunate there aren't any
snapshots available for Maven users and thus it waits for such to appear.
|
| Best greetings,
| Patrick
|
| [1]http://www.mail-archive.com/dev@cocoon.apache.org/msg52282.html
|
| Grzegorz: if you read this 'accidentally': Is it alright for you, when I send you my
MainController-Tutorial and ask for comments as soon as I finished that thing? Thanks...
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkf9oTIACgkQLNdJvZjjVZBEpQCeO5SOHC0pzvxmWoIomig9rmyl
ovYAoLHe3fgC5puJm3/iGIpO1TU94ZQW
=6LEP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Patrick Heiden pisze:
>
> Grzegorz: if you read this 'accidentally': Is it alright for you, when I send you my
> MainController-Tutorial and ask for comments as soon as I finished that thing? Thanks...
Sure, I'm happy to read it and give some comments. However, I'll be able to take a look at it at the
end of week, not earlier. I hope it's fine for you.
--
Grzegorz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Patrick Heiden <pa...@gmx.de>.
Hello!
<snip/>
> I thought Giacomo had the sample once up and running, but he used the
> latest acegi sources from trunk, which aren't available in a maven
> repository.
> Maybe it's worth to give it a try.
>
> Felix
I will try this within the next hours and will give feedback.
Best greetings,
Patrick
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Patrick Heiden <pa...@gmx.de>.
Hi Grzegorz !
> Patrick Heiden pisze:
> <snip what="some good tips how to get Acegi running"/>
> >
> > I would enjoy to see this little update inside cocoon-trunk for new
> users. Maybe one 'little'
> > problem is the aforementioned availability of the spring-security
> artifact (2.0.0 RC1) inside
> > mavens repository. Could this be solved permanently by now?
>
> What about asking spring-security maintainers to prepare a release? It's
> project maintainer's duty
> to prepare a release and publish Maven artifacts. At least in a perfect
> world.
Right away I will do so!
And about my MainController tutorial: I think I will need a bit more time then till the end of this week, so no time-trouble with this one ;)
I'll be back with this 'issue' as soon as I am ready with that!
Best regards,
Patrick
>
>
> --
> Best regards,
> Grzegorz Kossakowski
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
http://games.entertainment.gmx.net/de/entertainment/games/free
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Patrick Heiden <pa...@gmx.de>.
> Unfortunately, this bit is still missing:
> http://cocoon.apache.org/1273_1_1.html
>
> Quick guide is:
> 1. Checkout sources of Cocoon.
> 2. Hack them.
> 3. Use your favorite IDE/Subversion fronted to prepare patches of your
> changes.
> 4. Create an issue in JIRA (https://issues.apache.org/jira/browse/COCOON)
> 5. Attach your patch file to the issue you have created.
>
> Hope that helps.
If created the issue [1]. The patch actually does not include repository for spring-security nor uses the spring-security namespaces! I've done it that way to left decisions about repo and keep things simple. The ample is running, that's it ;)
Best regards,
Patrick
[1]https://issues.apache.org/jira/browse/COCOON-2197
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Patrick Heiden <pa...@gmx.de>.
Alright, I will following your steps as soon as I am ready to do!
Thank you very much!
-------- Original-Nachricht --------
> Datum: Thu, 10 Apr 2008 21:16:16 +0200
> Von: Grzegorz Kossakowski <gr...@tuffmail.com>
> An: users@cocoon.apache.org
> Betreff: Re: RCL goal refactorings / acegi
> Patrick Heiden pisze:
> >
> > Yes, this would be possible. I am actually working on set up that block,
> using new
> > spring-security namespace configuration. Are there any guidelines on how
> (and where ;) to create
> > patches/issues for cocoon?
>
> Unfortunately, this bit is still missing:
> http://cocoon.apache.org/1273_1_1.html
>
> Quick guide is:
> 1. Checkout sources of Cocoon.
> 2. Hack them.
> 3. Use your favorite IDE/Subversion fronted to prepare patches of your
> changes.
> 4. Create an issue in JIRA (https://issues.apache.org/jira/browse/COCOON)
> 5. Attach your patch file to the issue you have created.
>
> Hope that helps.
>
> --
> Grzegorz Kossakowski
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Patrick Heiden pisze:
>
> Yes, this would be possible. I am actually working on set up that block, using new
> spring-security namespace configuration. Are there any guidelines on how (and where ;) to create
> patches/issues for cocoon?
Unfortunately, this bit is still missing:
http://cocoon.apache.org/1273_1_1.html
Quick guide is:
1. Checkout sources of Cocoon.
2. Hack them.
3. Use your favorite IDE/Subversion fronted to prepare patches of your changes.
4. Create an issue in JIRA (https://issues.apache.org/jira/browse/COCOON)
5. Attach your patch file to the issue you have created.
Hope that helps.
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Patrick Heiden <pa...@gmx.de>.
Hello!
> Patrick Heiden pisze:
> > Hi!
> >
> >> <snip what="some good tips how to get Acegi running"/>
> >>> I would enjoy to see this little update inside cocoon-trunk for new
> >> users. Maybe one 'little'
> >>> problem is the aforementioned availability of the spring-security
> >> artifact (2.0.0 RC1) inside
> >>> mavens repository. Could this be solved permanently by now?
> >> What about asking spring-security maintainers to prepare a release?
> It's project maintainer's
> >> duty to prepare a release and publish Maven artifacts. At least in a
> perfect world.
> >
> > They state following few minutes ago: [...] "Only final releases are
> uploaded to the central
> > repository. If you want to use intermediate snapshots, milestone
> releases etc then you can do so
> > by adding the appropriate repository declarations to your maven
> project."
> >
> > This comes due to general maven-artifact rules from springsource [1].
> Maybe it is possible (no
> > idea if advisable or even undesirable) to integrate these repositorys
> inside the
> > cocoon-acegisecurity-sample?
>
> Patrick,
>
> We have a policy to not depend on any snapshots or external Maven
> repositories in our blocks but I
> think this does not apply to samples.
>
> Would you mind providing a patch and filling up an issue?
Yes, this would be possible. I am actually working on set up that block, using new spring-security namespace configuration. Are there any guidelines on how (and where ;) to create patches/issues for cocoon?
Best greetings,
Patrick
>
> --
> Grzegorz Kossakowski
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Patrick Heiden pisze:
> Hi!
>
>> <snip what="some good tips how to get Acegi running"/>
>>> I would enjoy to see this little update inside cocoon-trunk for new
>> users. Maybe one 'little'
>>> problem is the aforementioned availability of the spring-security
>> artifact (2.0.0 RC1) inside
>>> mavens repository. Could this be solved permanently by now?
>> What about asking spring-security maintainers to prepare a release? It's project maintainer's
>> duty to prepare a release and publish Maven artifacts. At least in a perfect world.
>
> They state following few minutes ago: [...] "Only final releases are uploaded to the central
> repository. If you want to use intermediate snapshots, milestone releases etc then you can do so
> by adding the appropriate repository declarations to your maven project."
>
> This comes due to general maven-artifact rules from springsource [1]. Maybe it is possible (no
> idea if advisable or even undesirable) to integrate these repositorys inside the
> cocoon-acegisecurity-sample?
Patrick,
We have a policy to not depend on any snapshots or external Maven repositories in our blocks but I
think this does not apply to samples.
Would you mind providing a patch and filling up an issue?
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Patrick Heiden <pa...@gmx.de>.
Hi!
> <snip what="some good tips how to get Acegi running"/>
> >
> > I would enjoy to see this little update inside cocoon-trunk for new
> users. Maybe one 'little'
> > problem is the aforementioned availability of the spring-security
> artifact (2.0.0 RC1) inside
> > mavens repository. Could this be solved permanently by now?
>
> What about asking spring-security maintainers to prepare a release? It's
> project maintainer's duty
> to prepare a release and publish Maven artifacts. At least in a perfect
> world.
They state following few minutes ago:
[...]
"Only final releases are uploaded to the central repository. If you want to use intermediate snapshots, milestone releases etc then you can do so by adding the appropriate repository declarations to your maven project."
This comes due to general maven-artifact rules from springsource [1].
Maybe it is possible (no idea if advisable or even undesirable) to integrate these repositorys inside the cocoon-acegisecurity-sample?
Best regards,
Patrick
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Patrick Heiden pisze:
<snip what="some good tips how to get Acegi running"/>
>
> I would enjoy to see this little update inside cocoon-trunk for new users. Maybe one 'little'
> problem is the aforementioned availability of the spring-security artifact (2.0.0 RC1) inside
> mavens repository. Could this be solved permanently by now?
What about asking spring-security maintainers to prepare a release? It's project maintainer's duty
to prepare a release and publish Maven artifacts. At least in a perfect world.
--
Best regards,
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Patrick Heiden <pa...@gmx.de>.
Hi!
<snip/>
> I thought Giacomo had the sample once up and running, but he used the
> latest acegi sources from trunk, which aren't available in a maven
> repository.
> Maybe it's worth to give it a try.
>
> Felix
This was a very usefull hint, I got it up running smoothly ;)
Following steps need to be performed:
1) get the latest trunk from spring-security (acegi) (see [1] for details)
2) compile and install that trunk (mvn install, maybe skip the more than 1000 tests ;)
3) change the pom.xml of cocoon-acegisecurity-sample block:
replace the acegi dependency with:
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-core</artifactId>
<version>2.0.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>avalon-framework</groupId>
<artifactId>avalon-framework</artifactId>
</exclusion>
</exclusions>
</dependency>
4) replacements in META-INF/cocoon/xpatch/acegi-filter-patch.xweb:
every org.acegi. ... should be replaced by org.springframework.security
5) the same needs to be done for all bean's class attribute inside META-INF/cocoon/spring/cocoon-acegisecurity.xml
6) mvn install; mvn jetty:run
I would guess, that by making acegi a spring portfolio project, the rework on that project contains better adoption of spring bean-lifecycles.
I would enjoy to see this little update inside cocoon-trunk for new users. Maybe one 'little' problem is the aforementioned availability of the spring-security artifact (2.0.0 RC1) inside mavens repository. Could this be solved permanently by now?
Best regards,
Patrick
[1] http://www.acegisecurity.org/cvs-usage.html
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
http://games.entertainment.gmx.net/de/entertainment/games/free
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: RCL goal refactorings / acegi
Posted by Felix Knecht <fe...@otego.com>.
Patrick Heiden schrieb:
> Hello together!
>
> Why is the acegi example still out-of-order? I've read [1] from Reinhard Poetz (back in Jun 2007) and there he mentioned trouble with ApplicationContext access due to the fact it seems to get closed when integrating acegi. I am able to reproduce the exception with baby-fresh trunk few minutes ago.
>
> Are there solutions / hints for this one?
>
I thought Giacomo had the sample once up and running, but he used the
latest acegi sources from trunk, which aren't available in a maven
repository.
Maybe it's worth to give it a try.
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org