GateIn portal component test infrastructure
by Julien Viet
I worked on starting to create an infrastructure for making the
various unit test of GateIn easier to configure. Actually it is an
attempt to fix several points that hurts us today:
1/ control the services that are used during the unit test : we had an
issue a couple of weeks ago by a service declared in core component
(in exo-jcr repo) that was declaring an hibernate service shadowing in
some unit test the same service declared in GateIn. While it was fixed
in core component (requiring a release only for that purpose), the
fact to import all the configuration is pretty much an issue for
several reasons (dependencies are not controlled, boot time is impacted)
2/ avoid to repeat the configuration for testing over and over. We
want to achieve reusability and minimality when we write unit test for
a module. For instance if a module requires a JCR repo and the
organization service, we want:
- not declare them locally unless a special configuration is required
- share that configuration between module unit tests
3/ fix the absolute path required for several unit tests (not now,
when effort will be achieved)
For that matter I started the effort by providing a minimal set of
code to reuse in unit test (namely the AbstractGateInTest class) that
works by filtering the configuration loaded from the classpath by
removing all configuration except the explicitly defined
configuration. Configured is explicitly defined by annotating the unit
test either with shared reusable configuration or with custom
configuration found in the classpath (usually located in the test /
resources of the module).
The initial reusable module is the JCR module that when booted
provides a repository with a unique workspace called "portal-test".
For now only one module uses it and that is the component/common
module. For other modules (like component/portal or component/
application-registry), there is a need for doing an organization
module and that is not yet done.
Note that each test component is a standalone maven module in order to
express the classpath dependencies of the test component.
I started to write things in the wiki on this page http://www.jboss.org/community/wiki/GateInPortalTestComponent
I hope we can complete that effort soon and achieve the following:
1/ rationalized configuration
2/ not reuse portal configuration
3/ no more absolute path needed
4/ fast boot time for unit test providing a better productivity for
developers
cheers
Julien
15 years, 12 months
An issue is related to WSRP deploying with Tomcat
by Trong Tran
Hi,
Currently we have an exception when starting up GateIn beta05 ( trunk ) in
Tomcat only. Unfortunately, I have downloaded to try the released GateIn
beta04 tomcat binaries which is published
http://sourceforge.net/projects/jboss/files/GateIn/Portal/3.0.0-Beta04/ and
i have got the same problem.
In the log, it say that there are missing classes of WRSP integration like
following :
*java.lang.ClassNotFoundException:
org.gatein.portal.wsrp.ExoKernelIntegration
at java.lang.ClassLoader.findClass(ClassLoader.java:437)
at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
*
Yes, we can realize the miss of WRSP artifacts when deploying GateIn with
Tomcat. indeed, we have deactivated the WSRP deployment on Tomcat for more
than two months ago GTNPORTAL-32.
i have tried to remove the following two lines in the Tomcat.js file in the
gatein/tools/packager project and the Tomcat has worked properly for me
* //GTNPORTAL-32 No WSRP on tomcat yet
product.removeDependency(new Project("org.exoplatform.portal",
"exo.portal.component.wsrp", "jar", product.serverPluginVersion ));
product.removeDependencyByGroupId("org.gatein.wsrp");
*
so should it be activated back ?
--
Tran The Trong
eXo Platform SAS
16 years
Update of JCR to 1.12.0-Beta05
by Julien Viet
I started to update GateIn to JCR 1.12.5-Beta05.
That required a few fixes in Chromattic that I just finished (plus
many things in GateIn locally).
I will release chromattic next beta tomorrow and then update GateIn to
JCR + Chromattic.
The next JCR version has in the kernel new features that I have added
for making the configuration more flexible and also the component
request life cycle management more correct.
cheers
Julien
16 years
Commit + JIRA... nothing less
by Nicolas Filotto
Hi Guys,
I've seen several commits without any link to a specific JIRA in the EXOJCR
project, it is an eXo mandatory rule that applies to all exo developers so
it should apply to you too. So please avoid it in the future, since it is
hard for us to understand what you did and for what purpose without any
trace such as a JIRA. Moreover, we won't be able to retrieve easily what it
has been done in a given release of JCR without this.
BR,
--
Nicolas Filotto
JCR Product Manager
Project Manager
eXo Platform SAS
nicolas.filotto(a)exoplatform.com
+33 (0)6 31 32 92 19
16 years
Portlet Markup Headers
by Matt Wringe
I am trying to get portlet markup headers working with gatein. This
allows portlets to set content in the html head of the portal page. This
only works if the portlets are processed before the page gets generated,
which is currently not the case.
We can get around this by creating a preRender phase to the webui
lifecycle. This phase would generate the markup for the uicomponent and
store it. When the processRender phase occurs, it will just retrieve
this stored markup.
Adding a new phase to the lifecycle is going to require a bunch of
changes to webui.
I already have a simple proof of concept with a preRender phase that is
working with portlets to allow setting the html head.
Before I get too far with this, I would to know if anyone else has any
better ideas about how to handle this.
We could modify the html head using javascript that gets called when the
page is loaded. This will work and would be easy to implement, but seems
like a hack.
I looked into seeing if we could just modify how the UIPortalApplication
gets rendered so that we wouldn't need to touch the rest of the webui
lifecyle. We could do something like render the html body to a temporary
writer first, but this is a messy hack.
16 years
MC-integration
by Marko Strukelj
Hey,
I've addressed the two issues regarding mc-integration:
1) Separate mc-integration code in its own module, so that container module
has no dependencies on mc-kernel artifacts.
2) Add xml file configuration for marking certain components to use
mc-interception even though they are not marked as @InterceptMC
Quick starter doc is here:
http://anonsvn.jboss.org/repos/exo-jcr/kernel/branches/mc-int-branch/exo....
There are full instructions for checking out, building, packaging jboss or
tomcat for integration tests, and running the integration tests.
The AOP integration has some limitations:
"Because proxy mechanism is used to do AOP, there is a requirement that a
class to be AOP-ed needs to have a public or protected zero-args
constructor.
Service objects that make up exo-kernel and gatein mostly use constructor
based DI, and only have constructors that take some injected parameters. In
order to make these eligible for AOP, *we would have to make sure they all
have a protected zero-args constructor*."
Any added noop zero-args constructor (let's call it 'fake constructor')
would be there purely for technical reasons (proxy extends service
implementation type to keep type compatibility), and will only be invoked
during proxy object instantiation - when object state and semantics don't
matter. Proxy is a dummy object that delegates everything to the actual
service instance. Any other state that happens to be inherited by the proxy
instance is ignored, and unused.
"Also, when AOP is activated, field injection doesn't work even if it's
turned on. This is again a limitation of proxy mechanism and inability to
intercept set-field operations in java."
I'm still doing some code beautification - javadoc, some tests ...
Julien maybe take a look if you can find some additional suggestions about
the build or something else.
Cheers,
- marko
16 years
exo.kernel.component.ext.cache.impl.jboss.v3 testMultiThreading likes to fail
by Marko Strukelj
There's something fishy about the following test - it likes to fail when CPU
is on full or computer is stalling.
Run test org.exoplatform.services.cache.impl.jboss.TestAbstractExoCache
********************************************************
BEGIN TEST CASE
testMultiThreading
********************************************************
Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 18.631 sec
<<< FAILURE!
Running org.exoplatform.services.cache.impl.jboss.TestExoCacheCreator
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec
Running org.exoplatform.services.cache.impl.jboss.TestExoCacheConfig
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.617 sec
Running org.exoplatform.services.cache.impl.jboss.TestLRUCache
log4j:WARN No appenders could be found for logger
(org.exoplatform.container.RootContainer).
log4j:WARN Please initialize the log4j system properly.
Run test org.exoplatform.services.cache.impl.jboss.TestLRUCache
Surefire report:
-------------------------------------------------------------------------------
Test set: org.exoplatform.services.cache.impl.jboss.TestAbstractExoCache
-------------------------------------------------------------------------------
Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 18.626 sec
<<< FAILURE!
testMultiThreading(org.exoplatform.services.cache.impl.jboss.TestAbstractExoCache)
Time elapsed: 11.333 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<100> but was:<74>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:280)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:198)
at junit.framework.Assert.assertEquals(Assert.java:204)
at
org.exoplatform.services.cache.impl.jboss.TestAbstractExoCache.testMultiThreading(TestAbstractExoCache.java:518)
Cheers,
- marko
16 years
Kernel-cache 2.2.0-Beta05-SNAPSHOT causing portal build failure
by Marko Strukelj
With the latest kernel-caching looks like the contract was changed by adding
a few 'throws Exception' declarations on methods.
Now portal build fails for me. To get the build to pass I had to catch the
exceptions in a few places (exception handling not necessarily appropriate):
Index:
component/portal/src/main/java/org/exoplatform/portal/pom/config/POMSession.java
===================================================================
---
component/portal/src/main/java/org/exoplatform/portal/pom/config/POMSession.java
(revision 981)
+++
component/portal/src/main/java/org/exoplatform/portal/pom/config/POMSession.java
(working copy)
@@ -96,7 +96,14 @@
{
throw new IllegalStateException("Cannot read object in shared
cache from a modified session");
}
- return mgr.cache.get(key);
+ try
+ {
+ return mgr.cache.get(key);
+ }
+ catch (Exception e)
+ {
+ throw new RuntimeException("Exception while getting from cache: ",
e);
+ }
}
public void putInCache(Serializable key, Object value)
@@ -105,7 +112,14 @@
{
throw new IllegalStateException("Cannot put object in shared cache
from a modified session");
}
- mgr.cache.put(key, value);
+ try
+ {
+ mgr.cache.put(key, value);
+ }
+ catch (Exception e)
+ {
+ throw new RuntimeException("Exception while putting into cache: ",
e);
+ }
}
public void scheduleForEviction(Serializable key)
@@ -407,7 +421,13 @@
{
for (Serializable key : staleKeys)
{
- mgr.cache.remove(key);
+ try
+ {
+ mgr.cache.remove(key);
+ }
+ catch (Exception ignored)
+ {
+ }
}
}
}
Index:
component/portal/src/main/java/org/exoplatform/portal/pom/config/POMSessionManager.java
===================================================================
---
component/portal/src/main/java/org/exoplatform/portal/pom/config/POMSessionManager.java
(revision 981)
+++
component/portal/src/main/java/org/exoplatform/portal/pom/config/POMSessionManager.java
(working copy)
@@ -95,7 +95,14 @@
public void clearCache()
{
- cache.clearCache();
+ try
+ {
+ cache.clearCache();
+ }
+ catch (Exception e)
+ {
+ throw new RuntimeException("Failed to clear cache: ", e);
+ }
}
public MOPService getPOMService()
Index:
component/resources/src/main/java/org/exoplatform/services/resources/impl/BaseResourceBundleService.java
===================================================================
---
component/resources/src/main/java/org/exoplatform/services/resources/impl/BaseResourceBundleService.java
(revision 981)
+++
component/resources/src/main/java/org/exoplatform/services/resources/impl/BaseResourceBundleService.java
(working copy)
@@ -266,7 +266,14 @@
*/
protected final void invalidate(String name)
{
- cache_.remove(name);
+ try
+ {
+ cache_.remove(name);
+ }
+ catch (Exception ex)
+ {
+ log_.warn("Failed to invalidate entry: " + name, ex);
+ }
}
public ResourceBundle getResourceBundle(String name, Locale locale,
ClassLoader cl)
Cheers,
- marko
16 years
