[jira] Commented: (GERONIMO-4900) MissingDependencyException while deploying EAR in Clustering Environment
[ https://issues.apache.org/jira/browse/GERONIMO-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12766976#action_12766976 ] Gianny Damour commented on GERONIMO-4900: - Hi Ashish, this looks fine. What is the branch you want this patch to be applied to? MissingDependencyException while deploying EAR in Clustering Environment Key: GERONIMO-4900 URL: https://issues.apache.org/jira/browse/GERONIMO-4900 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.4 Reporter: Amit puri Assignee: Ashish Jain Fix For: 2.1.5 Attachments: ClusterTestEAR.ear, Geronimo4900.patch 1. Installed two geronimo instances A and B at different paths 2. Made the following changes to Geronimo A For var\config\config-substitutions.properties clusterNodeName=NODE -- clusterNodeName=NODE-A For var\config\config.xml, add the following contents to module: org.apache.geronimo.configs/farming/2.1.4/car - gbean name=org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=NodeInfo,name=NODE-B gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo attribute name=nameNODE-B/attribute attribute propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor name=extendedJMXConnectorInfo ns:javabean class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2; xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns= ns:property name=usernamesystem/ns:property ns:property name=passwordmanager/ns:property ns:property name=protocolrmi/ns:property ns:property name=hostlocalhost/ns:property ns:property name=port1109/ns:property ns:property name=urlPathJMXConnector/ns:property ns:property name=localfalse/ns:property /ns:javabean/attribute /gbean - 3. Made the following changes to Geronimo B For var\config\config-substitutions.properties clusterNodeName=NODE -- clusterNodeName=NODE-B PortOffset=0 -- PortOffset=10 For var\config\config.xml, add the following contents to module: org.apache.geronimo.configs/farming/2.1.4/car - gbean name=org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=NodeInfo,name=NODE-A gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo attribute name=nameNODE-A/attribute attribute propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor name=extendedJMXConnectorInfo ns:javabean class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2; xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns= ns:property name=usernamesystem/ns:property ns:property name=passwordmanager/ns:property ns:property name=protocolrmi/ns:property ns:property name=hostlocalhost/ns:property ns:property name=port1099/ns:property ns:property name=urlPathJMXConnector/ns:property ns:property name=localfalse/ns:property /ns:javabean/attribute /gbean - 4. Started both Geronimo A and B 5. Ran the following commands in Geronimo_A_Path\bin deploy --user system --password manager start org.apache.geronimo.configs/farming/2.1.4/car deploy --user system --password manager --port 1109 start org.apache.geronimo.configs/farming/2.1.4/car 6. Deployed one sample ClusterTestEAR.ear in Geronimo_A_Path\bin deploy --user system --password manager deploy --targets org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=ConfigurationStore,name=MasterConfigurationStore PATH_SAMPLE\ClusterTestEAR.ear Output: A) Errors in Geronimo A geronimo.log INFO [BasicClusterConfigurationStoreClient] Upload of configuration [default/ClusterTestEAR_G_SLAVE/1.0/ear] - [File(s) transferred to server. Resuming deployment operation.] INFO
[jira] Commented: (GERONIMO-4900) MissingDependencyException while deploying EAR in Clustering Environment
[ https://issues.apache.org/jira/browse/GERONIMO-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12764643#action_12764643 ] Gianny Damour commented on GERONIMO-4900: - This problem is due to the modification of configuration names (suffix '_G_SLAVE' is added to base name) happening during farm deployment. GERONIMO-4556, which should have been included in 2.1.4, addresses this problem. In a few words, configuration names are no longer updated. MissingDependencyException while deploying EAR in Clustering Environment Key: GERONIMO-4900 URL: https://issues.apache.org/jira/browse/GERONIMO-4900 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.4 Reporter: Amit puri Assignee: Ashish Jain Attachments: ClusterTestEAR.ear 1. Installed two geronimo instances A and B at different paths 2. Made the following changes to Geronimo A For var\config\config-substitutions.properties clusterNodeName=NODE -- clusterNodeName=NODE-A For var\config\config.xml, add the following contents to module: org.apache.geronimo.configs/farming/2.1.4/car - gbean name=org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=NodeInfo,name=NODE-B gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo attribute name=nameNODE-B/attribute attribute propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor name=extendedJMXConnectorInfo ns:javabean class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2; xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns= ns:property name=usernamesystem/ns:property ns:property name=passwordmanager/ns:property ns:property name=protocolrmi/ns:property ns:property name=hostlocalhost/ns:property ns:property name=port1109/ns:property ns:property name=urlPathJMXConnector/ns:property ns:property name=localfalse/ns:property /ns:javabean/attribute /gbean - 3. Made the following changes to Geronimo B For var\config\config-substitutions.properties clusterNodeName=NODE -- clusterNodeName=NODE-B PortOffset=0 -- PortOffset=10 For var\config\config.xml, add the following contents to module: org.apache.geronimo.configs/farming/2.1.4/car - gbean name=org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=NodeInfo,name=NODE-A gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo attribute name=nameNODE-A/attribute attribute propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor name=extendedJMXConnectorInfo ns:javabean class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2; xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns= ns:property name=usernamesystem/ns:property ns:property name=passwordmanager/ns:property ns:property name=protocolrmi/ns:property ns:property name=hostlocalhost/ns:property ns:property name=port1099/ns:property ns:property name=urlPathJMXConnector/ns:property ns:property name=localfalse/ns:property /ns:javabean/attribute /gbean - 4. Started both Geronimo A and B 5. Ran the following commands in Geronimo_A_Path\bin deploy --user system --password manager start org.apache.geronimo.configs/farming/2.1.4/car deploy --user system --password manager --port 1109 start org.apache.geronimo.configs/farming/2.1.4/car 6. Deployed one sample ClusterTestEAR.ear in Geronimo_A_Path\bin deploy --user system --password manager deploy --targets org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=ConfigurationStore,name=MasterConfigurationStore PATH_SAMPLE\ClusterTestEAR.ear Output: A) Errors in Geronimo A geronimo.log INFO [BasicClusterConfigurationStoreClient] Upload
Re: using wadi with tomcat web app in an ear
Hi Ashish,
I added a comment to GERONIMO-4900. This problem should have been
fixed as part of 2.1.4; unfortunately, it seems that the fix was
applied to trunk after the creation of the 2.1.4 branch. Could you
please confirm that this works OK against trunk?
Regarding the Tomcat bug reported by this email, the problem is
caused by the AbstractNameQuery used to find the name of Tomcat Web
app context GBean. When the clustered WAR is within an EAR, the query
returned by
WADITomcatClusteringBuilder.createTomcatWebAppContextNameQuery does
not work. I am not sure why as I cannot debug (I cannot build the
server due to missing a dependency org.apache.activemq:activemq-
core:jar:5.3.0...). Having said that, I would suggest to substitute
WADITomcatClusteringBuilder.extractWebModule.with:
protected GBeanData extractWebModule(DeploymentContext
moduleContext) throws DeploymentException {
Configuration configuration = moduleContext.getConfiguration();
try {
return configuration.getGBeans().get
(moduleContext.getModuleName());
} catch (GBeanNotFoundException e) {
throw new DeploymentException(Could not locate web
module gbean in web app configuration, e);
}
}
I hope this helps.
Thanks,
Gianny
On 12/10/2009, at 7:09 PM, Ashish Jain wrote:
Hello Gianny,
I see you have suggested that you were able to figure out the
problem. Can you please suggest what is the problem? Is there any
workaround for this issue?
Any associated JIRA's???
There is another JIRA which has been opened for a similar issue.
Please have a look at the following url https://issues.apache.org/
jira/browse/GERONIMO-4900.
I am still investigating will let you know if I find anything.
Thanks
Ashish
On Tue, Jul 8, 2008 at 6:21 PM, Jason Warner jaw...@gmail.com wrote:
Fantastic, Gianny. Thanks for looking into this!
On Mon, Jul 7, 2008 at 9:19 PM, Gianny Damour
gianny.dam...@optusnet.com.au wrote:
Hello Jason,
I had a quick look and identified the problem. I will check-in a
fix during the day.
Thanks,
Gianny
On 08/07/2008, at 4:10 AM, Jason Warner wrote:
I've spent some time looking at this, but I haven't really gotten
anywhere with it. While debugging I noticed that the error occurs
because the configuration id that is provided by the module upon
loading doesn't match what geronimo is expecting. The problem I'm
having is figuring out where on earth geronimo is getting the
config id that it's expecting. It seems that it's pulling it from
the plan itself, but I'm not sure how. I've been a little busy
lately though and haven't been able to look into it further.
Anyone else have any thoughts on what could be the cause of this?
Thanks
On Tue, Jul 1, 2008 at 5:17 PM, jon.saba...@gmail.com
jon.saba...@gmail.com wrote:
The end goal would be to deploy an ear containing a coupe ejb
modules, wars
rars with wadi clustering enabled for the web apps - packaging the
wadi-webapp.war into an ear was the simplest test I could think of
to see if
the war would deploy cleanly with tomcat-clustering-wadi in the
deployment
plan.
In the ear that I used to test I actually left out application.xml
geronimo-application.xml (just jarred up the war), but here is the
web.xml
geronimo-web.xml I used:
?xml version=1.0?
!DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web
Application
2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd;
web-app
distributable/
context-param
param-nameorg.mortbay.jetty.servlet.SessionPath/param-name
param-value/wadi/param-value
!-- descriptioncreate session cookies with given path/
description
-- !-- upsets geronimo-1.0.0 --
/context-param
!--
Automatically created by Apache Jakarta Tomcat JspC.
Place this fragment in the web.xml before all icon, display-name,
description, distributable, and context-param elements.
--
servlet
servlet-namejsp.aopTest_jsp/servlet-name
servlet-classjsp.aopTest_jsp/servlet-class
/servlet
servlet
servlet-namejsp.destroy_jsp/servlet-name
servlet-classjsp.destroy_jsp/servlet-class
/servlet
servlet
servlet-namejsp.index_jsp/servlet-name
servlet-classjsp.index_jsp/servlet-class
/servlet
servlet
servlet-namejsp.session_jsp/servlet-name
servlet-classjsp.session_jsp/servlet-class
/servlet
servlet-mapping
servlet-namejsp.aopTest_jsp/servlet-name
url-pattern/aopTest.jsp/url-pattern
/servlet-mapping
servlet-mapping
servlet-namejsp.destroy_jsp/servlet-name
url-pattern/destroy.jsp/url-pattern
/servlet-mapping
servlet-mapping
servlet-namejsp.index_jsp/servlet-name
url-pattern/index.jsp/url-pattern
/servlet-mapping
servlet-mapping
servlet-namejsp.session_jsp/servlet-name
url-pattern/session.jsp/url-pattern
/servlet-mapping
!--
All session-config, mime-mapping, welcome-file-list, error-page,
taglib,
resource-ref
Trunk Build Error - geronimo-jetty7-jee5 assembly?
Hi, I am not able to build the geronimo-jetty7-jee5 assembly due to the following error: [java] Exception in thread main java.lang.NoSuchMethodError: org.apache.xalan.transformer.SerializerSwitcher.switchSerializerIfHTML (Ljava/lang/String;Ljava/lang/String;Ljava/util/Properties;Lorg/ apache/xml/serializer/Serializer;)Lorg/apache/xml/serializer/Serializer; [java] at org.apache.xalan.transformer.TransformerIdentityImpl.startElement (TransformerIdentityImpl.java:1044) [java] at org.apache.xml.serializer.TreeWalker.startNode (TreeWalker.java:359) [java] at org.apache.xml.serializer.TreeWalker.traverse (TreeWalker.java:145) [java] at org.apache.xalan.transformer.TransformerIdentityImpl.transform (TransformerIdentityImpl.java:390) [java] at org.apache.geronimo.jaxws.builder.GShellCommandRegistration $Layout.save(GShellCommandRegistration.java:276) [java] at org.apache.geronimo.jaxws.builder.GShellCommandRegistration.main (GShellCommandRegistration.java:158) I am using maven 2.0.10 (tried with maven 2.2.1) with JDK 1.6 (tried with JDK 1.5) with a clean repo. Any clues so that I can try to reproduce a problem with form authentication + WADI clustering? Thanks, Gianny
Re: Duplicate clustername value sets in config-subsititions file
I would say the other way around. A cluster is a type of farm. I see a farm as a set of independent instances. I see a cluster as a set of collaborating instances. You can deploy a non clustered application to a farm whereby you do not have resilience in case of service failure. And you can deploy a clustered application to a farm to increase service resiliency if necessary. Thanks, Gianny On 09/07/2009, at 12:49 PM, Rex Wang wrote: well, Gianny, is a server farm not a type of cluster? -Rex 2009/7/8 Gianny Damour gianny.dam...@optusnet.com.au Hi, It seems to me that farmName would be better than farmingClusterName as there is a clear distinction between a farm and a cluster. Thanks, Gianny On 06/07/2009, at 7:47 PM, chi runhua wrote: Hi all, I just noticed there are 2 pairs of clusterName=CLUSTER_NAME in config-substitions.properties. My understanding of them is one for WADI clustering and another for farming. Can we using different keywords to identify them? ie. farmingClusterName and WADIClusterName or sth. like that. Jeff C
Re: Duplicate clustername value sets in config-subsititions file
Hi, It seems to me that farmName would be better than farmingClusterName as there is a clear distinction between a farm and a cluster. Thanks, Gianny On 06/07/2009, at 7:47 PM, chi runhua wrote: Hi all, I just noticed there are 2 pairs of clusterName=CLUSTER_NAME in config-substitions.properties. My understanding of them is one for WADI clustering and another for farming. Can we using different keywords to identify them? ie. farmingClusterName and WADIClusterName or sth. like that. Jeff C
Re: Web app clustering with WADI in Geronimo Tomcat 2.1.4 broken?
Hi,
In addition to this doc update, what about trying to uniformise the
node name?
if the XSD was not extracted, then it was an oversight.
Thanks,
Gianny
On 08/07/2009, at 12:34 PM, chi runhua wrote:
Hi all,
Doc updated for both 2.1 and 2.2 by now.
If you are using a Tomcat assembly of Geronimo distribution,
replace clustering-wadi/ with tomcat-clustering-wadi/ element
in the deployment plan.
(1) http://cwiki.apache.org/confluence/display/GMOxDOC21/WADI
+Clustering+Support
(2) http://cwiki.apache.org/confluence/display/GMOxDOC22/WADI
+Clustering
And one more question, is there any reason that the schema file
!-- @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom:
0.08in } -- (ie. geronimo-tomcat-clustering-wadi-X.xsd ) was not
extracted to geronimo_home/schema after build.
Thanks.
Jeff C
On Tue, Jul 7, 2009 at 6:58 PM, Gianny Damour
gianny.dam...@optusnet.com.au wrote:
Hi Vamsi,
In the case of tomcat, you need to use the node
tomcat-clustering-wadi /
instead of
clustering-wadi /
I wonder if it would not be better to uniformise node names across
Jetty and Tomcat to prevent confusion.
Thanks,
Gianny
On 07/07/2009, at 4:57 PM, Vamsavardhana Reddy wrote:
I am trying to deploy a clustered web application in Geronimo
Tomcat 2.1.4. I have added distributable/ in web.xml and
clustering-wadi/ in geronimo-web.xml. When I deploy the
application, I am getting the following deployment error:
xml problem for web app .
org.apache.geronimo.common.DeploymentException: xml problem for web
app .
at
org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWeb
App(TomcatModuleBuilder.java:318)
at
org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.createModule
(TomcatModuleBuilder.java:207)
at
org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createMo
dule(AbstractWebModuleBuilder.java:179)
at
org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModul
e(SwitchingModuleBuilder.java:94)
at
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan
(EARConfigBuilder.java:307)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:227)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:134)
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:585)
at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke
(ReflectionMethodInvoker.java:34)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
(GBeanOperation.java:124)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
(GBeanInstance.java:867)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke
(BasicKernel.java:239)
at
org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDe
ploy(AbstractDeployCommand.java:116)
at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run
(DistributeCommand.java:61)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.xmlbeans.XmlException: Invalid deployment
descriptor: errors:
error: cvc-complex-type.2.4a: Expected elements 'work-...@http://
geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 cluster...@http://
geronimo.apache.org/xml/ns/j2ee/application-2.0 web-
contai...@http://geronimo.apache.org/xml/ns/naming-1.2 h...@http://
geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 cross-
cont...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1
disable-cook...@http://geronimo.apache.org/xml/ns/j2ee/web/
tomcat-2.0.1 valve-ch...@http://geronimo.apache.org/xml/ns/j2ee/web/
tomcat-2.0.1 listener-ch...@http://geronimo.apache.org/xml/ns/j2ee/
web/tomcat-2.0.1 tomcat-re...@http://geronimo.apache.org/xml/ns/
j2ee/web/tomcat-2.0.1 mana...@http://geronimo.apache.org/xml/ns/
j2ee/web/tomcat-2.0.1 clus...@http://geronimo.apache.org/xml/ns/
j2ee/web/tomcat-2.0.1 abstract-naming-en...@http://
geronimo.apache.org/xml/ns/naming-1.2 ejb-...@http://
geronimo.apache.org/xml/ns/naming-1.2 ejb-local-...@http://
geronimo.apache.org/xml/ns/naming-1.2 service-...@http://
geronimo.apache.org/xml/ns/naming-1.2 resource-...@http://
geronimo.apache.org/xml/ns/naming-1.2 resource-env-...@http://
geronimo.apache.org/xml/ns/naming-1.2 message-destinat...@http://
geronimo.apache.org/xml/ns/naming-1.2 security-realm-n...@http://
geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 serv...@http://
geronimo.apache.org/xml/ns/deployment-1.2 persiste...@http://
java.sun.com/xml/ns/persistence' instead of 'clustering-w...@http://
geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1' here
Descriptor:
xml-fragment xmlns:tom=http://geronimo.apache.org/xml/ns/j2ee/web/
tomcat-2.0.1
!--web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/
tomcat-2.0.1 xmlns:app=http://geronimo.apache.org/xml/ns/j2ee
Re: Web app clustering with WADI in Geronimo Tomcat 2.1.4 broken?
Hi Vamsi, In the case of tomcat, you need to use the node tomcat-clustering-wadi / instead of clustering-wadi / I wonder if it would not be better to uniformise node names across Jetty and Tomcat to prevent confusion. Thanks, Gianny On 07/07/2009, at 4:57 PM, Vamsavardhana Reddy wrote: I am trying to deploy a clustered web application in Geronimo Tomcat 2.1.4. I have added distributable/ in web.xml and clustering-wadi/ in geronimo-web.xml. When I deploy the application, I am getting the following deployment error: xml problem for web app . org.apache.geronimo.common.DeploymentException: xml problem for web app . at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWeb App(TomcatModuleBuilder.java:318) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.createModule (TomcatModuleBuilder.java:207) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createMo dule(AbstractWebModuleBuilder.java:179) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModul e(SwitchingModuleBuilder.java:94) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan (EARConfigBuilder.java:307) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:227) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:134) 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:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke (ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDe ploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run (DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: errors: error: cvc-complex-type.2.4a: Expected elements 'work-...@http:// geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 cluster...@http:// geronimo.apache.org/xml/ns/j2ee/application-2.0 web- contai...@http://geronimo.apache.org/xml/ns/naming-1.2 h...@http:// geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 cross- cont...@http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 disable-cook...@http://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-2.0.1 valve-ch...@http://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-2.0.1 listener-ch...@http://geronimo.apache.org/xml/ns/j2ee/ web/tomcat-2.0.1 tomcat-re...@http://geronimo.apache.org/xml/ns/ j2ee/web/tomcat-2.0.1 mana...@http://geronimo.apache.org/xml/ns/ j2ee/web/tomcat-2.0.1 clus...@http://geronimo.apache.org/xml/ns/ j2ee/web/tomcat-2.0.1 abstract-naming-en...@http:// geronimo.apache.org/xml/ns/naming-1.2 ejb-...@http:// geronimo.apache.org/xml/ns/naming-1.2 ejb-local-...@http:// geronimo.apache.org/xml/ns/naming-1.2 service-...@http:// geronimo.apache.org/xml/ns/naming-1.2 resource-...@http:// geronimo.apache.org/xml/ns/naming-1.2 resource-env-...@http:// geronimo.apache.org/xml/ns/naming-1.2 message-destinat...@http:// geronimo.apache.org/xml/ns/naming-1.2 security-realm-n...@http:// geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 serv...@http:// geronimo.apache.org/xml/ns/deployment-1.2 persiste...@http:// java.sun.com/xml/ns/persistence' instead of 'clustering-w...@http:// geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1' here Descriptor: xml-fragment xmlns:tom=http://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-2.0.1 !--web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web/ tomcat-2.0.1 xmlns:app=http://geronimo.apache.org/xml/ns/j2ee/ application-2.0-- dep:environment xmlns:dep=http://geronimo.apache.org/xml/ns/ deployment-1.2 dep:moduleId dep:groupIdpackt-samples/dep:groupId dep:artifactIdhelloworld-cluster/dep:artifactId dep:version1.0/dep:version dep:typewar/dep:type /dep:moduleId dep:dependencies/ /dep:environment tom:context-root/helloworld-cluster/tom:context-root tom:clustering-wadi/ /xml-fragment at org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.validateDD (XmlBeansUtil.java:187) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.getTomcatWeb App(TomcatModuleBuilder.java:312) ... 17 more Appears like the deployer is not liking the tag clustering-wadi/. I do have org.apache.geronimo.configs/tomcat6-clustering-wadi/ 2.1.4/car and org.apache.geronimo.configs/tomcat6-clustering- builder-wadi/2.1.4/car configurations started before deploying the web application. I tried deploying the same application in Geronimo Tomcat
Re: Are these hardcodeed user/pass/host/port in plan.xml of farming correct ?
Hi,
The way to configure this attribute in config.xml is to use
attribute
propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnecto
rInfoEditor ...
See
http://cwiki.apache.org/GMOxDOC22/farming-using-deployment.html
for a full example.
Thanks,
Gianny
On 19/06/2009, at 6:01 PM, Shawn Jiang wrote:
I can NOT find xml-attribute in schema of config.xml : http://
geronimo.apache.org/schemas-2.1/docs/attributes-1.2.xsd.html
So that I don't think config.xml support xml-attribute which only
exists in general deployment plan: http://geronimo.apache.org/
schemas-2.1/docs/geronimo-module-1.2.xsd.html
Anyway, I'll give it a try and update the result here.
On Fri, Jun 19, 2009 at 3:41 PM, David Jencks
david_jen...@yahoo.com wrote:
On Jun 19, 2009, at 12:13 AM, Shawn Jiang wrote:
Can anyone shed some light on this ?
The entire bit of xml is a single attribute for this gbean so if
you want to modify something via config.xml you'd need the entire
xml snippet in config.xml. At that point the ${} substitutions
ought to work.
I don't recall anything like this in the standard geronimo plugins
but we do something like this in the tck server to redefine the
default environments for the builder so as to add some dependencies
needed by all the test apps.
hope this relates to your question...
thanks
david jencks
On Tue, Jun 16, 2009 at 11:26 AM, Shawn Jiang
genspr...@gmail.com wrote:
Another question, Seems config.xml does not support
xml-attribute name=extendedJMXConnectorInfo
ns:javabean xmlns:ns=http://geronimo.apache.org/xml/
ns/deployment/javabean-1.0
class=org.apache.geronimo.farm.deployment.DeploymentExtendedJMXConne
ctorInfo
ns:property name=usernamesystem/ns:property
ns:property name=passwordmanager/ns:property
ns:property name=protocolrmi/ns:property
ns:property name=hostlocalhost/ns:property
ns:property name=port ${NamingPort +
PortOffset}/ns:property
ns:property name=urlPathJMXConnector/
ns:property
ns:property name=localtrue/ns:property
/ns:javabean
/xml-attribute
style configuration. I have to add a port attribute to
BasicNodeInfo so that I can expose it to config.xml in pom.xml.
Also, I agree that username and password should not be in config-
substitutions.properties. But I do think they should be exposed
in config.xml so that the user can change them when he change the
user/password of server.
On Mon, Jun 15, 2009 at 6:50 PM, Gianny Damour
gianny.dam...@optusnet.com.au wrote:
Hi Shawn,
username, password and host should not be in config-
substitutions.properties.
port is the only candidate and should be set to ${NamingPort +
PortOffset}
Thanks,
Gianny
On 15/06/2009, at 6:14 PM, Shawn Jiang wrote:
In Gtrunk\plugins\clustering\farming\src\main\plan\plan.xml,
there are some hardcodeed ser/pass/host/port string in it. I'm
not sure if they should be something like ${PlanClusterNodeName}
so that they can be set in server\config
\config_substitution.properties.
gbean name=NodeInfo
class=org.apache.geronimo.farm.config.BasicNodeInfo
attribute name=name${PlanClusterNodeName}/attribute
xml-attribute name=extendedJMXConnectorInfo
ns:javabean xmlns:ns=http://geronimo.apache.org/xml/
ns/deployment/javabean-1.0
class=org.apache.geronimo.farm.deployment.DeploymentExtendedJMXConne
ctorInfo
ns:property name=usernamesystem/ns:property
ns:property name=passwordmanager/ns:property
ns:property name=protocolrmi/ns:property
ns:property name=hostlocalhost/ns:property
ns:property name=port1099/ns:property
ns:property name=urlPathJMXConnector/
ns:property
ns:property name=localtrue/ns:property
/ns:javabean
/xml-attribute
/gbean
Can anyone give me any thoughts ?
--
Shawn
--
Shawn
--
Shawn
--
Shawn
Re: Are these hardcodeed user/pass/host/port in plan.xml of farming correct ?
Hi Shawn,
username, password and host should not be in config-
substitutions.properties.
port is the only candidate and should be set to ${NamingPort +
PortOffset}
Thanks,
Gianny
On 15/06/2009, at 6:14 PM, Shawn Jiang wrote:
In Gtrunk\plugins\clustering\farming\src\main\plan\plan.xml,
there are some hardcodeed ser/pass/host/port string in it. I'm not
sure if they should be something like ${PlanClusterNodeName} so
that they can be set in server\config\config_substitution.properties.
gbean name=NodeInfo
class=org.apache.geronimo.farm.config.BasicNodeInfo
attribute name=name${PlanClusterNodeName}/attribute
xml-attribute name=extendedJMXConnectorInfo
ns:javabean xmlns:ns=http://geronimo.apache.org/xml/
ns/deployment/javabean-1.0
class=org.apache.geronimo.farm.deployment.DeploymentExtendedJMXConnec
torInfo
ns:property name=usernamesystem/ns:property
ns:property name=passwordmanager/ns:property
ns:property name=protocolrmi/ns:property
ns:property name=hostlocalhost/ns:property
ns:property name=port1099/ns:property
ns:property name=urlPathJMXConnector/
ns:property
ns:property name=localtrue/ns:property
/ns:javabean
/xml-attribute
/gbean
Can anyone give me any thoughts ?
--
Shawn
[jira] Resolved: (GERONIMO-4626) Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing
[ https://issues.apache.org/jira/browse/GERONIMO-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour resolved GERONIMO-4626. - Resolution: Fixed Fix Version/s: (was: 2.2) Fix has been checked in and integration tested with mod_jk. Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing Key: GERONIMO-4626 URL: https://issues.apache.org/jira/browse/GERONIMO-4626 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.4 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1.5 It is not possible to fulfill session affinity with Apache mod_jk as the value of the JSESSIONID cookie does not embed a jvmRoute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4626) Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing
Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing Key: GERONIMO-4626 URL: https://issues.apache.org/jira/browse/GERONIMO-4626 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.1.4 Reporter: Gianny Damour Assignee: Gianny Damour It is not possible to fulfill session affinity with Apache mod_jk as the value of the JSESSIONID cookie does not embed a jvmRoute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
On 08/04/2009, at 5:10 PM, David Jencks wrote:
On Apr 7, 2009, at 1:46 AM, Gianny Damour wrote:
On 07/04/2009, at 4:00 AM, David Jencks wrote:
There are two things that worry me about this.
1. IIUC whenever you include a jar in a configuration all the
configuration's parents get added as parents to the jar's global
classloader, in this code in MultiParentClassLoader2:
protected void addParents(SetGlobalClassLoader
globalClassLoaders) {
for (GlobalClassLoader globalClassLoader :
globalClassLoaders) {
for (ClassLoader parent : parents) {
globalClassLoader.addParent(parent);
}
}
}
I don't think this is acceptable. I think that once we have a
GlobalClassloader set up for a jar it needs to be immutable.
With your code which jar a class is loaded from could depend on
which configurations are started when you try to load the class.
I agree and this was one of my concerns; though it can be
addressed. The problem is that the dependencies defined by a given
config may not be complete.
Let's assume:
* config A imports dependency D1, D4;
* config B imports dependency D2 and D3;
* config B is a child of config A; and
* D1 and D3 are declared as maven dependencies for D2.
The current implementation builds a partial tree of
GlobalClassLoaders based on the dependencies defined by a given
config. This means that in the above scenario when config B is
started only GlobalClassLoaders for D2 and D3 are put at the right
place according to their maven dependencies, i.e. D3 is a parent
of D2. D1 is artificially put as a parent of D2 by adding config
A's classloader to D2.
A better implementation would be to add the relevant
GlobalClassLoaders defined by parent configurations, in our
example D1, to the GlobalClassLoaders used by a given config, in
our example D2.
I can fix this problem.
I'm sure I haven't thought this through completely but I really
wonder if adding parents to the global classloaders is
necessary. If we ignore geronimo plugins based on javaee apps
for a moment, geronimo plugins won't have any classes in them,
and jars will have maven dependencies on the appropriate other
jars anyway. So I think that in the normal case adding these
parents won't add any missing classes. Constructing a
classloader for a javaee app that can be used as a parent of some
other classloader is a geronimo specific feature anyway not
supported by maven so I think it would be OK to just have people
include such dependencies in the baseURL-additional.xml (or the
pom, possibly).
If we drop this add-parents behavior we might need to add
classloading rules to the global classloaders and either specify
it directly or push it down from a plugin config. Again I
haven't thought this through.
I think that classloading rules are only going to be useful to
isolate javaee apps. I think this is going to be OK as
classloading rules were introduced to better isolate javaee apps
from their runtime container.
2. IIUC the baseURL-additional.xml only lets you add to the
maven pom. I think we need to be able to delete stuff too.
I can add this functionality.
Assuming that the above is fixed by mid-next week, do you think
that current classloading problems would be resolved? Or do you
think that re-platforming to an OSGi approach will provide a
better mileage?
I'm being led into more extensive changes, I hope to have something
working tomorrow or the next day. I think this will be a good and
illuminating step towards osgi and that most likely releasing 2.2
with this system will be a good idea before attempting more
extensive osgi integration.
Based on this fact, it appears to me as useless to continue further
down the road I explored.
I do still believe that simplifying the configuration model is more
important than OSGi integration. Making IoC simpler (e.g. no need to
declare or annotate injected attributes or references), more flexible
(e.g. use of service factory) and to the point (i.e. less verbose) is
hopefully part of the extensive changes. Re-using Apache Felix iPOJO
would be good.
Thanks,
Gianny
thanks
david jencks
Thanks,
Gianny
As a probably easy-to-fix bug I think that we currently decide if
something is a jar or a plugin in MavenDependencyResolver by
whether there is exactly one URL for the artifact. However a
geronimo plugin with classes inside -- say an ejb jar -- could
have exactly one url but not be a jar.
These are just my first impressions, I'll keep looking.
thanks!
david jencks
Re: Whence the geronimo kernel?
On 07/04/2009, at 4:00 AM, David Jencks wrote:
There are two things that worry me about this.
1. IIUC whenever you include a jar in a configuration all the
configuration's parents get added as parents to the jar's global
classloader, in this code in MultiParentClassLoader2:
protected void addParents(SetGlobalClassLoader
globalClassLoaders) {
for (GlobalClassLoader globalClassLoader :
globalClassLoaders) {
for (ClassLoader parent : parents) {
globalClassLoader.addParent(parent);
}
}
}
I don't think this is acceptable. I think that once we have a
GlobalClassloader set up for a jar it needs to be immutable. With
your code which jar a class is loaded from could depend on which
configurations are started when you try to load the class.
I agree and this was one of my concerns; though it can be addressed.
The problem is that the dependencies defined by a given config may
not be complete.
Let's assume:
* config A imports dependency D1, D4;
* config B imports dependency D2 and D3;
* config B is a child of config A; and
* D1 and D3 are declared as maven dependencies for D2.
The current implementation builds a partial tree of
GlobalClassLoaders based on the dependencies defined by a given
config. This means that in the above scenario when config B is
started only GlobalClassLoaders for D2 and D3 are put at the right
place according to their maven dependencies, i.e. D3 is a parent of
D2. D1 is artificially put as a parent of D2 by adding config A's
classloader to D2.
A better implementation would be to add the relevant
GlobalClassLoaders defined by parent configurations, in our example
D1, to the GlobalClassLoaders used by a given config, in our example D2.
I can fix this problem.
I'm sure I haven't thought this through completely but I really
wonder if adding parents to the global classloaders is necessary.
If we ignore geronimo plugins based on javaee apps for a moment,
geronimo plugins won't have any classes in them, and jars will have
maven dependencies on the appropriate other jars anyway. So I
think that in the normal case adding these parents won't add any
missing classes. Constructing a classloader for a javaee app that
can be used as a parent of some other classloader is a geronimo
specific feature anyway not supported by maven so I think it would
be OK to just have people include such dependencies in the
baseURL-additional.xml (or the pom, possibly).
If we drop this add-parents behavior we might need to add
classloading rules to the global classloaders and either specify it
directly or push it down from a plugin config. Again I haven't
thought this through.
I think that classloading rules are only going to be useful to
isolate javaee apps. I think this is going to be OK as classloading
rules were introduced to better isolate javaee apps from their
runtime container.
2. IIUC the baseURL-additional.xml only lets you add to the maven
pom. I think we need to be able to delete stuff too.
I can add this functionality.
Assuming that the above is fixed by mid-next week, do you think that
current classloading problems would be resolved? Or do you think that
re-platforming to an OSGi approach will provide a better mileage?
Thanks,
Gianny
As a probably easy-to-fix bug I think that we currently decide if
something is a jar or a plugin in MavenDependencyResolver by
whether there is exactly one URL for the artifact. However a
geronimo plugin with classes inside -- say an ejb jar -- could have
exactly one url but not be a jar.
These are just my first impressions, I'll keep looking.
thanks!
david jencks
Re: First step towards making kernel more classloader-agnostic
Hi, Those are great changes to merge. Well, the xbean-naming comment could be improved thought :) Thanks, Gianny On 18/03/2009, at 9:47 PM, Gianny Damour wrote: On 18/03/2009, at 6:24 PM, David Jencks wrote: After more work than I expected I have the server running with Configuration being basically a pojo rather than constructing the classloaders itself in its constructor. I commited my current work in sandbox/djencks/framework together with a patch (cl- factore.patch.1 -- I seem to have misspelled factory) for the rest of geronimo. The server starts and seems to work although a bunch of testsuite tests fail when run automatically when I try the same thing by hand they seem to work. Some of the changes: -- separate classloader construction into a factory -- track resolved configuration dependencies in a separate object -- configuration now is a data container -- I basically eliminated the EditableKernelConfigurationManager which is used in a few places to modify existing configurations. I've always thought this ability was a rather bad idea. I would rather replace it with something like always storing the plan into plugins (done now with car-maven-plugin, we just need to add it for stuff deployed into geronimo directly) and providing a way to edit the plan and redeploy the plugin with a new version number (or only letting you edit snapshot plugins) -- There's been a long-standing problem that many of the auxillary builders can't figure out whether they need to add dependencies to the environment until after they get to scan for annotations at which time it was too late to modify the classloader. As a result most of these builders always add their dependencies whether or not they are actually needed. I think that since the classloader construction is separated from the configuration initialization we can now solve this problem and create new classloaders each time we update the dependencies. I haven't verified this but am rather hopeful. I think that this is a bit of a conceptual simplification of some of the work the configuration manager is doing and that it would be ok to commit these changes to trunk. The main objection I could see would be to the EditiableConfigurationManager change. This functionality can probably be added back without too much difficulty although I really think it is a mistake. Thoughts? The main change is in rev 755494, I removed an accidental file in rev 755496. I haven't had a chance to look at Gianny's classloader-per-jar patch but I'm hopeful that can be merged into this without excessive difficulty. Based on a cursory review of the changes, a simple change to JarFileClassLoaderFactory should be enough to merge the proposed changes. If the patch makes sense, then I can easily merge against this branch. I will review in more details the overall change, however the extraction of a classloader factory is certainly good. Thanks, Gianny many thanks david jencks
Re: First step towards making kernel more classloader-agnostic
On 18/03/2009, at 6:24 PM, David Jencks wrote: After more work than I expected I have the server running with Configuration being basically a pojo rather than constructing the classloaders itself in its constructor. I commited my current work in sandbox/djencks/framework together with a patch (cl- factore.patch.1 -- I seem to have misspelled factory) for the rest of geronimo. The server starts and seems to work although a bunch of testsuite tests fail when run automatically when I try the same thing by hand they seem to work. Some of the changes: -- separate classloader construction into a factory -- track resolved configuration dependencies in a separate object -- configuration now is a data container -- I basically eliminated the EditableKernelConfigurationManager which is used in a few places to modify existing configurations. I've always thought this ability was a rather bad idea. I would rather replace it with something like always storing the plan into plugins (done now with car-maven-plugin, we just need to add it for stuff deployed into geronimo directly) and providing a way to edit the plan and redeploy the plugin with a new version number (or only letting you edit snapshot plugins) -- There's been a long-standing problem that many of the auxillary builders can't figure out whether they need to add dependencies to the environment until after they get to scan for annotations at which time it was too late to modify the classloader. As a result most of these builders always add their dependencies whether or not they are actually needed. I think that since the classloader construction is separated from the configuration initialization we can now solve this problem and create new classloaders each time we update the dependencies. I haven't verified this but am rather hopeful. I think that this is a bit of a conceptual simplification of some of the work the configuration manager is doing and that it would be ok to commit these changes to trunk. The main objection I could see would be to the EditiableConfigurationManager change. This functionality can probably be added back without too much difficulty although I really think it is a mistake. Thoughts? The main change is in rev 755494, I removed an accidental file in rev 755496. I haven't had a chance to look at Gianny's classloader-per-jar patch but I'm hopeful that can be merged into this without excessive difficulty. Based on a cursory review of the changes, a simple change to JarFileClassLoaderFactory should be enough to merge the proposed changes. If the patch makes sense, then I can easily merge against this branch. I will review in more details the overall change, however the extraction of a classloader factory is certainly good. Thanks, Gianny many thanks david jencks
[jira] Created: (GERONIMO-4590) One ClassLoader per Jar Model
One ClassLoader per Jar Model - Key: GERONIMO-4590 URL: https://issues.apache.org/jira/browse/GERONIMO-4590 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour As discussed on @dev, to reduce the number of ClassCastExceptions caused by collaborating configurations importing the same dependencies, the classloading design can be improved to use a shared and global poll of classloaders. Each classloader in this global poll is mapped to only one JAR. They are put in a hierarchy according to their maven dependency declarations. As maven dependencies may not be systematically correct, additional dependency declarations can also be provided by dropping a XML file artifactId-version-additional.xml beside the JAR or POM file artifactId-version.jar (.pom) whose dependencies are to be supplemented. This patch is a preview of the functionality to trigger more discussions. 22 out of the 74 configurations of the jetty-jee5 assembly can start fine with this patch. The failure observed for the failing configuration appears to be another maven dependency declaration issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4590) One ClassLoader per Jar Model
[ https://issues.apache.org/jira/browse/GERONIMO-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-4590: Attachment: additional-maven-dependencies.jar OneClassLoaderPerJar.txt OneClassLoaderPerJar.txt is a geronimo-kernel patch. additional-maven-dependencies.jar is a jar to be unpacked in the geronimo repository, which include additional maven dependency declarations for specific JAR. One ClassLoader per Jar Model - Key: GERONIMO-4590 URL: https://issues.apache.org/jira/browse/GERONIMO-4590 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Attachments: additional-maven-dependencies.jar, OneClassLoaderPerJar.txt As discussed on @dev, to reduce the number of ClassCastExceptions caused by collaborating configurations importing the same dependencies, the classloading design can be improved to use a shared and global poll of classloaders. Each classloader in this global poll is mapped to only one JAR. They are put in a hierarchy according to their maven dependency declarations. As maven dependencies may not be systematically correct, additional dependency declarations can also be provided by dropping a XML file artifactId-version-additional.xml beside the JAR or POM file artifactId-version.jar (.pom) whose dependencies are to be supplemented. This patch is a preview of the functionality to trigger more discussions. 22 out of the 74 configurations of the jetty-jee5 assembly can start fine with this patch. The failure observed for the failing configuration appears to be another maven dependency declaration issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
On 13/03/2009, at 6:44 PM, David Jencks wrote: On Mar 12, 2009, at 10:02 AM, David Jencks wrote: On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote: On 12/03/2009, at 4:29 AM, David Jencks wrote: I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. IMO the danger here is that the maven pom may not exist or may be wrong. OSGI has the same problem in that the vast majority of released jars don't have osgi manifests. I think I saw a rumor that spring spent a lot of effort osgi-ifying a lot of commonly used jars to try to solve this problem. I also don't know if there are situations in which a small number of closely related jars need to be loaded in a single classloader, perhaps because one of the jars is optional but if present the main jar needs access to its classes. I think there was an osgi feature that looked sort of like this. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Unless you are pretty sure we won't have the kind of problems with bad community metadata suggested above it might be a good idea to do this in a sandbox branch? Thinking about this more I really expect the code will be easy compared to straightening out the dependencies :-( As a concrete example, the JACC spec needs the servlet and ejb specs but in our maven poms we've excluded them as dependencies so as to make it easier to upgrade the jars independently. While (especially with maven 3) we can probably put in the dependencies with version ranges, they aren't there now. Getting the server to work again may be time consuming. I really hope I'm wrong :-D Hi David, I just created a patch http://issues.apache.org/jira/browse/GERONIMO-4590 which provides a preview of the code changes necessary to move to a one classloader per jar model. It is not yet good enough to create a branch as only 22 configurations out of the 27 of the jetty-jee5 assemblies can successfully start (failing config is certainly a maven dependency problem). The design is rather simple: 1. when a configuraton classloader is created, configuration dependencies and classPath entries are used to generate a bunch of GlobalClassLoaders - one per dependency or one for all the classPath entries. 2. this set of GlobalClassLoaders are put in a hierarchy according to maven dependency declarations (note that dependency version declarations are not honored even if present). Maven dependency declarations can be augmented by dropping an XML file with maven like dependencies declarations. 3. the classloaders of the parent configuration of the configuration being created are added to this set of GlobalClassLoaders. 4. this set of GlobalClassLoaders is used under the hood of the configuration's MultiParentClassLoader to implement find class and resources contracts. Four maven dependency declarations had to be supplemented to start 22 configurations. Assuming the same ratio, about 14 dependency declarations may have to be supplemented to start the jetty-jee5 assembly. This is not too involving. Could you please have a cursory review of this preview patch and let me know your thoughts? Thanks, Gianny thanks david jencks thanks david jencks Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11
Re: Whence the geronimo kernel?
On 12/03/2009, at 4:29 AM, David Jencks wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's
Re: Whence the geronimo kernel?
On 12/03/2009, at 5:26 AM, David Jencks wrote: On Mar 11, 2009, at 12:57 AM, Gianny Damour wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http:// www.grails.org/Spring+Bean+Builder). That looks nice, but is there any syntax validation possible? I'm pretty much unwilling to use groovy for anything at this point due to my bad experiences with lack of pre-runtime syntax validation and unclear error messages writing some simple gshell commands. xml is really horrible but most editors do support validation against a schema. This is the weakness but also the power of the approach whereby users can mix arbitrary code and declarations. Syntax validation is pretty much addressed by IDEs; however, only testing the script will prove that it does what it is supposed to do. I do understand your reticence thought and I will not insist. On the other hand, I think we could come up with something even shorter, clearer, and to the point, with syntax validation, using scala. This is an interesting idea. I am keen to see something more streamlined and efficient than yet another XML approach to configure a bunch of services in the kernel! Thanks, Gianny thanks david jencks If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean- spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The init method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies
Re: Whence the geronimo kernel?
Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/ import dependency declarations. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/ Spring+Bean+Builder). If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean- spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The init method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import- bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well
Re: Whence the geronimo kernel?
Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no conflicts between the two versions of bundle D). OSGi has a much more powerful CLing mechanism where you can express lots of different constraints. The drawback is that establishing the classloader can take a bit of time, so going to OSGi most certainly leads to a big slowdown at startup while creating the classloaders. Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ... I certainly don't want to say OSGi is not the way to go, just want to make the point that there are benefits but also drawbacks. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http:// www.grails.org/Spring+Bean+Builder). If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean- spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects
[jira] Commented: (GERONIMO-4579) There are errors during zip file extracted on Linux OS using farm clustering
[
https://issues.apache.org/jira/browse/GERONIMO-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680397#action_12680397
]
Gianny Damour commented on GERONIMO-4579:
-
I do not understand what you mean by files are not in the correct path.
Can you start the WAR on NODE-A?
There are errors during zip file extracted on Linux OS using farm clustering
Key: GERONIMO-4579
URL: https://issues.apache.org/jira/browse/GERONIMO-4579
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.4
Environment: SW:
JAVA6+WIN2008+SLES10SP2
HW:
Intel x86
Reporter: Zhen Chen
Attachments: zip_extracted_errors .jpg
Can't deploy a war to farm clustering successfully, because the zip file
extracted on Linux OS is wrong.
After deploying a war to farm clustering(ex, NODE-A,NODE-B), I found that the
files are not in the correct path, while named in the form like
WEB-INF\classes\..
.java in cluster-repository on Linux OS.
I have tried that on RHEL 5.2, SLES 10 OS. Same error occurs.
I think this is a bug, Please check it.
My steps:
1.Login on NODE-A server
1.1 For var\config\config-substitutions.properties
{code:xml}
clusterNodeName=NODE -- clusterNodeName=NODE-A
RemoteDeployHostname=MachineA_IP
{code}
1.2 For var\config\config.xml, add the following contents to module:
org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
{code:xml}
gbean
name=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2
.1.4/car,j2eeType=NodeInfo,name=NodeInfoB
gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo
attribute name=nameNODE-B/attribute
attribute
propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor
name=extendedJMXConnectorInfo
ns:javabean
class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo
xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2;
xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns=
ns:property name=usernamesystem/ns:property
ns:property name=passwordmanager/ns:property
ns:property name=protocolrmi/ns:property
ns:property name=hostMachineB_IP/ns:property
ns:property name=port1099/ns:property
ns:property name=urlPathJMXConnector/ns:property
ns:property name=localfalse/ns:property
/ns:javabean/attribute
/gbean
{code}
2.Login on NODE-B server
2.1 For var\config\config-substitutions.properties
{code:xml}
clusterNodeName=NODE -- clusterNodeName=NODE-B
RemoteDeployHostname=MachineB_IP
{code}
2.2 For var\config\config.xml, add the following contents to module:
org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
{code:xml}
gbean
name=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/far
ming/2.1.4-SNAPSHOT/car,j2eeType=NodeInfo,name=NodeInfoA
gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo
attribute name=nameNODE-A/attribute
attribute
propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor
name=extendedJMXConnectorInfo
ns:javabean
class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo
xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2;
xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns=
ns:property name=usernamesystem/ns:property
ns:property name=passwordmanager/ns:property
ns:property name=protocolrmi/ns:property
ns:property name=hostMachineA_IP/ns:property
ns:property name=port1099/ns:property
ns:property name=urlPathJMXConnector/ns:property
ns:property name=localfalse/ns:property
/ns:javabean/attribute
/gbean
{code}
3. Start NODE- A server , and NODE-B server
4.Run the following commands in GERONIMO_HOME\bin in Machine A
{code:xml}
4.1 deploy.bat/sh --user system --password manager start
org.apache.geronimo.configs/farming//car
4.2 deploy.bat/sh --user system --password manager --host MachineB_IP
start org.apache.geronimo.configs/farming//car
{code}
5.deploy.bat/sh --user system --password manager deploy --targets
{code:xml}
org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car,j2eeType=Confi
gurationStore,name
Heads-up - Clustered OpenJPA DataCache implementation with wadi-cache
Hi, I have been working on an implementation of the DataCache API based on wadi-cache, a distributed, replicated and transaction cache. The implementation can be found there: https://svn.codehaus.org/wadi/trunk/wadi/wadi-cache-openjpa/src/main/ java/org/codehaus/wadi/cache/openjpa/WADIDataCache.java and a smoke test there: https://svn.codehaus.org/wadi/trunk/wadi/wadi-cache-openjpa/src/test/ java/org/codehaus/wadi/cache/openjpa/itest/SmokeTest.java A couple of things still need to be implemented: 1. DataCache.lock/unlock contracts: even if it is quite easy to implement them, I believe this may result in a noticeable reduction of throughput for cache misses. I wonder if it would not be preferable to have a more optimistic implementation strategy with retires. 2. removeAllInternal(Class cls, boolean subclasses): I intend to provide an implementation as soon as distributed service operations against data cache entries is supported by wadi-cache. 3. The timeout of cache entries is not honored: whatever the timeout attribute value of @DataCache, entities have their timeout defaulted by WADI. I intend to work on a fix. So far, the implementation has been tested within Geronimo behind a transactional EJB. If you would like to give me a hand to complete implementation or tests, then please feel free to ping me. Thanks, Gianny
[jira] Closed: (GERONIMO-4556) Farm deployment of configurations using JNDI resource references does not work
[
https://issues.apache.org/jira/browse/GERONIMO-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour closed GERONIMO-4556.
---
Resolution: Fixed
Fix Version/s: 2.1.4
Farmed modules are no more renamed to prevent issues with JNDI resource
reference resolutions. The master module is name named X_G_MASTER where X is
the artifact id of the farmed module.
Farm deployment of configurations using JNDI resource references does not work
--
Key: GERONIMO-4556
URL: https://issues.apache.org/jira/browse/GERONIMO-4556
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.1.3
Reporter: Gianny Damour
Assignee: Gianny Damour
Fix For: 2.1.4
Due to the transformation of the name of a configuration when it is
distributed to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI
resource references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4556) Farm deployment of configurations using JNDI resource references does not work
Farm deployment of configurations using JNDI resource references does not work
--
Key: GERONIMO-4556
URL: https://issues.apache.org/jira/browse/GERONIMO-4556
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: deployment
Affects Versions: 2.1.3
Reporter: Gianny Damour
Due to the transformation of the name of a configuration when it is distributed
to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI resource
references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4556) Farm deployment of configurations using JNDI resource references does not work
[
https://issues.apache.org/jira/browse/GERONIMO-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour updated GERONIMO-4556:
Description:
Due to the transformation of the name of a configuration when it is distributed
to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI resource
references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code}
was:
Due to the transformation of the name of a configuration when it is distributed
to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI resource
references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code]
Farm deployment of configurations using JNDI resource references does not work
--
Key: GERONIMO-4556
URL: https://issues.apache.org/jira/browse/GERONIMO-4556
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.1.3
Reporter: Gianny Damour
Due to the transformation of the name of a configuration when it is
distributed to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI
resource references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4556) Farm deployment of configurations using JNDI resource references does not work
[
https://issues.apache.org/jira/browse/GERONIMO-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour reassigned GERONIMO-4556:
---
Assignee: Gianny Damour
Farm deployment of configurations using JNDI resource references does not work
--
Key: GERONIMO-4556
URL: https://issues.apache.org/jira/browse/GERONIMO-4556
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.1.3
Reporter: Gianny Damour
Assignee: Gianny Damour
Due to the transformation of the name of a configuration when it is
distributed to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI
resource references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Use apache's nexus for release and snapshot staging and deployment
+1 Gianny On 18/02/2009, at 6:17 AM, David Jencks wrote: Last week I noted that there's an apache nexus installation that we can use for staging and deployment... https://issues.apache.org/ jira/browse/INFRA-1896 They suggest a vote on this, so here goes. Lets ask sonatype/infra to move geronimo to using nexus for deployment. +1 about time already +0 needs more thought -1... I prefer doing things the hard way :-D Vote open for 72 hours. thanks david jencks
Re: Pulling Geronimo Configuration
On 12/02/2009, at 9:46 AM, David Jencks wrote: I think it would be great to get node discovery based on WADI working. Unfortunately I was in too much of a hurry when I implemented the plugin based farming to look into how to do this. Where is your ejb client failover code? Hi David, The code is located in the project plugins/openejb/geronimo-openejb-clustering-wadi The interesting class is NetworkConnectorMonitor where the method registerListenerForMembershipUpdates provides to joining peers the list of OpenEJB deployments currently running along with the network connector URIs EJB clients can used to access the EJB server running these deployments. Reading the code once again, it actually uses the geronimo-clustering API to track joining/leaving SessionManagers. So, if a BasicWADISessionManager is installed on admin and farm nodes the same type of approach may be used. I can certainly work on swapping the current node discovery implementation with a WADI implementation. Chance, do you want to give it a shot? Thanks, Gianny thanks david jencks
Re: Pulling Geronimo Configuration
On 12/02/2009, at 6:08 AM, Chance Yeoman wrote: On Feb 11, 2009, at 9:32 AM, Chance Yeoman wrote: Thank you for information, My understanding of the plugin-based farming is incomplete as well. From the Geronimo 2.1 documentation of plugin-based farming, it did not seem as if node server configuration was checked and updated upon startup. Is this new to Geronimo 2.2 farming? I think the plugin based farming is only in 2.2. IIRC the deployment based farming in 2.1 relies on pushing stuff. As an alternative to multicast, our configuration could use a configured admin server approach to node discovery by using a virtual IP that would route to a master server. Unlike multicasting, this approach would require configuration external to Geronimo to remain flexible, like virtual IP routing or DNS management. While multicast would be a better choice for most configurations, would it be plausible to include admin server hostname/IP based node discovery as a configuration option, with multicast as the default? That sounds reasonable to me, although I don't know how virtual IP works. Since we're talking about a new feature it would be better to move the discussion to the dev list, and if you would open a jira that would also help. Depending on your requirements I can think of a couple of possible strategies: 1. when a node starts up it request the plugin list from the admin server. In this case the admin server doesn't track the node members and if you update a plugin list nodes won't know until they restart. 2. when a node starts up it starts pinging the admin server. The admin server tracks cluster members similarly to how it does now with multicast. Changes to plugin lists will be propagated quickly to running nodes. I think (2) would be easier to implement as it just replaces the multicast heartbeat with a more configured one. Would you be interested in contributing an implementation? thanks david jencks Absolutely. I'm taking a peek at the MulticastDiscoveryAgent code to get an idea of how a new implementation would plug in. I agree that strategy 2 would be a good place to start as the behavior of the server farm would be the same regardless of the node discovery mechanism. One requirement that this would not address is the ability to rotate plugin deployments to cluster member nodes one at a time or in separate batches rather than all at once. This functionality would probably belong elsewhere though. I will open a jira about optionally configuring an admin host for node discovery and begin work on an implementation. Hi, FWIW, WADI provides API to implement this kind of tracking and trigger remote services. A ServiceSpace can be executed on each note http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ servicespace/ServiceSpace.html . When a node joins or stops, you can receive events by registering a ServiceSpaceListener http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ servicespace/ServiceSpaceListener.html If you are interested by a specific remote service running on a node, e.g. a service tracking the plugins installed on the admin server, then you can also receive events all along its lifecycle by registering a ServiceListener http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ servicespace/ServiceListener.html To invoke a remote service, e.g. to retrieve all the plugins installed on the admin server, you can dynamically create a service proxy by using a ServiceProxyFactory (more info there http:// docs.codehaus.org/display/WADI/2.+Distributed+Services) http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ servicespace/ServiceProxyFactory.html This is the approach I used to track the location of specific stateful SessionBean types to support the fail-over of EJB clients. This is also the approach I used to implement the WADI admin console which can track where sessions are located and gather various statistics. If you want to implement from scratch a node discovery feature, then I believe that capturing the key contracts as part of the geronimo- clustering project would be great (which has support for the tracking of cluster member). Thanks, Gianny Thanks for your help, Chance
Application client module - JPA
Hi, I am working on a cache implementation for OpenJPA using wadi-cache (clustered, replicated and transactional cache implementation) and I am facing a problem when starting an app-client module using JPA. The root cause is: org.apache.geronimo.gbean.InvalidConfigurationException: Could not load GBeanInfo class from classloader: [org.apache.geronimo.kernel.config.MultiParentClassLoader id=AccountJPA/AccountJPA-app-client/3.0/jar] className=org.apache.geronimo.persistence.PersistenceUnitGBean Debugging the class loader hierarchy of the app-client, I can see that the client-transaction module is a parent configuration of my app-client. client-transaction used to import geronimo-persistence- jpa10 which defines PersistenceUnitGBean. I believe that transitive dependencies are not been picked up (see last commit message - svn diff -r690858 plugins/connector/client-transaction/pom.xml). I will have a closer look later during the day; meanwhile, if someone, David J :-), have suggestions, I would appreciate. Thanks, Gianny
Re: Application client module - JPA
Hi, I believe this was a typo and I added back geronimo-persistence-jpa. Thanks, Gianny On 26/01/2009, at 10:26 AM, Gianny Damour wrote: Hi, I am working on a cache implementation for OpenJPA using wadi-cache (clustered, replicated and transactional cache implementation) and I am facing a problem when starting an app-client module using JPA. The root cause is: org.apache.geronimo.gbean.InvalidConfigurationException: Could not load GBeanInfo class from classloader: [org.apache.geronimo.kernel.config.MultiParentClassLoader id=AccountJPA/AccountJPA-app-client/3.0/jar] className=org.apache.geronimo.persistence.PersistenceUnitGBean Debugging the class loader hierarchy of the app-client, I can see that the client-transaction module is a parent configuration of my app-client. client-transaction used to import geronimo-persistence- jpa10 which defines PersistenceUnitGBean. I believe that transitive dependencies are not been picked up (see last commit message - svn diff -r690858 plugins/connector/client-transaction/ pom.xml). I will have a closer look later during the day; meanwhile, if someone, David J :-), have suggestions, I would appreciate. Thanks, Gianny
Dual ActiveMQ configuration style [WAS: Add tomcat-specific configuration]
Hi David, Your post is opportunistic for me to raise some concerns on dual configuration style, one via GBean and another one via the native configuration mechanism, which may cause trouble to users. No more than a couple of hours ago, I was trying to make sense of a port conflict related to the ActiveMQ Broker trying to bind to the same port whatever the value of PortOffSet. I figured out that I had to change the port configuration in the activemq.xml configuration file of the instance I was trying to start. The typical user expectation is that PortOffset should be honored whatever the configuration style. I do not have a solution; though I wanted to report on this bad experience. Thanks, Gianny Begin forwarded message: From: David Jencks david_jen...@yahoo.com Date: 14 January 2009 7:18:59 PM To: u...@geronimo.apache.org Subject: Re: Add tomcat-specific configuration Reply-To: u...@geronimo.apache.org On Jan 13, 2009, at 8:32 PM, Ivan wrote: I was always thinking that shall we have a better way to handle all the available setting provided by the third-party modules? As we all know, usually, all the GBeans only delegate those important and popular settings, it is impossible for us to allow all the configurations could be done via GBean. Let us take Tomcat as an example, maybe we shall give an interface to set those configurations that we do not provide now. I think we could expose all the knobs on tomcat components in our gbeans but it might not be the most usable approach. Basically the problem is that we have two component containers -- tomcat and geronimo -- both of which insist on creating all the components themselves. While I tend to think that the main problem is that tomcat mixes the lifecycle and runtime code to intimately the only realistic way to get farther than we have now is to change geronimo so the components don't have to be created directly by the gbean infrastructure. david jencks 2009/1/14 Jack Cai greensi...@gmail.com Thanks Ivan! I've examined the geronimo-tomcat-2.0.1.xsd and geronimo-tomcat-config-1.0.xsd, and am pretty sure many configurations are not available, like antiJARLocking, unloadDelay, etc. I understand that many of these settings might not work in Geronimo. Just try to see how we can play with the context.xml etc., which might be some good tips for migration from Tomcat. -Jack 2009/1/14 Ivan xhh...@gmail.com Basically, Geronimo have created a GBean for each element in the server.xml, which means we should configure those settings via GBeans in the config.xml. But so far, I am sure the existing GBeans have not covered all the settings that tomcat provides. e.g. for server.xml, we have host gbean for the HOST element, actually, you could check the current setting in the geronimo \plugins\tomcat\tomcat6\src\main\plan\plan.xml. For the context.xml, a TomcatWebAppContext GBean will be created while deploying the web applications, and most configurations could be set in the geronimo-web.xml file. Thanks for any comment, if any mistake is made, please point it out ! 2009/1/13 Jack Cai greensi...@gmail.com I just realize that I can put a context.xml in var/catalina/conf so that I can specify lots of Tomcat options there. I did a small experiment with the workDir param and it seems taking effect. Wondering whether this is supposed to work? Can I also put a server.xml there? Thanks! - Jack -- Ivan -- Ivan
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663467#action_12663467 ] Gianny Damour commented on GERONIMO-4508: - Hi Kevan, This is a recurrent problem; now that we have a private class support whereby we can explicitly configure specific classes and resources as private for a given config, I believe we should use this mechanism to insulate CXF children configurations. Thanks, Gianny Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r712326 - in /geronimo/server/trunk: framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/classloader/ framework/modules/geronimo-kernel/src/main/java/org/apache/
Hi Joe, Thanks for your investigations. This is a very good catch. Based on a cursory review of GeronimoTldLocationsCache, I believe that the implementation can be improved to remove such a weird instanceof identification mechanism, which is fragile and increases coupling to Geronimo class loading internals. Furthermore, the implementation simply skips any logic, e.g. class loading logic, which is encapsulated within a class loader. An integration analogy would be to directly retrieve stuff from a database instead of going through the application layer providing relevant business logic to retrieve the stuff you are looking for. My understanding is that ClassLoader.getResources() can be used to implement GeronimoTldLocationsCache.scanJars without requiring any dependency on MCCL and CCCL. Thanks, Gianny On 21/11/2008, at 6:39 AM, Joe Bohn wrote: I finally just checked in a fix for this. Turned out it wasn't related to the resource processing in the classloader ... but rather to the jasper navigation of the classloader hierarchy that had to be extended for the new ChildrenConfigurationClassLoader. See http://svn.apache.org/viewvc?rev=719329view=rev Joe Joe Bohn wrote: I think I'm getting it narrowed down a bit. It seems that when ChildrenConfigurationClassLoader.getResource(name) is called it never actually resulting in invoking MultiParentClassLoader.getResource(name) (at least not in this case). The MPCL should have been passed in when the CCCL was constructed. CCCL.getResource calls super.getResource (super being SecureClassLoader) which should ultimately result in MPCL.getResource being invoked - but that doesn't seem to be happening. Perhaps we should update CCCL.getResource to directly invoke MPCL.getResource rather than super.getResource? I guess the other possibility is that the parent isn't what I think it should be ... still investigating. Joe Joe Bohn wrote: Gianny Damour wrote: On 19/11/2008, at 5:19 AM, Joe Bohn wrote: Joe Bohn wrote: Just a heads up that I *think* there are still some issues with this change. It appears that the hiddenResource processing from the MultiParentClassloader was removed. Correction ... it was not removed but rather changed and relocated. I'm still looking to understand why this is causing a problem. Hi, Indeed, I changed the implementation to properly encapsulate class loading rules. The new implementation is way cleaner this way; when my frustration coming from reported issues will reduce, I may use this better encapsulation to add import and export class loading rules. I agree that what you added for the ClassLoadingRules is cleaner. However, I think it might be the ChildrenConfigurationClassLoader and it's replacement of MultiParentClassLoader in the Configuration that might be causing us problems. The testsuite failures that I mentioned are failing as well as nearly all of the jstl tck tests since this change. Perhaps it is working as designed, but it seems strange to me that as we process the parent classloaders they are all of type ChildrenConfigurationClassLoader when they used to be MultiParentClassLoaders. BTW, I've verified that these tests were not failing prior to this change and begin to fail with just the change a few other necessary changes (the reverting of the xsd changes and fixing the dependency history files). I think this has resulted in some testsuite failures involving tld processing. There are failures in the web-testsuite/test-2.1-jsps and web-testsuite/ test-myfaces tests. I'm looking at what would be necessary to add in the hiddenResource logic again hoping that will resolve the issue. This is a really nice feature and it is great to have the capability. However could you please run the testsuite in the future to avoid problems like this (especially when introducing fundamental changes like this)? If this is indeed a bug related to this change, then let's ensure that we have a proper unit test to prevent regression. Let's also ensure that this test is collocated with the proper component to improve cohesion. I have been observing various changes, many of them do not have proper unit tests and this causes problems further down the path as other developers can not safely change code. I'm fine with that, but I'm sure there are probably a number of more obscure situations that aren't covered by the unit tests ... they can only do so much. That's one of the reasons for the testsuite. Regarding private-classes, the current Geronimo - OpenEJB DD coupling is unfortunate. Does the OpenEJB deployer needs to know about the Geronimo environment? If it does not need to know about it, then let's strip from the DD the environment element and pass to OpenEJB the stripped version. This will reduce a little bit coupling. Another approach is to transform the Geronimo DD
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
Hi, The definition of mark-up interfaces may require the definition of a specific mark-up interface for each deployer type. For instance, a MBE may be specific to Tomcat and not to Jetty. Hence we may need WebMBE, TomcatMBE amd JettyMBE. Also for kind of the same reason than giving a deployer reference to the MBE does not work, the mark-up interface is not the silver-bullet as it is not flexible enough: you may have two deployers and you may only want to add the MBE to one of them. The explicit addition of a reference pattern provides the best flexibility. As pointed out, it requires some explicit configuration. However it is already supported through two mechanisms: manual update of config.xml or script deployment. Thanks, Gianny On 14/11/2008, at 4:58 AM, Vamsavardhana Reddy wrote: I agree that we need a general solution to dynamically add MBEs. The trick that Gianny showed does got me going with the Tuscany plugin work that I am doing. On Thu, Nov 13, 2008 at 11:21 PM, David Jencks [EMAIL PROTECTED] wrote: These solutions certainly work but don't address the fundamental problem of adding MBE's dynamically to some builders and not others. For instance we can just modify the tomcat6-deployer plan right now to include the tuscany MBE and guess that eventually we'll have a jetspeed MBE and try to think of some more. But when someone comes up with a new one we didn't imagine -- jspwiki MBE or something -- they'll have to update the list again. I would like to solve the problem once and for all so that no specific configuration for particular MBE's is needed. Making the reference go the other way -- giving the MBE a reference to the web deployer -- won't work well for the same reason, we don't know how many web deployers there will be next week, even if we only have two this week. thanks david jencks On Nov 13, 2008, at 3:21 AM, Vamsavardhana Reddy wrote: Thanks Gianny. I could add the MBE to TomcatBuilder by modifying config.xml. I have added the following gbean under org.apache.geronimo.configs/tomcat6-deployer/2.1.3/car to modify the reference to include a new MBE: gbean name=TomcatWebBuilder reference name=ModuleBuilderExtensions pattern namePersistenceUnitBuilder/name /pattern pattern nameJspModuleBuilderExtension/name /pattern pattern nameMyFacesModuleBuilderExtension/name /pattern pattern nameTuscanyModuleBuilderExtension/name /pattern /reference /gbean On Thu, Nov 13, 2008 at 4:10 PM, Gianny Damour [EMAIL PROTECTED] wrote: On 13/11/2008, at 10:08 AM, David Jencks wrote: On Nov 12, 2008, at 1:07 PM, Vamsavardhana Reddy wrote: As part of deploying SCA enhanced Web Applications in Geronimo with Tuscany Plugin, I am looking to add a ModuleBuilderExtension (MBE) to TomcatModuleBuilder and a NamingBuilder. The purpose of the MBE is to add SCA related EmbeddedRuntimeGBean to the web application config which will deploy the application composite to the SCA domain. The purpose of the NamingBuilder is to add SCA Domain and other objects (required for injection of SCA references in servlets etc.) into the WebAppContext. I am seeing that the MBE and NamingBuilder GBeans which are added as part of the Tuscany Plugin can not get dynamically added to the MBEs configured in tomcat6-builder config and NamingBuilders configured in j2ee-deployer config. The one option I see is to update the plan.xml files in tomcat6-builder and j2ee-deployer configs and rebuild the server. But this won't be like the MBE and NamingBuilder is getting added as part of Tuscany-plugin installation. The other option is to add (don't know if it is easy to do this hack) the MBE and NamingBuilder to the corresponding collections in TomcatModuleBuilder and NamingBuilder GBeans. I appreciate any suggestions/comments or inputs on any alternate approach that I am not seeing. Yup, this is a problem. So far we've sidestepped it by just adding all the known desired MBE's to the appropriate *-deployer plan, and as you have found this is non-extensible. I do not understand why overriding the relevant TomcatModuleBuilder GBean pattern in config.xml does not work. This is better than having to redeploy the tomcat6-builder plugin. If the problem is to provide a way to update the tomcat6-builder plugin when the Tuscany Plugin is installed, then an approach is to package within the Tuscany plugin a script to update the reference patterns of the GBean TomcatWebBuilder. For instance, by dropping a file named GBeansTuscanyEnhancer.groovy in the folder repository/org/apache/geronimo/configs/tomcat6-deployer/2.*/ tomcat6-deployer-2.*.car/ which kind of looks like
Re: 2.2 (trunk) bucket-o-snapshots
On 13/11/2008, at 5:13 AM, Joe Bohn wrote: Gianny Damour wrote: On 12/11/2008, at 10:04 AM, Joe Bohn wrote: It has been mentioned several times that we should be looking to release Geronimo 2.2 before the end of the year (preferrably mid- December). Before we can consider a release there are a large number of snapshots that need to be removed/replaced in our project. Can anybody shed any light on these (or others that I may have missed)? -wadi 2.1-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're using 2.0. What function requires 2.1-SNAPSHOT and is can somebody directly involved with wadi provide an estimate on when this might be released? I will release WADI 2.1 whenever a release version is required for Geronimo. Thanks Gianny. Is there any reason to avoid pursuing a release now? Are you anticipating more changes from Geronimo or other projects soon? Any snapshot dependencies that we can quickly remove will help us more keenly focus on those that require a bit more effort. Well, I am working on and off on WADI cache, which will provide a distributed, replicated and transactional cache. Have a look here https://svn.codehaus.org/wadi/trunk/wadi/wadi-cache/src/test/java/org/ codehaus/wadi/cache/demo/Main.java if you want to see a sample. Obviously, if people are interested to help, then please ping me. I understand where you are coming from. Rest assure that the cut of a WADI release is not a severe dependency for Geronimo 2.2. What do you think of me cutting a release end November, say the week-end of November 29th? Thanks, Gianny Thanks, Joe
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
On 15/11/2008, at 5:08 AM, David Jencks wrote: On Nov 14, 2008, at 12:40 AM, Gianny Damour wrote: Hi, The definition of mark-up interfaces may require the definition of a specific mark-up interface for each deployer type. For instance, a MBE may be specific to Tomcat and not to Jetty. Hence we may need WebMBE, TomcatMBE amd JettyMBE. 1. So far we don't have any examples of such MBEs 2. Even if we did, this can easily be handled with a single WebMBE interface by not deploying the e.g. JettyMBEImpl on a tomcat server. Indeed, we do not have an example yet. Let's assume that we do. Also for kind of the same reason than giving a deployer reference to the MBE does not work, the mark-up interface is not the silver- bullet as it is not flexible enough: you may have two deployers and you may only want to add the MBE to one of them. I can't think of a remotely plausible example of this, could you suggest one? Let's also assume that we have Jetty and Tomcat deployers running in the same server. In this situation, we cannot selectively deploy the MBE as the server is running our two deployers and you only want to update one of them. Obviously the above point w/o an actual example is moot. Do you think that we will never see a deployer specific MBE? The explicit addition of a reference pattern provides the best flexibility. As pointed out, it requires some explicit configuration. However it is already supported through two mechanisms: manual update of config.xml or script deployment. True, but it is not a declarative solution to the problem, it involves procedural code. Since we've gotten everything else to work with a declarative solution I'd like to see if we can solve this problem declaratively also. OK. I have started to believe that XML declarations should be replaced by DSLs. Also, the introduction of mark-up interfaces increases the number of things that developers need to know. What do you think of using annotations instead of interfaces? This is the preferred style I think. Thanks, Gianny thanks david jencks Thanks, Gianny On 14/11/2008, at 4:58 AM, Vamsavardhana Reddy wrote: I agree that we need a general solution to dynamically add MBEs. The trick that Gianny showed does got me going with the Tuscany plugin work that I am doing. On Thu, Nov 13, 2008 at 11:21 PM, David Jencks [EMAIL PROTECTED] wrote: These solutions certainly work but don't address the fundamental problem of adding MBE's dynamically to some builders and not others. For instance we can just modify the tomcat6-deployer plan right now to include the tuscany MBE and guess that eventually we'll have a jetspeed MBE and try to think of some more. But when someone comes up with a new one we didn't imagine -- jspwiki MBE or something -- they'll have to update the list again. I would like to solve the problem once and for all so that no specific configuration for particular MBE's is needed. Making the reference go the other way -- giving the MBE a reference to the web deployer -- won't work well for the same reason, we don't know how many web deployers there will be next week, even if we only have two this week. thanks david jencks On Nov 13, 2008, at 3:21 AM, Vamsavardhana Reddy wrote: Thanks Gianny. I could add the MBE to TomcatBuilder by modifying config.xml. I have added the following gbean under org.apache.geronimo.configs/tomcat6-deployer/2.1.3/car to modify the reference to include a new MBE: gbean name=TomcatWebBuilder reference name=ModuleBuilderExtensions pattern namePersistenceUnitBuilder/name /pattern pattern nameJspModuleBuilderExtension/name /pattern pattern nameMyFacesModuleBuilderExtension/name /pattern pattern nameTuscanyModuleBuilderExtension/name /pattern /reference /gbean On Thu, Nov 13, 2008 at 4:10 PM, Gianny Damour [EMAIL PROTECTED] wrote: On 13/11/2008, at 10:08 AM, David Jencks wrote: On Nov 12, 2008, at 1:07 PM, Vamsavardhana Reddy wrote: As part of deploying SCA enhanced Web Applications in Geronimo with Tuscany Plugin, I am looking to add a ModuleBuilderExtension (MBE) to TomcatModuleBuilder and a NamingBuilder. The purpose of the MBE is to add SCA related EmbeddedRuntimeGBean to the web application config which will deploy the application composite to the SCA domain. The purpose of the NamingBuilder is to add SCA Domain and other objects (required for injection of SCA references in servlets etc.) into the WebAppContext. I am seeing that the MBE and NamingBuilder GBeans which are added as part of the Tuscany Plugin can not get dynamically added to the MBEs configured in tomcat6-builder config and NamingBuilders configured in j2ee
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
On 13/11/2008, at 10:08 AM, David Jencks wrote:
On Nov 12, 2008, at 1:07 PM, Vamsavardhana Reddy wrote:
As part of deploying SCA enhanced Web Applications in Geronimo
with Tuscany Plugin, I am looking to add a ModuleBuilderExtension
(MBE) to TomcatModuleBuilder and a NamingBuilder. The purpose of
the MBE is to add SCA related EmbeddedRuntimeGBean to the web
application config which will deploy the application composite to
the SCA domain. The purpose of the NamingBuilder is to add SCA
Domain and other objects (required for injection of SCA references
in servlets etc.) into the WebAppContext. I am seeing that the
MBE and NamingBuilder GBeans which are added as part of the
Tuscany Plugin can not get dynamically added to the MBEs
configured in tomcat6-builder config and NamingBuilders configured
in j2ee-deployer config. The one option I see is to update the
plan.xml files in tomcat6-builder and j2ee-deployer configs and
rebuild the server. But this won't be like the MBE and
NamingBuilder is getting added as part of Tuscany-plugin
installation. The other option is to add (don't know if it is
easy to do this hack) the MBE and NamingBuilder to the
corresponding collections in TomcatModuleBuilder and NamingBuilder
GBeans. I appreciate any suggestions/comments or inputs on any
alternate approach that I am not seeing.
Yup, this is a problem. So far we've sidestepped it by just adding
all the known desired MBE's to the appropriate *-deployer plan, and
as you have found this is non-extensible.
I do not understand why overriding the relevant TomcatModuleBuilder
GBean pattern in config.xml does not work. This is better than having
to redeploy the tomcat6-builder plugin.
If the problem is to provide a way to update the tomcat6-builder
plugin when the Tuscany Plugin is installed, then an approach is to
package within the Tuscany plugin a script to update the reference
patterns of the GBean TomcatWebBuilder. For instance, by dropping a
file named
GBeansTuscanyEnhancer.groovy
in the folder
repository/org/apache/geronimo/configs/tomcat6-deployer/2.*/tomcat6-
deployer-2.*.car/
which kind of looks like (indicative...)
import org.apache.geronimo.gbean.AbstractNameQuery
def tomcatWebBuilderGBean = gbeanDatas.find { it.gbeanInfo.className
== 'org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder' }
def moduleBuilderExtensionsPatterns =
tomcatWebBuilderGBean.getReferencePatterns('ModuleBuilderExtensions')
Set newPatterns = []
newPatterns.addAll(moduleBuilderExtensionsPatterns.patterns)
newPatterns.add(new AbstractNameQuery(new URI
(PUT_YOUR_TUSCANY_MBE_PATTERN_NAME_HERE)))
tomcatWebBuilderGBean.setReferencePatterns(newPatterns)
You should be done.
Thanks,
Gianny
One possiblitly would be to define marker interfaces such as
WebMBE, EjbMBE, etc that the appropriate MBE's could implement and
use the interface in the references pattern.
Anyone have a better idea?
thanks
david jencks
Thanks,
Vamsi
Re: svn commit: r713680 - in /geronimo/server/trunk/framework/modules: geronimo-service-builder/src/main/java/org/apache/geronimo/deployment/service/ geronimo-service-builder/src/main/xsd/ geronimo-se
Hi, The feature is still available. However we do not provide a XML configuration style for it. We only provide a script configuration style. For instance, by dropping a file named: DependenciesPrivateClass.groovy in the folder of the plugin to update and with a content looking like Set privateClasses = ['hide.this', 'hide.that'] configurationData.environment.classLoadingRules.privateRule.addClassPref ixes(privateClasses) You can achieve the same effect. Let me know if you think that we should also provide a XML configuration style. Regarding the TCK problem, I do not think that this change is related. I believe that the TCK problem is due to the new OpenEJB snapshot. Jason, could you please confirm? Thanks, Gianny On 14/11/2008, at 5:19 AM, Joe Bohn wrote: I think I was one of the people asking for this to be reverted. Just to clarify my position: I'm very much in favor of keeping the functionality. I think it will help with some of the more obscure classloader issues we've been hitting. My suggestion to revert the change was more pragmatic to resolve two issues: 1) new TCK failures reported by Jason 2) The implicit dependency on a new OpenEJB 3.1.x release If we can resolve these 2 issues without reverting the change (or for #2 if it seems we need a new OpenEJB 3.1.x release for other reasons ... like other TCK failures) then I'm very much in favor of keeping this change. Joe David Jencks wrote: Um, -1. I thought this was a great idea for 2.2. What's the problem that leads you to revert it? thanks david jencks On Nov 13, 2008, at 12:35 AM, [EMAIL PROTECTED] wrote: Author: gdamour Date: Thu Nov 13 00:35:05 2008 New Revision: 713680 URL: http://svn.apache.org/viewvc?rev=713680view=rev Log: Revert addition of private-classes element. Private classes can be configured via scripts. (GERONIMO-4403) Provide a mechanism to hide specific classes of a configuration to all its children snip
Re: 2.2 (trunk) bucket-o-snapshots
On 12/11/2008, at 10:04 AM, Joe Bohn wrote: It has been mentioned several times that we should be looking to release Geronimo 2.2 before the end of the year (preferrably mid- December). Before we can consider a release there are a large number of snapshots that need to be removed/replaced in our project. Can anybody shed any light on these (or others that I may have missed)? -wadi 2.1-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're using 2.0. What function requires 2.1-SNAPSHOT and is can somebody directly involved with wadi provide an estimate on when this might be released? I will release WADI 2.1 whenever a release version is required for Geronimo. Thanks, Gianny
[jira] Updated: (GERONIMO-4400) Improve error message of DependencyChangeMojo
[ https://issues.apache.org/jira/browse/GERONIMO-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-4400: Component/s: buildsystem Affects Version/s: 2.1.3 Fix Version/s: 2.2 Improve error message of DependencyChangeMojo - Key: GERONIMO-4400 URL: https://issues.apache.org/jira/browse/GERONIMO-4400 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1.3 Reporter: Gianny Damour Fix For: 2.2 When dependencies change, it would be great to have an error message providing some basic instructions on how to proceed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4399) GBean Annotations are not supported for GBeans declared in XML configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-4399: --- Assignee: Gianny Damour GBean Annotations are not supported for GBeans declared in XML configuration Key: GERONIMO-4399 URL: https://issues.apache.org/jira/browse/GERONIMO-4399 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 It is not possible to declare a GBean using the annotation base configuration style in any DDs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4400) Improve error message of DependencyChangeMojo
[ https://issues.apache.org/jira/browse/GERONIMO-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-4400: --- Assignee: Gianny Damour Improve error message of DependencyChangeMojo - Key: GERONIMO-4400 URL: https://issues.apache.org/jira/browse/GERONIMO-4400 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When dependencies change, it would be great to have an error message providing some basic instructions on how to proceed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4399) GBean Annotations are not supported for GBeans declared in XML configuration
GBean Annotations are not supported for GBeans declared in XML configuration Key: GERONIMO-4399 URL: https://issues.apache.org/jira/browse/GERONIMO-4399 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Fix For: 2.2 It is not possible to declare a GBean using the annotation base configuration style in any DDs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4400) Improve error message of DependencyChangeMojo
Improve error message of DependencyChangeMojo - Key: GERONIMO-4400 URL: https://issues.apache.org/jira/browse/GERONIMO-4400 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Reporter: Gianny Damour When dependencies change, it would be great to have an error message providing some basic instructions on how to proceed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4401) Extension of configuration dependencies and gbeans via Groovy scripts
Extension of configuration dependencies and gbeans via Groovy scripts - Key: GERONIMO-4401 URL: https://issues.apache.org/jira/browse/GERONIMO-4401 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When a configuration is started, we should provide a way to modify dependencies and GBeans of the configuration through the execution of Groovy scripts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4403) Provide a mechanism to hide specific classes of a configuration to all its children
Provide a mechanism to hide specific classes of a configuration to all its children Key: GERONIMO-4403 URL: https://issues.apache.org/jira/browse/GERONIMO-4403 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When a configuration uses a commonly used library, e.g. Spring, the only way to prevent child configurations to use this library and use their own copy is to fiddle with the class loading set-up of each child. To some extent, it can be quite user unfriendly to provide such an extract class loading configuration for each child. A mechanism allowing the configuration of classes only visible by the configuration declaring them would be more user friendly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: An idea for defining custom valves in config.xml
Hi Jason,
This is now checked-in. I had to change some naming conventions to
have better stack trace information when a Groovy script fails.
Scripts must match the patterns Dependencies(.*).groovy and GBeans
(.*).groovy to be picked up.
Let me know how you go!
Thanks,
Gianny
On 30/10/2008, at 4:37 AM, Jason Warner wrote:
There's no need to check in what you have if you don't feel it's
quite done yet. I was just wondering where you were at. I was
eager to have a solution for the original issue find its way into
the 2.2 release, and it seems that would be the case. I think that
improving the classloading isolation would be the best approach to
solve the issue you raised. I'm not too familiar with the
classloader as is, though, so I'm not sure what impact that would
have. From a purely user point of view, it seems like the correct
way to go. Let me know if you need any help testing or coding any
of this. As I said, I'm not too familiar with the classloader, but
if I flop around in the code enough I might be able to make a few
small waves ;)
Thanks!
On Tue, Oct 28, 2008 at 4:53 PM, Gianny Damour
[EMAIL PROTECTED] wrote:
Hi Jason,
It is implemented and I will check-in over the week-end.
Here is the design:
1. When a ConfigurationData is loaded from a ConfigurationStore,
its dependencies can be altered based on scripts matching the
pattern dependencies-(.*).groovy. Here is the script I have been
using to perform my integration test:
configurationDataBuilder.configure {
addDependency(groupId: org.springframework, artifactId:
spring-core, version: 2.0.5, type: jar)
}
2. When the GBeans of a configuration are loaded, i.e. when a
Configuration instance is created, GBeans can be updated based on
scripts matching the pattern gbeans-(,*).groovy. Here is my
integration test script:
import org.springframework.core.SpringVersion
gbeanDataBuilder.configure {
addGBean(name: 'name', gbean: SpringVersion) {
}
}
Scripts are searched in the configuration directory, i.e. in the
same folder of the META-INF folder of a configuration. This can be
easily changed by implementing a ScriptLocater strategy.
I had to add a groovy dependency to the j2ee-system config which is
not ideal as all the configurations will now see the Groovy
classes. Ideally, I would like to add another configuration where
ConfigurationDataTransformers can be declared and the out-of-the-
box GroovyTransformer can be specified. This is problematic as such
a configuration needs to be started after j2ee-system and before
any other configurations. I could add a dependency to this
configuration on the innermost configuration after j2ee-system.
Another approach would be to improve the isolation of configuration
classloaders, which should also address classloading problems
reported by users and the need to fiddle with hidden-classes
declarations. Assuming that I stick to the current configuration
approach where I declare a GroovyTransformer in j2ee-system, the
improvement I am thinking about is:
1) add a new classloading declaration element, maybe hidden-for-
children, where users can specify a pattern a la hidden-classes.
2) The above declarations are used to build a classloader which
simply delegates to the configuration classloader and filter out
classes matching the hidden-for-children declarations.
3) Children configurations are provided with the above classloader
instead of the configuration classloader.
With this thing in place, I will be able to add a groovy dependency
to j2ee-system w/o having to thing about the impacts to children
configurations as I can hide the groovy classes.
If you want me to check-in as-is this scripting stuff and revisit
the implementation as soon as I figure out which of the two
approaches, i.e. add another config or improve classloading
isolation, is the best, then let me know.
Thanks,
Gianny
On 29/10/2008, at 2:21 AM, Jason Warner wrote:
Hi Gianny,
Have you made any progress with this? Are you targeting this for
the 2.2 release (whenever that happens to be)?
Thanks!
On Fri, Oct 17, 2008 at 8:11 PM, Gianny Damour
[EMAIL PROTECTED] wrote:
Hi,
I am proposing the following implementation to start with:
1. In the META-INF folder of a config, we scan for files matching
the patterns dependencies-(.*).groovy and extentions-(.*).groovy.
2. We execute the scripts dependencies-(.*).groovy which modify
dependencies. For instance, such scripts may look like:
configurationData + dependency(groupId: 'group', artifactId:
'artifact', version: '1.1', type: 'jar', importType: importType) --
add the declared dependency
configurationData - dependency(groupId: 'group', artifactId:
'artifact', version: '1.0', type: 'jar') -- remove the declared
dependency
This gives us the final classloader of the config.
3. We execute the scripts extentions-(.*).groovy which update the
GBeans
[jira] Closed: (GERONIMO-4403) Provide a mechanism to hide specific classes of a configuration to all its children
[ https://issues.apache.org/jira/browse/GERONIMO-4403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-4403. --- Resolution: Fixed Feature checked-in. Provide a mechanism to hide specific classes of a configuration to all its children Key: GERONIMO-4403 URL: https://issues.apache.org/jira/browse/GERONIMO-4403 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When a configuration uses a commonly used library, e.g. Spring, the only way to prevent child configurations to use this library and use their own copy is to fiddle with the class loading set-up of each child. To some extent, it can be quite user unfriendly to provide such an extract class loading configuration for each child. A mechanism allowing the configuration of classes only visible by the configuration declaring them would be more user friendly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4401) Extension of configuration dependencies and gbeans via Groovy scripts
[ https://issues.apache.org/jira/browse/GERONIMO-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-4401. --- Resolution: Fixed Feature checked-in. Extension of configuration dependencies and gbeans via Groovy scripts - Key: GERONIMO-4401 URL: https://issues.apache.org/jira/browse/GERONIMO-4401 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When a configuration is started, we should provide a way to modify dependencies and GBeans of the configuration through the execution of Groovy scripts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4399) GBean Annotations are not supported for GBeans declared in XML configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-4399. --- Resolution: Fixed This is now fixed. GBean Annotations are not supported for GBeans declared in XML configuration Key: GERONIMO-4399 URL: https://issues.apache.org/jira/browse/GERONIMO-4399 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 It is not possible to declare a GBean using the annotation base configuration style in any DDs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4400) Improve error message of DependencyChangeMojo
[ https://issues.apache.org/jira/browse/GERONIMO-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-4400. --- Resolution: Fixed This is now implemented. Improve error message of DependencyChangeMojo - Key: GERONIMO-4400 URL: https://issues.apache.org/jira/browse/GERONIMO-4400 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When dependencies change, it would be great to have an error message providing some basic instructions on how to proceed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-710) Generating DDLs for CMP deployment
[ https://issues.apache.org/jira/browse/GERONIMO-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-710. -- Resolution: Won't Fix superseded. Generating DDLs for CMP deployment -- Key: GERONIMO-710 URL: https://issues.apache.org/jira/browse/GERONIMO-710 Project: Geronimo Issue Type: New Feature Components: deployment, OpenEJB Affects Versions: 1.0-M4 Reporter: Jacek Laskowski Assignee: Gianny Damour Fix For: Wish List Generate DDL automatically at CMP deployment. SunONE has a command line option - -generateSQL - which I think generate SQLs when CMPs are deployed. It could then be configurable if the DDLs should be applied to the runtime and what strategy to choose - generate only if the scheme doesn't yet exist, regenerate every time, doesn't apply, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1668) Support of dynamic EJBQL queries
[ https://issues.apache.org/jira/browse/GERONIMO-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-1668. --- Resolution: Won't Fix Superseded Support of dynamic EJBQL queries Key: GERONIMO-1668 URL: https://issues.apache.org/jira/browse/GERONIMO-1668 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.0 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: Wish List This new feature covers the need to provide an API to compile and execute dynamic EJBQL queries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1081) CMP create causes update SQL too
[ https://issues.apache.org/jira/browse/GERONIMO-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-1081. --- Resolution: Won't Fix Superseded CMP create causes update SQL too Key: GERONIMO-1081 URL: https://issues.apache.org/jira/browse/GERONIMO-1081 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Gianny Damour Fix For: 1.x I have a situation where I call a session bean method that does nothing but look up an Entity home and call create on it. This result in an UPDATE SQL being executed, not just an INSERT. It seems to me that for performance reasons if nothing else, we should perform just one INSERT. (How do I know? Because I ran into GERONIMO-1080 when calling the session bean method, which caused the create to always roll back, so I couldn't actually create anything -- another good reason to fix this.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1374) Open EJB does not allow the setting of a ForiegnKey that is involved in a CMR relationship
[ https://issues.apache.org/jira/browse/GERONIMO-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-1374. --- Resolution: Won't Fix Superseded Open EJB does not allow the setting of a ForiegnKey that is involved in a CMR relationship -- Key: GERONIMO-1374 URL: https://issues.apache.org/jira/browse/GERONIMO-1374 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.0-M5 Environment: JDK 1.4.2_09 WindowsXP Reporter: Manu T George Assignee: Gianny Damour Fix For: 1.x Attachments: CMPContainerBuilder.patch, CMPContainerBuilder.patch, CMRCompoundAccessor.java, CMRMultiplePKAsFKAccessor.java, CompoundPKTransform.patch I have two CMPs with a 1:n relationship. CMP1 - Order - PK = OrderPK which has a single field orderId CMP2 - OrderItem = OrderItemPk which has 2 fields InventoryId and order_orderId OrderId and order_orderId are mapped When i do a setOrder_orderId in the ejbCreate of OrderItem geronimo gives an error during runtime saying cannot set read only field. When i don't set it geronimo says partial null key . In this case I set the cmr field in the ejbPostCreate method org.tranql.identity.UndefinedIdentityException: Partial null key at org.tranql.identity.DerivedIdentity.defineIdentity(DerivedIdentity.java:80) at org.openejb.entity.cmp.CMPCreateMethod.execute(CMPCreateMethod.java:175) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) at org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136) at org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:90) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-601) Reverse context identifier transformations when possible
[ https://issues.apache.org/jira/browse/GERONIMO-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-601. -- Resolution: Won't Fix Superseded. Reverse context identifier transformations when possible Key: GERONIMO-601 URL: https://issues.apache.org/jira/browse/GERONIMO-601 Project: Geronimo Issue Type: Task Components: OpenEJB Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 1.x ContainerSecurityBuilder and EJBSecurityInterceptor replace ',' with a '_'. This operation needs to be reversed when possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2928) PersistenceUnit located in the EAR library directory is not yet implemented
[ https://issues.apache.org/jira/browse/GERONIMO-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2928. --- Resolution: Fixed Has been fixed a while back. PersistenceUnit located in the EAR library directory is not yet implemented --- Key: GERONIMO-2928 URL: https://issues.apache.org/jira/browse/GERONIMO-2928 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Reporter: Gianny Damour Assignee: Gianny Damour Persistence units located in the EAR library directory are not yet processed. I am working on a fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: An idea for defining custom valves in config.xml
Hi Jason,
It is implemented and I will check-in over the week-end.
Here is the design:
1. When a ConfigurationData is loaded from a ConfigurationStore, its
dependencies can be altered based on scripts matching the pattern
dependencies-(.*).groovy. Here is the script I have been using to
perform my integration test:
configurationDataBuilder.configure {
addDependency(groupId: org.springframework, artifactId:
spring-core, version: 2.0.5, type: jar)
}
2. When the GBeans of a configuration are loaded, i.e. when a
Configuration instance is created, GBeans can be updated based on
scripts matching the pattern gbeans-(,*).groovy. Here is my
integration test script:
import org.springframework.core.SpringVersion
gbeanDataBuilder.configure {
addGBean(name: 'name', gbean: SpringVersion) {
}
}
Scripts are searched in the configuration directory, i.e. in the same
folder of the META-INF folder of a configuration. This can be easily
changed by implementing a ScriptLocater strategy.
I had to add a groovy dependency to the j2ee-system config which is
not ideal as all the configurations will now see the Groovy classes.
Ideally, I would like to add another configuration where
ConfigurationDataTransformers can be declared and the out-of-the-box
GroovyTransformer can be specified. This is problematic as such a
configuration needs to be started after j2ee-system and before any
other configurations. I could add a dependency to this configuration
on the innermost configuration after j2ee-system.
Another approach would be to improve the isolation of configuration
classloaders, which should also address classloading problems
reported by users and the need to fiddle with hidden-classes
declarations. Assuming that I stick to the current configuration
approach where I declare a GroovyTransformer in j2ee-system, the
improvement I am thinking about is:
1) add a new classloading declaration element, maybe hidden-for-
children, where users can specify a pattern a la hidden-classes.
2) The above declarations are used to build a classloader which
simply delegates to the configuration classloader and filter out
classes matching the hidden-for-children declarations.
3) Children configurations are provided with the above classloader
instead of the configuration classloader.
With this thing in place, I will be able to add a groovy dependency
to j2ee-system w/o having to thing about the impacts to children
configurations as I can hide the groovy classes.
If you want me to check-in as-is this scripting stuff and revisit
the implementation as soon as I figure out which of the two
approaches, i.e. add another config or improve classloading
isolation, is the best, then let me know.
Thanks,
Gianny
On 29/10/2008, at 2:21 AM, Jason Warner wrote:
Hi Gianny,
Have you made any progress with this? Are you targeting this for
the 2.2 release (whenever that happens to be)?
Thanks!
On Fri, Oct 17, 2008 at 8:11 PM, Gianny Damour
[EMAIL PROTECTED] wrote:
Hi,
I am proposing the following implementation to start with:
1. In the META-INF folder of a config, we scan for files matching
the patterns dependencies-(.*).groovy and extentions-(.*).groovy.
2. We execute the scripts dependencies-(.*).groovy which modify
dependencies. For instance, such scripts may look like:
configurationData + dependency(groupId: 'group', artifactId:
'artifact', version: '1.1', type: 'jar', importType: importType) --
add the declared dependency
configurationData - dependency(groupId: 'group', artifactId:
'artifact', version: '1.0', type: 'jar') -- remove the declared
dependency
This gives us the final classloader of the config.
3. We execute the scripts extentions-(.*).groovy which update the
GBeans, For instance, such scripts may look like:
gBeanBuilder.configure {
addGBean(BasicNodeInfo) { -- add a GBean
attribute(name: 'node1')
attribute(extendedJMXConnectorInfo: new
BasicExtendedJMXConnectorInfo(...))
reference(referenceName) {
pattern('aPattern')
pattern('aSecondPattern')
}
}
removeGBeansMatching('aPattern')
}
gBeanBuilder.updatedConfigurationData
The implementation of such scripts should be as simple as the
modification of config.xml.
The fact that they are collocated with the configuration they
modify increases cohesion. It would be neat to have such scripts
instead of the native or XStream serializations of config.ser.
Let me know your thoughts?
Thanks,
Gianny
On 16/10/2008, at 11:17 PM, Jason Warner wrote:
While David is more interested in the philosophy, I'd prefer to
know a little bit more about your thoughts on implementation.
Specifically what do you imagine would be involved in defining this
configuration? Would it be as simple as a definition in config.xml?
On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour
[EMAIL PROTECTED] wrote:
Hi David,
You are correct
xbean-3.5-SNAPSHOT problem
Hi, I am not able to build trunk due to xbean-3.5-SNAPSHOT being missing from the apache.snapshots Maven repo: http://people.apache.org/repo/ m2-snapshot-repository/org/apache/xbean/ Snapshots have been deployed to this repo on Oct 23rd. Any ideas? Thanks, Gianny
Re: An idea for defining custom valves in config.xml
Hi,
I am proposing the following implementation to start with:
1. In the META-INF folder of a config, we scan for files matching the
patterns dependencies-(.*).groovy and extentions-(.*).groovy.
2. We execute the scripts dependencies-(.*).groovy which modify
dependencies. For instance, such scripts may look like:
configurationData + dependency(groupId: 'group', artifactId:
'artifact', version: '1.1', type: 'jar', importType: importType) --
add the declared dependency
configurationData - dependency(groupId: 'group', artifactId:
'artifact', version: '1.0', type: 'jar') -- remove the declared
dependency
This gives us the final classloader of the config.
3. We execute the scripts extentions-(.*).groovy which update the
GBeans, For instance, such scripts may look like:
gBeanBuilder.configure {
addGBean(BasicNodeInfo) { -- add a GBean
attribute(name: 'node1')
attribute(extendedJMXConnectorInfo: new
BasicExtendedJMXConnectorInfo(...))
reference(referenceName) {
pattern('aPattern')
pattern('aSecondPattern')
}
}
removeGBeansMatching('aPattern')
}
gBeanBuilder.updatedConfigurationData
The implementation of such scripts should be as simple as the
modification of config.xml.
The fact that they are collocated with the configuration they modify
increases cohesion. It would be neat to have such scripts instead of
the native or XStream serializations of config.ser.
Let me know your thoughts?
Thanks,
Gianny
On 16/10/2008, at 11:17 PM, Jason Warner wrote:
While David is more interested in the philosophy, I'd prefer to
know a little bit more about your thoughts on implementation.
Specifically what do you imagine would be involved in defining this
configuration? Would it be as simple as a definition in config.xml?
On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour
[EMAIL PROTECTED] wrote:
Hi David,
You are correct: the underpinning philosophy of these approaches is
to make it easier to modify pre-canned plugins through extension
points.
This may be a good approach to improve further the packaging model
of dependencies and services. Let's say that an end-user wants to
add a connector to the tomcat6 plugin. Instead of using the admin
console or updating his config.xml, he can simply deploy a
cumulative plan. This notion of cumulative plan is the key
differentiator as users can share their cumulative plans as-is -
i.e. w/o knowing what the plugin to be modified looks like. To
some extent, providing a plan ready to be deployed instead of
deployment instructions is better for novices.
I will work on the Groovy builder approach and post back more
details as I go.
Thanks,
Gianny
On 16/10/2008, at 10:59 AM, David Jencks wrote:
Hi Gianny,
First, I'd like to make sure I understand the philosophy behind
your proposals. IIUC they both involve the idea of making it easy
to modify an existing plugin rather than making it easy to replace
an existing plugin with a similar one.
Why is this a good idea? My idea has been that we should make it
easier to replace a plugin with a similar one than modify an
existing one, and then we will have the best of all worlds.
All this being said, I think your ideas are both quite
interesting. I'm especially interested in the groovy builder
approach.
I'll be fairly unavailable until next week but might keep thinking
about this anyway.
thanks!
david jencks
On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
On 15/10/2008, at 4:16 AM, David Jencks wrote:
That's one of the main missing bits of functionality. Right now
the only way to get the g-p.xml is to use c-m-p or to export the
plugin from a server it's been deployed into, or to do something by
hand with jar packing and unpacking.
The biggest problem here, in my mind, is that jsr88 only wants you
to have one plan: to deploy something you get to specify the
artifact and one plan. Our deployment system is built around
jsr88 so we either have to condense the g-p.xml and plan into one
plan or abandon jsr88.
At the moment I'm thinking that one satisfactory solution might be
to more or less embed the plan into g-p.xml. Perhaps we could
avoid duplicating most of the dependency info by adding the
import element to the dependencies in g-p.xml. I guess we'd
expect a more or less empty environment element in the plan and
fill in the dependencies from the g-p.xml when deploying.
I guess another possibility might be to include the info from g-
p.xml in the environment element of the plan.
I've been thinking about this on and off for a long time and don't
have any solution I'm entirely happy with so discussion and more
ideas are more than welcome :-)
Hi,
Another possible solution would be to allow the extension of a
given configuration by other configurations. This could work like
the web.xml fragment mechanism of the upcoming servlet specs
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
On 17/10/2008, at 12:42 AM, Joe Bohn wrote: Gianny Damour wrote: Hi, I also do not see a lot of room for improvement in Grails integration. FWIW, in addition to the sample Grails application of the IBM article, the WADI administration console, a Grails Web- app, can be deployed out-of-the-box to Geronimo to introspect WADI clusters. I believe there is room for scripting languages in Geronimo. For instance, gshell users can source command files to automate some of their actions. A more powerful approach would be to provide scripting capabilities to gshell users. I believe, Groovy is an appropriate scripting language choice as it is very easy to learn for Java people. Another user case would be to use scripting to replace the serialized configuration, I mean the config.ser. An xmlbean serialization of configurations is way better than a native Java serialization as end-users can easily see and update values of serialized stuff. A YAML or even better a Groovy builder serialization would be way better than a xmlbean serialization. i would even go a step further and say that the geronimo DD could be replaced by scripts. A programmatic way to configure GBeans would be simpler. This could be a little bit like the programmatic servlet component configuration mechanism defined by the upcoming Servlet spec. Sorry for the delayed response. I still haven't quite gotten my head around this idea yet? Can you provide some more information on how this would look and behave? I guess I need to take a look at the new Servlet spec. A third example is to provide a simpler extension of configurations. The addition of a custom Tomcat valve to the tomcat6 config is a use case. When a configuration is started a script is executed to provide GBean overrides (add, update or remove) and dependencies overrides to the pre-canned configuration. In the scripting context, users have access to the pre-canned configuration and are able to return an altered one if they want. This too is an interesting idea. Are you thinking that the extensions would only live in the script and be executed each time the configuration is started or would they be somehow persistent in the configuration? It seems that this and the previous idea are two different approaches to the same end ... an easy way for a user to enhance/alter a configuration via a scripting language ... is that correct? Hi Joe, I answered your question in the thread Re: An idea for defining custom valves in config.xml. Hope my answer there is helpful. Thanks, Gianny Joe Thanks, Gianny On 11/10/2008, at 5:42 AM, Jason Dillon wrote: IMO, language is irrelevant. What you want to consider is what you want the scripting language to do for you... that is what is important. Basically (almost) any scripting language can be integrated (bsf or direct) but what is missing is the users use- cases for what the really want scripted. But.. users't don't always tell you want they want up front, they look at what you have and then complain when its broken wrt their own needs. So it might be worthwhile doing some POC work to add more scripting support. Though I don't think that web-app scripting crapski is the best way to provide that. If you think about it, there are a few uses for scripting in the application server's context. First is that the app developers prefer the language, but they still provide JavaEE muck to install/run. So we could reduce some footprint by providing plugins, but that not really that important, as the feature will still work w/o it. The second is where the application exposes some configuration logic which is intended to be easily augmented when installing/running the application. In this model part of the application's behavior is configured via some scripting language, which is intended to be changed (slightly or dramatically) to fit the application installations requirements. The third is where the application wants to provide an extensible action interface, so allow such an application to do whatever it wants. For example, if an application supports some concept of filtering, one might desire that the filter be implemented by a script which the administrator of the application could writte/ configure. I'm sure I'm missing more examples, but it should be sufficient to point these out. Scripting is a very powerful way to extend you application, and I'm certainly a proponent. But what I'm having trouble realizing is... for a JavaEE application server, what/how/why would a developer want to script? --jason On Oct 11, 2008, at 1:13 AM, Joe Bohn wrote: ant elder wrote: On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Joe Bohn wrote: Any ideas on PHP and if this would be another potential area for integration? Python Joe Bill
Re: An idea for defining custom valves in config.xml
Hi David, You are correct: the underpinning philosophy of these approaches is to make it easier to modify pre-canned plugins through extension points. This may be a good approach to improve further the packaging model of dependencies and services. Let's say that an end-user wants to add a connector to the tomcat6 plugin. Instead of using the admin console or updating his config.xml, he can simply deploy a cumulative plan. This notion of cumulative plan is the key differentiator as users can share their cumulative plans as-is - i.e. w/o knowing what the plugin to be modified looks like. To some extent, providing a plan ready to be deployed instead of deployment instructions is better for novices. I will work on the Groovy builder approach and post back more details as I go. Thanks, Gianny On 16/10/2008, at 10:59 AM, David Jencks wrote: Hi Gianny, First, I'd like to make sure I understand the philosophy behind your proposals. IIUC they both involve the idea of making it easy to modify an existing plugin rather than making it easy to replace an existing plugin with a similar one. Why is this a good idea? My idea has been that we should make it easier to replace a plugin with a similar one than modify an existing one, and then we will have the best of all worlds. All this being said, I think your ideas are both quite interesting. I'm especially interested in the groovy builder approach. I'll be fairly unavailable until next week but might keep thinking about this anyway. thanks! david jencks On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote: On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one plan: to deploy something you get to specify the artifact and one plan. Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one plan or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the import element to the dependencies in g-p.xml. I guess we'd expect a more or less empty environment element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g- p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks
Re: An idea for defining custom valves in config.xml
On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one plan: to deploy something you get to specify the artifact and one plan. Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one plan or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the import element to the dependencies in g-p.xml. I guess we'd expect a more or less empty environment element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g- p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/ tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Hi, I also do not see a lot of room for improvement in Grails integration. FWIW, in addition to the sample Grails application of the IBM article, the WADI administration console, a Grails Web-app, can be deployed out-of-the-box to Geronimo to introspect WADI clusters. I believe there is room for scripting languages in Geronimo. For instance, gshell users can source command files to automate some of their actions. A more powerful approach would be to provide scripting capabilities to gshell users. I believe, Groovy is an appropriate scripting language choice as it is very easy to learn for Java people. Another user case would be to use scripting to replace the serialized configuration, I mean the config.ser. An xmlbean serialization of configurations is way better than a native Java serialization as end- users can easily see and update values of serialized stuff. A YAML or even better a Groovy builder serialization would be way better than a xmlbean serialization. i would even go a step further and say that the geronimo DD could be replaced by scripts. A programmatic way to configure GBeans would be simpler. This could be a little bit like the programmatic servlet component configuration mechanism defined by the upcoming Servlet spec. A third example is to provide a simpler extension of configurations. The addition of a custom Tomcat valve to the tomcat6 config is a use case. When a configuration is started a script is executed to provide GBean overrides (add, update or remove) and dependencies overrides to the pre-canned configuration. In the scripting context, users have access to the pre-canned configuration and are able to return an altered one if they want. Thanks, Gianny On 11/10/2008, at 5:42 AM, Jason Dillon wrote: IMO, language is irrelevant. What you want to consider is what you want the scripting language to do for you... that is what is important. Basically (almost) any scripting language can be integrated (bsf or direct) but what is missing is the users use- cases for what the really want scripted. But.. users't don't always tell you want they want up front, they look at what you have and then complain when its broken wrt their own needs. So it might be worthwhile doing some POC work to add more scripting support. Though I don't think that web-app scripting crapski is the best way to provide that. If you think about it, there are a few uses for scripting in the application server's context. First is that the app developers prefer the language, but they still provide JavaEE muck to install/ run. So we could reduce some footprint by providing plugins, but that not really that important, as the feature will still work w/o it. The second is where the application exposes some configuration logic which is intended to be easily augmented when installing/running the application. In this model part of the application's behavior is configured via some scripting language, which is intended to be changed (slightly or dramatically) to fit the application installations requirements. The third is where the application wants to provide an extensible action interface, so allow such an application to do whatever it wants. For example, if an application supports some concept of filtering, one might desire that the filter be implemented by a script which the administrator of the application could writte/configure. I'm sure I'm missing more examples, but it should be sufficient to point these out. Scripting is a very powerful way to extend you application, and I'm certainly a proponent. But what I'm having trouble realizing is... for a JavaEE application server, what/how/why would a developer want to script? --jason On Oct 11, 2008, at 1:13 AM, Joe Bohn wrote: ant elder wrote: On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Joe Bohn wrote: Any ideas on PHP and if this would be another potential area for integration? Python Joe Bill Also JavaScript with Rhino, and that gives you the big four - Groovy, JRuby, Rhino, and Jython. PHP would good but i've never found a PHP impl with Java integration and a compatible license. You can also use the JSR-223 APIs (Apache BSF) and get easy access to lots of lesser well known script language engines. I've done a bit with all those in Tuscany so will be interested to see what happens in Geronimo. Thanks for the input. Yes, I thought about BSF too. Regarding the others languages (Python, Rhino, Jython and PHP) licenses could be issues have to keep an eye on that. I thought about BSF too ... need to do some more research there. Actually, at this point it's all just some investigation and we'll see where it goes. Joe
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Great! It seems that it is not yet enabled thought. Thanks, Gianny On 11/10/2008, at 4:34 PM, Jason Dillon wrote: On Oct 11, 2008, at 7:07 AM, Gianny Damour wrote: I also do not see a lot of room for improvement in Grails integration. FWIW, in addition to the sample Grails application of the IBM article, the WADI administration console, a Grails Web- app, can be deployed out-of-the-box to Geronimo to introspect WADI clusters. I believe there is room for scripting languages in Geronimo. For instance, gshell users can source command files to automate some of their actions. A more powerful approach would be to provide scripting capabilities to gshell users. I believe, Groovy is an appropriate scripting language choice as it is very easy to learn for Java people. GShell has had a BSF-driven 'script' command for a long time now ;-) --jason
[jira] Updated: (GERONIMO-4299) Session invalidation problem - WADI Tomcat Clustering
[ https://issues.apache.org/jira/browse/GERONIMO-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-4299: Attachment: fixWADITomcatIntegration.patch Session invalidation problem - WADI Tomcat Clustering - Key: GERONIMO-4299 URL: https://issues.apache.org/jira/browse/GERONIMO-4299 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.2 Reporter: Gianny Damour Attachments: fixWADITomcatIntegration.patch Session invalidation fails with an IllegalStateException for WADI clustered Tomcat applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4299) Session invalidation problem - WADI Tomcat Clustering
Session invalidation problem - WADI Tomcat Clustering - Key: GERONIMO-4299 URL: https://issues.apache.org/jira/browse/GERONIMO-4299 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.1.2 Reporter: Gianny Damour Attachments: fixWADITomcatIntegration.patch Session invalidation fails with an IllegalStateException for WADI clustered Tomcat applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r686040 - /geronimo/server/trunk/pom.xml
My bad, I was so used to release milestone releases that when I published 2.0 I simply forgot to move the snapshot version of WADI to 2.1. I am publishing 2.1-SNAPSHOT right now. Thanks, Gianny On 15/08/2008, at 7:34 AM, Jacek Laskowski wrote: On Thu, Aug 14, 2008 at 10:54 PM, [EMAIL PROTECTED] wrote: Author: jawarner Date: Thu Aug 14 13:54:03 2008 New Revision: 686040 URL: http://svn.apache.org/viewvc?rev=686040view=rev Log: GERONIMO-4244: Update to new wadi snapshot Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml? rev=686040r1=686039r2=686040view=diff = = --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Thu Aug 14 13:54:03 2008 @@ -82,7 +82,7 @@ plutoVersion1.1.6-G643117/plutoVersion openjpaVersion1.0.2/openjpaVersion xbeanVersion3.4.1/xbeanVersion -wadiVersion2.0/wadiVersion +wadiVersion2.0-SNAPSHOT/wadiVersion How can 2.0-SNAPSHOT be newer than 2.0? I'm a bit confused. Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: [VOTE] Geronimo Server 2.1.2 Release
+1 Thanks, Gianny On 31/07/2008, at 12:52 PM, Joe Bohn wrote: All, I've prepared a release candidate of Geronimo Server 2.1.2 for your review and vote. The source for the Geronimo Server 2.1.2 release currently resides here: https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.2 When the release vote is approved, I will svn mv the code to https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.2 An archive of this source code can be found here: http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-2.1.2- src.tar.gz OR http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-2.1.2- src.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/ contains the 10 Java EE, Minimal, and Framework server binary distributions to be released (framework, tomcat/jetty, Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES, README, NOTICE, LICENSE, DISCLAIMER, and source code archives for the release. These extra txt files were included so that they could be leveraged by GEP if necessary (they are also included in the assembly images). For your convenience, here are pointers to the urls for the distributions in zip format: http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-jetty6- javaee5-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-jetty6- minimal-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo- tomcat6-javaee5-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo- tomcat6-minimal-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo- framework-2.1.2-bin.zip The maven artifacts for the release can be found here: http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.2/ When the release vote is approved, these maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. [ ] +1 Release Geronimo 2.1.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.1.2 (please provide rationale) 72 hours would expire at 11:00PM ET on Saturday evening, 8/2. However, the vote may go longer while the tck results are verified. Joe Bohn
Re: Liferay as a Geronimo Plugin
On 14/07/2008, at 5:17 PM, Peter Petersson wrote: Gianny Damour wrote: Hello Peter, This is great news for Liferay developers! IMHO, one of the pain points with Liferay development is the time it takes to build, pack and deploy a WAR to Liferay. Even if Liferay is not so bad on this front when compared with other portals, a typical build-deploy-test cycle is way too time consuming and hence seriously impacts productivity. It would be fantastic to have an in-place WAR development mode in Geronimo. What do you think? I guess you are referring to working with/in the liferay ext development environment (?). I know to little of Liferay internals (and Geronimo for that mater) to be sure exactly what you are looking for, but I am sure the Liferay team is working hard on making there development environment easier and faster to work with. Maybe you can elaborate a bit more on what you are thinking of. Hello, My understanding is that each time that you make a change, you need to build a WAR; drop it in the deployment folder of Liferay; Liferay scans and transforms the WAR (looking for portlets, themes et cetera); it then hands it over to Geronimo for deployment. These deployment steps are time consuming, especially during development. What I had in mind is a Geronimo plugin allowing the in-place deployment of WARs to Liferay: 1. I define a specific WAR project structure; 2. I set-up my IDE to work against this well-known WAR project structure; 3. I implement my portlets and my IDE compiles the sources to the right folder of the WAR project structure; 4. I deploy to Geronimo my WAR project structure; 5. A custom ModuleBuilder identifies that this is a liferay WAR project structure; looks for the relevant Liferay components; and deploys it in-place. Personally I will look in to setting up a maven project for building Liferay portlets and have them deployed to Geronimo in some automated way instead of working with the ext environment, maybe this is what you are looking for? I don't know yet how the deployment could be done but I guess that I will making use of Liferays hot-deploy mechanism and/or if possible find some way to make use of Geronimo:s plugin concept. If possible I would certainly prefer the plugin solution. I believe that the Liferay hot-deployment mechanism is way too slow in development. Does that make sense? Thanks, Gianny Maybe the deployment could be done in a similar way of what we have done with the roller-themes plugin in the geromimo-roller project ? see https://svn.apache.org/repos/asf/geronimo/plugins/roller/trunk regards peter petersson Thanks, Gianny On 14/07/2008, at 4:11 AM, Peter Petersson wrote: I have posted a feature issue containing the build code over at http://support.liferay.com/browse/LEP-6680 regards peter petersson Peter Petersson wrote: Hi With the help of David J custom server assemblies document ( http://cwiki.apache.org/GMOxDOC21/custom-server- assemblies.html ) and my experience working with David on the roller plugin I have manage to put together a Liferay ( http:// www.liferay.com ) plugin. For now the plugin is with liferay 5.0.1 rc1 on G 2.1.1 and consists of the following maven artifacts * geronimo-jetty-liferay -- A minimalistic server assembly with the geronimo kernel the lifray jetty plugin and the geronimo console plugin. * liferay-jetty -- The liferay jetty plugin built on the lesslibs liferay-portal war pulling in dependencys like lifray - kernel, -service and -portlet. * geronimo-tomcat-liferay -- A minimalistic server as above but with the liferay tomcat plugin. * liferay-tomcat -- The liferay tomcat plugin as liferay-jetty above but with tomcat. * liferay-derby -- The liferay derby db backend plugin. * lifray-portal -- The liferay portal war fetched from liferay and pulled in to a local maven repos. * liferay-portal-lesslibs -- A overlay of the liferay portal war with filtered lib jars making use of some geronimo builtins instead. The geronimo-tomcat-liferay server seems to work fine but the jetty equivalent has a issue in the login page. When I have ironed out the jetty issue, cleaned up the code, made some additional improvements and put together a simple readme with build instructions ;) I am thinking of wrapping it up and first of all contribute it to the liferay community ( as suggested by david in http://marc.info/?l=geronimo- userm=121304343919559w=2 ) to see if they are interested in it for there geronimo integration. Anny suggestions, opinions, tips or help to pull this together in the best way possible are appreciated. regards peter petersson
Re: Liferay as a Geronimo Plugin
Hello Peter, This is great news for Liferay developers! IMHO, one of the pain points with Liferay development is the time it takes to build, pack and deploy a WAR to Liferay. Even if Liferay is not so bad on this front when compared with other portals, a typical build-deploy-test cycle is way too time consuming and hence seriously impacts productivity. It would be fantastic to have an in-place WAR development mode in Geronimo. What do you think? Thanks, Gianny On 14/07/2008, at 4:11 AM, Peter Petersson wrote: I have posted a feature issue containing the build code over at http://support.liferay.com/browse/LEP-6680 regards peter petersson Peter Petersson wrote: Hi With the help of David J custom server assemblies document ( http://cwiki.apache.org/GMOxDOC21/custom-server- assemblies.html ) and my experience working with David on the roller plugin I have manage to put together a Liferay ( http:// www.liferay.com ) plugin. For now the plugin is with liferay 5.0.1 rc1 on G 2.1.1 and consists of the following maven artifacts * geronimo-jetty-liferay -- A minimalistic server assembly with the geronimo kernel the lifray jetty plugin and the geronimo console plugin. * liferay-jetty -- The liferay jetty plugin built on the lesslibs liferay-portal war pulling in dependencys like lifray -kernel, - service and -portlet. * geronimo-tomcat-liferay -- A minimalistic server as above but with the liferay tomcat plugin. * liferay-tomcat -- The liferay tomcat plugin as liferay-jetty above but with tomcat. * liferay-derby -- The liferay derby db backend plugin. * lifray-portal -- The liferay portal war fetched from liferay and pulled in to a local maven repos. * liferay-portal-lesslibs -- A overlay of the liferay portal war with filtered lib jars making use of some geronimo builtins instead. The geronimo-tomcat-liferay server seems to work fine but the jetty equivalent has a issue in the login page. When I have ironed out the jetty issue, cleaned up the code, made some additional improvements and put together a simple readme with build instructions ;) I am thinking of wrapping it up and first of all contribute it to the liferay community ( as suggested by david in http://marc.info/?l=geronimo-userm=121304343919559w=2 ) to see if they are interested in it for there geronimo integration. Anny suggestions, opinions, tips or help to pull this together in the best way possible are appreciated. regards peter petersson
[jira] Created: (GERONIMO-4185) Cannot deployed WADI clustered Jetty and Tomcat Web applications within an EAR
Cannot deployed WADI clustered Jetty and Tomcat Web applications within an EAR -- Key: GERONIMO-4185 URL: https://issues.apache.org/jira/browse/GERONIMO-4185 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.1.1 Reporter: Gianny Damour Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4185) Cannot deployed WADI clustered Jetty and Tomcat Web applications within an EAR
[ https://issues.apache.org/jira/browse/GERONIMO-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-4185. --- Resolution: Fixed Now fixed. Cannot deployed WADI clustered Jetty and Tomcat Web applications within an EAR -- Key: GERONIMO-4185 URL: https://issues.apache.org/jira/browse/GERONIMO-4185 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.1 Reporter: Gianny Damour Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: tomcat6 and wadi-clustering configuration classloader clashes
Kevan, Joe thanks for your feedback. I had a reconsider the approach due to many circular dependencies between org.apache.geronimo.tomcat and org.apache.geronimo.tomcat.cluster, which prevent me to easily move the clustering GBeans to a new project. So, I just checked-in a better solution, which is backward compatible: I simply added a tomcat6-no-ha that hides the Tribes classes and upon deployment of WADI clustered applications I replace tomcat6 with tomcat6-no-ha, which avoids the identified classloader clashes. Thanks, Gianny On 03/07/2008, at 7:10 PM, Gianny Damour wrote: Hello, I am back from holiday; A quick scan of the mailing lists tells me that the upgrade to WADI 2.0 is causing classloader clashes. As identified by Jason W. and Kevan, a Tribes class is loaded by two distinct classloaders (tomcat6 and wadi-clustering configuration classloaders), which causes CCE upon message delivery. After having investigated this problem, it seems to me that the best way to fix it is to split the tomcat6 dependencies into two configurations: tomcat6 and tomcat6-tribes. tomcat6-tribes imports the tomcat6 configuration and the tribes dependency. The new tomcat6 configuration is the current tomcat6 configuration minus the tribes dependency. Such a change will break all the configurations defining Tribes clustering GBeans. Users having such configurations will have to redeploy them after having added the tromcat6-tribes configuration. I tried a backward compatible approach where the tribes dependency was pushed up to a parent configuration. Unfortunately, this change can only work if WADI dependencies are also imported by this new configuration, which is a less ideal approach than the above one. If no one objects, I intend to check-in this change over the week-end. Thanks, Gianny
Re: Geronimo v2.2 discussion
On 06/07/2008, at 7:16 AM, Kevan Miller wrote: ... The following are a mix of features that have been discussed previously, by me and others, and a few new brainstorming ideas. I've placed in categories, to help me think about them... ... Potential new function: - XML-based configuration state (i.e. no more config.ser) - SFSB clustering - Gianny has mentioned this in the past. Would be great to see... Hello, It is actually check-in in trunk: see http://article.gmane.org/ gmane.comp.java.geronimo.devel/59717 for the email I sent to dev@ after having checked-in this feature. Thanks, Gianny
tomcat6 and wadi-clustering configuration classloader clashes
Hello, I am back from holiday; A quick scan of the mailing lists tells me that the upgrade to WADI 2.0 is causing classloader clashes. As identified by Jason W. and Kevan, a Tribes class is loaded by two distinct classloaders (tomcat6 and wadi-clustering configuration classloaders), which causes CCE upon message delivery. After having investigated this problem, it seems to me that the best way to fix it is to split the tomcat6 dependencies into two configurations: tomcat6 and tomcat6-tribes. tomcat6-tribes imports the tomcat6 configuration and the tribes dependency. The new tomcat6 configuration is the current tomcat6 configuration minus the tribes dependency. Such a change will break all the configurations defining Tribes clustering GBeans. Users having such configurations will have to redeploy them after having added the tromcat6-tribes configuration. I tried a backward compatible approach where the tribes dependency was pushed up to a parent configuration. Unfortunately, this change can only work if WADI dependencies are also imported by this new configuration, which is a less ideal approach than the above one. If no one objects, I intend to check-in this change over the week-end. Thanks, Gianny
Re: [VOTE] ASF hosted machines for TCK Proposal
+1 I hope that the ASF Infrastructure Team has a good idea of the type of rather heavyweight testing involved by the TCK to warrant such a configuration. Thanks, Gianny On 20/05/2008, at 10:22 PM, Joe Bohn wrote: If we are to take this proposal forward to the ASF Infrastructure team, they want assurance that the Geronimo PMC is behind the recommendation and supports the intended use of the systems. I think it also bodes well to demonstrate that the entire Geronimo community stands behind the proposal, particularly since we will administer the machines ourselves, - so I encourage all to vote. [ ] +1 I agree with the need and support the proposal. Present it to the ASF Infrastructure team. [ ] 0 No opinion [ ] -1 I don't see the need or disagree with the proposal. Do not present this proposal to the ASF Infrastructure team. I'll plan on calling this vote on Friday (5/23) morning (9 AM EST). PROPOSAL Rationale: The Apache Geronimo community has a need to support the execution and sharing of results from Sun certification tests (cts) which are necessary gain JavaEE5 certification compliance. This information is only available to those Geronimo committers that have signed the Sun NDA and other Apache committers that have signed an NDA and gained approval of the Apache Geronimo PMC. This has allowed other Apache projects to test new products/releases by running JavaEE 5 TCK tests using the Apache Geronimo test infrastructure. In the past these resource intensive tests have been run on private machines by individuals. As more people become involved with Apache Geronimo and related projects, it is becoming obvious that we need a central system to run and share the results of these tests. A centralized testing environment allows the Geronimo community to more fully participate in the TCK process. Some committers don't have access to the hardware resources needed to run the Java EE TCK tests in a timely manner. Although some ad-hoc sharing of private machines has occurred, this is not ideal from a community perspective. Community controlled systems allow us to equitably share these resources. Request: To fulfill this requirement, the Apache Geronimo PMC is requesting the ASF infrastructure team to provide and host machines that can be used for this purpose. Initially, we would like to request two (2) machines that meet (as closely as possible) the specification below. However, we can see the need for 2 additional machines in the not too distant future. Machine specs: - 8 core (two 3.0 GHz quad-core) - 16 GB memory - two 750GB 7200 - rpm SATA 3GB/s disks - DVD R/W (20x?) - rack mountable specification to work with ASF infra requirements - LOM or other features as necessary for ASF infra support - to be developer managed and maintained by the Apache Geronimo Team - Apache Geronimo would assume all responsibility for: - configuration - backup/recovery - secure access - Strictly limited to those Apache Geronimo committers with NDAs on file or additional Apache committers with NDAs and approved by Geronimo PMC. - full, admin access would be granted to ASF infra with reboot directions - At least 2 active Apache Geronimo committers (with NDA authorization) would identified to manage the machines. - Running Linux with something like Xen for 4 VM images per machine. We may increase the number of VM images if it is feasible. - We would require both ssh and VNC access to the VMs. - It is not yet decided if we would use NAT to access the VMs or public IP addresses. Is there are recommendation from ASF Infra? - Automation will most likely be added to run builds, execute tests, and produce reports. - Capability to manually run tests on demand would also be supported. Admin Volunteers: - Joe Bohn (PMC) - Jay McHugh (PMC) - Jason Warner - Matt Hogstrom (PMC) - Kevan Miller (PMC)
Re: Google Analytics
Hello, Can someone add me? gianny.damour at gmail.com Thanks, Gianny On 15/05/2008, at 4:32 PM, David Blevins wrote: Setup google analytics on all our spaces and added everyone who's a committer who I could easily find a gmail address for. [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] You don't need a gmail address, just a google account. So if you're not in the above list, just get someone in the above list to add your google account. Just visit http://www.google.com/analytics/ to log in and view the data. It'll be a day or two before we see much of anything. -David
[jira] Commented: (GERONIMO-3993) Server fails to relaunch after deploying an application to a WADI cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596953#action_12596953
]
Gianny Damour commented on GERONIMO-3993:
-
Hello Joe, it is quite easy to reproduce this problem. As a matter of fact, it
is more general than currently classified as it applies to any configurations
deployed to secondary repositories. Such configurations may be automatically
started upon server start-up as per config.xml. However, such configurations
are not visible as they are defined by secondary repositories which have not
yet started. It seems to me that we need to change the way start-up
configurations are processed: I think that this problem could be solved by
deferring the resolution of such configurations till all the other start-up
configurations are up and running.
Server fails to relaunch after deploying an application to a WADI cluster
-
Key: GERONIMO-3993
URL: https://issues.apache.org/jira/browse/GERONIMO-3993
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.1, 2.1.2, 2.1.x
Environment: Windows
Reporter: YunFeng Ma
Assignee: Gianny Damour
Fix For: 2.1.2, 2.1.x, 2.2
1. A WADI cluster with two Nodes: Node1 and Node2
2. Deploy an application to Node1
3. Stop Node1 and Node2
4. Start Node1 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4d5fdcaa.sort(generated)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
{noformat}
5. Start Node2 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer_G_SLAVE/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35
[jira] Updated: (GERONIMO-3993) Server fails to relaunch after deploying an application to a WADI cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour updated GERONIMO-3993:
Component/s: (was: Clustering)
startup/shutdown
Move to startup/shutdown component.
Server fails to relaunch after deploying an application to a WADI cluster
-
Key: GERONIMO-3993
URL: https://issues.apache.org/jira/browse/GERONIMO-3993
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 2.1.1, 2.1.2, 2.1.x
Environment: Windows
Reporter: YunFeng Ma
Assignee: Gianny Damour
Fix For: 2.1.2, 2.1.x, 2.2
1. A WADI cluster with two Nodes: Node1 and Node2
2. Deploy an application to Node1
3. Stop Node1 and Node2
4. Start Node1 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4d5fdcaa.sort(generated)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
{noformat}
5. Start Node2 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer_G_SLAVE/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4d5fdcaa.sort(generated)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45
Re: No longer provide gshell command execute-alias in Geronimo v2.1.2?
Hello Donald, This was certainly not the conclusion as execute-alias was implemented and was working. The conclusion was that gshell native alias support supersedes execute-alias. Thanks, Gianny On 08/05/2008, at 2:59 AM, Donald Woods wrote: I removed this to match the change in trunk (2.2) as the conclusion on another thread was that this was never implemented and not working in Geronimo 2.1 nor 2.2. Jason would have to answer if your specific scenario/example is still valid or not. -Donald YunFeng Ma wrote: Hi Jason, The following is my usecase: set username=system set password=manager set login=deploy/connect -u $username -w $password Then how do I execute $login? I've tried the following one: $login but failed with error message: ERROR NotFoundException: deploy/connect -u system -w manager Thanks a lot. -- Yun Feng --- On *Tue, 5/6/08, Gianny Damour / [EMAIL PROTECTED]/* wrote: From: Gianny Damour [EMAIL PROTECTED] Subject: Re: No longer provide gshell command execute-alias in Geronimo v2.1.2? To: dev@geronimo.apache.org Date: Tuesday, May 6, 2008, 2:32 AM Hello Yun Feng, Are you currently using the execute-alias command? If yes, then Jason you will have to plug-in native gshell support before 2.1.2. Thanks, Gianny On 06/05/2008, at 7:25 PM, Jason Dillon wrote: Aliases where never intended to be invoked via a command, instead alias, as they work in Bash, simply become a new command. --jason On May 6, 2008, at 4:17 PM, YunFeng Ma wrote: Will this command be available in G v2.1.2? or v2.2. No this command, users can not execute an alias. --Yun Feng --- On Tue, 5/6/08, Jason Dillon [EMAIL PROTECTED] wrote: From: Jason Dillon [EMAIL PROTECTED] Subject: Re: No longer provide gshell command execute-alias in Geronimo v2.1.2? To: dev@geronimo.apache.org Date: Tuesday, May 6, 2008, 12:15 AM All of the Geronimo-specific alias commands were dropped from trunk, pending native GShell alias and unalias commands. --jason On May 6, 2008, at 10:15 AM, YunFeng Ma wrote: There is a gshell command execute-alias in G v2.1.1, but it disappeared in V2.1.2. Should we no longer provide it in V2.1.2? I noticed the this groovy script is removed in V2.1.2: framework \modules\geronimo-commands\src\main\groovy\org\apache\geronimo \commands\ExecuteAliasCommand.groovy Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. - --- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://us.rd.yahoo.com/evt=51733/*http:// mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: svn commit: r653620 - /geronimo/server/trunk/framework/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/jmx/RemoteDeploymentManager.java
Hi,
It would be preferable to have tests instead of in-lined comments.
Thanks,
Gianny
On 06/05/2008, at 8:46 AM, [EMAIL PROTECTED] wrote:
Author: gawor
Date: Mon May 5 15:46:11 2008
New Revision: 653620
URL: http://svn.apache.org/viewvc?rev=653620view=rev
Log:
pass the right filename when doing remote deployment or remote
library installation (GERONIMO-3999)
Modified:
geronimo/server/trunk/framework/modules/geronimo-deploy-jsr88/
src/main/java/org/apache/geronimo/deployment/plugin/jmx/
RemoteDeploymentManager.java
Modified: geronimo/server/trunk/framework/modules/geronimo-deploy-
jsr88/src/main/java/org/apache/geronimo/deployment/plugin/jmx/
RemoteDeploymentManager.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/framework/
modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/
deployment/plugin/jmx/RemoteDeploymentManager.java?
rev=653620r1=653619r2=653620view=diff
==
--- geronimo/server/trunk/framework/modules/geronimo-deploy-jsr88/
src/main/java/org/apache/geronimo/deployment/plugin/jmx/
RemoteDeploymentManager.java (original)
+++ geronimo/server/trunk/framework/modules/geronimo-deploy-jsr88/
src/main/java/org/apache/geronimo/deployment/plugin/jmx/
RemoteDeploymentManager.java Mon May 5 15:46:11 2008
@@ -242,7 +242,9 @@
}
PluginInstaller installer = getPluginInstaller();
try {
-return installer.startInstall(carFile,
defaultRepository, restrictToDefaultRepository, username, password);
+// make sure to pass args[0] as
RemoteDeployUtil.uploadFilesToServer will update
+// the args argument with the filenames returned from
the server
+return installer.startInstall(args[0],
defaultRepository, restrictToDefaultRepository, username, password);
} finally {
kernel.getProxyManager().destroyProxy(installer);
}
@@ -339,7 +341,9 @@
SetAbstractName set = kernel.listGBeans(new
AbstractNameQuery(PluginInstaller.class.getName()));
for (AbstractName name : set) {
PluginInstaller installer = (PluginInstaller)
kernel.getProxyManager().createProxy(name, PluginInstaller.class);
-Artifact artifact = installer.installLibrary(libFile,
groupId);
+// make sure to pass args[0] as
RemoteDeployUtil.uploadFilesToServer will update
+// the args argument with the filenames returned from
the server
+Artifact artifact = installer.installLibrary(args[0],
groupId);
kernel.getProxyManager().destroyProxy(installer);
return artifact;
}
Re: No longer provide gshell command execute-alias in Geronimo v2.1.2?
Hello Yun Feng, Are you currently using the execute-alias command? If yes, then Jason you will have to plug-in native gshell support before 2.1.2. Thanks, Gianny On 06/05/2008, at 7:25 PM, Jason Dillon wrote: Aliases where never intended to be invoked via a command, instead alias, as they work in Bash, simply become a new command. --jason On May 6, 2008, at 4:17 PM, YunFeng Ma wrote: Will this command be available in G v2.1.2? or v2.2. No this command, users can not execute an alias. --Yun Feng --- On Tue, 5/6/08, Jason Dillon [EMAIL PROTECTED] wrote: From: Jason Dillon [EMAIL PROTECTED] Subject: Re: No longer provide gshell command execute-alias in Geronimo v2.1.2? To: dev@geronimo.apache.org Date: Tuesday, May 6, 2008, 12:15 AM All of the Geronimo-specific alias commands were dropped from trunk, pending native GShell alias and unalias commands. --jason On May 6, 2008, at 10:15 AM, YunFeng Ma wrote: There is a gshell command execute-alias in G v2.1.1, but it disappeared in V2.1.2. Should we no longer provide it in V2.1.2? I noticed the this groovy script is removed in V2.1.2: framework \modules\geronimo-commands\src\main\groovy\org\apache\geronimo \commands\ExecuteAliasCommand.groovy Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: [YOKO][DISCUSS] Time to create a 1.0 release?
Hello Rick, Sorry, this is not directly related to your question. What kind of integration with ObjectGrid have you been working on? FWIW, I am working on a hierarchical, transactional, distributed, partitioned and replicated cache and data-grid solution as part of WADI and I am quite interested by this topic these days. Thanks, Gianny On 02/05/2008, at 11:43 PM, Rick McGuire wrote: I've recently completed an activity on seeing if we could get the IBM ObjectGrid product working with the Yoko ORB. This is a BIG CORBA application that rooted out quite a number of fringe bugs in the Yoko ORB. The testing effort involved no just interactions between a yoko client and server, but also in different client/ server combinations with the IBM ORB (ObjectGrid has some problems running on the Sun ORB at the moment, so that interoperability was not tested). In the process of debugging these problems, I also added quite a bit of additional logging to the core orb. Things are looking pretty good and stable at this point. Currently, Geronimo is shipping using a pinned snapshot of the yoko code rather than an official release. Harmony is picking up SNAPSHOT builds, I believe. I think it is time to consider publishing the 1.0 release so there's finally an official release level to work from. I currently don't have any work items I feel need to be done before a 1.0 release can get created. I have a number of items I think need to get improved what I'd prefer doing after we cut a 1.0 release. Does anybody else know of additional items that might be required for the 1.0 release? Rick
[jira] Assigned: (GERONIMO-3993) Server fails to relaunch after deploying an application to a WADI cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour reassigned GERONIMO-3993:
---
Assignee: Gianny Damour
Server fails to relaunch after deploying an application to a WADI cluster
-
Key: GERONIMO-3993
URL: https://issues.apache.org/jira/browse/GERONIMO-3993
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.1, 2.1.2, 2.1.x
Environment: Windows
Reporter: YunFeng Ma
Assignee: Gianny Damour
Fix For: 2.1.1, 2.1.2, 2.1.x
1. A WADI cluster with two Nodes: Node1 and Node2
2. Deploy an application to Node1
3. Stop Node1 and Node2
4. Start Node1 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4d5fdcaa.sort(generated)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
{noformat}
5. Start Node2 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer_G_SLAVE/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4d5fdcaa.sort(generated)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67
[jira] Closed: (GERONIMO-3991) Can not undeploy an application deployed in a WADI cluster via Admin Console
[ https://issues.apache.org/jira/browse/GERONIMO-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3991. --- Resolution: Won't Fix Fix Version/s: (was: 2.1.x) Assignee: YunFeng Ma Hello, What you are describing is the expected behavior. The configuration samples/cviewer_G_SLAVE/2.1.0.0/war is a standalone and slave configuration of the configuration samples/cviewer/2.1.0.0/war. You should uninstall samples/cviewer_G_SLAVE/2.1.0.0/war, note that it is classified as a system module and not as a Web module, in order to get an uninstall across your two nodes. Thanks, Gianny Can not undeploy an application deployed in a WADI cluster via Admin Console Key: GERONIMO-3991 URL: https://issues.apache.org/jira/browse/GERONIMO-3991 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.2, 2.1.x Environment: Windows Reporter: YunFeng Ma Assignee: YunFeng Ma Fix For: 2.1.2 1. Setup a WADI cluster with two notes: Note1 and Node2 2. Deploy an application, such as samples/cviewer/2.1.0.0/war, to Node1 3. cviewer works fine in Node1 and Node2 4. But in the Admin Console of Node1 and Node2, open Web App WARs portlet and there is only a application named samples/cviewer_G_SLAVE/2.1.0.0/war, even if I uninstall samples/cviewer_G_SLAVE/2.1.0.0/war in Node1's admin console, cviewer in GERONIMO_HOME\master-repository is not deleted and the cviewer in Node2 is not uninstalled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3989) gshell - infinite loop
gshell - infinite loop
--
Key: GERONIMO-3989
URL: https://issues.apache.org/jira/browse/GERONIMO-3989
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.1.1
Reporter: Gianny Damour
Priority: Critical
There is an infinite (exception?) loop problem with gshell where the exception
below is raised and not properly handled.
{code}
18:47:22,314 DEBUG (main) [org.apache.geronimo.gshell.console.JLineConsole]
Work failed: java.io.IOException: Input/output error
java.io.IOException: Input/output error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:194)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at jline.Terminal.readCharacter(Terminal.java:99)
at jline.UnixTerminal.readVirtualKey(UnixTerminal.java:128)
at jline.ConsoleReader.readVirtualKey(ConsoleReader.java:1450)
at jline.ConsoleReader.readBinding(ConsoleReader.java:651)
at jline.ConsoleReader.readLine(ConsoleReader.java:492)
at jline.ConsoleReader.readLine(ConsoleReader.java:446)
at
org.apache.geronimo.gshell.console.JLineConsole.readLine(JLineConsole.java:92)
at org.apache.geronimo.gshell.console.Console.work(Console.java:150)
at org.apache.geronimo.gshell.console.Console.run(Console.java:128)
at
org.apache.geronimo.gshell.console.JLineConsole.run(JLineConsole.java:68)
at org.apache.geronimo.gshell.DefaultShell.run(DefaultShell.java:202)
at org.apache.geronimo.gshell.GShell.run(GShell.java:156)
at org.apache.geronimo.gshell.cli.Main.boot(Main.java:249)
at org.apache.geronimo.gshell.cli.Main.main(Main.java:266)
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:585)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
18:47:22,315 DEBUG (main) [org.apache.geronimo.gshell.console.JLineConsole]
Work failed: java.io.IOException: Input/output error
java.io.IOException: Input/output error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:194)
{code}
Gr. As this exception is written every 1ms in gshell.log, it filled my hard
disk...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r651912 - in /geronimo/server/trunk/framework/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi: KernelContextGBean.java binding/GBeanBinding.java binding/GBeanFormatBind
The same goes for many many logs no?
Thanks,
Gianny
On 27/04/2008, at 8:20 PM, [EMAIL PROTECTED] wrote:
Author: jdillon
Date: Sun Apr 27 03:20:35 2008
New Revision: 651912
URL: http://svn.apache.org/viewvc?rev=651912view=rev
Log:
Make loggers static again
Modified:
geronimo/server/trunk/framework/modules/geronimo-naming/src/
main/java/org/apache/geronimo/gjndi/KernelContextGBean.java
geronimo/server/trunk/framework/modules/geronimo-naming/src/
main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java
geronimo/server/trunk/framework/modules/geronimo-naming/src/
main/java/org/apache/geronimo/gjndi/binding/GBeanFormatBinding.java
Modified: geronimo/server/trunk/framework/modules/geronimo-naming/
src/main/java/org/apache/geronimo/gjndi/KernelContextGBean.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/framework/
modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/
KernelContextGBean.java?rev=651912r1=651911r2=651912view=diff
==
--- geronimo/server/trunk/framework/modules/geronimo-naming/src/
main/java/org/apache/geronimo/gjndi/KernelContextGBean.java (original)
+++ geronimo/server/trunk/framework/modules/geronimo-naming/src/
main/java/org/apache/geronimo/gjndi/KernelContextGBean.java Sun Apr
27 03:20:35 2008
@@ -45,7 +45,7 @@
* @version $Rev$ $Date$
*/
public class KernelContextGBean extends WritableContext implements
GBeanLifecycle {
-private final Logger log = LoggerFactory.getLogger(getClass());
+private static final Logger log = LoggerFactory.getLogger
(KernelContextGBean.class);
private final Kernel kernel;
private final AbstractNameQuery abstractNameQuery;
Modified: geronimo/server/trunk/framework/modules/geronimo-naming/
src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/framework/
modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/
binding/GBeanBinding.java?rev=651912r1=651911r2=651912view=diff
==
--- geronimo/server/trunk/framework/modules/geronimo-naming/src/
main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java
(original)
+++ geronimo/server/trunk/framework/modules/geronimo-naming/src/
main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java Sun
Apr 27 03:20:35 2008
@@ -40,7 +40,7 @@
* @version $Rev$ $Date$
*/
public class GBeanBinding implements GBeanLifecycle {
-private final Logger log = LoggerFactory.getLogger(getClass());
+private static final Logger log = LoggerFactory.getLogger
(GBeanBinding.class);
private final Context context;
private final String name;
Modified: geronimo/server/trunk/framework/modules/geronimo-naming/
src/main/java/org/apache/geronimo/gjndi/binding/
GBeanFormatBinding.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/framework/
modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/
binding/GBeanFormatBinding.java?
rev=651912r1=651911r2=651912view=diff
==
--- geronimo/server/trunk/framework/modules/geronimo-naming/src/
main/java/org/apache/geronimo/gjndi/binding/GBeanFormatBinding.java
(original)
+++ geronimo/server/trunk/framework/modules/geronimo-naming/src/
main/java/org/apache/geronimo/gjndi/binding/GBeanFormatBinding.java
Sun Apr 27 03:20:35 2008
@@ -42,7 +42,7 @@
* @version $Rev$ $Date$
*/
public class GBeanFormatBinding extends KernelContextGBean {
-protected final Logger log = LoggerFactory.getLogger(getClass());
+protected static final Logger log = LoggerFactory.getLogger
(GBeanFormatBinding.class);
private static final Pattern PATTERN = Pattern.compile((\\{)(\
\w+)(}));
protected final String format;
Re: [VOTE] Geronimo Server 2.1.1 Release - RC2
+1 Thanks, Gianny On 24/04/2008, at 9:41 PM, Joe Bohn wrote: All, I've prepared a second release candidate of Geronimo Server 2.1.1 for your review and vote. The source for the Geronimo Server 2.1.1 release currently resides here: https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.1 When the release vote is approved, I will svn mv the code to https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.1 An archive of this source code can be found here: http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/ geronimo-2.1.1-src.tar.gz http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/ contains the 10 Java EE, Minimal, and Framework server binary distributions to be released (framework, tomcat/jetty, Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES and source code archives for the release. For your convenience, here are pointers to the urls for the distributions in zip format: http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo- jetty6-javaee5-2.1.1-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo- jetty6-minimal-2.1.1-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo- tomcat6-javaee5-2.1.1-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo- tomcat6-minimal-2.1.1-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.1-dist-rc2/geronimo- framework-2.1.1-bin.zip The maven artifacts for the release can be found here: http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.1-rc2/ When the release vote is approved, these maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. [ ] +1 Release Geronimo 2.1.1 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.1.1 (please provide rationale) I'll plan on calling this vote on Sunday evening (11 PM EST). I will start tck runs shortly on these images. Joe Bohn
Re: svn commit: r650430 - in /geronimo/server/trunk/plugins/clustering/farming: pom.xml src/main/plan/plan.xml
No.
Thanks,
Gianny
On 24/04/2008, at 2:11 AM, Donald Woods wrote:
Is this needed as part of the fix for GERONIMO-3970?
-Donald
[EMAIL PROTECTED] wrote:
Author: gdamour
Date: Tue Apr 22 02:46:42 2008
New Revision: 650430
URL: http://svn.apache.org/viewvc?rev=650430view=rev
Log:
Move cluster-repository and master-repository in the folder farming
Modified:
geronimo/server/trunk/plugins/clustering/farming/pom.xml
geronimo/server/trunk/plugins/clustering/farming/src/main/plan/
plan.xml
Modified: geronimo/server/trunk/plugins/clustering/farming/pom.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/
clustering/farming/pom.xml?rev=650430r1=650429r2=650430view=diff
=
=
--- geronimo/server/trunk/plugins/clustering/farming/pom.xml
(original)
+++ geronimo/server/trunk/plugins/clustering/farming/pom.xml Tue
Apr 22 02:46:42 2008
@@ -86,8 +86,8 @@
categoryClustering/category
instance
plugin-artifact
-copy-file relative-to=geronimo
dest-dir=cluster-repository/copy-file
-copy-file relative-to=geronimo
dest-dir=master-repository/copy-file
+copy-file relative-to=geronimo
dest-dir=farmingcluster-repository/copy-file
+copy-file relative-to=geronimo
dest-dir=farmingmaster-repository/copy-file
config-xml-content load=false
gbean name=NodeInfo
attribute name=name#
{clusterNodeName}/attribute
Modified: geronimo/server/trunk/plugins/clustering/farming/src/
main/plan/plan.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/
clustering/farming/src/main/plan/plan.xml?
rev=650430r1=650429r2=650430view=diff
=
=
--- geronimo/server/trunk/plugins/clustering/farming/src/main/plan/
plan.xml (original)
+++ geronimo/server/trunk/plugins/clustering/farming/src/main/plan/
plan.xml Tue Apr 22 02:46:42 2008
@@ -21,7 +21,7 @@
module xmlns=http://geronimo.apache.org/xml/ns/deployment-$
{geronimoSchemaVersion}
gbean name=MasterRepository
class=org.apache.geronimo.system.repository.Maven2Repository
-attribute name=rootmaster-repository//attribute
+attribute name=rootfarming/master-repository//
attribute
reference name=ServerInfo
nameServerInfo/name
/reference
@@ -55,7 +55,7 @@
/gbean
gbean name=ClusterRepository
class=org.apache.geronimo.system.repository.Maven2Repository
-attribute name=rootcluster-repository//attribute
+attribute name=rootfarming/cluster-repository//
attribute
reference name=ServerInfo
nameServerInfo/name
/reference
Re: svn commit: r600872 - in /geronimo/server/trunk: ./ assemblies/geronimo-boilerplate-minimal/ assemblies/geronimo-boilerplate-minimal/src/main/assembly/ assemblies/geronimo-boilerplate-minimal/src/
On 23/04/2008, at 4:21 PM, Jason Dillon wrote: Test is there: org.apache.geronimo.commands.RemoteServerControlCommandTest Documentation, talking about use-cases, would have been coming this week-end (I slowly started posting docos two weeks ago with farming followed by WADI clustering support). Is there anything up there now I can look at? No. Thanks, Gianny
[jira] Commented: (GERONIMO-3982) WADI cluster fails to distribute the installed application to all the nodes in the same cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591304#action_12591304
]
Gianny Damour commented on GERONIMO-3982:
-
Hello,
WADI is not involved at all in farming, i.e. deployment of modules to multiple
Geronimo instances. You need to follow the instructions provided by this WIKI
page http://cwiki.apache.org/confluence/display/GMOxDOC21/Farming.
The idea is to add a new GBean to the farming configuration for your second
node.
Thanks,
Giany
WADI cluster fails to distribute the installed application to all the nodes
in the same cluster
---
Key: GERONIMO-3982
URL: https://issues.apache.org/jira/browse/GERONIMO-3982
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.1, 2.1.x
Environment: Windows, IBM JDK
Reporter: YunFeng Ma
Fix For: 2.1.x, 2.2
1. Start two Geronimo servers (Node1 and Node2) which are in a WADI cluster,
I can see the following message in the geronmo launch console:
{noformat}
2008-4-22 14:16:49 org.codehaus.wadi.tribes.WadiMemberInterceptor memberAdded
信息: memberAdded:tcp://ZS01:4000
{noformat}
2. Deploy an application to Node1, verify the application and it works fine
in Node1
3. I can see the deployed application in Node1_Home\cluster-repository and
Node1_Home\master-repository, but there is no the application in
Node2_Home\cluster-repository and Node2_Home\master-repository
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: branches/2.1.1 in prep for a 2.1.1 release
Hi, I would like to port the change set -r 650083:650084 https:// svn.apache.org/repos/asf/geronimo/server/trunk to 2.1.1. This is a very minor change. If no one object, I will check-in in 24 hours. Thanks, Gianny On 15/04/2008, at 4:20 AM, Joe Bohn wrote: I'd like to branch later today in preparation for a 2.1.1 release (branches/2.1.1) and update branches/2.1 to 2.1.2-SNAPSHOT. Any objections? Minor changes can still be made in branches/2.1.1 while we make preparations for a release candidate. AFAIK the only remaining changes are version updates in the root pom for: OpenEJB 3.0 - Passed vote and currently available in M2 repo. David Blevins are you planning to update this in Geronimo or should I? ActiveMQ 4.1.2 - Passed vote ... not yet available in M2 repo. David Jencks are you planning to update this in Geronimo as soon as the artifacts are pushed? ActiveIO 3.0.1 - Passed vote and currently available in M2 repo. David Jencks are you planning to update this in Geronimo or should I? tranql-connector-db2-xa 1.2 - Currently available in M2 repo. David Jencks are you planning to update this in Geronimo or should I? Joe Bohn
[jira] Assigned: (GERONIMO-3970) Fail to delploy a web application to a WADI cluster
[ https://issues.apache.org/jira/browse/GERONIMO-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-3970: --- Assignee: Gianny Damour Fail to delploy a web application to a WADI cluster --- Key: GERONIMO-3970 URL: https://issues.apache.org/jira/browse/GERONIMO-3970 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.1 Environment: Windows Reporter: YunFeng Ma Assignee: Gianny Damour Fix For: 2.1.1 Deploy a web application to a WADI cluster with two nodes and get the following exceptions: H:\geornimo server2\bindeploy --user system --password manager --port 110 8 deploy --targets org.apache.geronimo.configs/farming/2.1.1-SNAPSHOT/car?Servic eModule=org.apache.geronimo.configs/farming/2.1.1-SNAPSHOT/car,j2eeType=Configur ationStore,name=MasterConfigurationStore f:\temp\servlet-examples-cluster-server 2.war f:\temp\servlet-examples-cluster-plan.xml Using GERONIMO_BASE: H:\geornimo server2 Using GERONIMO_HOME: H:\geornimo server2 Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:C:\Program Files\IBM\Java50\jre org.apache.geronimo.kernel.config.LifecycleException: start of samples/servlet-e xamples-cluster-server1/1.0/war failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:566) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:530) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl ectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: 239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl ectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: 239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBrid ge.java:172) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImp l.java:231) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:833) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802 ) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnecti onImpl.java:1423) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectio nImpl.java:96) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run (RMIConnectionImpl.java:1260) at java.security.AccessController.doPrivileged(AccessController.java:275 ) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(R MIConnectionImpl.java:1363) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImp l.java:797) at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309) at sun.rmi.transport.Transport$1.run(Transport.java:168) at java.security.AccessController.doPrivileged(AccessController.java:275 ) at sun.rmi.transport.Transport.serviceCall(Transport.java:164) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:5 06) at sun.rmi.transport.tcp.TCPTransport
[jira] Commented: (GERONIMO-3970) Fail to delploy a web application to a WADI cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590877#action_12590877
]
Gianny Damour commented on GERONIMO-3970:
-
Hello,
This is a problem with the MasterConfigurationStore GBean, which defines a
faulty defautlEnvironment: it imports the clustering configuration instead of
the farming one. To fix this problem, you can add the following GBean override
to your config.xml for the farming configuration:
{noformat}
gbean name=MasterConfigurationStore
attribute
propertyEditor=org.apache.geronimo.deployment.service.EnvironmentBuilder
name=defaultEnvironment
environment
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
dependencies
dependency
groupIdorg.apache.geronimo.configs/groupId
artifactIdfarming/artifactId
typecar/type
/dependency
/dependencies
/environment
/attribute
/gbean
{noformat}
Thanks for reporting this problem.
Fail to delploy a web application to a WADI cluster
---
Key: GERONIMO-3970
URL: https://issues.apache.org/jira/browse/GERONIMO-3970
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.1
Environment: Windows
Reporter: YunFeng Ma
Assignee: Gianny Damour
Fix For: 2.1.1
Deploy a web application to a WADI cluster with two nodes and get the
following exceptions:
H:\geornimo server2\bindeploy --user system --password manager --port 110
8 deploy --targets
org.apache.geronimo.configs/farming/2.1.1-SNAPSHOT/car?Servic
eModule=org.apache.geronimo.configs/farming/2.1.1-SNAPSHOT/car,j2eeType=Configur
ationStore,name=MasterConfigurationStore
f:\temp\servlet-examples-cluster-server
2.war f:\temp\servlet-examples-cluster-plan.xml
Using GERONIMO_BASE: H:\geornimo server2
Using GERONIMO_HOME: H:\geornimo server2
Using GERONIMO_TMPDIR: var\temp
Using JRE_HOME:C:\Program Files\IBM\Java50\jre
org.apache.geronimo.kernel.config.LifecycleException: start of
samples/servlet-e
xamples-cluster-server1/1.0/war failed
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
figuration(SimpleConfigurationManager.java:566)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
figuration(SimpleConfigurationManager.java:530)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl
ectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
n.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
java:867)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
239)
at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342)
at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl
ectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
n.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
java:867)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
239)
at
org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBrid
ge.java:172)
at
com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImp
l.java:231)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM
BeanServerInterceptor.java:833)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802
)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnecti
onImpl.java:1423)
at
javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectio
nImpl.java:96)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run
Re: What is the master-* cluster-* repository stuff?
Hello Jason, These two folders are used by the farming feature. They are the MasterConfigurationStore and ClusterStore repositories respectively (see http://cwiki.apache.org/GMOxDOC21/farming.html for description of these two repos.) If need be, we can easily move them. Is the following prettier? Within the root install: farming | +-- master-repository | +-- cluster-repository Thanks, Gianny On 21/04/2008, at 9:07 PM, Jason Dillon wrote: Seems very ugly to have these at the top-level... :-( --jason
