double event triggering and webui
by Matt Wringe
There is a strange issue with double events occuring between portlets,
but it only occurs in a very specific manner and seems to depend on how
the page is created and how the portlets are added to the page.
See https://jira.jboss.org/jira/browse/GTNPORTAL-17 for full details
(and patch)
We are seeing the double events occuring only when a portlet is added to
a page during the page creation. But not if a portlet is added to the
page after the page is already created.
If a user logs out, logs back in, or edits the page (with a save or an
abort), then the issue goes away.
Can someone who is familiar with webui and page creation please take a
look at this?
Thanks,
Matt Wringe.
15 years, 4 months
Tomcat Gatein and WCI behaviour
by Matt Wringe
[sorry for the long email]
The behaviour between the Tomcat and JBoss versions of GateIN is
different in regards to the deployment of portlets.
The WCI module has two different ways in which portlets can be deployed:
- generic deployment: the web.xml of the portlet contains a special
servlet or servletlistener which discovers the portlet.
The special servlets add their webapp to a list which wait for a wci
generic listener to be run. If the generic listener is not run, then the
list still gets created but nothing happens with it.
This is similar to how the eXo portal would handle portlet discovery.
- container specific: the server is setup to intercept wars being
deployed. The portlet itself doesn't need to have anything special done
to it so that it can be deployed (ie no special servlets/listeners
needed). This setup will find portlets regardless if the special
servlets are added or not.
The special servlet/listeners will still create the list of webapps, but
since the wci generic listener is not deployed nothing will happen with
that list.
This is similar to how the JBoss portal would handle portlet discovery
(ie nothing special needed).
In order to determine which type to use we need to specify it in the
web.xml of the integration war. They are mutually exclusive, so if you
specify both in the integration war then the first one that is started
will be used.
In the JBoss version of GateIN we use the container specific
implementation. This means we have (mostly) backwards compatibility with
portlets that would have worked on JBoss Portal or eXo portal.
In the Tomcat version of Gatein we use the generic implementation. This
means we have (mostly) backwards compatibility with portlets that would
have worked on eXo portal.
The Tomcat version can be switched to use the container specific
implementation by removing the commenting around the servlet in its
web.xml (and commenting out the listener).
I would like to switch the behaviour of the Tomcat version to use the
container specific wci implementation so that both versions behave the
same and so that we can get backwards compatibility with JBoss portal
portlets.
Is there any objections to switching over to this behaviour?
15 years, 4 months
Re: [gatein-dev] Build Failure !!!
by Arnaud HERITIER
Yes but others will reply that they don't want to be SPAM by those emails
and prefer to use hudson/jira dashboards or an RSS feed.In my case, I'm like
you, you can SPAM me, I'm a master in managing emails in GMails with emails,
filters & more.
Cheers,
Arnaud
# Arnaud Héritier
# Software Factory Manager
# eXo Platform
# http://www.exoplatform.com
# http://blog.aheritier.net
On Fri, Oct 9, 2009 at 9:47 AM, Julien Viet <julien(a)julienviet.com> wrote:
> for me notifications are fine if they can easily filtered by common mail
> rules.
>
>
> On Fri, Oct 9, 2009 at 9:44 AM, Arnaud HERITIER <aheritier(a)gmail.com>wrote:
>
>> FYI, in our continuous integration jobs, Maven checks if there are new
>> SNAPSHOTs on our global repository (Nexus -
>> http://repository.exoplatform.org) for each build.
>> Actually our central repository checks if there are new SNAPSHOTs on
>> jboss.org every 5 minutes.
>> Thus if there are less than 5 minutes between the deployment of SNAPSHOTs
>> and the build, it will fail.
>> This won't occur anymore when all GateIn resources (jobs, repositories,
>> ..) will be hosted on jboss.org
>>
>> About notifications, it is very very difficult to have all a team agreed
>> on it. That's why we often push them (issues, continuous integration,..) on
>> a dedicated mailing list (notifications@ maven.apache.org for exemple).
>> Thus, those who prefer to use RSS feeds for exemple to retrieve those
>> notifications can use it and not subscribe to the mailing list.
>>
>> Cheers,
>>
>> Arnaud
>>
>> # Arnaud Héritier
>> # Software Factory Manager
>> # eXo Platform
>> # http://www.exoplatform.com
>> # http://blog.aheritier.net
>>
>>
>> On Fri, Oct 9, 2009 at 2:32 AM, Dimitri BAELI <dbaeli(a)gmail.com> wrote:
>>
>>> Hello,
>>>
>>> Last commit broke the build. And will probably block the night team in
>>> VN :-)
>>>
>>>
>>> http://builder.exoplatform.org/hudson/view/All/job/gatein-portal-trunk/97...
>>>
>>>
>>> /home/hudson/hudson/jobs/gatein-portal-trunk/workspace/gatein/portal/trunk/component/pc/src/main/java/org/exoplatform/portal/pc/ExoKernelIntegration.java:[133,61] cannot find symbol
>>> symbol : variable LOCAL_PORTLET_INVOKER_ID
>>>
>>>
>>>
>>>
>>>
>>>
>>> location: interface org.gatein.pc.api.PortletInvoker
>>>
>>>
>>> *Questions:*
>>> How should we behave in such case ?
>>> Can we rollback the commit if the responsible is not present for few
>>> hours ? Or let it be and update to the last known stable state.
>>>
>>> *Experimentation:*
>>> I'll send the build notifications (only failures and back to normal
>>> state) to the gatein-dev list. Tell me if that's not acceptable also.
>>> Is there another target ML for that ?
>>>
>>> The notification rules:
>>>
>>> 1. Every failed build triggers a new e-mail.
>>> 2. A successful build after a failed (or unstable) build triggers a
>>> new e-mail, indicating that a crisis is over.
>>> 3. An unstable build after a successful build triggers a new e-mail,
>>> indicating that there's a regression.
>>> 4. Unless configured, every unstable build triggers a new e-mail,
>>> indicating that regression is still there.
>>>
>>>
>>>
>>> Dimitri BAELI - eXo Platform SAS
>>>
>>> _______________________________________________
>>> gatein-dev mailing list
>>> gatein-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>
>>>
>>
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
>>
>>
>
15 years, 4 months
Build Failure !!!
by Dimitri BAELI
Hello,
Last commit broke the build. And will probably block the night team in VN
:-)
http://builder.exoplatform.org/hudson/view/All/job/gatein-portal-trunk/97...
/home/hudson/hudson/jobs/gatein-portal-trunk/workspace/gatein/portal/trunk/component/pc/src/main/java/org/exoplatform/portal/pc/ExoKernelIntegration.java:[133,61]
cannot find symbol
symbol : variable LOCAL_PORTLET_INVOKER_ID
location: interface org.gatein.pc.api.PortletInvoker
*Questions:*
How should we behave in such case ?
Can we rollback the commit if the responsible is not present for few
hours ? Or let it be and update to the last known stable state.
*Experimentation:*
I'll send the build notifications (only failures and back to normal
state) to the gatein-dev list. Tell me if that's not acceptable also.
Is there another target ML for that ?
The notification rules:
1. Every failed build triggers a new e-mail.
2. A successful build after a failed (or unstable) build triggers a new
e-mail, indicating that a crisis is over.
3. An unstable build after a successful build triggers a new e-mail,
indicating that there's a regression.
4. Unless configured, every unstable build triggers a new e-mail,
indicating that regression is still there.
Dimitri BAELI - eXo Platform SAS
15 years, 4 months
Application registry (& co) design and WSRP support.
by Christophe Laprun
Hi,
In the process of trying to integrate the WSRP consumer within GateIn,
I found things that I find rather concerning design-wise. It might be
a reflection of me not understanding the overall design so please
humor me for a second.
In JBoss Portal, the integration of the WSRP consumer was rather
seamless: a FederatingPortletInvoker (implementing the Composite
design pattern) allowed us to register additional PortletInvokers
(which is what WSRP consumers are) and present a single, unified
interface to the portal. In essence, from the portal point of view
there wasn't much of a difference between a local or a remote portlet.
GateIn does use the FederatingPortletInvoker concept and the WSRP
consumers are properly registered with it. However, bridging over to
Portal, it seems currently rather complicated to support WSRP portlets
in a seamless fashion. The integration between the Application/
ApplicationCategory concepts and the Portlet Container is currently
exposing internal details of the PC (the portlet id format) in rather
crude way: hardcoded string parsing repeated in different spots.
This is bad for several reasons:
- This tightly ties the portal to the *implementation* of the portlet
container instead of its API.
- This has performance impact as the bridge is done by extracting
specific components from a String which might end up being parsed
several times.
- The parsing code is not encapsulated and is repeated in several
different spots.
More to the point, the whole Application concept is not adapted to
supporting WSRP as it requires a portlet application name and portlet
name to work. This can be emulated in WSRP (and I actually have
working code to do just so). However, invocations do not work because
the invocation code of the Portal hardcodes (again) specific knowledge
of the internal PC implementation (specifically, the format of portlet
ids). Moreover, this break of encapsulation also prevents the
FederatingPortletInvoker to do its job properly as the portlet ids are
improperly recreated from the formerly extracted application and
portlet names, hardcoding the invoker id of the local invoker.
This is embodied particularly in the ApplicationState.update method:
producerOfferedPortletContext = PortletContext.createPortletContext
("local./" + applicationName + "." + portletName);
So to sum up:
- Application concept is not appropriated to supporting remote portlets.
- Information specific to the portlet container implementation is
extracted from String versions of PortletContexts only so that said
PortletContexts can then be recreated in a way that prevents proper
dispatch of requests to WSRP consumers.
Solutions:
Get away from solutions that require knowledge of internal
implementation and require multiple String operations by using the
PortletContext everywhere application name / portlet name is used.
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, 4 months
A word about Exo kernel - MC integration
by Marko Strukelj
In order to facilitate finalization of MC instegration attempt I'm outlining
here current work, so that Exo guys working on eXo kernel see what I'm
doing, and also to maybe get some additional ideas about the functionality.
Initial Objectives:
o1) Get rid of picocontainer-1.1 (because there is no source code for it,
and that's unacceptable for EPP 5)
o2) Make some kind of integration with MC in order to - 'eat our own dog
food'
Constraints:
c1) Picocontainer was thought to be heavily used directly (not only though
exo kernel), which led to the belief that we have to keep at least
picocontainer-1.1 compatible API in there
Development:
Initial investigation showed that apart from exo kernel (which in principle
we can move to any other DI framework), other exo code, publicly available
through svn, only makes use of 2 interfaces:
- org.picocontainer.ComponentAdapter
- org.picocontainer.Startable
There is however a possibility that some of current Exo clients use
picocontainer directly in ways we don't know about.
I started my initial work on picocontainer-1.2 for which there are publicly
available sources. Comparison with picocontainer-1.1 showed that there was
some slight refactoring, some functionality was added, and some method
signatures changed in declared exceptions only.
Dropping picocontainer-1.2 in jboss-gatein distribution instead of
picocontainer-1.1 results in everything running fine.
That means that we can fulfill our objective o1) simply by upgrading to
picocontainer-1.2. Exo should test this more extensively with some of their
deployments.
The initial idea to fulfill o1) and o2) at the same time was to rewrite
picocontainer internals to delegate everything to MC.
The problem that immediately showed was that API of the both libraries was
quite different, and difficult to map.
Another problem was that it turned out object instantiation wasn't left to
picocontainer's code, but was overriden and was done in ExoContainer .
createComponent() method, which also takes care of which constructor to call
and fetches all the necessary argument values. DI is in effect implemented
inside ExoContainer and not really delegated to picocontainer.
So the first idea was just to delegate to MC kernel the holding of
configuration objects or instances.
But MC kernel actually has a nice pluggability mechanism where you can
expose to it other object stores and it will delegate component lookup to
them.
The most recent implementation doesn't touch picocontainer at all.
The idea is to do 2 things - a) use MC in a way that adds some substantial
new functionality - specifically AOP support, b) expose gatein components to
MC so they can be injected into other components deployed directly through
MC (should such components exist).
Currently all the containers used for DI by exo kernel extend
org.exoplatform.container.ExoContainer, which itself extends another
container:
DefaultPicoContainer
|- CachingContainer
|- ManageableContainer
|- ExoContainer
|- RootContainer
I introduced MCIntegrationContainer:
DefaultPicoContainer
|- MCIntegrationContainer <----
|- CachingContainer
|- ManageableContainer
|- ExoContainer
|- RootContainer
This one can intercept all the calls to DefaultPicoContainer and do the
necessary calls to MC kernel.
Additional interception is performed through MCComponentAdapter that we wrap
around any component adapter passed to registerComponent(ComponentAdapter)
method.
The interception passes the objects instanciated by ExoContainer's
createComponent() - the actual point in the code where all instantiations
occur - through MC kernel that wraps them in AOP proxies.
Since MC integration is now in the service of providing AOP, I also added an
annotation called InterceptMC, that you put on your service class (the one
that typically implements org.picocontainer.Startable), and we MC intercept
only objects of classes that carry this annotation. All the other objects
pass through the calls as if none of this new functionality is there.
To use the functionality, you make a jar or war file with your service
component annotated with InterceptMC, you put conf/configuration.xml in it,
as usually. But then you can also add MC configuration next to it as
conf/mc-beans.xml. It's the same configuration used in jboss-as. You can
install new POJO components directly through it, and you can set up AOP
there. You can pack in you jar a custom interceptor, and precisely configure
the types and methods that should be intercepted with your custom
interceptor.
You can add extra logging, performance measurements and things like that by
simply adding an interceptor class, tweaking config and repacking
/redeploying the jar.
Everything doesn't yet work as described, but I outlined the idea.
I'll be glad to answer any questions ...
Cheers,
- marko
15 years, 4 months
