[jira] Commented: (GERONIMO-4900) MissingDependencyException while deploying EAR in Clustering Environment

2009-10-17 Thread Gianny Damour (JIRA)

[ 
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

2009-10-12 Thread Gianny Damour (JIRA)

[ 
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

2009-10-12 Thread Gianny Damour

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?

2009-09-05 Thread Gianny Damour

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

2009-07-09 Thread Gianny Damour

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

2009-07-08 Thread Gianny Damour

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?

2009-07-08 Thread Gianny Damour

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?

2009-07-07 Thread Gianny Damour

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 ?

2009-06-19 Thread Gianny Damour

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 ?

2009-06-15 Thread Gianny Damour

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

2009-05-16 Thread Gianny Damour (JIRA)

 [ 
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

2009-05-14 Thread Gianny Damour (JIRA)
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?

2009-04-08 Thread Gianny Damour

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?

2009-04-07 Thread Gianny Damour

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

2009-03-19 Thread Gianny Damour

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

2009-03-18 Thread Gianny Damour

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

2009-03-17 Thread Gianny Damour (JIRA)
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

2009-03-17 Thread Gianny Damour (JIRA)

 [ 
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?

2009-03-17 Thread Gianny Damour


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?

2009-03-12 Thread Gianny Damour

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?

2009-03-12 Thread Gianny Damour

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?

2009-03-11 Thread Gianny Damour

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?

2009-03-11 Thread Gianny Damour

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

2009-03-10 Thread Gianny Damour (JIRA)

[ 
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

2009-03-07 Thread Gianny Damour

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

2009-03-01 Thread Gianny Damour (JIRA)

 [ 
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

2009-02-26 Thread Gianny Damour (JIRA)
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

2009-02-26 Thread Gianny Damour (JIRA)

 [ 
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

2009-02-26 Thread Gianny Damour (JIRA)

 [ 
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

2009-02-17 Thread Gianny Damour

+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

2009-02-12 Thread Gianny Damour


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

2009-02-11 Thread Gianny Damour

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

2009-01-25 Thread Gianny Damour

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

2009-01-25 Thread Gianny Damour

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]

2009-01-14 Thread Gianny Damour

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

2009-01-13 Thread Gianny Damour (JIRA)

[ 
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/

2008-11-20 Thread Gianny Damour

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

2008-11-14 Thread Gianny Damour

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

2008-11-14 Thread Gianny Damour

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

2008-11-14 Thread Gianny Damour

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

2008-11-13 Thread Gianny Damour

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

2008-11-13 Thread Gianny Damour

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

2008-11-12 Thread Gianny Damour

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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)
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

2008-11-07 Thread Gianny Damour (JIRA)
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

2008-11-07 Thread Gianny Damour (JIRA)
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

2008-11-07 Thread Gianny Damour (JIRA)
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

2008-11-07 Thread Gianny Damour

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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-11-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-10-28 Thread Gianny Damour

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

2008-10-24 Thread Gianny Damour

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

2008-10-17 Thread Gianny Damour

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

2008-10-17 Thread Gianny Damour

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

2008-10-16 Thread Gianny Damour

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

2008-10-15 Thread Gianny Damour

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

2008-10-10 Thread Gianny Damour

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

2008-10-10 Thread Gianny Damour

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

2008-09-11 Thread Gianny Damour (JIRA)

 [ 
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

2008-09-11 Thread Gianny Damour (JIRA)
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

2008-08-14 Thread Gianny Damour
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

2008-08-04 Thread Gianny Damour

+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

2008-07-16 Thread Gianny Damour

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

2008-07-13 Thread Gianny Damour

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

2008-07-07 Thread Gianny Damour (JIRA)
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

2008-07-07 Thread Gianny Damour (JIRA)

 [ 
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

2008-07-06 Thread Gianny Damour

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

2008-07-06 Thread Gianny Damour

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

2008-07-03 Thread Gianny Damour

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

2008-05-20 Thread Gianny Damour

+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

2008-05-16 Thread Gianny Damour


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

2008-05-14 Thread Gianny Damour (JIRA)

[ 
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

2008-05-14 Thread Gianny Damour (JIRA)

 [ 
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?

2008-05-07 Thread Gianny Damour

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

2008-05-06 Thread Gianny Damour

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?

2008-05-06 Thread Gianny Damour

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?

2008-05-02 Thread Gianny Damour

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

2008-04-29 Thread Gianny Damour (JIRA)

 [ 
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

2008-04-28 Thread Gianny Damour (JIRA)

 [ 
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

2008-04-27 Thread Gianny Damour (JIRA)
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

2008-04-27 Thread Gianny Damour

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

2008-04-26 Thread Gianny Damour

+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

2008-04-26 Thread Gianny Damour

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/

2008-04-26 Thread Gianny Damour


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

2008-04-22 Thread Gianny Damour (JIRA)

[ 
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

2008-04-21 Thread Gianny Damour

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

2008-04-21 Thread Gianny Damour (JIRA)

 [ 
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

2008-04-21 Thread Gianny Damour (JIRA)

[ 
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?

2008-04-21 Thread Gianny Damour

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




  1   2   3   4   5   6   7   >