Spring cleaning
by Thomas Heute
Autumn is the Spring of Winter.
I don't think we use the server/jboss/patch thing that is made to create
a 'sar'. It's probably not even working as I guess nobody tried it.
I would like to remove it, is that a problem for anyone ?
Thanks,
Thomas.
15 years, 10 months
Modification to the build
by Thomas Heute
As discussed earlier, now that the tests are run on all 'mvn install' it
requires an additional parameter.
While this is a constraint that will be removed in the future, currently
one need to set:
exo.projects.directory.src and the build enforce the existence of
some directories.
I changed it slightly (and about to commit) so that anyone who checkout:
http://anonsvn.jboss.org/repos/gatein/portal/trunk
doesn't have to create directories to match what was required.
It means that *if you defined exo.projects.directory.src before you now
need to change it to add /gatein/portal/trunk at the end*.
Said differently, Maven was checking for the existence of:
<file>${exo.projects.directory.src}/gatein/portal/trunk/web/portal/src/main/webapp</file>
and is now checking for:
<file>${exo.projects.directory.src}/web/portal/src/main/webapp</file>
I've tested locally and it works just fine, I may not be aware of other
use cases that require that parameter so please let me know if you face
an issue.
I've updated the readme.
Thanks,
Thomas.
15 years, 10 months
MC-kernel integration
by Marko Strukelj
I've committed mc-integration code to exo-kernel mc-int branch. Here are the
instructions how to build, and deploy, and a walk through the demo.
What exactly does the integration do? It makes it possible to inject
components deployed as MC beans into components deployed as exo-kernel
services. There is an annotation @InterceptMC, that you annotate your
service component with, to turn on mc integration for that component. MC
integration only works in JBossAS, so any components that rely on it have to
provide alternative injection mechanisms when deployed in Tomcat or
somewhere else (i.e. using exo-kernel configuration for injections, or
wiring up components manually - hardcoded in a component that does just
that).
*Building*
This used to be a multistep process right up until today (there have
supposedly been some problems with jboss snapshot repository - artifacts
missing even though they should be there). But now all external SNAPSHOT
dependencies have been upgraded to release versions, as some releases were
done yesterday, so it's now a piece-of-cake to build.
svn co http://anonsvn.jboss.org/repos/exo-jcr/kernel/branches/mc-int-branch/exo-...
cd exo-kernel-mc-int-branch
mvn install
*Deploying to GateIn-3.0.0-Beta02 JBoss*
You can use gatein/portal/trunk/packaging/pkg to deploy exo-kernel jars:
mvn -Ppkg-jboss package
There are additional jars required though ...
These are instructions for deploying manually - as automation of the
deployment is not done yet.
Unix:
#Set env constants we need
export JBOSS_HOME=<path_to_jboss-gatein-3.0.0-Beta02>
export GATEIN_LIB=$JBOSS_HOME/server/default/deploy/gatein.ear/lib
#Deploy exo-kernel jars - you can do this with packaging/pkg as well
cp
exo.kernel.container/target/exo.kernel.container-2.2.0-Beta04-SNAPSHOT.jar
$GATEIN_LIB
cp exo.kernel.commons/target/exo.kernel.commons-2.2.0-Beta04-SNAPSHOT.jar
$GATEIN_LIB
cp
exo.kernel.component.cache/target/exo.kernel.component.cache-2.2.0-Beta04-SNAPSHOT.jar
$GATEIN_LIB
cp
exo.kernel.component.command/target/exo.kernel.component.command-2.2.0-Beta04-SNAPSHOT.jar
$GATEIN_LIB
cp
exo.kernel.component.common/target/exo.kernel.component.common-2.2.0-Beta04-SNAPSHOT.jar
$GATEIN_LIB
cp
exo.kernel.component.remote/target/exo.kernel.component.remote-2.2.0-Beta04-SNAPSHOT.jar
$GATEIN_LIB
#Delete any previous versions:
rm $GATEIN_LIB/exo.kernel.*-2.2.0-Beta02.jar
#Copy extra jars needed for MC integration - this part will need automation,
so that these are automatically included when building the jboss package
cp
org.jboss.mc-kernel-extras/target/mc-kernel-extras-2.2.0-Beta04-SNAPSHOT.jar
$GATEIN_LIB
cp
~/.m2/repository/org/jboss/mc-int/jboss-mc-int-common/2.2.0.Alpha2/jboss-mc-int-common-2.2.0.Alpha2.jar
$GATEIN_LIB
cp
~/.m2/repository/org/jboss/mc-int/jboss-mc-int-servlet/2.2.0.Alpha2/jboss-mc-int-servlet-2.2.0.Alpha2.jar
$GATEIN_LIB
Windows:
@rem Set env constants we need
set JBOSS_HOME=<path_to_jboss-gatein-3.0.0-Beta02>
set GATEIN_LIB=%JBOSS_HOME%\server\default\deploy\gatein.ear\lib
@rem Deploy exo-kernel jars - you can do this with packaging\pkg
copy /Y
exo.kernel.container\target\exo.kernel.container-2.2.0-Beta04-SNAPSHOT.jar
%GATEIN_LIB%
copy /Y
exo.kernel.commons\target\exo.kernel.commons-2.2.0-Beta04-SNAPSHOT.jar
%GATEIN_LIB%
copy /Y
exo.kernel.component.cache\target\exo.kernel.component.cache-2.2.0-Beta04-SNAPSHOT.jar
%GATEIN_LIB%
copy /Y
exo.kernel.component.command\target\exo.kernel.component.command-2.2.0-Beta04-SNAPSHOT.jar
%GATEIN_LIB%
copy /Y
exo.kernel.component.common\target\exo.kernel.component.common-2.2.0-Beta04-SNAPSHOT.jar
%GATEIN_LIB%
copy /Y
exo.kernel.component.remote\target\exo.kernel.component.remote-2.2.0-Beta04-SNAPSHOT.jar
%GATEIN_LIB%
@rem Delete any previous versions:
del %GATEIN_LIB%\exo.kernel.*-2.2.0-Beta02.jar
@rem Copy extra jars needed for MC integration - this part will need
automation, so that these are automatically included when building the jboss
package
copy /Y
org.jboss.mc-kernel-extras\target\mc-kernel-extras-2.2.0-Beta04-SNAPSHOT.jar
%GATEIN_LIB%
copy /Y
%HOMEPATH%\.m2\repository\org\jboss\mc-int\jboss-mc-int-common\2.2.0.Alpha2\jboss-mc-int-common-2.2.0.Alpha2.jar
%GATEIN_LIB%
copy /Y
%HOMEPATH%\.m2\repository\org\jboss\mc-int\jboss-mc-int-servlet\2.2.0.Alpha2\jboss-mc-int-servlet-2.2.0.Alpha2.jar
%GATEIN_LIB%
*Deploying to GateIn-3.0.0-Beta02 Tomcat*
There is no support for MC integration in Tomcat deployment. No additional
jars need to be deployed. Integration code is factored in such a way that in
the absence of correct environment (existence of certain classes) it remains
dormant - no additional classes are required.
If a component annotated with @InterceptMC is deployed, a warning is logged,
but the component will be deployed anyway - without injections being
applied.
*MC Integration Demos*
Demos are available in submodule exo.kernel.demos.
*
*
*Build and deploy*
mvn install
cp
exo.kernel.demos/mc-injection/target/exo.mc-int.mc-injection-2.2.0-Beta04-SNAPSHOT.jar
$JBOSS_HOME/server/default/deploy/
(On Windows:
copy /Y
exo.kernel.demos\mc-injection\target\exo.mc-int.mc-injection-2.2.0-Beta04-SNAPSHOT.jar
%JBOSS_HOME%\server\default\deploy\
)
There's one demo at the moment ...
*mc-injection demo*
This demo demonstrates POJO creation via exo-kernel and use of MC injection
annotations to have some services injected into our exo-kernel-deployed POJO
by MC.
We have two service objects - InjectedBean and InjectingBean, packaged in a
single jar.
InjectedBeans gets instantiated by JBossAS deployer via
META-INF/jboss-beans.xml. InjectingBean on the other hand gets instantiated
by exo-kernel via conf/configuration.xml
Exo-kernel knows nothing about InjectedBean, but because InjectingBean is
annotated with @InterceptMC it is processed by MC integration logic when
instantiated by exo-kernel. The processing pipes it through MC-kernel logic
which processes MC-kernel injection annotations, and performs injection of
components.
Of course, MC-kernel knows nothing about exo-kernel service objects - it can
only inject components deployed through one of jbossas deployers that use
MC-kernel to instantiate, or at least register, components.
InjectingBean demonstrates several different ways in which you can perform
injection of JBoss services into a component. If instead of using exo-kernel
to deploy InjectingBean, you deploy it through JBossAS, these annotations
will work just the same - JBossAS uses MC-kernel, and MC-kernel will process
the annotations.
There are many annotations used in InjectingBean.java. Apart from
@InterceptMC they are all mc-kernel annotations used to configure
injections.
@InterceptMC is introduced by MC integration to mark classes that should be
integrated with MC. Through it you can also control if you want to use AOP
integration, and what kind of injections you want MC to perform. By default,
field injections are disabled by MC-kernel, as they are deemed an
anti-pattern for service objects - they may make your code more difficult to
maintain in the long run, as you are giving up the ability to intercept the
setting-of-the-field.
Service objects instantiated through exo-kernel don't become part of
MC-kernel object repository. That means that dependency management can't be
performed by MC-kernel, which means that all the dependencies InjectingBean
needs have to be fulfilled before MC-kernel first learns about it. Usually
MC-kernel makes several passes over the whole deployment (all the deployment
archives), first learning about services and their dependencies, then
starting up services that have no dependencies first, and services with
dependencies later - when their dependencies are fulfilled.
When using MC integration, we need to make sure, that all the dependencies
have already been installed before exo-kernel bootstrap happens. This can be
done by deploying all jboss beans as .jars containing
META-INF/jboss-beans.xml in deploy dir. JBossAS deploys .jars before .wars
and .ears.
*Things to look out for ...*
There are several exo-kernel bootstrap points in gatein .ears deployed in
GateIn JBossAS distribution:
exo-kernel/exo.kernel.container:
org.exoplatform.container.web.PortalContainerConfigOwner
org.exoplatform.container.web.PortalContainerCreator
gatein/portal/trunk/component/web:
org.exoplatform.web.GenericHttpListener
Any of these can trigger exo-kernel initialization by triggering a call to
RootContainer.getInstance(). MC-integration has to intercept this call at
Servlet API level, because it needs some ServletContext attributes. If the
call is not intercepted, then MC-integration doesn't work.
At the moment first two classes are modified to perform interception.
GenericHttpListener is in gatein portal trunk and I did not modify that one.
If any gatein-sample ear is present in jboss deploy, as is currently the
case, then that one is deployed before gatein.ear. That one uses
PortalContainerConfigOwner to trigger exo-kernel initialization, so
everything is fine. If gatein-sample ears are removed, then gatein.ear is
started first, and that one uses GenericHttpListener to trigger exo-kernel
initialization. In that case MC integration won't work - that's until
GenericHttpListener is modified to do interception - I should probably make
another branch in gatein portal, do that there, then at some point merge in
trunk.
I'm also looking into another possible solution that requires no Servlet API
level interception.
*TODOs*
1) I'm looking for a way to add server specific dependencies for packaging
the gateIn-jboss distro.
MC integration requires certain extra jars - but only when deployed to
JBoss. MC integration is not active when deployed to Tomcat, and is written
in a way that everything works without the extra MC integration jars.
Extra jars are the following:
cp
org.jboss.mc-kernel-extras/target/mc-kernel-extras-2.2.0-Beta04-SNAPSHOT.jar
$GATEIN_LIB
cp
~/.m2/repository/org/jboss/mc-int/jboss-mc-int-common/2.2.0.Alpha2/jboss-mc-int-common-2.2.0.Alpha2.jar
$GATEIN_LIB
cp
~/.m2/repository/org/jboss/mc-int/jboss-mc-int-servlet/2.2.0.Alpha2/jboss-mc-int-servlet-2.2.0.Alpha2.jar
$GATEIN_LIB
The first one is a module in exo-kernel-mc-int-branch, and contains an
mc-kernel class that wasn't there yet in version 2.0.6.GA - which is the one
that ships with JBossAS 5.1.0. The second two are MC integration jars that
don't come with JBossAS 5.1.0 in any version.
These three jars are not needed in Tomcat distribution, so they don't need
to be included.
Normally dependencies are declared in
packaging/modules/src/main/javascript/kernel.packaging.module.js, but these
are not deployment environment specific.
I've seen some hacks in
gatein/portal/trunk/packaging/pkg/target/exopackage/javascript/eXo/server/Jboss.js,
but maybe there exists a better way to do this.
2) I'm also looking into testing, and additional demos (AOP demo).
3) There's the already mentioned alternative interception I'm looking into
4) Also, this post is better suited for wiki where it can evolve through
time. Which wiki would be the best for this?
If someone is interested in a specific use-case, please let me know, and
I'll look into it, do a demo ...
Cheers,
- marko
15 years, 10 months
Packaging evolution : exopackage embedded in GateIn (work in progress)
by Dimitri BAELI
Hello,
I moved the packaging tooling (aka exobuild) in GateIn to be able to work
on it directly without having to release it (see
https://jira.jboss.org/jira/browse/GTNPORTAL-256 for more details).
I'll work on it with Arnaud in the coming days.
Currently it is not plugged (in /pakaging/pkg) because a build issue which
makes the build fails when "mvn install" is run from the root directory (or
packaging).
I'll try to solve that later today, I'll keep you informed.
Note for bolek:
I've commited a fix for the hibernate packaging GTNPORTAL-73 (no more
clean up of hibernate files, as we may need to include hibernate 3.3.2).
Dimitri BAELI - eXo Platform SAS
15 years, 10 months
Fix in portal list
by Julien Viet
I want to bring to you that useful following statistic available via
JMX, specially in JBoss where you can use the JMX console.
Wesley has been using it for his bridge demo (and I fixed the bug that
was present Wes :-) ).
I believe also that Marek could collect information during load
testing and create graphs that would be correlated with the
performances graphs. (for instance , showing the portal throughput and
the average response time on the same graph, or showing the usage of
the various caches correlated with the througput, I guess you get the
idea).
With the JMX console, the statistics are interesting but it remains
limited, it becomes very useful only if we can exploit the data via a
more powerful tool with charting and gauges.
1/ service=statistic,type=portal,view=portal
- gives you the list of portal ids
- for a given portal id you can get info like:
1/ average execution time
2/ minimum execution time
3/ maximum execution time
4/ execution count (can be graphed)
5/ throughput, i.e number of request per second (can be graphed)
2/ service=statistic,type=template,view=portal
- list of the 10 slowest templates
- list of the 10 fastest templates
- list of the 10 most used templates
- list of all template ids
- for each template it is possible to have info about:
1/ average time
2/ min time
3/ max time
4/ execution count
3/ service=SessionRegistry
it gives the list of the number of active JCR session in the portal
which can be graphed as it gives a good indicator of the load on the
server
4/ each cache is registered under the key
name="$CACHE_ID",service=cache which gives the usual information
there are other few mbeans available but they are less interesting, so
I won't talk much about it.
cheers
Julien
15 years, 10 months
Common logging
by Julien Viet
Hi,
I worked on providing a facade for SLF4J in the common module.
The various GateIn components are using another logger:
- Common module use Log4J
- WCI uses Log4J
- Portlet Container uses Log4J
- WSRP uses SLF4J directly
I have not intentionally migrated the common code to the logging in
order to avoid to break things in components that may use the common
module as a snapshot.
For the CR1 it would be a good idea to have the common/wci/portlet
components to use the logging facade to avoid the log4j usage.
Thomas and myself will discuss about that during the conf call tomorrow.
For the runtime, the tomcat server uses the SLF4J for JDK binding and
I think that the jboss server uses the SLF4J for Log4j binding
(correct me if I am wrong).
I created a documentation page in the wiki here : http://www.jboss.org/community/wiki/GateInCommon
cheers
Julien
15 years, 10 months
Common modules
by Christophe Laprun
Hi all,
We should probably spend some time cleaning up / merging the common
modules. There's duplicated code there as there are common utilities
from eXo as well as from JBoss so we'd be best served to merge
everything that can be into a single common module, preferably split
into functional submodules so that we don't have to import an über-
module with lots of dependencies.
Cordialement / Best,
Chris
==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow JBoss Portal: http://jbossportal.blogspot.com / http://twitter.com/jbossportal
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm
15 years, 10 months
