XML Parsing, where do we stand
by Thomas Heute
Nick, Julien, Alain,
As said before we'd like to harmonize the XML parsing accross the GateIn
projects. Let's kill this once for all...
It doesn't mean we would change the existing parsers overnight but it
means we will impose a way for any new parsing (or when we decide to
rewrite a parser).
If we need parser tools, they will go in Common module ultimately. There
might be a phase when the code will be duplicated (as Nick's tools need
to work on an untouched portal where upgrading common is not an option).
We already agreed that StAX as a base was the way to go, I hope we still
agree ;)
Let's separate in reading/writing XML (doesn't necessarily necessarily
mean marhalling/unmarshalling BTW) and agree on both.
Reading XML:
Option 1:
Plain StAX, JBoss AS 7 uses that (in fact they use StAX Mapper,
a very lightweight library made by the JBoss AS7 team.
https://github.com/jbossas/staxmapper/ which only helps to work with
multiple namespaces + some little helpers for ignoring part of the file,
format the XML when writing...)
One example of JBoss AS 7 parsing file:
https://github.com/emuckenhuber/jboss-as/blob/master/web/src/main/java/or...
Option 2:
Nick's stuff (please explain advantages/drawbacks)
Option 3:
Julien/Alain's stuff (please explain advantages/drawbacks)
Writing XML:
Option 1:
Plain StAX (well-formed guaranteed over plain Writer)
Option 2:
Nick's stuff (please explain advantages/drawbacks)
Option 3:
Julien/Alain's stuff (please explain advantages/drawbacks)
Note that there are other utilities and frameworks based on StAX:
Stax-Utils: http://stax-utils.dev.java.net/
StaxMate: http://wiki.fasterxml.com/StaxMateHome
Apache Axiom: http://ws.apache.org/commons/axiom/
Thomas/
/
15 years
GateIn parent pom
by Thomas Heute
To the Maven expert(s), i plan to do some update in our GateIn parent:
- Upgrade org.codehaus.mojo:jboss-packaging-maven-plugin upgrade to
2.0-beta1 => 2.1.1: Upgraditis + we were using a Beta. Not sure if we
are ever using it.
- Remove repositories + pluginRepositories definitions, it's
supposed to be a best practice, correct me if I'm wrong (But will
require people to have those defined in their local installation)
Anything I missed/got wrong ?
15 years, 1 month
Common module
by Thomas Heute
Time to consolidate modules for GateIn Portal 3.2, I would like to
release the common module soon after we agree on the parent POM.
Is "common" ready to be shipped or is someone expecting to add more into
it ?
Thomas.
15 years, 1 month
More suggestions about the build
by Marko Strukelj
1) README.txt in portal-parent is a bit outdated. I've put together a
proposal for a new one [1]. I've tested the instructions with empty local
repo.
2) Also, I propose we remove packaging/profiles.xml, as it's not maven 3
compatible, and move properties definitions to packaging/pom.xml.
3) Also, we should move arguments checking (maven-enforcer-plugin) into
portal-parent pom.xml so that when I do: 'mvn clean install -Ppkg-jbossas5'
I'm immediately notified about a missing
-Dexo.projects.directory.dependencies.
4) Then there was suggestion by Nick to also document and properly handle
'gatein.working.dir' property which he's been relying on.
I suggest moving it from packaging/pkg/pom.xml to packaging/pom.xml together
with the rest of properties (those currently in profiles.xml).
5) And, Chris suggested to put some kind of short help message at the
beginning of the build (like echo ...) that would list example command lines
for all the packaging options, to make it super user-friendly for users.
[1]
Prerequisites
==========
- Java Development Kit 1.6
- Recent Subversion client
- Recent Maven 3 (or Maven 2.2.1)
Build instructions
=============
1) Configure maven repositories:
Create file settings.xml in $HOME/.m2 (%HOMEPATH%\.m2 on Windows) with the
following content:
<settings>
<profiles>
<profile>
<id>jboss-public-repository</id>
<repositories>
<repository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Maven Repository Group</name>
<url>
https://repository.jboss.org/nexus/content/groups/public-jboss/</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Maven Repository Group</name>
<url>
https://repository.jboss.org/nexus/content/groups/public-jboss/</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
<profile>
<id>exo-public-repository</id>
<repositories>
<repository>
<id>exo-public-repository-group</id>
<name>eXo Public Maven Repository Group</name>
<url>http://repository.exoplatform.org/content/groups/public</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>exo-public-repository-group</id>
<name>eXo Public Maven Repository Group</name>
<url>http://repository.exoplatform.org/content/groups/public</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>jboss-public-repository</activeProfile>
<activeProfile>exo-public-repository</activeProfile>
</activeProfiles>
</settings>
2) Check out gatein-portal
svn co http://anonsvn.jboss.org/repos/gatein/portal/trunk gatein-portal
cd gatein-portal
3) Prepare containers to use for packaging
Create a directory on your disk that will contain specific released versions
of JBoss-AS, Tomcat, Jetty, or some other container, used as a template for
GateIn packaging.
Let’s refer to this directory as CONTAINERS_DIR.
4) Build and package gatein-portal
GateIn can be packaged with different web / application servers. The
specific container to use is selected by using an appropriate profile.
Packaging with JBoss-AS-5.1.0.GA
----------------------------------------------------
If you don’t have an existing JBoss-AS distribution, tell the build to
automatically download it for you.
Issue the following command:
mvn clean install -Ppkg-jbossas5,download
-Dexo.projects.directory.dependencies=$CONTAINERS_DIR
If you have an already downloaded JBoss-AS-5.1.0.GA distribution from
jboss.org, unpack it into CONTAINERS_DIR directory so that you get
CONTAINERS_DIR/jboss-5.1.0.GA directory.
Issue the following command:
mvn clean install -Ppkg-jbossas5
-Dexo.projects.directory.dependencies=$CONTAINERS_DIR
The packaged GateIn is available in packaging/jboss-as5/pkg/target/jboss.
Packaging with JBoss-AS-6.0.0.Final
----------------------------------------------------
If you don’t have an existing JBoss-AS distribution, tell the build to
automatically download it for you.
Issue the following command:
mvn clean install -Ppkg-jbossas6,download
-Dexo.projects.directory.dependencies=$CONTAINERS_DIR
If you have an already downloaded JBoss-AS-6.0.0.Final distribution from
jboss.org, unpack it into CONTAINERS_DIR directory so that you get
CONTAINERS_DIR/jboss-6.0.0.Final directory.
Issue the following command:
mvn clean install -Ppkg-jbossas6
-Dexo.projects.directory.dependencies=$CONTAINERS_DIR
The packaged GateIn is available in packaging/jboss-as6/pkg/target/jboss.
Packaging with Tomcat 6.x.x
----------------------------------------------------
Download latest Tomcat 6.x.x distribution from tomcat.apache.org, and unpack
it into CONTAINERS_DIR directory so that you get
CONTAINERS_DIR/apache-tomcat-6.x.x directory.
Issue the following command:
mvn clean install -Ppkg-tomcat
-Dexo.projects.directory.dependencies=$CONTAINERS_DIR
-Dexo.projects.app.tomcat.version=apache-tomcat-6.x.x
The packaged GateIn is available in packaging/tomcat/pkg/tc6/target/tomcat6.
Packaging with Tomcat 7.x.x
----------------------------------------------------
Download latest Tomcat 7.x.x distribution from tomcat.apache.org, and unpack
it into CONTAINERS_DIR directory so that you get
CONTAINERS_DIR/apache-tomcat-7.x.x directory.
Issue the following command:
mvn clean install -Ppkg-tomcat7
-Dexo.projects.directory.dependencies=$CONTAINERS_DIR
-Dexo.projects.app.tomcat7.version=apache-tomcat-7.x.x
The packaged GateIn is available in packaging/tomcat/pkg/tc7/target/tomcat7.
(eof)
- marko
15 years, 1 month
Login modules in gatein-jboss-beans.xml
by Michal Vančo
Hi everyone,
I have an important question about login modules in GateIn/EPP5.
Now there is a gatein-jboss-beans.xml file which contains definition of 3 login modules for gatein-domain (default realmName).
Think of this situation:
- we have a set of new portlets and we need to add new login module
- we are using an extension mechanism to deply everything and initialize new portal (we don't want to touch gatein.ear at all)
- we add a new gatein-jboss-beans.xml in extension .ear (with old + new login modules defined), now it means that both gatein-jboss-beans.xml (from gatein.ear and from extension .ear) are used
But it's a problem because you will get an error during startup: IllegalStateException: gatein-domain is already installed.
Now I know about these options:
1) replace gatein-jboss-beans.xml in gatein.ear with new file
2) have new gatein-jboss-beans.xml in extension .ear and rename file in gatein.ear to something like: gatein-jboss-beans.xml-backup (it means that only the one from extension is used)
3) create new portal container with new realmName and define all login modules in new domain (but in our case we want to extend default portal container)
So the question is if there is some other way how to define new login modules (without touching gatein.ear)?
Thanks for any help or ideas!
Best regards,
Michal Vančo, JBoss QA
(I have it temporarily done with second option, but I'd like to improve it - I want only to deploy new .ear and that's all)
15 years, 1 month
CRaSH 1.0.0 beta 18 release
by Julien Viet
with many improvements, the biggest ones
- contextual command line completion (a long wanted feature)
- advanced command documentation
- command grouping in the same Groovy class / sub commands à la "git add", useful to bundle commands and promote reuse
- new packaging : a JCR independant packaging for use anywhere and the gatein packaging to use with JCR.
the biggest change you should experience first is the connection to a repository, the previous connect/disconnect commands are gone and replace by:
> ws login -c portal -u root -p gtn portal-system
> ws logout
then you can try the help system and the new "man" command:
> log -h
> log ls -h
> man log
> man log ls
the exact same documentation is now generated in the guide as a command reference (so it's always accurate) that you can consult here http://crsh.googlecode.com/svn/doc/1.0.0-beta18/html/index.html#d0e291
if you have written commands in the past, the arg4j is still supported but you should rewrite your commands with the built in framework if you want to leverage the documentation and completion.
There are more changes under the hood:
- a plugin system to boostrap the various part based on java.util.ServiceLoader and decouple telnet / ssh
- an embedded mode, to bootstrap CRaSH inside a VM
- a new connector was added jline that provides a shell access in the same VM (so useful for testing during dev or in embedded mode)
- a virtual file system, that search for commands in file system / war files / jars
let us know your feedback, I will blog about that later to give more details.
15 years, 1 month
How to export nodes using CRaSH SCP protocol ?
by Olivier Picciotto
Reading the forum, the post,
http://community.jboss.org/message/561004#561004 speaks about the CRaSH
console for acessing the JCR through the command line interface. It doese
work ok and We sucessfully managed to install int in GateIN, access it
though telnet and ssh, list nodes etc ...
Now, the CRaSH documentation speaks about exporting nodes with the SCP
protocol
'scp -P 2000 root@localhost:portal:portal-system:/production/app:gadgets .
'
We tried that with CRaSH 1.0.0-beta17
Documentation says that CRaSH password is 'crash' so this is what we entered
as password when the SCP asks it. unfortunatly the SCP command returns
immediatly with a :
'Connection to localhost closed by remote host.' message
And no data is copied
Any Ideas ?
15 years, 1 month
