RE: [portal] deprecation of request data store
The latest code for the 2.1.x branch contains a similar code that doesn't
use
the RequestDataStore - a simple request.getAttribute(this.key) works.
Carsten
> -Original Message-
> From: DURDINA Michal [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 10, 2004 11:17 AM
> To: [EMAIL PROTECTED]
> Subject: [portal] deprecation of request data store
>
> This mail refers a bit to my previous thread "Sharing
> cocoon.jar between multiple web aplications"
> http://marc.theaimsgroup.com/?t=10946512153&r=1&w=2
>
> I have problem with portal engine running in ear bundled with
> other portlet webapps when all libraries are on ear level. I
> get NPE when portlet is resolving its portlet-url via
>
> PortletURLProviderImpl.toString() ->
> PortalServiceImpl.getComponentManager() ->
> PortalServiceInfo.getInfo() ->
> PortalInfo.getComponentManager() -> returns null !
>
> I am using the cocoon-2.1.5 release and the code in
> PortalServiceImpl has changed since then in CVS
>
> from version 1.10:
>
> protected PortalServiceInfo getInfo() {
> PortalServiceInfo info = (PortalServiceInfo)
> this.dataStore.getRequestData(this.key);
> if ( info == null ) {
> info = new PortalServiceInfo();
>
> info.setup(ContextHelper.getObjectModel(this.context),
> this.portalComponentManagers);
> this.dataStore.setRequestData(this.key, info);
> }
> return info;
> }
>
> to version 1.12 (CVS comment CZ: "Deprecate request data
> store and remove it's use in the portal"):
>
> protected PortalServiceInfo getInfo() {
> final Request request = ContextHelper.getRequest(
> this.context );
> PortalServiceInfo info = (PortalServiceInfo)
> request.getAttribute(this.key, Request.GLOBAL_SCOPE);
> ...
> }
>
> I would like to know what was the reason for this change and
> if it would solve the problem I described upper.
>
> In that case I would like to make a patch that would make
> those changes applicable for cocoon 2.1.5 release. But the
> change introduced the use of feature new to cocoon-2.2.0-dev
> core -> request.getAttribute(this.key, Request.GLOBAL_SCOPE).
> Will it be feasable to backport all this functionality back
> to cocoon 2.1.5? Or you would advise another solution.
>
> Thank you,
> Michal
>
>
> ---
> Michal Ďurdina
> ASSET Soft, a.s. / eBussiness Solutions
> Košická 56, 821 08 Bratislava SLOVAK REPUBLIC
> Phone: +421-2-50703-523
> Fax: +421-2-50703-444
> e-mail: [EMAIL PROTECTED]
>
> http://www.assetsoft.sk
>
Re: Nightly builds for SVN WAS: [portal] deprecation of request data store
ÏURDINA Michal said: >> -Original Message- >> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] >> >> >>http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/ >> >> Vadim >> >> > > NO, because I am relly stuck behind the firewall. I rdiffed branch > BRANCH_2_1_X with RELEASE_2_1_5 in cvs and found no changes assuming that > all changes are done only in subversion. For SVN I wanted to use our > httpproxy (squid) but it is configured not to allow extended http methods > that svn use and I have no impact on its configuration. > Try using https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/ that works for me while http does not. Ralph
Nightly builds for SVN WAS: [portal] deprecation of request data store
> -Original Message- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] > Sent: Friday, September 10, 2004 12:58 PM > To: [EMAIL PROTECTED] > Subject: Re: [portal] deprecation of request data store > > > ĎURDINA Michal wrote: > > > In that case I would like to make a patch that would make > those changes > > applicable for cocoon 2.1.5 release. But the change > introduced the use > > of feature new to cocoon-2.2.0-dev core -> > > request.getAttribute(this.key, Request.GLOBAL_SCOPE). Will it be > > feasable to backport all this functionality back to cocoon 2.1.5? > > Or you would advise another solution. > > Have you checked in 2.1.X branch? It might have the fix you > are looking for. > >http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/ > > Vadim > > NO, because I am relly stuck behind the firewall. I rdiffed branch BRANCH_2_1_X with RELEASE_2_1_5 in cvs and found no changes assuming that all changes are done only in subversion. For SVN I wanted to use our httpproxy (squid) but it is configured not to allow extended http methods that svn use and I have no impact on its configuration. So I wanted to download snapshot from http://cvs.apache.org/snapshots/cocoon-2.1/ but then I realized that it would probably doing only HEAD snapshots and only from CVS. Where is the location for nightly built snapshots of cocoon-2.1.6-dev ? Can I command svn client not to use HTTP extended methods? Does it exist any tool like cvsgrab for svn? Thank you, Michal
Re: [portal] deprecation of request data store
ĎURDINA Michal wrote: In that case I would like to make a patch that would make those changes > applicable for cocoon 2.1.5 release. But the change introduced the use > of feature new to cocoon-2.2.0-dev core -> > request.getAttribute(this.key, Request.GLOBAL_SCOPE). Will it be > feasable to backport all this functionality back to cocoon 2.1.5? > Or you would advise another solution. Have you checked in 2.1.X branch? It might have the fix you are looking for. http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/ Vadim
[portal] deprecation of request data store
This mail refers a bit to my previous thread "Sharing cocoon.jar between multiple web
aplications"
http://marc.theaimsgroup.com/?t=10946512153&r=1&w=2
I have problem with portal engine running in ear bundled with other portlet webapps
when all libraries are on ear level. I get NPE when portlet is resolving its
portlet-url via
PortletURLProviderImpl.toString() ->
PortalServiceImpl.getComponentManager() ->
PortalServiceInfo.getInfo() ->
PortalInfo.getComponentManager() -> returns null !
I am using the cocoon-2.1.5 release and the code in PortalServiceImpl has changed
since then in CVS
from version 1.10:
protected PortalServiceInfo getInfo() {
PortalServiceInfo info = (PortalServiceInfo)
this.dataStore.getRequestData(this.key);
if ( info == null ) {
info = new PortalServiceInfo();
info.setup(ContextHelper.getObjectModel(this.context),
this.portalComponentManagers);
this.dataStore.setRequestData(this.key, info);
}
return info;
}
to version 1.12 (CVS comment CZ: "Deprecate request data store and remove it's use in
the portal"):
protected PortalServiceInfo getInfo() {
final Request request = ContextHelper.getRequest( this.context );
PortalServiceInfo info = (PortalServiceInfo) request.getAttribute(this.key,
Request.GLOBAL_SCOPE);
...
}
I would like to know what was the reason for this change and if it would solve the
problem I described upper.
In that case I would like to make a patch that would make those changes applicable for
cocoon 2.1.5 release. But the change introduced the use of feature new to
cocoon-2.2.0-dev core -> request.getAttribute(this.key, Request.GLOBAL_SCOPE). Will it
be feasable to backport all this functionality back to cocoon 2.1.5? Or you would
advise another solution.
Thank you,
Michal
---
Michal Ďurdina
ASSET Soft, a.s. / eBussiness Solutions
Košická 56, 821 08 Bratislava SLOVAK REPUBLIC
Phone: +421-2-50703-523
Fax: +421-2-50703-444
e-mail: [EMAIL PROTECTED]
http://www.assetsoft.sk
