1:01 p.m.
I had to do some classloading and logging changes for exo.kernel.container
to work nicely on JBoss AS7.
I'd like to get these changes from my sandbox gatein-as7 branch to
exo.kernel.container trunk.
Here's the diff (effectively against exo-jcr/kernel/tags/
2.3.0.GA/exo.kernel.container/src):
svn diff -r 7504:7557
http://anonsvn.jboss.org/repos/gatein/sandbox/as7_support/branches/gatein...
And here's the JIRA issue for it:
https://issues.jboss.org/browse/EXOJCR-1580
- marko
8:16 a.m.
Nicolas,
Julien told me you will be decision person to accept such patch into the kernel. Marko can
apply details about the context of those changes if needed.
Bolek
On Oct 6, 2011, at 8:01 PM, Marko Strukelj wrote:
I had to do some classloading and logging changes for
exo.kernel.container to work nicely on JBoss AS7.
I'd like to get these changes from my sandbox gatein-as7 branch to
exo.kernel.container trunk.
Here's the diff (effectively against
exo-jcr/kernel/tags/2.3.0.GA/exo.kernel.container/src):
svn diff -r 7504:7557
http://anonsvn.jboss.org/repos/gatein/sandbox/as7_support/branches/gatein...
And here's the JIRA issue for it: https://issues.jboss.org/browse/EXOJCR-1580
- marko
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
9:20 a.m.
Well, it depends on the expected fix version of this patch. Do you expect it
in eXo JCR 1.14.x or in the future version? and What would be the deadline?
Anyway I know that Marko is very good and has a good knowledge of the
kernel, however I still can't apply it blindly, I need to double check it to
ensure that we will have no regression with it, so for me it is a real task
that has to be planned. Thus I need your answers first to know when it can
be planned according to your needs and expectations and ours.
NB: To be able to validate it, I will need a complete overview of what has
been done not only at kernel level but even at GateIn level. Is it possible
to describe a little bit all the patches that you proposed?
On Mon, Oct 10, 2011 at 1:16 PM, Boleslaw Dawidowicz <
boleslaw.dawidowicz(a)gmail.com> wrote:
Nicolas,
Julien told me you will be decision person to accept such patch into the
kernel. Marko can apply details about the context of those changes if
needed.
Bolek
On Oct 6, 2011, at 8:01 PM, Marko Strukelj wrote:
I had to do some classloading and logging changes for exo.kernel.container
to work nicely on JBoss AS7.
I'd like to get these changes from my sandbox gatein-as7 branch to
exo.kernel.container trunk.
Here's the diff (effectively against exo-jcr/kernel/tags/
2.3.0.GA/exo.kernel.container/src):
svn diff -r 7504:7557
http://anonsvn.jboss.org/repos/gatein/sandbox/as7_support/branches/gatein...
And here's the JIRA issue for it:
https://issues.jboss.org/browse/EXOJCR-1580
- marko
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
5:16 p.m.
WCI changes introduce a jboss7 module which is only used if explicitly
referenced in configuration - no impact on anything there. It also
introduces a deadlock patch in wci-wci which adds an extra synchronized
block. Without this patch a deadlock can occur (and often does occur on
JBoss AS7) when shutting down the server. No impact on performance or memory
usage.
Kernel changes are limited to exo.kernel.container module where in two
places there was a need to introduce the use of TCCL for classloading
instead of using a local ClassLoader.
The new classloading uses ‘TCCL first’ approach with fallback to the old
behavior. The use of TCCL was necessary to allow GateIn services to properly
startup in an environment of isolated classloaders.
I added a method:
org.exoplatform.container.util.ContainerUtil.class:
public static Class loadClass(String type) throws ClassNotFoundException
{
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader localCl = ContainerUtil.class.getClassLoader();
ClassLoader cl = tccl != null ? tccl : localCl;
try
{
return cl.loadClass(type);
}
catch (ClassNotFoundException e)
{
if (cl == tccl)
return localCl.loadClass(type);
throw e;
}
}
It is used in two places instead of Class.forName():
- org/exoplatform/xml/object/XMLObject.java
- org/exoplatform/container/jmx/MX4JComponentAdapter.java
It’s possible to imagine a scenario where due to deployment archive
packaging the same classes may be available through different .jars, .wars,
.ears. In such a situation the new code may load the class from portlet
application deployment archive, or portal extension deployment archive
instead of gatein portal’s lib/*.jar (gatein.ear/lib on JBossAS5 / JBossAS6,
$TOMCAT_HOME/lib on Tomcat).
Actually by making it local loader first with TCCL fallback there would be
no chance of any side effects. It may even be more appropriate as it
prevents the accidental override of GateIn's classes due to packaging.
So I'll change the method to:
public static Class loadClass(String type) throws ClassNotFoundException
{
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader localCl = ContainerUtil.class.getClassLoader();
try
{
return localCl.loadClass(type);
}
catch (ClassNotFoundException e)
{
if (tccl != null)
return tccl.loadClass(type);
throw e;
}
}
I'll prepare a patch against exo.kernel.container trunk and attach it to the
issue.
On Mon, Oct 10, 2011 at 4:20 PM, Nicolas FILOTTO <
nicolas.filotto(a)exoplatform.com> wrote:
Well, it depends on the expected fix version of this patch. Do you
expect
it in eXo JCR 1.14.x or in the future version? and What would be the
deadline?
Anyway I know that Marko is very good and has a good knowledge of the
kernel, however I still can't apply it blindly, I need to double check it to
ensure that we will have no regression with it, so for me it is a real task
that has to be planned. Thus I need your answers first to know when it can
be planned according to your needs and expectations and ours.
NB: To be able to validate it, I will need a complete overview of what has
been done not only at kernel level but even at GateIn level. Is it possible
to describe a little bit all the patches that you proposed?
On Mon, Oct 10, 2011 at 1:16 PM, Boleslaw Dawidowicz <
boleslaw.dawidowicz(a)gmail.com> wrote:
> Nicolas,
>
> Julien told me you will be decision person to accept such patch into the
> kernel. Marko can apply details about the context of those changes if
> needed.
>
> Bolek
>
>
> On Oct 6, 2011, at 8:01 PM, Marko Strukelj wrote:
>
> I had to do some classloading and logging changes for exo.kernel.container
> to work nicely on JBoss AS7.
>
> I'd like to get these changes from my sandbox gatein-as7 branch to
> exo.kernel.container trunk.
>
> Here's the diff (effectively against exo-jcr/kernel/tags/
> 2.3.0.GA/exo.kernel.container/src):
>
> svn diff -r 7504:7557
>
http://anonsvn.jboss.org/repos/gatein/sandbox/as7_support/branches/gatein...
>
> And here's the JIRA issue for it:
> https://issues.jboss.org/browse/EXOJCR-1580
>
>
> - marko
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>
>
5:37 a.m.
How do you deploy all the jar files of Gatein (aka kernel, core, ws, jcr,
and gatein jars)? Let's say that we have a vanilla JBoss AS 7 instance, what
are the steps to deploy gatein successully
I still need to know the target version and the deadline
On Mon, Oct 10, 2011 at 10:16 PM, Marko Strukelj
<marko.strukelj(a)gmail.com>wrote:
WCI changes introduce a jboss7 module which is only used if explicitly
referenced in configuration - no impact on anything there. It also
introduces a deadlock patch in wci-wci which adds an extra synchronized
block. Without this patch a deadlock can occur (and often does occur on
JBoss AS7) when shutting down the server. No impact on performance or memory
usage.
Kernel changes are limited to exo.kernel.container module where in two
places there was a need to introduce the use of TCCL for classloading
instead of using a local ClassLoader.
The new classloading uses ‘TCCL first’ approach with fallback to the old
behavior. The use of TCCL was necessary to allow GateIn services to properly
startup in an environment of isolated classloaders.
I added a method:
org.exoplatform.container.util.ContainerUtil.class:
public static Class loadClass(String type) throws ClassNotFoundException
{
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader localCl = ContainerUtil.class.getClassLoader();
ClassLoader cl = tccl != null ? tccl : localCl;
try
{
return cl.loadClass(type);
}
catch (ClassNotFoundException e)
{
if (cl == tccl)
return localCl.loadClass(type);
throw e;
}
}
It is used in two places instead of Class.forName():
- org/exoplatform/xml/object/XMLObject.java
- org/exoplatform/container/jmx/MX4JComponentAdapter.java
It’s possible to imagine a scenario where due to deployment archive
packaging the same classes may be available through different .jars, .wars,
.ears. In such a situation the new code may load the class from portlet
application deployment archive, or portal extension deployment archive
instead of gatein portal’s lib/*.jar (gatein.ear/lib on JBossAS5 / JBossAS6,
$TOMCAT_HOME/lib on Tomcat).
Actually by making it local loader first with TCCL fallback there would be
no chance of any side effects. It may even be more appropriate as it
prevents the accidental override of GateIn's classes due to packaging.
So I'll change the method to:
public static Class loadClass(String type) throws ClassNotFoundException
{
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader localCl = ContainerUtil.class.getClassLoader();
try
{
return localCl.loadClass(type);
}
catch (ClassNotFoundException e)
{
if (tccl != null)
return tccl.loadClass(type);
throw e;
}
}
I'll prepare a patch against exo.kernel.container trunk and attach it to
the issue.
On Mon, Oct 10, 2011 at 4:20 PM, Nicolas FILOTTO <
nicolas.filotto(a)exoplatform.com> wrote:
> Well, it depends on the expected fix version of this patch. Do you expect
> it in eXo JCR 1.14.x or in the future version? and What would be the
> deadline?
>
> Anyway I know that Marko is very good and has a good knowledge of the
> kernel, however I still can't apply it blindly, I need to double check it to
> ensure that we will have no regression with it, so for me it is a real task
> that has to be planned. Thus I need your answers first to know when it can
> be planned according to your needs and expectations and ours.
>
> NB: To be able to validate it, I will need a complete overview of what has
> been done not only at kernel level but even at GateIn level. Is it possible
> to describe a little bit all the patches that you proposed?
>
>
> On Mon, Oct 10, 2011 at 1:16 PM, Boleslaw Dawidowicz <
> boleslaw.dawidowicz(a)gmail.com> wrote:
>
>> Nicolas,
>>
>> Julien told me you will be decision person to accept such patch into the
>> kernel. Marko can apply details about the context of those changes if
>> needed.
>>
>> Bolek
>>
>>
>> On Oct 6, 2011, at 8:01 PM, Marko Strukelj wrote:
>>
>> I had to do some classloading and logging changes for
>> exo.kernel.container to work nicely on JBoss AS7.
>>
>> I'd like to get these changes from my sandbox gatein-as7 branch to
>> exo.kernel.container trunk.
>>
>> Here's the diff (effectively against exo-jcr/kernel/tags/
>> 2.3.0.GA/exo.kernel.container/src):
>>
>> svn diff -r 7504:7557
>>
http://anonsvn.jboss.org/repos/gatein/sandbox/as7_support/branches/gatein...
>>
>> And here's the JIRA issue for it:
>> https://issues.jboss.org/browse/EXOJCR-1580
>>
>>
>> - marko
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>
>>
>>
>
6:53 a.m.
On Tue, Oct 11, 2011 at 11:12 AM, Thomas Heute <theute(a)redhat.com> wrote:
On 10/11/2011 12:37 PM, Nicolas FILOTTO wrote:
> y gatein successully
>
> I still need to know the target version and the deadline
>
This is low priority (not for EPP 5.2 or any product in the future).
It will be great for community.
I see thx for clarification, if so it will be done in the next version of
eXo JCR but we won't start working on the next version until the complete
landing of PLF 3.5 and EPP 5.2, in other words not before at least mid
November
Thomas.
6:08 a.m.
On Oct 11, 2011, at 1:53 PM, Nicolas FILOTTO wrote:
On Tue, Oct 11, 2011 at 11:12 AM, Thomas Heute <theute(a)redhat.com> wrote:
On 10/11/2011 12:37 PM, Nicolas FILOTTO wrote:
y gatein successully
I still need to know the target version and the deadline
This is low priority (not for EPP 5.2 or any product in the future).
It will be great for community.
I see thx for clarification, if so it will be done in the next version of eXo JCR but we
won't start working on the next version until the complete landing of PLF 3.5 and EPP
5.2, in other words not before at least mid November
Thomas.
Could you write to which version of JCR/Kernel should it be pointing to in JIRA then? Just
so we don't loose it from sight.
Bolek
6:31 a.m.
I set a temporary version id since the version id of the next version is not
yet defined
On Wed, Oct 12, 2011 at 11:08 AM, Boleslaw Dawidowicz <
boleslaw.dawidowicz(a)gmail.com> wrote:
On Oct 11, 2011, at 1:53 PM, Nicolas FILOTTO wrote:
On Tue, Oct 11, 2011 at 11:12 AM, Thomas Heute <theute(a)redhat.com> wrote:
> On 10/11/2011 12:37 PM, Nicolas FILOTTO wrote:
>
>> y gatein successully
>>
>> I still need to know the target version and the deadline
>>
> This is low priority (not for EPP 5.2 or any product in the future).
> It will be great for community.
>
I see thx for clarification, if so it will be done in the next version of
eXo JCR but we won't start working on the next version until the complete
landing of PLF 3.5 and EPP 5.2, in other words not before at least mid
November
>
> Thomas.
>
Could you write to which version of JCR/Kernel should it be pointing to in
JIRA then? Just so we don't loose it from sight.
Bolek
7:54 a.m.
Easiest way to deploy to AS7 is to follow the instructions:
http://anonsvn.jboss.org/repos/gatein/portal/trunk/packaging/jboss-as7/RE...
I think you're most interested in how classpath works. AS7 uses a module
system. There's no traditional classpath as a list of directories/jars any
more. Instead there are modules with cross dependencies on other modules.
Classpath becomes like a tree branching out from each submodule and cross
folding back onto itself with cross-dependencies (that go out from any to
any module - so it's not really a tree, but a graph). Each module is
represented by one classloader. Class lookup always starts at one module,
looks locally at what that module provides, then if not found - tries
dependency modules - where each one repeats the lookup procedure. In effect
- each module has its own 'classpath'.
All gatein.ear/lib/*.jar have been moved to modules. Typically one .jar
becomes one module with a list of dependencies on other modules (like maven
artifact for example). But to simplify things for starters, I put many jars
into the main module that represents gatein libraries. Most can be found in
gatein/modules/org/gatein/lib/main. The plan is to more fine-grain these in
the future - exo-jcr could become it's own module, or exo-jcr-kernel,
exo-jcr-core ... could become its own module. Or these could be just
aggregation modules to provide acces to several finegrained modules at once
- each jar as its own module.
All the GateIn libs are under $JBOSS_HOME/standalone/gatein/modules which is
used as a secondary modules system root directory. This way all the GateIn
libs are nicely seperated from those that come out-of-the-box with AS7.
In the end visibility is established in such a way that no other changes to
GateIn libs were necessary except the mentioned WCI, and
exo.kernel.container.
I need to expand the README.txt with some of this info. Also AS7 support in
its initial form still needs some work and fine proofing ...
- m
On Tue, Oct 11, 2011 at 12:37 PM, Nicolas FILOTTO <
nicolas.filotto(a)exoplatform.com> wrote:
How do you deploy all the jar files of Gatein (aka kernel, core, ws,
jcr,
and gatein jars)? Let's say that we have a vanilla JBoss AS 7 instance, what
are the steps to deploy gatein successully
I still need to know the target version and the deadline
On Mon, Oct 10, 2011 at 10:16 PM, Marko Strukelj <marko.strukelj(a)gmail.com
> wrote:
>
> WCI changes introduce a jboss7 module which is only used if explicitly
> referenced in configuration - no impact on anything there. It also
> introduces a deadlock patch in wci-wci which adds an extra synchronized
> block. Without this patch a deadlock can occur (and often does occur on
> JBoss AS7) when shutting down the server. No impact on performance or memory
> usage.
>
>
> Kernel changes are limited to exo.kernel.container module where in two
> places there was a need to introduce the use of TCCL for classloading
> instead of using a local ClassLoader.
>
> The new classloading uses ‘TCCL first’ approach with fallback to the old
> behavior. The use of TCCL was necessary to allow GateIn services to properly
> startup in an environment of isolated classloaders.
>
> I added a method:
>
> org.exoplatform.container.util.ContainerUtil.class:
>
>
> public static Class loadClass(String type) throws ClassNotFoundException
> {
> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> ClassLoader localCl = ContainerUtil.class.getClassLoader();
> ClassLoader cl = tccl != null ? tccl : localCl;
> try
> {
> return cl.loadClass(type);
> }
> catch (ClassNotFoundException e)
> {
> if (cl == tccl)
> return localCl.loadClass(type);
>
> throw e;
> }
> }
>
> It is used in two places instead of Class.forName():
>
> - org/exoplatform/xml/object/XMLObject.java
> - org/exoplatform/container/jmx/MX4JComponentAdapter.java
>
>
>
> It’s possible to imagine a scenario where due to deployment archive
> packaging the same classes may be available through different .jars, .wars,
> .ears. In such a situation the new code may load the class from portlet
> application deployment archive, or portal extension deployment archive
> instead of gatein portal’s lib/*.jar (gatein.ear/lib on JBossAS5 / JBossAS6,
> $TOMCAT_HOME/lib on Tomcat).
>
>
> Actually by making it local loader first with TCCL fallback there would be
> no chance of any side effects. It may even be more appropriate as it
> prevents the accidental override of GateIn's classes due to packaging.
>
> So I'll change the method to:
>
>
> public static Class loadClass(String type) throws
> ClassNotFoundException
> {
> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> ClassLoader localCl = ContainerUtil.class.getClassLoader();
> try
> {
> return localCl.loadClass(type);
> }
> catch (ClassNotFoundException e)
> {
> if (tccl != null)
> return tccl.loadClass(type);
>
> throw e;
> }
> }
>
>
> I'll prepare a patch against exo.kernel.container trunk and attach it to
> the issue.
>
>
>
> On Mon, Oct 10, 2011 at 4:20 PM, Nicolas FILOTTO <
> nicolas.filotto(a)exoplatform.com> wrote:
>
>> Well, it depends on the expected fix version of this patch. Do you expect
>> it in eXo JCR 1.14.x or in the future version? and What would be the
>> deadline?
>>
>> Anyway I know that Marko is very good and has a good knowledge of the
>> kernel, however I still can't apply it blindly, I need to double check it to
>> ensure that we will have no regression with it, so for me it is a real task
>> that has to be planned. Thus I need your answers first to know when it can
>> be planned according to your needs and expectations and ours.
>>
>> NB: To be able to validate it, I will need a complete overview of what
>> has been done not only at kernel level but even at GateIn level. Is it
>> possible to describe a little bit all the patches that you proposed?
>>
>>
>> On Mon, Oct 10, 2011 at 1:16 PM, Boleslaw Dawidowicz <
>> boleslaw.dawidowicz(a)gmail.com> wrote:
>>
>>> Nicolas,
>>>
>>> Julien told me you will be decision person to accept such patch into the
>>> kernel. Marko can apply details about the context of those changes if
>>> needed.
>>>
>>> Bolek
>>>
>>>
>>> On Oct 6, 2011, at 8:01 PM, Marko Strukelj wrote:
>>>
>>> I had to do some classloading and logging changes for
>>> exo.kernel.container to work nicely on JBoss AS7.
>>>
>>> I'd like to get these changes from my sandbox gatein-as7 branch to
>>> exo.kernel.container trunk.
>>>
>>> Here's the diff (effectively against exo-jcr/kernel/tags/
>>> 2.3.0.GA/exo.kernel.container/src):
>>>
>>> svn diff -r 7504:7557
>>>
http://anonsvn.jboss.org/repos/gatein/sandbox/as7_support/branches/gatein...
>>>
>>> And here's the JIRA issue for it:
>>> https://issues.jboss.org/browse/EXOJCR-1580
>>>
>>>
>>> - marko
>>> _______________________________________________
>>> gatein-dev mailing list
>>> gatein-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>
>>>
>>>
>>
>
4:24 p.m.
FYI, I worked a little bit on
https://issues.jboss.org/browse/EXOJCR-1580and proposed a set of
patches for it (as you can see there are a lot of
changes). In my patches, I added the support of jboss.server.config.dir
thanks to it, you have no need to set the exo.conf.dir only the
exo.conf.dir.name is enough. In the configuration.properties the variables
gatein.jcr.workspace.system and gatein.jcr.workspace.default are missing
which cause https://issues.jboss.org/browse/GTNPORTAL-2258. I guess you
know it already but the dependency management is hard coded so I had to
rebuild the class GateInExtensionConfiguration any time I had to add or
remove an ear or a war otherwise I had errors at startup of type:
15:23:55,271 INFO [org.jboss.as.server.controller]
(DeploymentScanner-threads - 2) Deployment of "gatein-sample-skin.war" was
rolled back with failure message {"Services with missing/unavailable
dependencies" =>
["jboss.deployment.unit.\"gatein-sample-skin.war\".CONFIGURE_MODULE
missing
[ jboss.module.information.service.\"deployment.gatein.ear\".main,
jboss.module.information.service.\"deployment.gatein-sample-portal.ear\".main,
jboss.module.information.service.\"deployment.gatein-sample-extension.ear\".main
]"]}
What a time wasted trying to figure out why it did not work even if I
modified the config file standalone.xml? Don't hesitate to warn me next
time :-(
I also noticed that when we logout we get the following stacktrace
9:29:20,864 ERROR [exo.core.component.security.core.JbossLoginModule.class]
(http--127.0.0.1-8080-1) Could not perform JBoss security manager cache
eviction: javax.management.InstanceNotFoundException:
jboss.security:service=JaasSecurityManager
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094)
[:1.6.0_26]
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833)
[:1.6.0_26]
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
[:1.6.0_26]
at
org.exoplatform.services.security.j2ee.JbossLoginModule.logout(JbossLoginModule.java:120)
[exo.core.component.security.core-2.4.4-GA-SNAPSHOT.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_26]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
[:1.6.0_26]
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
[:1.6.0_26]
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
[:1.6.0_26]
at java.security.AccessController.doPrivileged(Native Method)
[:1.6.0_26]
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
[:1.6.0_26]
at javax.security.auth.login.LoginContext.logout(LoginContext.java:629)
[:1.6.0_26]
at
org.jboss.security.authentication.JBossCachedAuthenticationManager$DomainInfo.logout(JBossCachedAuthenticationManager.java:513)
[picketbox-infinispan-4.0.1.jar:4.0.1]
at
org.jboss.as.security.plugins.DefaultAuthenticationCacheFactory$1.remove(DefaultAuthenticationCacheFactory.java:57)
at
org.jboss.as.security.plugins.DefaultAuthenticationCacheFactory$1.remove(DefaultAuthenticationCacheFactory.java:48)
at
org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache(JBossCachedAuthenticationManager.java:183)
[picketbox-infinispan-4.0.1.jar:4.0.1]
at
org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache(JBossCachedAuthenticationManager.java:58)
[picketbox-infinispan-4.0.1.jar:4.0.1]
at
org.jboss.as.web.security.JBossGenericPrincipal.logout(JBossGenericPrincipal.java:93)
[jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at org.apache.catalina.connector.Request.logout(Request.java:3262)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.connector.RequestFacade.logout(RequestFacade.java:1092)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.gatein.wci.jboss.JB7ServletContainerContext.logout(JB7ServletContainerContext.java:151)
[wci-jboss7-2.1.0-Beta07-AS7-Beta01.jar:2.1.0-Beta07-AS7-Beta01]
at
org.gatein.wci.impl.DefaultServletContainer.logout(DefaultServletContainer.java:117)
[wci-wci-2.1.0-Beta07-AS7-Beta01.jar:2.1.0-Beta07-AS7-Beta01]
at
org.exoplatform.portal.application.PortalLogoutLifecycle.onEndRequest(PortalLogoutLifecycle.java:60)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalLogoutLifecycle.onEndRequest(PortalLogoutLifecycle.java:37)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalRequestHandler.processRequest(PortalRequestHandler.java:218)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalRequestHandler.execute(PortalRequestHandler.java:150)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.WebAppController.service(WebAppController.java:349)
[exo.portal.component.web.controller-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalController.onService(PortalController.java:127)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
[exo.kernel.container-2.3.4-GA-SNAPSHOT.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.sample.portal.web.SampleFilter.doFilter(SampleFilter.java:46)
[exo.portal.sample.portal.jar-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:106)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:80)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:79)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:116)
[exo.jcr.framework.web-1.14.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:73)
[exo.portal.component.web.security-3.2.0-M02-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
[exo.core.component.security.core-2.4.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
[exo.kernel.container-2.3.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:139)
[jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:388)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
[jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
To finish, I also noticed that when I try to apply the sample skin on the
sample portal I got:
15:07:27,053 ERROR [portal:UIPortletLifecycle] (http--127.0.0.1-8080-1)
Portlet render threw an exception:
org.exoplatform.services.portletcontainer.PortletContainerException:
org.exoplatform.portal.config.NoSuchDataException: Can not find
6f1c00d1c0a801026e840613ffe92fd1
at
org.exoplatform.portal.webui.application.UIPortletLifecycle.processRender(UIPortletLifecycle.java:340)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.application.UIPortletLifecycle.processRender(UIPortletLifecycle.java:62)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:368)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:358)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at sun.reflect.GeneratedMethodAccessor154.invoke(Unknown Source)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
[groovy-all-1.7.6.jar:]
at UIPortal.run(UIPortal.gtmpl:18) at
org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:111)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:119)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.text.TemplateService.merge(TemplateService.java:117)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.renderTemplate(Lifecycle.java:125)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.processRender(Lifecycle.java:83)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.portal.UIPortalLifecycle.processRender(UIPortalLifecycle.java:41)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.portal.UIPortalLifecycle.processRender(UIPortalLifecycle.java:30)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponentDecorator.renderChildren(UIComponentDecorator.java:101)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_26]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
[groovy-all-1.7.6.jar:]
at UISiteBody.run(UISiteBody.gtmpl:27) at
org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:111)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:119)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.text.TemplateService.merge(TemplateService.java:117)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.renderTemplate(Lifecycle.java:125)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.processRender(Lifecycle.java:83)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:368)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:358)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_26]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
[groovy-all-1.7.6.jar:]
at UIContainer.run(UIContainer.gtmpl:49) at
org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:111)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:119)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.text.TemplateService.merge(TemplateService.java:117)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.renderTemplate(Lifecycle.java:125)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.processRender(Lifecycle.java:83)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponentDecorator$UIComponentDecoratorLifecycle.processRender(UIComponentDecorator.java:113)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponentDecorator$UIComponentDecoratorLifecycle.processRender(UIComponentDecorator.java:104)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:368)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:358)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_26]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
[groovy-all-1.7.6.jar:]
at UIWorkingWorkspace.run(UIWorkingWorkspace.gtmpl:12) at
org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:111)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:119)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.text.TemplateService.merge(TemplateService.java:117)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.renderTemplate(Lifecycle.java:125)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.processRender(Lifecycle.java:83)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:368)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:358)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIApplication.renderChildren(UIApplication.java:120)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_26]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
[groovy-all-1.7.6.jar:]
at
UIPortalApplicationChildren.run(UIPortalApplicationChildren.gtmpl:17) at
org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:111)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:119)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.text.TemplateService.merge(TemplateService.java:117)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.renderTemplate(Lifecycle.java:125)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processRender(UIPortalApplicationLifecycle.java:142)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processRender(UIPortalApplicationLifecycle.java:105)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processRender(UIPortalApplicationLifecycle.java:37)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.workspace.UIPortalApplication.processRender(UIPortalApplication.java:611)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalRequestHandler.processRequest(PortalRequestHandler.java:184)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalRequestHandler.execute(PortalRequestHandler.java:150)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.WebAppController.service(WebAppController.java:349)
[exo.portal.component.web.controller-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalController.onService(PortalController.java:127)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
[exo.kernel.container-2.3.4-GA-SNAPSHOT.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.sample.portal.web.SampleFilter.doFilter(SampleFilter.java:46)
[exo.portal.sample.portal.jar-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:106)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:80)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:79)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:116)
[exo.jcr.framework.web-1.14.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:73)
[exo.portal.component.web.security-3.2.0-M02-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
[exo.core.component.security.core-2.4.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
[exo.kernel.container-2.3.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:139)
[jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:388)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
[jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: org.exoplatform.portal.config.NoSuchDataException: Can not find
6f1c00d1c0a801026e840613ffe92fd1
at
org.exoplatform.portal.pom.config.POMSession.findCustomizationById(POMSession.java:214)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.tasks.PreferencesTask$Load.run(PreferencesTask.java:91)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.POMSession.execute(POMSession.java:405)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.ExecutorDispatcher.execute(ExecutorDispatcher.java:60)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.TaskExecutionDecorator.execute(TaskExecutionDecorator.java:38)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.cache.DataCache.read(DataCache.java:169)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.cache.DataCache.execute(DataCache.java:61)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.TaskExecutionDecorator.execute(TaskExecutionDecorator.java:38)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.cache.PortalNamesCache.execute(PortalNamesCache.java:79)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.POMSessionManager.execute(POMSessionManager.java:253)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.POMDataStorage.load(POMDataStorage.java:176)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.config.DataStorageImpl.load(DataStorageImpl.java:111)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.application.ModelAdapter$1.getPortletContext(ModelAdapter.java:89)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.application.UIPortlet.getPortletContext(UIPortlet.java:993)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.application.UIPortlet.create(UIPortlet.java:829)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.application.UIPortletLifecycle.processRender(UIPortletLifecycle.java:212)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
... 129 more
On Tue, Oct 11, 2011 at 12:54 PM, Marko Strukelj
<marko.strukelj(a)gmail.com>wrote:
Easiest way to deploy to AS7 is to follow the instructions:
http://anonsvn.jboss.org/repos/gatein/portal/trunk/packaging/jboss-as7/RE...
I think you're most interested in how classpath works. AS7 uses a module
system. There's no traditional classpath as a list of directories/jars any
more. Instead there are modules with cross dependencies on other modules.
Classpath becomes like a tree branching out from each submodule and cross
folding back onto itself with cross-dependencies (that go out from any to
any module - so it's not really a tree, but a graph). Each module is
represented by one classloader. Class lookup always starts at one module,
looks locally at what that module provides, then if not found - tries
dependency modules - where each one repeats the lookup procedure. In effect
- each module has its own 'classpath'.
All gatein.ear/lib/*.jar have been moved to modules. Typically one .jar
becomes one module with a list of dependencies on other modules (like maven
artifact for example). But to simplify things for starters, I put many jars
into the main module that represents gatein libraries. Most can be found in
gatein/modules/org/gatein/lib/main. The plan is to more fine-grain these in
the future - exo-jcr could become it's own module, or exo-jcr-kernel,
exo-jcr-core ... could become its own module. Or these could be just
aggregation modules to provide acces to several finegrained modules at once
- each jar as its own module.
All the GateIn libs are under $JBOSS_HOME/standalone/gatein/modules which
is used as a secondary modules system root directory. This way all the
GateIn libs are nicely seperated from those that come out-of-the-box with
AS7.
In the end visibility is established in such a way that no other changes
to GateIn libs were necessary except the mentioned WCI, and
exo.kernel.container.
I need to expand the README.txt with some of this info. Also AS7 support
in its initial form still needs some work and fine proofing ...
- m
On Tue, Oct 11, 2011 at 12:37 PM, Nicolas FILOTTO <
nicolas.filotto(a)exoplatform.com> wrote:
> How do you deploy all the jar files of Gatein (aka kernel, core, ws, jcr,
> and gatein jars)? Let's say that we have a vanilla JBoss AS 7 instance,
> what are the steps to deploy gatein successully
>
> I still need to know the target version and the deadline
>
>
> On Mon, Oct 10, 2011 at 10:16 PM, Marko Strukelj <
> marko.strukelj(a)gmail.com> wrote:
>
>>
>> WCI changes introduce a jboss7 module which is only used if explicitly
>> referenced in configuration - no impact on anything there. It also
>> introduces a deadlock patch in wci-wci which adds an extra synchronized
>> block. Without this patch a deadlock can occur (and often does occur on
>> JBoss AS7) when shutting down the server. No impact on performance or
>> memory usage.
>>
>>
>> Kernel changes are limited to exo.kernel.container module where in two
>> places there was a need to introduce the use of TCCL for classloading
>> instead of using a local ClassLoader.
>>
>> The new classloading uses ‘TCCL first’ approach with fallback to the old
>> behavior. The use of TCCL was necessary to allow GateIn services to
>> properly startup in an environment of isolated classloaders.
>>
>> I added a method:
>>
>> org.exoplatform.container.util.ContainerUtil.class:
>>
>>
>> public static Class loadClass(String type) throws
>> ClassNotFoundException
>> {
>> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
>> ClassLoader localCl = ContainerUtil.class.getClassLoader();
>> ClassLoader cl = tccl != null ? tccl : localCl;
>> try
>> {
>> return cl.loadClass(type);
>> }
>> catch (ClassNotFoundException e)
>> {
>> if (cl == tccl)
>> return localCl.loadClass(type);
>>
>> throw e;
>> }
>> }
>>
>> It is used in two places instead of Class.forName():
>>
>> - org/exoplatform/xml/object/XMLObject.java
>> - org/exoplatform/container/jmx/MX4JComponentAdapter.java
>>
>>
>>
>> It’s possible to imagine a scenario where due to deployment archive
>> packaging the same classes may be available through different .jars, .wars,
>> .ears. In such a situation the new code may load the class from portlet
>> application deployment archive, or portal extension deployment archive
>> instead of gatein portal’s lib/*.jar (gatein.ear/lib on JBossAS5 /
>> JBossAS6, $TOMCAT_HOME/lib on Tomcat).
>>
>>
>> Actually by making it local loader first with TCCL fallback there would
>> be no chance of any side effects. It may even be more appropriate as it
>> prevents the accidental override of GateIn's classes due to packaging.
>>
>> So I'll change the method to:
>>
>>
>> public static Class loadClass(String type) throws
>> ClassNotFoundException
>> {
>> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
>> ClassLoader localCl = ContainerUtil.class.getClassLoader();
>> try
>> {
>> return localCl.loadClass(type);
>> }
>> catch (ClassNotFoundException e)
>> {
>> if (tccl != null)
>> return tccl.loadClass(type);
>>
>> throw e;
>> }
>> }
>>
>>
>> I'll prepare a patch against exo.kernel.container trunk and attach it to
>> the issue.
>>
>>
>>
>> On Mon, Oct 10, 2011 at 4:20 PM, Nicolas FILOTTO <
>> nicolas.filotto(a)exoplatform.com> wrote:
>>
>>> Well, it depends on the expected fix version of this patch. Do you
>>> expect it in eXo JCR 1.14.x or in the future version? and What would be the
>>> deadline?
>>>
>>> Anyway I know that Marko is very good and has a good knowledge of the
>>> kernel, however I still can't apply it blindly, I need to double check
it
>>> to ensure that we will have no regression with it, so for me it is a real
>>> task that has to be planned. Thus I need your answers first to know when it
>>> can be planned according to your needs and expectations and ours.
>>>
>>> NB: To be able to validate it, I will need a complete overview of what
>>> has been done not only at kernel level but even at GateIn level. Is it
>>> possible to describe a little bit all the patches that you proposed?
>>>
>>>
>>> On Mon, Oct 10, 2011 at 1:16 PM, Boleslaw Dawidowicz <
>>> boleslaw.dawidowicz(a)gmail.com> wrote:
>>>
>>>> Nicolas,
>>>>
>>>> Julien told me you will be decision person to accept such patch into
>>>> the kernel. Marko can apply details about the context of those changes
if
>>>> needed.
>>>>
>>>> Bolek
>>>>
>>>>
>>>> On Oct 6, 2011, at 8:01 PM, Marko Strukelj wrote:
>>>>
>>>> I had to do some classloading and logging changes for
>>>> exo.kernel.container to work nicely on JBoss AS7.
>>>>
>>>> I'd like to get these changes from my sandbox gatein-as7 branch to
>>>> exo.kernel.container trunk.
>>>>
>>>> Here's the diff (effectively against exo-jcr/kernel/tags/
>>>> 2.3.0.GA/exo.kernel.container/src):
>>>>
>>>> svn diff -r 7504:7557
>>>>
http://anonsvn.jboss.org/repos/gatein/sandbox/as7_support/branches/gatein...
>>>>
>>>> And here's the JIRA issue for it:
>>>> https://issues.jboss.org/browse/EXOJCR-1580
>>>>
>>>>
>>>> - marko
>>>> _______________________________________________
>>>> gatein-dev mailing list
>>>> gatein-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>>
>>>>
>>>>
>>>
>>
>
7:34 a.m.
On Fri, Nov 4, 2011 at 10:24 PM, Nicolas FILOTTO <
nicolas.filotto(a)exoplatform.com> wrote:
FYI, I worked a little bit on
https://issues.jboss.org/browse/EXOJCR-1580and proposed a set of patches for it (as you
can see there are a lot of
changes). In my patches, I added the support of jboss.server.config.dir
thanks to it, you have no need to set the exo.conf.dir only the
exo.conf.dir.name is enough. In the configuration.properties the
variables gatein.jcr.workspace.system and gatein.jcr.workspace.default are
missing which cause https://issues.jboss.org/browse/GTNPORTAL-2258. I
guess you know it already but the dependency management
I've noticed some problems a few days ago when updating trunk, and tracked
it down to changes in files that are patched (overwritten) during as7
packaging. configuration.properties was among them. Didn't get to
committing the fixes yet.
is hard coded so I had to rebuild the class
GateInExtensionConfiguration
any time I had to add or remove an ear or a war otherwise I had errors at
startup of type:
Subsystem configuration in standalone.xml for 'gatein' subsystem should
contain a list of deployment archives that together form GateIn deployment.
15:23:55,271 INFO [org.jboss.as.server.controller]
(DeploymentScanner-threads - 2) Deployment of "gatein-sample-skin.war" was
rolled back with failure message {"Services with missing/unavailable
dependencies" =>
["jboss.deployment.unit.\"gatein-sample-skin.war\".CONFIGURE_MODULE
missing
[ jboss.module.information.service.\"deployment.gatein.ear\".main,
jboss.module.information.service.\"deployment.gatein-sample-portal.ear\".main,
jboss.module.information.service.\"deployment.gatein-sample-extension.ear\".main
]"]}
What a time wasted trying to figure out why it did not work even if I
modified the config file standalone.xml? Don't hesitate to warn me next
time :-(
Sorry to hear that. I wasn't aware of this problem. I'll have to take a
closer look into why changing standalone.xml would not override the default
(hardcoded) list.
I also noticed that when we logout we get the following stacktrace
9:29:20,864 ERROR
[exo.core.component.security.core.JbossLoginModule.class]
(http--127.0.0.1-8080-1) Could not perform JBoss security manager cache
eviction: javax.management.InstanceNotFoundException:
jboss.security:service=JaasSecurityManager
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094)
[:1.6.0_26]
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833)
[:1.6.0_26]
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
[:1.6.0_26]
at
org.exoplatform.services.security.j2ee.JbossLoginModule.logout(JbossLoginModule.java:120)
[exo.core.component.security.core-2.4.4-GA-SNAPSHOT.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_26]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
[:1.6.0_26]
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
[:1.6.0_26]
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
[:1.6.0_26]
at java.security.AccessController.doPrivileged(Native Method)
[:1.6.0_26]
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
[:1.6.0_26]
at
javax.security.auth.login.LoginContext.logout(LoginContext.java:629)
[:1.6.0_26]
at
org.jboss.security.authentication.JBossCachedAuthenticationManager$DomainInfo.logout(JBossCachedAuthenticationManager.java:513)
[picketbox-infinispan-4.0.1.jar:4.0.1]
at
org.jboss.as.security.plugins.DefaultAuthenticationCacheFactory$1.remove(DefaultAuthenticationCacheFactory.java:57)
at
org.jboss.as.security.plugins.DefaultAuthenticationCacheFactory$1.remove(DefaultAuthenticationCacheFactory.java:48)
at
org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache(JBossCachedAuthenticationManager.java:183)
[picketbox-infinispan-4.0.1.jar:4.0.1]
at
org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache(JBossCachedAuthenticationManager.java:58)
[picketbox-infinispan-4.0.1.jar:4.0.1]
at
org.jboss.as.web.security.JBossGenericPrincipal.logout(JBossGenericPrincipal.java:93)
[jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at org.apache.catalina.connector.Request.logout(Request.java:3262)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.connector.RequestFacade.logout(RequestFacade.java:1092)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.gatein.wci.jboss.JB7ServletContainerContext.logout(JB7ServletContainerContext.java:151)
[wci-jboss7-2.1.0-Beta07-AS7-Beta01.jar:2.1.0-Beta07-AS7-Beta01]
at
org.gatein.wci.impl.DefaultServletContainer.logout(DefaultServletContainer.java:117)
[wci-wci-2.1.0-Beta07-AS7-Beta01.jar:2.1.0-Beta07-AS7-Beta01]
at
org.exoplatform.portal.application.PortalLogoutLifecycle.onEndRequest(PortalLogoutLifecycle.java:60)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalLogoutLifecycle.onEndRequest(PortalLogoutLifecycle.java:37)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalRequestHandler.processRequest(PortalRequestHandler.java:218)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalRequestHandler.execute(PortalRequestHandler.java:150)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.WebAppController.service(WebAppController.java:349)
[exo.portal.component.web.controller-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalController.onService(PortalController.java:127)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
[exo.kernel.container-2.3.4-GA-SNAPSHOT.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.sample.portal.web.SampleFilter.doFilter(SampleFilter.java:46)
[exo.portal.sample.portal.jar-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:106)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:80)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:79)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:116)
[exo.jcr.framework.web-1.14.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:73)
[exo.portal.component.web.security-3.2.0-M02-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
[exo.core.component.security.core-2.4.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
[exo.kernel.container-2.3.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:139)
[jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:388)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
[jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Yeah, I mentioned this issue during presentation, but it's not yet
mentioned in README.txt. It reminds me of
https://issues.jboss.org/browse/EXOJCR-1303 although it's not exactly the
same.
at
org.exoplatform.services.security.j2ee.JbossLoginModule.logout(JbossLoginModule.java:120)
expects 'jboss.security:service=JaasSecurityManager' mbean to exist but on
AS7 it obviously does not.
I've created https://issues.jboss.org/browse/EXOJCR-1619.
To finish, I also noticed that when I try to apply the sample skin on the
sample portal I got:
15:07:27,053 ERROR [portal:UIPortletLifecycle] (http--127.0.0.1-8080-1)
Portlet render threw an exception:
org.exoplatform.services.portletcontainer.PortletContainerException:
org.exoplatform.portal.config.NoSuchDataException: Can not find
6f1c00d1c0a801026e840613ffe92fd1
at
org.exoplatform.portal.webui.application.UIPortletLifecycle.processRender(UIPortletLifecycle.java:340)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.application.UIPortletLifecycle.processRender(UIPortletLifecycle.java:62)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:368)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:358)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at sun.reflect.GeneratedMethodAccessor154.invoke(Unknown Source)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
[groovy-all-1.7.6.jar:]
at UIPortal.run(UIPortal.gtmpl:18) at
org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:111)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:119)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.text.TemplateService.merge(TemplateService.java:117)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.renderTemplate(Lifecycle.java:125)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.processRender(Lifecycle.java:83)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.portal.UIPortalLifecycle.processRender(UIPortalLifecycle.java:41)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.portal.UIPortalLifecycle.processRender(UIPortalLifecycle.java:30)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponentDecorator.renderChildren(UIComponentDecorator.java:101)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_26]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
[groovy-all-1.7.6.jar:]
at UISiteBody.run(UISiteBody.gtmpl:27) at
org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:111)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:119)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.text.TemplateService.merge(TemplateService.java:117)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.renderTemplate(Lifecycle.java:125)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.processRender(Lifecycle.java:83)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:368)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:358)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_26]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
[groovy-all-1.7.6.jar:]
at UIContainer.run(UIContainer.gtmpl:49) at
org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:111)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:119)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.text.TemplateService.merge(TemplateService.java:117)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.renderTemplate(Lifecycle.java:125)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.processRender(Lifecycle.java:83)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponentDecorator$UIComponentDecoratorLifecycle.processRender(UIComponentDecorator.java:113)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponentDecorator$UIComponentDecoratorLifecycle.processRender(UIComponentDecorator.java:104)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:368)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:358)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_26]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
[groovy-all-1.7.6.jar:]
at UIWorkingWorkspace.run(UIWorkingWorkspace.gtmpl:12) at
org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:111)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:119)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.text.TemplateService.merge(TemplateService.java:117)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.renderTemplate(Lifecycle.java:125)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.processRender(Lifecycle.java:83)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:368)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIContainer.renderChildren(UIContainer.java:358)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIApplication.renderChildren(UIApplication.java:120)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_26]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_26]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
[groovy-all-1.7.6.jar:]
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
[groovy-all-1.7.6.jar:]
at
UIPortalApplicationChildren.run(UIPortalApplicationChildren.gtmpl:17) at
org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:111)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:119)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.groovyscript.text.TemplateService.merge(TemplateService.java:117)
[exo.portal.component.scripting-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.lifecycle.Lifecycle.renderTemplate(Lifecycle.java:125)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processRender(UIPortalApplicationLifecycle.java:142)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processRender(UIPortalApplicationLifecycle.java:105)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processRender(UIPortalApplicationLifecycle.java:37)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.webui.core.UIComponent.processRender(UIComponent.java:144)
[exo.portal.webui.framework-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.workspace.UIPortalApplication.processRender(UIPortalApplication.java:611)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalRequestHandler.processRequest(PortalRequestHandler.java:184)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalRequestHandler.execute(PortalRequestHandler.java:150)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.WebAppController.service(WebAppController.java:349)
[exo.portal.component.web.controller-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.application.PortalController.onService(PortalController.java:127)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
[exo.kernel.container-2.3.4-GA-SNAPSHOT.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.sample.portal.web.SampleFilter.doFilter(SampleFilter.java:46)
[exo.portal.sample.portal.jar-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:106)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:80)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:79)
[exo.portal.component.web.api-3.2.0-M02-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:116)
[exo.jcr.framework.web-1.14.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:73)
[exo.portal.component.web.security-3.2.0-M02-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
[exo.core.component.security.core-2.4.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
[exo.kernel.container-2.3.4-GA-SNAPSHOT.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:139)
[jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:388)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
[jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952)
[jbossweb-7.0.1.Final.jar:7.0.2.Final]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: org.exoplatform.portal.config.NoSuchDataException: Can not find
6f1c00d1c0a801026e840613ffe92fd1
at
org.exoplatform.portal.pom.config.POMSession.findCustomizationById(POMSession.java:214)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.tasks.PreferencesTask$Load.run(PreferencesTask.java:91)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.POMSession.execute(POMSession.java:405)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.ExecutorDispatcher.execute(ExecutorDispatcher.java:60)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.TaskExecutionDecorator.execute(TaskExecutionDecorator.java:38)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.cache.DataCache.read(DataCache.java:169)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.cache.DataCache.execute(DataCache.java:61)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.TaskExecutionDecorator.execute(TaskExecutionDecorator.java:38)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.cache.PortalNamesCache.execute(PortalNamesCache.java:79)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.POMSessionManager.execute(POMSessionManager.java:253)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.pom.config.POMDataStorage.load(POMDataStorage.java:176)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.config.DataStorageImpl.load(DataStorageImpl.java:111)
[exo.portal.component.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.application.ModelAdapter$1.getPortletContext(ModelAdapter.java:89)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.application.UIPortlet.getPortletContext(UIPortlet.java:993)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.application.UIPortlet.create(UIPortlet.java:829)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
at
org.exoplatform.portal.webui.application.UIPortletLifecycle.processRender(UIPortletLifecycle.java:212)
[exo.portal.webui.portal-3.2.0-M02-SNAPSHOT.jar:]
... 129 more
I tested applying sample skin before committing initial AS7 support to
trunk, and it worked without exceptions. I'll take a closer look after I
apply your proposed patched to kernel modules and get trunk and extension
to work with that.
Thanks for giving it a try and for your feedback.
On Tue, Oct 11, 2011 at 12:54 PM, Marko Strukelj <marko.strukelj(a)gmail.com
> wrote:
> Easiest way to deploy to AS7 is to follow the instructions:
>
>
> http://anonsvn.jboss.org/repos/gatein/portal/trunk/packaging/jboss-as7/RE...
>
> I think you're most interested in how classpath works. AS7 uses a module
> system. There's no traditional classpath as a list of directories/jars any
> more. Instead there are modules with cross dependencies on other modules.
> Classpath becomes like a tree branching out from each submodule and cross
> folding back onto itself with cross-dependencies (that go out from any to
> any module - so it's not really a tree, but a graph). Each module is
> represented by one classloader. Class lookup always starts at one module,
> looks locally at what that module provides, then if not found - tries
> dependency modules - where each one repeats the lookup procedure. In effect
> - each module has its own 'classpath'.
>
> All gatein.ear/lib/*.jar have been moved to modules. Typically one .jar
> becomes one module with a list of dependencies on other modules (like maven
> artifact for example). But to simplify things for starters, I put many jars
> into the main module that represents gatein libraries. Most can be found in
> gatein/modules/org/gatein/lib/main. The plan is to more fine-grain these in
> the future - exo-jcr could become it's own module, or exo-jcr-kernel,
> exo-jcr-core ... could become its own module. Or these could be just
> aggregation modules to provide acces to several finegrained modules at once
> - each jar as its own module.
>
> All the GateIn libs are under $JBOSS_HOME/standalone/gatein/modules which
> is used as a secondary modules system root directory. This way all the
> GateIn libs are nicely seperated from those that come out-of-the-box with
> AS7.
>
> In the end visibility is established in such a way that no other changes
> to GateIn libs were necessary except the mentioned WCI, and
> exo.kernel.container.
>
> I need to expand the README.txt with some of this info. Also AS7 support
> in its initial form still needs some work and fine proofing ...
>
> - m
>
>
> On Tue, Oct 11, 2011 at 12:37 PM, Nicolas FILOTTO <
> nicolas.filotto(a)exoplatform.com> wrote:
>
>> How do you deploy all the jar files of Gatein (aka kernel, core, ws,
>> jcr, and gatein jars)? Let's say that we have a vanilla JBoss AS 7
>> instance, what are the steps to deploy gatein successully
>>
>> I still need to know the target version and the deadline
>>
>>
>> On Mon, Oct 10, 2011 at 10:16 PM, Marko Strukelj <
>> marko.strukelj(a)gmail.com> wrote:
>>
>>>
>>> WCI changes introduce a jboss7 module which is only used if explicitly
>>> referenced in configuration - no impact on anything there. It also
>>> introduces a deadlock patch in wci-wci which adds an extra synchronized
>>> block. Without this patch a deadlock can occur (and often does occur on
>>> JBoss AS7) when shutting down the server. No impact on performance or
>>> memory usage.
>>>
>>>
>>> Kernel changes are limited to exo.kernel.container module where in two
>>> places there was a need to introduce the use of TCCL for classloading
>>> instead of using a local ClassLoader.
>>>
>>> The new classloading uses ‘TCCL first’ approach with fallback to the
>>> old behavior. The use of TCCL was necessary to allow GateIn services to
>>> properly startup in an environment of isolated classloaders.
>>>
>>> I added a method:
>>>
>>> org.exoplatform.container.util.ContainerUtil.class:
>>>
>>>
>>> public static Class loadClass(String type) throws
>>> ClassNotFoundException
>>> {
>>> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
>>> ClassLoader localCl = ContainerUtil.class.getClassLoader();
>>> ClassLoader cl = tccl != null ? tccl : localCl;
>>> try
>>> {
>>> return cl.loadClass(type);
>>> }
>>> catch (ClassNotFoundException e)
>>> {
>>> if (cl == tccl)
>>> return localCl.loadClass(type);
>>>
>>> throw e;
>>> }
>>> }
>>>
>>> It is used in two places instead of Class.forName():
>>>
>>> - org/exoplatform/xml/object/XMLObject.java
>>> - org/exoplatform/container/jmx/MX4JComponentAdapter.java
>>>
>>>
>>>
>>> It’s possible to imagine a scenario where due to deployment archive
>>> packaging the same classes may be available through different .jars, .wars,
>>> .ears. In such a situation the new code may load the class from portlet
>>> application deployment archive, or portal extension deployment archive
>>> instead of gatein portal’s lib/*.jar (gatein.ear/lib on JBossAS5 /
>>> JBossAS6, $TOMCAT_HOME/lib on Tomcat).
>>>
>>>
>>> Actually by making it local loader first with TCCL fallback there would
>>> be no chance of any side effects. It may even be more appropriate as it
>>> prevents the accidental override of GateIn's classes due to packaging.
>>>
>>> So I'll change the method to:
>>>
>>>
>>> public static Class loadClass(String type) throws
>>> ClassNotFoundException
>>> {
>>> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
>>> ClassLoader localCl = ContainerUtil.class.getClassLoader();
>>> try
>>> {
>>> return localCl.loadClass(type);
>>> }
>>> catch (ClassNotFoundException e)
>>> {
>>> if (tccl != null)
>>> return tccl.loadClass(type);
>>>
>>> throw e;
>>> }
>>> }
>>>
>>>
>>> I'll prepare a patch against exo.kernel.container trunk and attach it
>>> to the issue.
>>>
>>>
>>>
>>> On Mon, Oct 10, 2011 at 4:20 PM, Nicolas FILOTTO <
>>> nicolas.filotto(a)exoplatform.com> wrote:
>>>
>>>> Well, it depends on the expected fix version of this patch. Do you
>>>> expect it in eXo JCR 1.14.x or in the future version? and What would be
the
>>>> deadline?
>>>>
>>>> Anyway I know that Marko is very good and has a good knowledge of the
>>>> kernel, however I still can't apply it blindly, I need to double
check it
>>>> to ensure that we will have no regression with it, so for me it is a
real
>>>> task that has to be planned. Thus I need your answers first to know when
it
>>>> can be planned according to your needs and expectations and ours.
>>>>
>>>> NB: To be able to validate it, I will need a complete overview of what
>>>> has been done not only at kernel level but even at GateIn level. Is it
>>>> possible to describe a little bit all the patches that you proposed?
>>>>
>>>>
>>>> On Mon, Oct 10, 2011 at 1:16 PM, Boleslaw Dawidowicz <
>>>> boleslaw.dawidowicz(a)gmail.com> wrote:
>>>>
>>>>> Nicolas,
>>>>>
>>>>> Julien told me you will be decision person to accept such patch into
>>>>> the kernel. Marko can apply details about the context of those
changes if
>>>>> needed.
>>>>>
>>>>> Bolek
>>>>>
>>>>>
>>>>> On Oct 6, 2011, at 8:01 PM, Marko Strukelj wrote:
>>>>>
>>>>> I had to do some classloading and logging changes for
>>>>> exo.kernel.container to work nicely on JBoss AS7.
>>>>>
>>>>> I'd like to get these changes from my sandbox gatein-as7 branch
to
>>>>> exo.kernel.container trunk.
>>>>>
>>>>> Here's the diff (effectively against exo-jcr/kernel/tags/
>>>>> 2.3.0.GA/exo.kernel.container/src):
>>>>>
>>>>> svn diff -r 7504:7557
>>>>>
http://anonsvn.jboss.org/repos/gatein/sandbox/as7_support/branches/gatein...
>>>>>
>>>>> And here's the JIRA issue for it:
>>>>> https://issues.jboss.org/browse/EXOJCR-1580
>>>>>
>>>>>
>>>>> - marko
>>>>> _______________________________________________
>>>>> gatein-dev mailing list
>>>>> gatein-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
8:46 a.m.
About https://issues.jboss.org/browse/EXOJCR-1619, to avoid any
misunderstanding, can you ask internally how we can flush cached
credentials (as described here
http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html_single/i...)
on JBoss AS 7? Maybe it is not needed anymore? Or do you expect that I ask
the question in the forum of JBoss AS 7?
11:26 a.m.
I'm looking into it. I found a service that does that - but it exists at
MSC level, so it needs to be accessed via JBoss AS7 proprietary API.
http://community.jboss.org/thread/174545
Bolek, you can prod Anil to comment on this post.
On Mon, Nov 7, 2011 at 3:46 PM, Nicolas FILOTTO <
nicolas.filotto(a)exoplatform.com> wrote:
About https://issues.jboss.org/browse/EXOJCR-1619, to avoid any
misunderstanding, can you ask internally how we can flush cached
credentials (as described here
http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html_single/i...)
on JBoss AS 7? Maybe it is not needed anymore? Or do you expect that I ask
the question in the forum of JBoss AS 7?
7:41 a.m.
Asked him for suggestions.
Bolek
On Nov 7, 2011, at 6:26 PM, Marko Strukelj wrote:
I'm looking into it. I found a service that does that - but it
exists at MSC level, so it needs to be accessed via JBoss AS7 proprietary API.
http://community.jboss.org/thread/174545
Bolek, you can prod Anil to comment on this post.
On Mon, Nov 7, 2011 at 3:46 PM, Nicolas FILOTTO <nicolas.filotto(a)exoplatform.com>
wrote:
About https://issues.jboss.org/browse/EXOJCR-1619, to avoid any misunderstanding, can you
ask internally how we can flush cached credentials (as described here
http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html_single/i...)
on JBoss AS 7? Maybe it is not needed anymore? Or do you expect that I ask the question in
the forum of JBoss AS 7?
10:03 a.m.
Re: How to perform security cache evictioncreated by Anil
Saldhana<http://community.jboss.org/people/anil.saldhana>
in *AS7 Users* - View the full
discussion<http://community.jboss.org/message/635560#635560>
------------------------------
Each cache entry has a time to live. When that expires, it is evicted.
Overall the cache itself has a default timeout.
You only care about cache eviction in situations where in the web
application has logged the user out but he is not yet evicted in the
authenticaiton cache. It is a border condition where in the user password
has changed or you need to get newer roles for the user.
Reply to this message by going to
Community<http://community.jboss.org/message/635560#635560>
Start a new discussion in AS7 Users at
Community<http://community.jboss.org/choose-container!input.jspa?conte...
On Tue, Nov 8, 2011 at 2:41 PM, Boleslaw Dawidowicz <
boleslaw.dawidowicz(a)gmail.com> wrote:
Asked him for suggestions.
Bolek
On Nov 7, 2011, at 6:26 PM, Marko Strukelj wrote:
I'm looking into it. I found a service that does that - but it exists at
MSC level, so it needs to be accessed via JBoss AS7 proprietary API.
http://community.jboss.org/thread/174545
Bolek, you can prod Anil to comment on this post.
On Mon, Nov 7, 2011 at 3:46 PM, Nicolas FILOTTO <
nicolas.filotto(a)exoplatform.com> wrote:
> About https://issues.jboss.org/browse/EXOJCR-1619, to avoid any
> misunderstanding, can you ask internally how we can flush cached
> credentials (as described here
>
http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html_single/i...)
> on JBoss AS 7? Maybe it is not needed anymore? Or do you expect that I ask
> the question in the forum of JBoss AS 7?
>
10:13 a.m.
I hope the TTL is >= session timeout otherwise we will face weird bugs.
More generally, I hope that the lifecycle of the cache entry corresponding
to a cached credentials can have the same lifecycle than the http session,
otherwise we will face situations where the credentials are not cached
anymore and the session is still alive and vice and versa, which will cause
unexpected bugs
On Tue, Nov 8, 2011 at 4:03 PM, Marko Strukelj <marko.strukelj(a)gmail.com>wrote:
Re: How to perform security cache evictioncreated by Anil
Saldhana<http://community.jboss.org/people/anil.saldhana>
in *AS7 Users* - View the full
discussion<http://community.jboss.org/message/635560#635560>
------------------------------
Each cache entry has a time to live. When that expires, it is evicted.
Overall the cache itself has a default timeout.
You only care about cache eviction in situations where in the web
application has logged the user out but he is not yet evicted in the
authenticaiton cache. It is a border condition where in the user password
has changed or you need to get newer roles for the user.
Reply to this message by going to
Community<http://community.jboss.org/message/635560#635560>
Start a new discussion in AS7 Users at
Community<http://community.jboss.org/choose-container%21input.jspa?con...
On Tue, Nov 8, 2011 at 2:41 PM, Boleslaw Dawidowicz <
boleslaw.dawidowicz(a)gmail.com> wrote:
> Asked him for suggestions.
>
> Bolek
>
> On Nov 7, 2011, at 6:26 PM, Marko Strukelj wrote:
>
> I'm looking into it. I found a service that does that - but it exists at
> MSC level, so it needs to be accessed via JBoss AS7 proprietary API.
>
> http://community.jboss.org/thread/174545
>
> Bolek, you can prod Anil to comment on this post.
>
>
> On Mon, Nov 7, 2011 at 3:46 PM, Nicolas FILOTTO <
> nicolas.filotto(a)exoplatform.com> wrote:
>
>> About https://issues.jboss.org/browse/EXOJCR-1619, to avoid any
>> misunderstanding, can you ask internally how we can flush cached
>> credentials (as described here
>>
http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html_single/i...)
>> on JBoss AS 7? Maybe it is not needed anymore? Or do you expect that I ask
>> the question in the forum of JBoss AS 7?
>>
>
>
>
4773
days inactive
4806
days old
16 comments
4 participants
participants (4)
-
Boleslaw Dawidowicz -
Marko Strukelj -
Nicolas FILOTTO -
Thomas Heute