Property enforced in gatein portal
by Arnaud HERITIER
Hi guys,
Thomas I just see your messages on IRC. We discovered few days ago
that this property (or mock.portal.dir ) has to be set to pass unit
tests . (it seems to be an issue in Exo kernel). Julien can probably
tell more about it.
Thus having tests failures in a build by default isn't possible for
me. We have actually 2 short term choices :
- force the developper to correctly setup it's environment to be sure
that tests will pass (it's what I did)
- disable tests by default using a profile thus you can build gatein
without additional config.
The targetted solution is to remove the usage of absolute paths in the
build (I opened a jira about that). But I don't know when it will be
done
cheers
Arnaud
--
Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net
14 years, 5 months
Commit messages
by Christophe Laprun
Could we please make sure that the commit messages are meaningful?
Just committing lots of changes with a simple repetition of the related JIRA number and title as a commit message is not very helpful. I understand that nothing more is required when the changes are simple but when they involve several files with sometimes complex changes, it'd be easier for everyone if a description of the work that was done was used instead of a rather useless repetition of the JIRA issue summary. This is especially true when several different commits are made for the same issue.
This would help people trying to figure out what was done when looking at the commit emails and possibly help track down issues down the road.
Thanks in advance.
Cordialement / Best,
Chris
==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm
14 years, 5 months
Persistence needs for WSRP
by Christophe Laprun
Now that the WSRP integration with Portal is starting to shape up, I
need to move to the second phase of the integration which is
persistence of WSRP-related state.
Caution: wall of text incoming! :(
There are several aspects that need to be considered:
1. Definition of WSRP consumers (i.e. definition of connection to
remote producers):
This entails data that wouldn't change too often but can still be
dynamic, especially during the initial registration process (if
required). The data that is needed here is the URL for the WSDL file
published by the remote producer, a cache expiration duration in
seconds and data pertaining to registration as required by the remote
producer, which in most instances, is determined dynamically during
the initial negotiation with the producer. This data needs then to be
presented to the user and filled out then persisted. This data is
stored on the consumer side of things. To get a sense of that
interactive process, have a look at how this was done in JBoss Portal: http://docs.jboss.com/jbportal/v2.7.1/referenceGuide/html/wsrp.html#consu...
While a GUI tool to perform that operation is the ultimate goal, this
is currently done using an XML configuration file that is located in
the wsrp-consumer-1.0.0-Beta01.jar under conf/wsrp-consumers-
config.xml. Ideally, I would like to get rid of that file but I
understand that some people might need to configure their consumers
without using a graphical interface.
The question then is, based on how Portal deals with similar
configuration issues (which I need to be educated on), what is the
best persistence strategy for this user editable data?
2. Configuration of the WSRP producer:
The behavior of the WSRP producer is controlled by some user-definable
configuration as well, in particular with respect to whether or not
consumers are required to register with it and how registration
properties are validated. This is currently done via another XML file
located in wsrp-producer.war/WEB-INF/conf/producer/config.xml. Again,
ideally, this data would be edited graphically and persisted. See http://docs.jboss.com/jbportal/v2.7.1/referenceGuide/html/wsrp.html#produ...
for how it was done in JBoss Portal.
Again, what is the best strategy to persist this user editable data
and how does it fit with the existing administration tools?
3. Registration data sent by remote consumers to the WSRP producer:
If the WSRP producer has been configured to require consumers to
register with it before any further interaction, the data associated
with that registration must be persisted across server restarts so
that an already registered consumer is not faced with errors. More to
the point, any portlet state that is created within the scope of a
valid registration life should also be associated with that
registration. More precisely, if a consumer is registered with our
producer and during its interaction with it, portlets are cloned, the
resulting state should be scoped to the registration between the
consumer and the producer so that if that registration ever becomes
invalid, the associated state can be destroyed.
As a result, we need to be able to not only persist the data
associated to the registration itself (i.e. consumer name, provided
values for expected registration properties, etc.) but we also need to
be able to reference portlet state as defined by the portlet
container. Note that local persistence of consumer configured state
(cloned portlets) is not mandated by the specification and it is
possible to send that state back to the consumer for it to manage.
Again, what is the best strategy to persist such data within GateIn?
Note that this data should not require user edits, though it might be
useful for administrators to be able to look at that data and possible
perform maintenance operations on it.
How were these issues managed in eXo Portal?
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
14 years, 6 months
Branch update
by Julien Viet
The performance branch was merged 2 days ago and I have asked Trong to
merge the wsrp integration branch that Chris has been working on for a
couple of weeks.
The merge is symbolized by that JIRA task : https://jira.jboss.org/jira/browse/GTNPORTAL-176
we're waiting for followup from Trong.
cheers
Julien
14 years, 6 months
JIra and fields
by Thomas Heute
I've seen that several people used the:
"Affect-Version" field in Jira for versions that have not been
released yet.
Please do not use that field unless you know that a particular bug
affect some particular released version.
I've removed all "Affect-Version: 3.0.0-CR01".
The issue is for users when they run a particular version and want to
see what bugs affect the version they are running.
14 years, 6 months
packaging/profiles.xml
by Dimitri BAELI
Hello,
I'm confused about the profiles.xml file, it is part of the codebase but
we have to modify it for local informations.
I suggest to create a profiles.xml.template and put profiles.xml in
svn:ignore, so that the profiles.xml is not is permanent conflict and the
new users can easily create his setup.
I've commited a sample profiles.xml.template in packaging.
If that's ok for you, here is what still to be done:
* Update the /README.txt to explain from which file we should create the
profiles.xml
* Remove profiles.xml from the codebase and add it in the svn:ignoe
Thanks,
Dimitri BAELI - eXo Platform SAS
14 years, 6 months
Groovy template engine rewrite
by Julien Viet
In my optimization effort I have rewritten the Groovy Template engine
from scratch.
The previous engine was a fork of the basic SimpleTemplateEngine in
the Groovy package (why it was forked ? I haven't had an answer so far).
One part of the optimization consist into translating the markup
chunks of the template directly into UTF-8 encoded bytes so it can be
directly written on the Servlet output stream. Actually if you think
about it, on every request constants character data (the markup
chunks) are converted into byte using the UTF-8 encoding. So it has 2
nasty effects:
1/ encoding a char into a byte[] (some chars take several bytes) is
costly specially if the Servlet engine do it for you (as it is
possible to optimize it and that's what we do in other parts of GateIn)
2/ unnecessary serialization as when you encode the string GateIn
basically you
- write the char[] on the Writer
- tomcat read the char[]
- tomcat translate each char into a byte[]
- the corresponding byte[] is written to the output (with usually an
additional buffer)
The Groovy markup chunk optimization computes the byte[] and write
them to the servlet output, removing the cost of doing the translation
to byte[] (encoding) and a read/write of the array (serialization).
The second part of the optimization is to pre parse directly the
Groovy strings (known as GString). As you may know in Groovy it is
possible to have $foo or ${foo} into the markup which cause an
evalutation of the string. The new template compiler pre parse that
into expression and markup chunks.
The benefit of template rewrite in the capability to maintain a table
of template line number to groovy line number which allowed me to
implement more precise error reporting when an exception occurs, for
instance:
1. abc <% throw new Exception(); %> def
is compiled into Groovy like:
1. out.print("abc");
2. throw new Exception();
3. out.print("def");
So when the exception occurs, Groovy say the error happened at line 2
but what interest us is where it happened in the template file.
So I have been able to craft that into the engine and normally it
should work better (I'm saying that because I have unit tests but I'm
not 100% sure that I cover all cases).
cheers
Julien
14 years, 6 months
