Jboss51 deployment with cargo-1.0.3 ?
by Alain DEFRANCE
Hi Matt,
I currently work with Julien Viet on WCI to deploy him on tomcat7.
I've changed the cargo version from 1.0.1-alpha2 to 1.0.3 (tomcat7 support + bugfix).
Since the 1.0.3 version (In the 1.0.2 version it's work fine), cargo can't deploy on jboss51.
According to this documentation http://cargo.codehaus.org/JBoss+Remote+Deployer, I'd added the 2 dependencies cargo-core-tools-jboss-deployer-5.1-and-onwards
and jboss-profileservice-spi.
Some classes still cannot be found (for instance : org.jboss.aop.proxy.MarshalledInterfaceProxy).
You can look that here : http://anonsvn.jboss.org/repos/gatein/components/wci/branches/adf/
It is a bug in cargo or missing other dependencies ?
Regards.
Alain Defrance.
16 years
WCI branch
by Julien Viet
Hi Matt,
I would like to branch WCI to 2.0.x and update the trunk to 2.1.0-Beta01-SNAPSHOT, could you proceed and create the corresponding JIRA version ?
this is necessary because we are going to implement some features in WCI soon.
thanks
Julien
16 years, 1 month
PC update
by Julien Viet
Hi,
I have just released PC 2.2.0-Beta02 which includes a couple of minor updates for GateIn:
1/ fix an odd behavior on PortletURL#getParameterMap() that was previously returning a copy of the state, now it returns the original (that is still safe of values, so doing parameterMap.get("foo")[0] = null does not affect the original value, the String[] values are still copied as required by the spec). I think the previous behavior was not correct (as one of the goal of the parameter map returned is the capability to call the clear operation on the map to reset the URL. The spec and the API does not make any mention of this. I added a unit test for that.
2/ implement the propagation of BaseURL properties, for now they were noops but as it was not used it was OK. Now they are propagated with a new method on the PC API ContainerURL#getProperties() which returns a Map<String, String> of the properties.
Both are for GateIn and the current navcontroller branch at the moment and will be merged later. The 1/ makes easy to "reset" and reuse a PortletURL, the 2/ makes easy to declare an URL as ajax with setProperty("ajax", "true") that will instruct GateIn to wrap the URL with "ajaxGet".
cheers
Julien
16 years, 1 month
Fwd: Update on GateIn examples
by Nguyen Anh Kien
Hi,
Have one person leave his praise to our portlet container of GateIn. He is
author of Portlet In Action book :)
---------- Forwarded message ----------
From: Ashish Sarin <ashes.sarin(a)gmail.com>
Date: Mon, Sep 13, 2010 at 1:39 PM
Subject: Update on GateIn examples
To: Nguyen Anh Kien <nguyenanhkien2a(a)gmail.com>
Hi Kien,
I have updated quite a few examples for GateIn and the details about it is
available in Manning Author Online forum. I'll keep you posted on what we're
doing to include GateIn details in the Portlets in Action book.
After working for sometime on GateIn portal, I'll have to say that except a
few minor bugs, the portlet container of GateIn is pretty impressive. I
think you guys have done a fantastic job.
regards
ashish
--
------
Best Regards!
==============================
==============
Kien Nguyen
Portal Team Developer
eXo Platform South East Asia (http://www.exoplatform.com)
A: 7 Flr, ThaiHa building, 18/11 alley, ThaiHa Str, Hanoi, Viet Nam
M: (+84) 933.975.960
E: kien.nguyen(a)exoplatform.com
16 years, 1 month
Selenium tests
by Marko Strukelj
In order to run selenium tests with jboss I have to do the following
modification to current pom.xml:
Index: testsuite/selenium-snifftests/pom.xml
===================================================================
--- testsuite/selenium-snifftests/pom.xml (revision 4045)
+++ testsuite/selenium-snifftests/pom.xml (working copy)
@@ -13,12 +13,12 @@
<properties>
<org.selenium.server.version>1.0.1</org.selenium.server.version>
- <selenium.port>4444</selenium.port>
+ <selenium.port>8444</selenium.port>
<selenium.browser>firefox</selenium.browser>
<selenium.timeout>10000</selenium.timeout>
<selenium.speed>300</selenium.speed>
<selenium.host>localhost</selenium.host>
-
<org.selenium.maven-plugin.version>1.0</org.selenium.maven-plugin.version>
+
<org.selenium.maven-plugin.version>1.0.1</org.selenium.maven-plugin.version>
</properties>
<dependencies>
I've been running these a lot the last two days.
They aren't very useful at the moment for doing pre-commit checks to catch
any introduction of systemic issues primarily for three reasons.
- one, it takes 1 hour 40 mins on my laptop to run the suite. If I want a
'before my change', and 'after my change' I have to run it twice so I can
see a diff in test failures. The name 'snifftests' gives an impression that
this is a quick testsuite to be run before doing a commit :)
- two, at the moment many tests are failing - my last run: Tests run: 248,
Failures: 74, Errors: 21, Skipped: 0
which makes it difficult to determine if some might be due to my code
changes. The same tests sometimes fail with a 'Failure', and sometimes with
'Error', so the end report always looks different making finding effective
differences a challenge even with a diff tool.
- three, some of the tests seem to fail randomly - more likely they are
sensitive to initial conditions which can change if some other test fails to
do a proper cleanup. It can also happen by killing the test in the middle
of execution. The situation is exacerbated by the fact that the tests are
run in random order ...
Point number one could be addressed by making a set of simple to maintain
tests that perform a few operations that touch many aspects of the portal.
These would go into 'snifftests' module. The exhaustive mass of other
detailed tests - which are undoubtedly also a burden to maintain, would go
into 'alltests'.
Point number two could be addressed by creating some kind of final report
that would throw 'failures' and 'errors' in a single set and sort it
alphabetically.
For point number three, a slow workaround is to run another
packaging/pkg/mvn install.
Maybe we could add some cleanup mechanism, so each test can define the tear
down sequence which would go through all the steps ignoring any errors.
Removing test artifacts created during a test is already part of the
existing tests. But if it was separated it could be run explicitly:
mvn -Pselenium-cleanup integration-test
Otherwise thumbs up for the sheer number of these tests, and the systematic
approach ...
- marko
16 years, 1 month
JCR GetCommand --> No such file or directory
by Noel Rocher
Hi all,
I've got a strange thing today. After seeing that default gadgets were
returning HTTP 500 and the gadgets I've added working well. I've decided
to delete all the local directory (here:
/app/jboss/AAA_Platforms_products/EPP/5.0.0/demoPSA/repository/jcr) and
restart EPP to let the re-indexing process work.
After this, all my gadgets return HTTP 500. (Unable to retrieve gadget
xml. HTTP error 500)
Any hint?
--------------------------------
17:25:49,746 ERROR [GetCommand]
/app/jboss/AAA_Platforms_products/EPP/5.0.0/demoPSA/repository/jcr/values/portal-system/e/7/2/5/d/d/6/f0a20c1b479fe0c734aea1d27/e725dd6f0a20c1b479fe0c734aea1d270
(No such file or directory)
javax.jcr.RepositoryException:
/app/jboss/AAA_Platforms_products/EPP/5.0.0/demoPSA/repository/jcr/values/portal-system/e/7/2/5/d/d/6/f0a20c1b479fe0c734aea1d27/e725dd6f0a20c1b479fe0c734aea1d270
(No such file or directory):
/app/jboss/AAA_Platforms_products/EPP/5.0.0/demoPSA/repository/jcr/values/portal-system/e/7/2/5/d/d/6/f0a20c1b479fe0c734aea1d27/e725dd6f0a20c1b479fe0c734aea1d270
(No such file or directory)
at
org.exoplatform.services.jcr.impl.storage.jdbc.JDBCStorageConnection.getItemByName(JDBCStorageConnection.java:918)
at
org.exoplatform.services.jcr.impl.storage.jdbc.JDBCStorageConnection.getItemData(JDBCStorageConnection.java:763)
at
org.exoplatform.services.jcr.impl.dataflow.persistent.WorkspacePersistentDataManager.getItemData(WorkspacePersistentDataManager.java:804)
at
org.exoplatform.services.jcr.impl.dataflow.persistent.CacheableWorkspaceDataManager.getPersistedItemData(CacheableWorkspaceDataManager.java:656)
at
org.exoplatform.services.jcr.impl.dataflow.persistent.CacheableWorkspaceDataManager.getItemData(CacheableWorkspaceDataManager.java:398)
at
org.exoplatform.services.jcr.impl.dataflow.persistent.ACLInheritanceSupportedWorkspaceDataManager.getItemData(ACLInheritanceSupportedWorkspaceDataManager.java:170)
at
org.exoplatform.services.jcr.impl.dataflow.persistent.VersionableWorkspaceDataManager.getItemData(VersionableWorkspaceDataManager.java:140)
at
org.exoplatform.services.jcr.impl.dataflow.session.TransactionableDataManager.getItemData(TransactionableDataManager.java:232)
at
org.exoplatform.services.jcr.impl.core.SessionDataManager.getItemData(SessionDataManager.java:221)
at
org.exoplatform.services.jcr.impl.core.SessionDataManager.getItemData(SessionDataManager.java:178)
at
org.exoplatform.services.jcr.impl.core.SessionDataManager.getItem(SessionDataManager.java:320)
at
org.exoplatform.services.jcr.impl.core.NodeImpl.getProperty(NodeImpl.java:1198)
at
org.exoplatform.services.jcr.webdav.resource.FileResource.dataProperty(FileResource.java:396)
at
org.exoplatform.services.jcr.webdav.resource.FileResource.getContentAsStream(FileResource.java:347)
at
org.exoplatform.services.jcr.webdav.command.GetCommand.get(GetCommand.java:124)
at
org.exoplatform.services.jcr.webdav.WebDavServiceImpl.get(WebDavServiceImpl.java:548)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.exoplatform.services.rest.impl.method.DefaultMethodInvoker.invokeMethod(DefaultMethodInvoker.java:140)
at
org.exoplatform.services.rest.impl.RequestDispatcher.invokeSubResourceMethod(RequestDispatcher.java:266)
...
--------------------------------
--
Noel Rocher
Sr Solution Architect, France
JBoss Enterprise Middleware
Cell: +33 674 847 899
Red Hat France SARL, Immeuble Le Linéa, 1 rue du Général Leclerc, 92047 Paris la Défense CEDEX
Siret : 421 199 464 00064
16 years, 1 month
GateIn trunk activity
by Trong Tran
Hi everybody,
We have just created a GateIn branch from trunk at revision #4047 and name
it as "branch-r4047". The branch activity includes works are planned to do
in 2 weeks that you can refer to the list of JIRA issues here :
http://bit.ly/c2N7bb
Any issue that is fixed/committed in the branch would have a "depends"
relationship link to this activity JIRA issue
https://jira.jboss.org/browse/GTNPORTAL-1457
The life cycle started today. At the end, the branch will be tested to
possibly avoid any regression and bug before merging into the *trunk* main
code base.
Thanks
--
Tran The Trong
eXo Platform SAS
16 years, 1 month
