Hi Nick thank you for your help, see below my comments:
Writing the response into memory would of course work but it is
clearly not an option for obvious reasons.
I'm not sure I understand what you mean by "For WS-284 could you still
write the response out but then supply an error code later ?" If the
"response" is already written I don't see how it would be possible to
change the status code (I guess it is what you mean by error code)
later knowing that the status code is part of the header which is
written before the body that contains the "response". Even if it was
possible we would have an inconsistency between the body and the
status code which will be seen as a bug for many
customers/partners/consultants
So I keep on saying that there is nothing I can do on my side, unless
you have other suggestions. If not as it is not possible to improve
the code on gatein, I will revert the changes for WS-284 within the
context of 285
Yea I can't really think of a good solution for this. +1 for
reverting,
or maybe even better just have the exceptions from
RequestLifecycle.end() logged. I believe previously they were ignored.
On Mon, Dec 2, 2013 at 4:24 PM, Nick Scavelli <nscavell(a)redhat.com
<mailto:nscavell@redhat.com>> wrote:
Hmm yes, unfortunately the only way to retrieve portlet state
which is non transient is to load it from the backend which will
definitely require JCR session to be available.
For WS-284 could you still write the response out but then supply
an error code later ? So at least you have an error from the
server even though the response has been written out. When I
looked at this awhile ago - I was playing with writing the
response into memory, but that obviously won't scale.
On 12/02/2013 10:53 AM, Nicolas Filotto wrote:
> If so it means that WS-285 and WS-284 are simply incompatible. To
> be able to fix WS-284, we need to call RequestLifeCycle.end()
> before writing the response but for WS-285 we need to call
> RequestLifeCycle.end() after writing the response so there is
> nothing I can do on my side.
> If at gatein level you cannot improve your mop marshaller to
> avoid depending on the RequestLifeCycle, I believe that the only
> way to fix it would be to simply revert the changes done for WS-284
>
> Please check on your side and tell me if the mop marshaller can
> be improved, if not I will revert WS-284 within the context of
> WS-285.
> Thank you in advance
>
>
> On Mon, Dec 2, 2013 at 2:10 PM, Lucas Ponce <lponce(a)redhat.com
> <mailto:lponce@redhat.com>> wrote:
>
> Hello Nicolas,
>
> I've tested your .jar in my scenario and I can't make it work.
>
> I'm still having same Exception.
>
> You can test it from gatein using a simple curl command:
>
> curl -i -H "Accept: application/json" -u root:gtn
>
http://localhost:8080/rest/private/managed-components/mop/portalsites/cla...
>
> You get a Exception meanshile a xml is expected.
>
> Thanks,
> Lucas
>
>
> ----- Mensaje original -----
> > De: "Nicolas Filotto" <nicolas.filotto(a)exoplatform.com
> <mailto:nicolas.filotto@exoplatform.com>>
> > Para: "Trong Tran" <trongtt(a)gmail.com
> <mailto:trongtt@gmail.com>>
> > CC: "Lucas Ponce" <lponce(a)redhat.com
> <mailto:lponce@redhat.com>>, "gatein-dev"
> <gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>>
> > Enviados: Lunes, 2 de Diciembre 2013 9:45:12
> > Asunto: Re: [gatein-dev] SessionManagerContainer in
> exo.kernel.container 2.5.0-Alpha3
> >
> > @Trong Great catch !!
> > @Lucas Thank you very much for reporting this issue and
> proposing a PR, I
> > really appreciate !
> > Could you please try with this jar file and tell me if
> WS-285 and WS-284?
> >
> > NB: For the PR, please note that we use the repository
> "exoplatform" for
> > the maintenance branches and "exodev" for the master, so in
> this particular
> > case you were supposed to use exodev as it affects the
> master, thank you
> > very much anyway for your PR.
> >
> >
> > On Fri, Nov 29, 2013 at 9:24 AM, Trong Tran
> <trongtt(a)gmail.com <mailto:trongtt@gmail.com>> wrote:
> >
> > > I believe that this problem is related to
> > >
>
https://github.com/exoplatform/ws/commit/50a829a047ff91a1f358d9ef2536486d...
> > >
> > > It seems to me that RequestLifeCycle.end() is being
> called sooner than
> > > expected in
> > >
>
https://github.com/exoplatform/ws/blob/2.4.0-Alpha3/exo.ws.rest.core/src/...
> > >
> > >
> > >
> > > On 29 November 2013 15:15, Nicolas Filotto <
> > > nicolas.filotto(a)exoplatform.com
> <mailto:nicolas.filotto@exoplatform.com>> wrote:
> > >
> > >> There are many things that have been added between
> Alpha1 and Alpha3, so
> > >> I will need more details. What do you mean exactly by
> "strange behavior
> > >> with some ThreadLocal<> variables"?
> > >>
> > >> Please note that I don't work on Fridays so I will
> answer next week once
> > >> I will have more details
> > >>
> > >>
> > >> On Thu, Nov 28, 2013 at 8:46 PM, Lucas Ponce
> <lponce(a)redhat.com <mailto:lponce@redhat.com>> wrote:
> > >>
> > >>> Nicolas,
> > >>>
> > >>> Do you know if there is some change related
> multithreading between
> > >>> kernel 2.5.0-Alpha3 and 2.5.0-Alpha1 ?
> > >>>
> > >>> Debugging a class I'm seeing some strange behaviour
> with some
> > >>> ThreadLocal<> variables.
> > >>>
> > >>> Thanks again,
> > >>> Lucas
> > >>>
> > >>> ----- Mensaje original -----
> > >>> > De: "Nicolas Filotto"
> <nicolas.filotto(a)exoplatform.com
> <mailto:nicolas.filotto@exoplatform.com>>
> > >>> > Para: "Lucas Ponce" <lponce(a)redhat.com
> <mailto:lponce@redhat.com>>
> > >>> > CC: "gatein-dev"
<gatein-dev(a)lists.jboss.org
> <mailto:gatein-dev@lists.jboss.org>>
> > >>> > Enviados: Jueves, 28 de Noviembre 2013 18:08:29
> > >>> > Asunto: Re: [gatein-dev] SessionManagerContainer in
> > >>> exo.kernel.container 2.6.0-Alpha3
> > >>> >
> > >>> > If you use the SessionManagerContainer, why don't
you
> have a
> > >>> compilation
> > >>> > error ?
> > >>> >
> > >>> >
> > >>> > On Thu, Nov 28, 2013 at 4:50 PM, Lucas Ponce
> <lponce(a)redhat.com <mailto:lponce@redhat.com>>
> > >>> wrote:
> > >>> >
> > >>> > > Hello Nicolas,
> > >>> > >
> > >>> > > POMSessionManager.java needs to access to
> SessionContext at this
> > >>> point:
> > >>> > >
> > >>> > > public POMSession getSession() {
> > >>> > > SessionContext context =
configurator.getContext();
> > >>> > > return context != null ? (POMSession)
> > >>> > > context.getAttachment("mopsession") :
null;
> > >>> > > }
> > >>> > >
> > >>> > > This is needed to PortalNamesCache.java to
perform
> a query to
> > >>> > > POMDataStorage component:
> > >>> > >
> > >>> > > @Override
> > >>> > > public <V> V execute(POMSession
session,
> POMTask<V> task) throws
> > >>> > > Exception {
> > >>> > > if (!session.isModified()) {
> > >>> > > if (task instanceof
> SearchTask.FindSiteKey) {
> > >>> > > SearchTask.FindSiteKey find =
> > >>> (SearchTask.FindSiteKey)
> > >>> > > task;
> > >>> > > List<PortalKey> data =
(List<PortalKey>)
> > >>> > > session.getFromCache(find.getKey());
> > >>> > > if (data == null) {
> > >>> > > V result = super.execute(session, task);
> > >>> > > LazyPageList<PortalKey> list =
> > >>> > > (LazyPageList<PortalKey>) result;
> > >>> > > session.putInCache(find.getKey(),
> > >>> > > Collections.unmodifiableList(new
> > >>> ArrayList<PortalKey>(list.getAll())));
> > >>> > > return result;
> > >>> > > } else {
> > >>> > > return (V) new
LazyPageList<PortalKey>(new
> > >>> > > ListAccessImpl<PortalKey>(PortalKey.class,
data), 10);
> > >>> > > }
> > >>> > > } else if (task instanceof
> PortalConfigTask.Save || task
> > >>> > > instanceof PortalConfigTask.Remove) {
> > >>> > > V result = super.execute(session, task);
> > >>> > >
> > >>> > >
> session.scheduleForEviction(SearchTask.FindSiteKey.PORTAL_KEY);
> > >>> > >
> > >>> > >
> session.scheduleForEviction(SearchTask.FindSiteKey.GROUP_KEY);
> > >>> > > return result;
> > >>> > > }
> > >>> > > }
> > >>> > >
> > >>> > > //
> > >>> > > return super.execute(session, task);
> > >>> > > }
> > >>> > >
> > >>> > > With the current change of version in exo.core,
the
> getSession() in
> > >>> > > POMSessionManager is always null, so a NPE is
> thrown breaking the POM
> > >>> > > service.
> > >>> > >
> > >>> > > I wonder how I can integrate these new changes
to
> have same
> > >>> behaviour that
> > >>> > > previous version.
> > >>> > >
> > >>> > > Thanks,
> > >>> > > Lucas
> > >>> > >
> > >>> > >
> > >>> > > ----- Mensaje original -----
> > >>> > > > De: "Nicolas Filotto"
> <nicolas.filotto(a)exoplatform.com
> <mailto:nicolas.filotto@exoplatform.com>>
> > >>> > > > Para: "Lucas Ponce"
<lponce(a)redhat.com
> <mailto:lponce@redhat.com>>
> > >>> > > > CC: "gatein-dev"
<gatein-dev(a)lists.jboss.org
> <mailto:gatein-dev@lists.jboss.org>>
> > >>> > > > Enviados: Jueves, 28 de Noviembre 2013
17:29:27
> > >>> > > > Asunto: Re: [gatein-dev]
SessionManagerContainer in
> > >>> exo.kernel.container
> > >>> > > 2.6.0-Alpha3
> > >>> > > >
> > >>> > > > What is the need exactly ? Beeing able to
scope a
> component to a
> > >>> Session?
> > >>> > > > If so it is now possible to define a scope
to a
> component thanks to
> > >>> > > >
https://jira.exoplatform.org/browse/KER-258.
Out
> of the box, the
> > >>> kernel
> > >>> > > > supports the scope Singleton,
ApplicationScoped
> and Dependent. By
> > >>> adding
> > >>> > > > some configuration you can extend the list
to
> SessionScoped and
> > >>> > > > RequestScoped. Here is the configuration to
add
> if you want both:
> > >>> > > >
> > >>> > > > <component>
> > >>> > > >
> <key>org.exoplatform.container.context.ContextManager</key>
> > >>> > > >
>
<type>org.exoplatform.container.context.ContextManagerImpl</type>
> > >>> > > > <component-plugins>
> > >>> > > > <component-plugin>
> > >>> > > > <name>main-scopes</name>
> > >>> > > >
<set-method>addContexts</set-method>
> > >>> > > >
> <type>org.exoplatform.container.context.ContextPlugin</type>
> > >>> > > > <init-params>
> > >>> > > > <object-param>
> > >>> > > > <name>request-scope</name>
> > >>> > > > <object
> type="org.exoplatform.container.context.RequestContext"/>
> > >>> > > > </object-param>
> > >>> > > > <object-param>
> > >>> > > > <name>session-scope</name>
> > >>> > > > <object
> type="org.exoplatform.container.context.SessionContext"/>
> > >>> > > > </object-param>
> > >>> > > > </init-params>
> > >>> > > > </component-plugin>
> > >>> > > > </component-plugins>
> > >>> > > > </component>
> > >>> > > >
> > >>> > > > Please note that the components that you
want to
> scope to
> > >>> SessionScoped
> > >>> > > or
> > >>> > > > RequestScoped must be proxyable as they are
> normal scopes (which
> > >>> means
> > >>> > > that
> > >>> > > > you will access to the methods through a
proxy
> and you must not
> > >>> access to
> > >>> > > > the fields directly), moreover components
that
> you want to scope to
> > >>> > > > SessionScoped must be Serializable as
> SessionScoped is a
> > >>> passivating
> > >>> > > scope.
> > >>> > > >
> > >>> > > > Please also note that thanks to KER-252 you
can
> use the annotations
> > >>> > > defined
> > >>> > > > in JSR 330 such as Inject
> > >>> > > >
> > >>> > > >
> > >>> > > > On Thu, Nov 28, 2013 at 3:36 PM, Lucas
Ponce
> <lponce(a)redhat.com <mailto:lponce@redhat.com>>
> > >>> wrote:
> > >>> > > >
> > >>> > > > > Hello,
> > >>> > > > >
> > >>> > > > > There is a issue in current master that
is
> impacting to REST
> > >>> management
> > >>> > > > > services in GateIn.
> > >>> > > > >
> > >>> > > > >
https://issues.jboss.org/browse/GTNPORTAL-3308
> > >>> > > > >
> > >>> > > > > Investigating it looks like that issue
appears
> since migration to
> > >>> > > > > 2.6.0-Alpha3 core.
> > >>> > > > >
> > >>> > > > > Main symptom is a NPE in
POMSessionManager class:
> > >>> > > > >
> > >>> > > > >
> > >>> > > > >
> > >>> > >
> > >>>
>
https://github.com/gatein/gatein-portal/blob/428874e25ee9e6dada3fd1a54a4a...
> > >>> > > > >
> > >>> > > > > One of the changes of 2.6.0-Alpha3 is
to drop the
> > >>> > > SessionManagerContainer
> > >>> > > > > interface from PortalContainer.
> > >>> > > > >
> > >>> > > > > Is there a workaround to access to
same
> functionality in order
> > >>> to fix
> > >>> > > this
> > >>> > > > > issue ?
> > >>> > > > >
> > >>> > > > > Thanks in advance,
> > >>> > > > > Lucas
> > >>> > > > >
_______________________________________________
> > >>> > > > > gatein-dev mailing list
> > >>> > > > > gatein-dev(a)lists.jboss.org
> <mailto:gatein-dev@lists.jboss.org>
> > >>> > > > >
https://lists.jboss.org/mailman/listinfo/gatein-dev
> > >>> > > > >
> > >>> > > >
> > >>> > >
> > >>> >
> > >>>
> > >>
> > >>
> > >> _______________________________________________
> > >> gatein-dev mailing list
> > >> gatein-dev(a)lists.jboss.org
> <mailto:gatein-dev@lists.jboss.org>
> > >>
https://lists.jboss.org/mailman/listinfo/gatein-dev
> > >>
> > >
> > >
> > >
> > > --
> > > *Trong Tran*
> > > *(+84) 983841909 <tel:%28%2B84%29%20983841909>
> <%28%2B84%29%20983841909> | *trongtt(a)gmail.com
> <mailto:trongtt@gmail.com>
> > > Twitter:
http://twitter.com/trongtt
> > >
> >
>
>
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/gatein-dev