[jira] Commented: (GERONIMO-4900) MissingDependencyException while deploying EAR in Clustering Environment
[ https://issues.apache.org/jira/browse/GERONIMO-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12766976#action_12766976 ] Gianny Damour commented on GERONIMO-4900: - Hi Ashish, this looks fine. What is the branch you want this patch to be applied to? MissingDependencyException while deploying EAR in Clustering Environment Key: GERONIMO-4900 URL: https://issues.apache.org/jira/browse/GERONIMO-4900 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.4 Reporter: Amit puri Assignee: Ashish Jain Fix For: 2.1.5 Attachments: ClusterTestEAR.ear, Geronimo4900.patch 1. Installed two geronimo instances A and B at different paths 2. Made the following changes to Geronimo A For var\config\config-substitutions.properties clusterNodeName=NODE -- clusterNodeName=NODE-A For var\config\config.xml, add the following contents to module: org.apache.geronimo.configs/farming/2.1.4/car - gbean name=org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=NodeInfo,name=NODE-B gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo attribute name=nameNODE-B/attribute attribute propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor name=extendedJMXConnectorInfo ns:javabean class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2; xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns= ns:property name=usernamesystem/ns:property ns:property name=passwordmanager/ns:property ns:property name=protocolrmi/ns:property ns:property name=hostlocalhost/ns:property ns:property name=port1109/ns:property ns:property name=urlPathJMXConnector/ns:property ns:property name=localfalse/ns:property /ns:javabean/attribute /gbean - 3. Made the following changes to Geronimo B For var\config\config-substitutions.properties clusterNodeName=NODE -- clusterNodeName=NODE-B PortOffset=0 -- PortOffset=10 For var\config\config.xml, add the following contents to module: org.apache.geronimo.configs/farming/2.1.4/car - gbean name=org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=NodeInfo,name=NODE-A gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo attribute name=nameNODE-A/attribute attribute propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor name=extendedJMXConnectorInfo ns:javabean class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2; xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns= ns:property name=usernamesystem/ns:property ns:property name=passwordmanager/ns:property ns:property name=protocolrmi/ns:property ns:property name=hostlocalhost/ns:property ns:property name=port1099/ns:property ns:property name=urlPathJMXConnector/ns:property ns:property name=localfalse/ns:property /ns:javabean/attribute /gbean - 4. Started both Geronimo A and B 5. Ran the following commands in Geronimo_A_Path\bin deploy --user system --password manager start org.apache.geronimo.configs/farming/2.1.4/car deploy --user system --password manager --port 1109 start org.apache.geronimo.configs/farming/2.1.4/car 6. Deployed one sample ClusterTestEAR.ear in Geronimo_A_Path\bin deploy --user system --password manager deploy --targets org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=ConfigurationStore,name=MasterConfigurationStore PATH_SAMPLE\ClusterTestEAR.ear Output: A) Errors in Geronimo A geronimo.log INFO [BasicClusterConfigurationStoreClient] Upload of configuration [default/ClusterTestEAR_G_SLAVE/1.0/ear] - [File(s) transferred to server. Resuming deployment operation.] INFO
[jira] Commented: (GERONIMO-4900) MissingDependencyException while deploying EAR in Clustering Environment
[ https://issues.apache.org/jira/browse/GERONIMO-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12764643#action_12764643 ] Gianny Damour commented on GERONIMO-4900: - This problem is due to the modification of configuration names (suffix '_G_SLAVE' is added to base name) happening during farm deployment. GERONIMO-4556, which should have been included in 2.1.4, addresses this problem. In a few words, configuration names are no longer updated. MissingDependencyException while deploying EAR in Clustering Environment Key: GERONIMO-4900 URL: https://issues.apache.org/jira/browse/GERONIMO-4900 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.4 Reporter: Amit puri Assignee: Ashish Jain Attachments: ClusterTestEAR.ear 1. Installed two geronimo instances A and B at different paths 2. Made the following changes to Geronimo A For var\config\config-substitutions.properties clusterNodeName=NODE -- clusterNodeName=NODE-A For var\config\config.xml, add the following contents to module: org.apache.geronimo.configs/farming/2.1.4/car - gbean name=org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=NodeInfo,name=NODE-B gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo attribute name=nameNODE-B/attribute attribute propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor name=extendedJMXConnectorInfo ns:javabean class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2; xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns= ns:property name=usernamesystem/ns:property ns:property name=passwordmanager/ns:property ns:property name=protocolrmi/ns:property ns:property name=hostlocalhost/ns:property ns:property name=port1109/ns:property ns:property name=urlPathJMXConnector/ns:property ns:property name=localfalse/ns:property /ns:javabean/attribute /gbean - 3. Made the following changes to Geronimo B For var\config\config-substitutions.properties clusterNodeName=NODE -- clusterNodeName=NODE-B PortOffset=0 -- PortOffset=10 For var\config\config.xml, add the following contents to module: org.apache.geronimo.configs/farming/2.1.4/car - gbean name=org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=NodeInfo,name=NODE-A gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo attribute name=nameNODE-A/attribute attribute propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor name=extendedJMXConnectorInfo ns:javabean class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2; xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns= ns:property name=usernamesystem/ns:property ns:property name=passwordmanager/ns:property ns:property name=protocolrmi/ns:property ns:property name=hostlocalhost/ns:property ns:property name=port1099/ns:property ns:property name=urlPathJMXConnector/ns:property ns:property name=localfalse/ns:property /ns:javabean/attribute /gbean - 4. Started both Geronimo A and B 5. Ran the following commands in Geronimo_A_Path\bin deploy --user system --password manager start org.apache.geronimo.configs/farming/2.1.4/car deploy --user system --password manager --port 1109 start org.apache.geronimo.configs/farming/2.1.4/car 6. Deployed one sample ClusterTestEAR.ear in Geronimo_A_Path\bin deploy --user system --password manager deploy --targets org.apache.geronimo.configs/farming/2.1.4/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4/car,j2eeType=ConfigurationStore,name=MasterConfigurationStore PATH_SAMPLE\ClusterTestEAR.ear Output: A) Errors in Geronimo A geronimo.log INFO [BasicClusterConfigurationStoreClient] Upload of
[jira] Resolved: (GERONIMO-4626) Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing
[ https://issues.apache.org/jira/browse/GERONIMO-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour resolved GERONIMO-4626. - Resolution: Fixed Fix Version/s: (was: 2.2) Fix has been checked in and integration tested with mod_jk. Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing Key: GERONIMO-4626 URL: https://issues.apache.org/jira/browse/GERONIMO-4626 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.4 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1.5 It is not possible to fulfill session affinity with Apache mod_jk as the value of the JSESSIONID cookie does not embed a jvmRoute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4626) Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing
Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing Key: GERONIMO-4626 URL: https://issues.apache.org/jira/browse/GERONIMO-4626 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.1.4 Reporter: Gianny Damour Assignee: Gianny Damour It is not possible to fulfill session affinity with Apache mod_jk as the value of the JSESSIONID cookie does not embed a jvmRoute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4590) One ClassLoader per Jar Model
One ClassLoader per Jar Model - Key: GERONIMO-4590 URL: https://issues.apache.org/jira/browse/GERONIMO-4590 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour As discussed on @dev, to reduce the number of ClassCastExceptions caused by collaborating configurations importing the same dependencies, the classloading design can be improved to use a shared and global poll of classloaders. Each classloader in this global poll is mapped to only one JAR. They are put in a hierarchy according to their maven dependency declarations. As maven dependencies may not be systematically correct, additional dependency declarations can also be provided by dropping a XML file artifactId-version-additional.xml beside the JAR or POM file artifactId-version.jar (.pom) whose dependencies are to be supplemented. This patch is a preview of the functionality to trigger more discussions. 22 out of the 74 configurations of the jetty-jee5 assembly can start fine with this patch. The failure observed for the failing configuration appears to be another maven dependency declaration issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4590) One ClassLoader per Jar Model
[ https://issues.apache.org/jira/browse/GERONIMO-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-4590: Attachment: additional-maven-dependencies.jar OneClassLoaderPerJar.txt OneClassLoaderPerJar.txt is a geronimo-kernel patch. additional-maven-dependencies.jar is a jar to be unpacked in the geronimo repository, which include additional maven dependency declarations for specific JAR. One ClassLoader per Jar Model - Key: GERONIMO-4590 URL: https://issues.apache.org/jira/browse/GERONIMO-4590 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Attachments: additional-maven-dependencies.jar, OneClassLoaderPerJar.txt As discussed on @dev, to reduce the number of ClassCastExceptions caused by collaborating configurations importing the same dependencies, the classloading design can be improved to use a shared and global poll of classloaders. Each classloader in this global poll is mapped to only one JAR. They are put in a hierarchy according to their maven dependency declarations. As maven dependencies may not be systematically correct, additional dependency declarations can also be provided by dropping a XML file artifactId-version-additional.xml beside the JAR or POM file artifactId-version.jar (.pom) whose dependencies are to be supplemented. This patch is a preview of the functionality to trigger more discussions. 22 out of the 74 configurations of the jetty-jee5 assembly can start fine with this patch. The failure observed for the failing configuration appears to be another maven dependency declaration issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4579) There are errors during zip file extracted on Linux OS using farm clustering
[
https://issues.apache.org/jira/browse/GERONIMO-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680397#action_12680397
]
Gianny Damour commented on GERONIMO-4579:
-
I do not understand what you mean by files are not in the correct path.
Can you start the WAR on NODE-A?
There are errors during zip file extracted on Linux OS using farm clustering
Key: GERONIMO-4579
URL: https://issues.apache.org/jira/browse/GERONIMO-4579
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.4
Environment: SW:
JAVA6+WIN2008+SLES10SP2
HW:
Intel x86
Reporter: Zhen Chen
Attachments: zip_extracted_errors .jpg
Can't deploy a war to farm clustering successfully, because the zip file
extracted on Linux OS is wrong.
After deploying a war to farm clustering(ex, NODE-A,NODE-B), I found that the
files are not in the correct path, while named in the form like
WEB-INF\classes\..
.java in cluster-repository on Linux OS.
I have tried that on RHEL 5.2, SLES 10 OS. Same error occurs.
I think this is a bug, Please check it.
My steps:
1.Login on NODE-A server
1.1 For var\config\config-substitutions.properties
{code:xml}
clusterNodeName=NODE -- clusterNodeName=NODE-A
RemoteDeployHostname=MachineA_IP
{code}
1.2 For var\config\config.xml, add the following contents to module:
org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
{code:xml}
gbean
name=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2
.1.4/car,j2eeType=NodeInfo,name=NodeInfoB
gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo
attribute name=nameNODE-B/attribute
attribute
propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor
name=extendedJMXConnectorInfo
ns:javabean
class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo
xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2;
xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns=
ns:property name=usernamesystem/ns:property
ns:property name=passwordmanager/ns:property
ns:property name=protocolrmi/ns:property
ns:property name=hostMachineB_IP/ns:property
ns:property name=port1099/ns:property
ns:property name=urlPathJMXConnector/ns:property
ns:property name=localfalse/ns:property
/ns:javabean/attribute
/gbean
{code}
2.Login on NODE-B server
2.1 For var\config\config-substitutions.properties
{code:xml}
clusterNodeName=NODE -- clusterNodeName=NODE-B
RemoteDeployHostname=MachineB_IP
{code}
2.2 For var\config\config.xml, add the following contents to module:
org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
{code:xml}
gbean
name=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/far
ming/2.1.4-SNAPSHOT/car,j2eeType=NodeInfo,name=NodeInfoA
gbeanInfo=org.apache.geronimo.farm.config.BasicNodeInfo
attribute name=nameNODE-A/attribute
attribute
propertyEditor=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor
name=extendedJMXConnectorInfo
ns:javabean
class=org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo
xmlns:ns4=http://geronimo.apache.org/xml/ns/attributes-1.2;
xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; xmlns=
ns:property name=usernamesystem/ns:property
ns:property name=passwordmanager/ns:property
ns:property name=protocolrmi/ns:property
ns:property name=hostMachineA_IP/ns:property
ns:property name=port1099/ns:property
ns:property name=urlPathJMXConnector/ns:property
ns:property name=localfalse/ns:property
/ns:javabean/attribute
/gbean
{code}
3. Start NODE- A server , and NODE-B server
4.Run the following commands in GERONIMO_HOME\bin in Machine A
{code:xml}
4.1 deploy.bat/sh --user system --password manager start
org.apache.geronimo.configs/farming//car
4.2 deploy.bat/sh --user system --password manager --host MachineB_IP
start org.apache.geronimo.configs/farming//car
{code}
5.deploy.bat/sh --user system --password manager deploy --targets
{code:xml}
org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car,j2eeType=Confi
[jira] Closed: (GERONIMO-4556) Farm deployment of configurations using JNDI resource references does not work
[
https://issues.apache.org/jira/browse/GERONIMO-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour closed GERONIMO-4556.
---
Resolution: Fixed
Fix Version/s: 2.1.4
Farmed modules are no more renamed to prevent issues with JNDI resource
reference resolutions. The master module is name named X_G_MASTER where X is
the artifact id of the farmed module.
Farm deployment of configurations using JNDI resource references does not work
--
Key: GERONIMO-4556
URL: https://issues.apache.org/jira/browse/GERONIMO-4556
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.1.3
Reporter: Gianny Damour
Assignee: Gianny Damour
Fix For: 2.1.4
Due to the transformation of the name of a configuration when it is
distributed to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI
resource references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4556) Farm deployment of configurations using JNDI resource references does not work
Farm deployment of configurations using JNDI resource references does not work
--
Key: GERONIMO-4556
URL: https://issues.apache.org/jira/browse/GERONIMO-4556
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: deployment
Affects Versions: 2.1.3
Reporter: Gianny Damour
Due to the transformation of the name of a configuration when it is distributed
to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI resource
references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4556) Farm deployment of configurations using JNDI resource references does not work
[
https://issues.apache.org/jira/browse/GERONIMO-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour updated GERONIMO-4556:
Description:
Due to the transformation of the name of a configuration when it is distributed
to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI resource
references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code}
was:
Due to the transformation of the name of a configuration when it is distributed
to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI resource
references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code]
Farm deployment of configurations using JNDI resource references does not work
--
Key: GERONIMO-4556
URL: https://issues.apache.org/jira/browse/GERONIMO-4556
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.1.3
Reporter: Gianny Damour
Due to the transformation of the name of a configuration when it is
distributed to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI
resource references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4556) Farm deployment of configurations using JNDI resource references does not work
[
https://issues.apache.org/jira/browse/GERONIMO-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour reassigned GERONIMO-4556:
---
Assignee: Gianny Damour
Farm deployment of configurations using JNDI resource references does not work
--
Key: GERONIMO-4556
URL: https://issues.apache.org/jira/browse/GERONIMO-4556
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.1.3
Reporter: Gianny Damour
Assignee: Gianny Damour
Due to the transformation of the name of a configuration when it is
distributed to a server farm (i.e. the _G_SLAVE suffix is appended) JNDI
resource references can not be resolved.
Here is an user provided stack trace which illustrates this problem:
{code}
java.lang.IllegalStateException: No configuration found for id:
clustering/clustering/2.1/war
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getConfiguration(AbstractEntryFactory.java:110)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.resolveTargetName(AbstractEntryFactory.java:126)
at
org.apache.geronimo.naming.reference.AbstractEntryFactory.getGBean(AbstractEntryFactory.java:64)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:44)
at
org.apache.geronimo.naming.reference.ResourceReferenceFactory.buildEntry(ResourceReferenceFactory.java:33)
at
org.apache.geronimo.naming.enc.EnterpriseNamingContext.createEnterpriseNamingContext(EnterpriseNamingContext.java:55)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.init(TomcatWebAppContext.java:181)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4508) Spring AOP AspectJ conflict when using Apache CXF
[ https://issues.apache.org/jira/browse/GERONIMO-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663467#action_12663467 ] Gianny Damour commented on GERONIMO-4508: - Hi Kevan, This is a recurrent problem; now that we have a private class support whereby we can explicitly configure specific classes and resources as private for a given config, I believe we should use this mechanism to insulate CXF children configurations. Thanks, Gianny Spring AOP AspectJ conflict when using Apache CXF - Key: GERONIMO-4508 URL: https://issues.apache.org/jira/browse/GERONIMO-4508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Spring 2.5.6, Geronimo JEE Tomcat 2.1.3, AspectJ 1.6.2 Reporter: Bruno César Brito Sant'Anna Attachments: jetty_trace.txt, trace.txt I'm trying to create a WebService Bean on Geronimo using Spring IoC container. Well, I followed this tutorial http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html My GERONIMO_OPTS var value is -Dorg.apache.geronimo.jaxws.provider=cxf -Dorg.apache.geronimo.saaj.provider=axis2 -Dorg.apache.cxf.jaxws.checkPublishEndpointPermission=false When server starts, when reading Spring AOC Config my server crashes... Summary stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.support.DefaultBeanFactoryPointcutAdvisor': Instantiation of bean failed; nested exception is java.lang.AbstractMethodError: org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.determineConstructor(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/reflect/Constructor; It took me several hours to discover that cxf environment was messing around with Spring... reseting GERONIMO_OPTS and removing cxf webservice stuff from my applicationContext.xml made my server run again. Looks like I cannot use CXF with AOP... I'll attach full stack trace... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4400) Improve error message of DependencyChangeMojo
[ https://issues.apache.org/jira/browse/GERONIMO-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-4400: Component/s: buildsystem Affects Version/s: 2.1.3 Fix Version/s: 2.2 Improve error message of DependencyChangeMojo - Key: GERONIMO-4400 URL: https://issues.apache.org/jira/browse/GERONIMO-4400 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1.3 Reporter: Gianny Damour Fix For: 2.2 When dependencies change, it would be great to have an error message providing some basic instructions on how to proceed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4399) GBean Annotations are not supported for GBeans declared in XML configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-4399: --- Assignee: Gianny Damour GBean Annotations are not supported for GBeans declared in XML configuration Key: GERONIMO-4399 URL: https://issues.apache.org/jira/browse/GERONIMO-4399 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 It is not possible to declare a GBean using the annotation base configuration style in any DDs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4400) Improve error message of DependencyChangeMojo
[ https://issues.apache.org/jira/browse/GERONIMO-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-4400: --- Assignee: Gianny Damour Improve error message of DependencyChangeMojo - Key: GERONIMO-4400 URL: https://issues.apache.org/jira/browse/GERONIMO-4400 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When dependencies change, it would be great to have an error message providing some basic instructions on how to proceed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4399) GBean Annotations are not supported for GBeans declared in XML configuration
GBean Annotations are not supported for GBeans declared in XML configuration Key: GERONIMO-4399 URL: https://issues.apache.org/jira/browse/GERONIMO-4399 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Fix For: 2.2 It is not possible to declare a GBean using the annotation base configuration style in any DDs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4400) Improve error message of DependencyChangeMojo
Improve error message of DependencyChangeMojo - Key: GERONIMO-4400 URL: https://issues.apache.org/jira/browse/GERONIMO-4400 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Reporter: Gianny Damour When dependencies change, it would be great to have an error message providing some basic instructions on how to proceed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4401) Extension of configuration dependencies and gbeans via Groovy scripts
Extension of configuration dependencies and gbeans via Groovy scripts - Key: GERONIMO-4401 URL: https://issues.apache.org/jira/browse/GERONIMO-4401 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When a configuration is started, we should provide a way to modify dependencies and GBeans of the configuration through the execution of Groovy scripts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4403) Provide a mechanism to hide specific classes of a configuration to all its children
Provide a mechanism to hide specific classes of a configuration to all its children Key: GERONIMO-4403 URL: https://issues.apache.org/jira/browse/GERONIMO-4403 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When a configuration uses a commonly used library, e.g. Spring, the only way to prevent child configurations to use this library and use their own copy is to fiddle with the class loading set-up of each child. To some extent, it can be quite user unfriendly to provide such an extract class loading configuration for each child. A mechanism allowing the configuration of classes only visible by the configuration declaring them would be more user friendly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4403) Provide a mechanism to hide specific classes of a configuration to all its children
[ https://issues.apache.org/jira/browse/GERONIMO-4403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-4403. --- Resolution: Fixed Feature checked-in. Provide a mechanism to hide specific classes of a configuration to all its children Key: GERONIMO-4403 URL: https://issues.apache.org/jira/browse/GERONIMO-4403 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When a configuration uses a commonly used library, e.g. Spring, the only way to prevent child configurations to use this library and use their own copy is to fiddle with the class loading set-up of each child. To some extent, it can be quite user unfriendly to provide such an extract class loading configuration for each child. A mechanism allowing the configuration of classes only visible by the configuration declaring them would be more user friendly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4401) Extension of configuration dependencies and gbeans via Groovy scripts
[ https://issues.apache.org/jira/browse/GERONIMO-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-4401. --- Resolution: Fixed Feature checked-in. Extension of configuration dependencies and gbeans via Groovy scripts - Key: GERONIMO-4401 URL: https://issues.apache.org/jira/browse/GERONIMO-4401 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When a configuration is started, we should provide a way to modify dependencies and GBeans of the configuration through the execution of Groovy scripts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4399) GBean Annotations are not supported for GBeans declared in XML configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-4399. --- Resolution: Fixed This is now fixed. GBean Annotations are not supported for GBeans declared in XML configuration Key: GERONIMO-4399 URL: https://issues.apache.org/jira/browse/GERONIMO-4399 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 It is not possible to declare a GBean using the annotation base configuration style in any DDs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4400) Improve error message of DependencyChangeMojo
[ https://issues.apache.org/jira/browse/GERONIMO-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-4400. --- Resolution: Fixed This is now implemented. Improve error message of DependencyChangeMojo - Key: GERONIMO-4400 URL: https://issues.apache.org/jira/browse/GERONIMO-4400 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 When dependencies change, it would be great to have an error message providing some basic instructions on how to proceed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-710) Generating DDLs for CMP deployment
[ https://issues.apache.org/jira/browse/GERONIMO-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-710. -- Resolution: Won't Fix superseded. Generating DDLs for CMP deployment -- Key: GERONIMO-710 URL: https://issues.apache.org/jira/browse/GERONIMO-710 Project: Geronimo Issue Type: New Feature Components: deployment, OpenEJB Affects Versions: 1.0-M4 Reporter: Jacek Laskowski Assignee: Gianny Damour Fix For: Wish List Generate DDL automatically at CMP deployment. SunONE has a command line option - -generateSQL - which I think generate SQLs when CMPs are deployed. It could then be configurable if the DDLs should be applied to the runtime and what strategy to choose - generate only if the scheme doesn't yet exist, regenerate every time, doesn't apply, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1668) Support of dynamic EJBQL queries
[ https://issues.apache.org/jira/browse/GERONIMO-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-1668. --- Resolution: Won't Fix Superseded Support of dynamic EJBQL queries Key: GERONIMO-1668 URL: https://issues.apache.org/jira/browse/GERONIMO-1668 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.0 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: Wish List This new feature covers the need to provide an API to compile and execute dynamic EJBQL queries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1081) CMP create causes update SQL too
[ https://issues.apache.org/jira/browse/GERONIMO-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-1081. --- Resolution: Won't Fix Superseded CMP create causes update SQL too Key: GERONIMO-1081 URL: https://issues.apache.org/jira/browse/GERONIMO-1081 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Gianny Damour Fix For: 1.x I have a situation where I call a session bean method that does nothing but look up an Entity home and call create on it. This result in an UPDATE SQL being executed, not just an INSERT. It seems to me that for performance reasons if nothing else, we should perform just one INSERT. (How do I know? Because I ran into GERONIMO-1080 when calling the session bean method, which caused the create to always roll back, so I couldn't actually create anything -- another good reason to fix this.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1374) Open EJB does not allow the setting of a ForiegnKey that is involved in a CMR relationship
[ https://issues.apache.org/jira/browse/GERONIMO-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-1374. --- Resolution: Won't Fix Superseded Open EJB does not allow the setting of a ForiegnKey that is involved in a CMR relationship -- Key: GERONIMO-1374 URL: https://issues.apache.org/jira/browse/GERONIMO-1374 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.0-M5 Environment: JDK 1.4.2_09 WindowsXP Reporter: Manu T George Assignee: Gianny Damour Fix For: 1.x Attachments: CMPContainerBuilder.patch, CMPContainerBuilder.patch, CMRCompoundAccessor.java, CMRMultiplePKAsFKAccessor.java, CompoundPKTransform.patch I have two CMPs with a 1:n relationship. CMP1 - Order - PK = OrderPK which has a single field orderId CMP2 - OrderItem = OrderItemPk which has 2 fields InventoryId and order_orderId OrderId and order_orderId are mapped When i do a setOrder_orderId in the ejbCreate of OrderItem geronimo gives an error during runtime saying cannot set read only field. When i don't set it geronimo says partial null key . In this case I set the cmr field in the ejbPostCreate method org.tranql.identity.UndefinedIdentityException: Partial null key at org.tranql.identity.DerivedIdentity.defineIdentity(DerivedIdentity.java:80) at org.openejb.entity.cmp.CMPCreateMethod.execute(CMPCreateMethod.java:175) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) at org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136) at org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:90) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-601) Reverse context identifier transformations when possible
[ https://issues.apache.org/jira/browse/GERONIMO-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-601. -- Resolution: Won't Fix Superseded. Reverse context identifier transformations when possible Key: GERONIMO-601 URL: https://issues.apache.org/jira/browse/GERONIMO-601 Project: Geronimo Issue Type: Task Components: OpenEJB Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 1.x ContainerSecurityBuilder and EJBSecurityInterceptor replace ',' with a '_'. This operation needs to be reversed when possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2928) PersistenceUnit located in the EAR library directory is not yet implemented
[ https://issues.apache.org/jira/browse/GERONIMO-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2928. --- Resolution: Fixed Has been fixed a while back. PersistenceUnit located in the EAR library directory is not yet implemented --- Key: GERONIMO-2928 URL: https://issues.apache.org/jira/browse/GERONIMO-2928 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Reporter: Gianny Damour Assignee: Gianny Damour Persistence units located in the EAR library directory are not yet processed. I am working on a fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4299) Session invalidation problem - WADI Tomcat Clustering
[ https://issues.apache.org/jira/browse/GERONIMO-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-4299: Attachment: fixWADITomcatIntegration.patch Session invalidation problem - WADI Tomcat Clustering - Key: GERONIMO-4299 URL: https://issues.apache.org/jira/browse/GERONIMO-4299 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.2 Reporter: Gianny Damour Attachments: fixWADITomcatIntegration.patch Session invalidation fails with an IllegalStateException for WADI clustered Tomcat applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4299) Session invalidation problem - WADI Tomcat Clustering
Session invalidation problem - WADI Tomcat Clustering - Key: GERONIMO-4299 URL: https://issues.apache.org/jira/browse/GERONIMO-4299 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.1.2 Reporter: Gianny Damour Attachments: fixWADITomcatIntegration.patch Session invalidation fails with an IllegalStateException for WADI clustered Tomcat applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4185) Cannot deployed WADI clustered Jetty and Tomcat Web applications within an EAR
Cannot deployed WADI clustered Jetty and Tomcat Web applications within an EAR -- Key: GERONIMO-4185 URL: https://issues.apache.org/jira/browse/GERONIMO-4185 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.1.1 Reporter: Gianny Damour Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4185) Cannot deployed WADI clustered Jetty and Tomcat Web applications within an EAR
[ https://issues.apache.org/jira/browse/GERONIMO-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-4185. --- Resolution: Fixed Now fixed. Cannot deployed WADI clustered Jetty and Tomcat Web applications within an EAR -- Key: GERONIMO-4185 URL: https://issues.apache.org/jira/browse/GERONIMO-4185 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.1 Reporter: Gianny Damour Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3993) Server fails to relaunch after deploying an application to a WADI cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596953#action_12596953
]
Gianny Damour commented on GERONIMO-3993:
-
Hello Joe, it is quite easy to reproduce this problem. As a matter of fact, it
is more general than currently classified as it applies to any configurations
deployed to secondary repositories. Such configurations may be automatically
started upon server start-up as per config.xml. However, such configurations
are not visible as they are defined by secondary repositories which have not
yet started. It seems to me that we need to change the way start-up
configurations are processed: I think that this problem could be solved by
deferring the resolution of such configurations till all the other start-up
configurations are up and running.
Server fails to relaunch after deploying an application to a WADI cluster
-
Key: GERONIMO-3993
URL: https://issues.apache.org/jira/browse/GERONIMO-3993
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.1, 2.1.2, 2.1.x
Environment: Windows
Reporter: YunFeng Ma
Assignee: Gianny Damour
Fix For: 2.1.2, 2.1.x, 2.2
1. A WADI cluster with two Nodes: Node1 and Node2
2. Deploy an application to Node1
3. Stop Node1 and Node2
4. Start Node1 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4d5fdcaa.sort(generated)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
{noformat}
5. Start Node2 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer_G_SLAVE/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
[jira] Updated: (GERONIMO-3993) Server fails to relaunch after deploying an application to a WADI cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour updated GERONIMO-3993:
Component/s: (was: Clustering)
startup/shutdown
Move to startup/shutdown component.
Server fails to relaunch after deploying an application to a WADI cluster
-
Key: GERONIMO-3993
URL: https://issues.apache.org/jira/browse/GERONIMO-3993
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: startup/shutdown
Affects Versions: 2.1.1, 2.1.2, 2.1.x
Environment: Windows
Reporter: YunFeng Ma
Assignee: Gianny Damour
Fix For: 2.1.2, 2.1.x, 2.2
1. A WADI cluster with two Nodes: Node1 and Node2
2. Deploy an application to Node1
3. Stop Node1 and Node2
4. Start Node1 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4d5fdcaa.sort(generated)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
{noformat}
5. Start Node2 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer_G_SLAVE/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4d5fdcaa.sort(generated)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at
[jira] Assigned: (GERONIMO-3993) Server fails to relaunch after deploying an application to a WADI cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianny Damour reassigned GERONIMO-3993:
---
Assignee: Gianny Damour
Server fails to relaunch after deploying an application to a WADI cluster
-
Key: GERONIMO-3993
URL: https://issues.apache.org/jira/browse/GERONIMO-3993
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.1, 2.1.2, 2.1.x
Environment: Windows
Reporter: YunFeng Ma
Assignee: Gianny Damour
Fix For: 2.1.1, 2.1.2, 2.1.x
1. A WADI cluster with two Nodes: Node1 and Node2
2. Deploy an application to Node1
3. Stop Node1 and Node2
4. Start Node1 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4d5fdcaa.sort(generated)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
{noformat}
5. Start Node2 and get the following exception:
{noformat}
org.apache.geronimo.kernel.config.NoSuchConfigException:
samples/cviewer_G_SLAVE/2.1.0.0/war
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:476)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:456)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.sort(SimpleConfigurationManager.java:448)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$4d5fdcaa.sort(generated)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:152)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at
[jira] Closed: (GERONIMO-3991) Can not undeploy an application deployed in a WADI cluster via Admin Console
[ https://issues.apache.org/jira/browse/GERONIMO-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3991. --- Resolution: Won't Fix Fix Version/s: (was: 2.1.x) Assignee: YunFeng Ma Hello, What you are describing is the expected behavior. The configuration samples/cviewer_G_SLAVE/2.1.0.0/war is a standalone and slave configuration of the configuration samples/cviewer/2.1.0.0/war. You should uninstall samples/cviewer_G_SLAVE/2.1.0.0/war, note that it is classified as a system module and not as a Web module, in order to get an uninstall across your two nodes. Thanks, Gianny Can not undeploy an application deployed in a WADI cluster via Admin Console Key: GERONIMO-3991 URL: https://issues.apache.org/jira/browse/GERONIMO-3991 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.2, 2.1.x Environment: Windows Reporter: YunFeng Ma Assignee: YunFeng Ma Fix For: 2.1.2 1. Setup a WADI cluster with two notes: Note1 and Node2 2. Deploy an application, such as samples/cviewer/2.1.0.0/war, to Node1 3. cviewer works fine in Node1 and Node2 4. But in the Admin Console of Node1 and Node2, open Web App WARs portlet and there is only a application named samples/cviewer_G_SLAVE/2.1.0.0/war, even if I uninstall samples/cviewer_G_SLAVE/2.1.0.0/war in Node1's admin console, cviewer in GERONIMO_HOME\master-repository is not deleted and the cviewer in Node2 is not uninstalled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3989) gshell - infinite loop
gshell - infinite loop
--
Key: GERONIMO-3989
URL: https://issues.apache.org/jira/browse/GERONIMO-3989
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.1.1
Reporter: Gianny Damour
Priority: Critical
There is an infinite (exception?) loop problem with gshell where the exception
below is raised and not properly handled.
{code}
18:47:22,314 DEBUG (main) [org.apache.geronimo.gshell.console.JLineConsole]
Work failed: java.io.IOException: Input/output error
java.io.IOException: Input/output error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:194)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at jline.Terminal.readCharacter(Terminal.java:99)
at jline.UnixTerminal.readVirtualKey(UnixTerminal.java:128)
at jline.ConsoleReader.readVirtualKey(ConsoleReader.java:1450)
at jline.ConsoleReader.readBinding(ConsoleReader.java:651)
at jline.ConsoleReader.readLine(ConsoleReader.java:492)
at jline.ConsoleReader.readLine(ConsoleReader.java:446)
at
org.apache.geronimo.gshell.console.JLineConsole.readLine(JLineConsole.java:92)
at org.apache.geronimo.gshell.console.Console.work(Console.java:150)
at org.apache.geronimo.gshell.console.Console.run(Console.java:128)
at
org.apache.geronimo.gshell.console.JLineConsole.run(JLineConsole.java:68)
at org.apache.geronimo.gshell.DefaultShell.run(DefaultShell.java:202)
at org.apache.geronimo.gshell.GShell.run(GShell.java:156)
at org.apache.geronimo.gshell.cli.Main.boot(Main.java:249)
at org.apache.geronimo.gshell.cli.Main.main(Main.java:266)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
18:47:22,315 DEBUG (main) [org.apache.geronimo.gshell.console.JLineConsole]
Work failed: java.io.IOException: Input/output error
java.io.IOException: Input/output error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:194)
{code}
Gr. As this exception is written every 1ms in gshell.log, it filled my hard
disk...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3982) WADI cluster fails to distribute the installed application to all the nodes in the same cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591304#action_12591304
]
Gianny Damour commented on GERONIMO-3982:
-
Hello,
WADI is not involved at all in farming, i.e. deployment of modules to multiple
Geronimo instances. You need to follow the instructions provided by this WIKI
page http://cwiki.apache.org/confluence/display/GMOxDOC21/Farming.
The idea is to add a new GBean to the farming configuration for your second
node.
Thanks,
Giany
WADI cluster fails to distribute the installed application to all the nodes
in the same cluster
---
Key: GERONIMO-3982
URL: https://issues.apache.org/jira/browse/GERONIMO-3982
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.1, 2.1.x
Environment: Windows, IBM JDK
Reporter: YunFeng Ma
Fix For: 2.1.x, 2.2
1. Start two Geronimo servers (Node1 and Node2) which are in a WADI cluster,
I can see the following message in the geronmo launch console:
{noformat}
2008-4-22 14:16:49 org.codehaus.wadi.tribes.WadiMemberInterceptor memberAdded
信息: memberAdded:tcp://ZS01:4000
{noformat}
2. Deploy an application to Node1, verify the application and it works fine
in Node1
3. I can see the deployed application in Node1_Home\cluster-repository and
Node1_Home\master-repository, but there is no the application in
Node2_Home\cluster-repository and Node2_Home\master-repository
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3970) Fail to delploy a web application to a WADI cluster
[ https://issues.apache.org/jira/browse/GERONIMO-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-3970: --- Assignee: Gianny Damour Fail to delploy a web application to a WADI cluster --- Key: GERONIMO-3970 URL: https://issues.apache.org/jira/browse/GERONIMO-3970 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.1 Environment: Windows Reporter: YunFeng Ma Assignee: Gianny Damour Fix For: 2.1.1 Deploy a web application to a WADI cluster with two nodes and get the following exceptions: H:\geornimo server2\bindeploy --user system --password manager --port 110 8 deploy --targets org.apache.geronimo.configs/farming/2.1.1-SNAPSHOT/car?Servic eModule=org.apache.geronimo.configs/farming/2.1.1-SNAPSHOT/car,j2eeType=Configur ationStore,name=MasterConfigurationStore f:\temp\servlet-examples-cluster-server 2.war f:\temp\servlet-examples-cluster-plan.xml Using GERONIMO_BASE: H:\geornimo server2 Using GERONIMO_HOME: H:\geornimo server2 Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:C:\Program Files\IBM\Java50\jre org.apache.geronimo.kernel.config.LifecycleException: start of samples/servlet-e xamples-cluster-server1/1.0/war failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:566) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:530) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl ectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: 239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl ectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: 239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBrid ge.java:172) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImp l.java:231) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM BeanServerInterceptor.java:833) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802 ) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnecti onImpl.java:1423) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectio nImpl.java:96) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run (RMIConnectionImpl.java:1260) at java.security.AccessController.doPrivileged(AccessController.java:275 ) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(R MIConnectionImpl.java:1363) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImp l.java:797) at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309) at sun.rmi.transport.Transport$1.run(Transport.java:168) at java.security.AccessController.doPrivileged(AccessController.java:275 ) at sun.rmi.transport.Transport.serviceCall(Transport.java:164) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:5 06) at
[jira] Commented: (GERONIMO-3970) Fail to delploy a web application to a WADI cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590877#action_12590877
]
Gianny Damour commented on GERONIMO-3970:
-
Hello,
This is a problem with the MasterConfigurationStore GBean, which defines a
faulty defautlEnvironment: it imports the clustering configuration instead of
the farming one. To fix this problem, you can add the following GBean override
to your config.xml for the farming configuration:
{noformat}
gbean name=MasterConfigurationStore
attribute
propertyEditor=org.apache.geronimo.deployment.service.EnvironmentBuilder
name=defaultEnvironment
environment
xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2;
dependencies
dependency
groupIdorg.apache.geronimo.configs/groupId
artifactIdfarming/artifactId
typecar/type
/dependency
/dependencies
/environment
/attribute
/gbean
{noformat}
Thanks for reporting this problem.
Fail to delploy a web application to a WADI cluster
---
Key: GERONIMO-3970
URL: https://issues.apache.org/jira/browse/GERONIMO-3970
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.1
Environment: Windows
Reporter: YunFeng Ma
Assignee: Gianny Damour
Fix For: 2.1.1
Deploy a web application to a WADI cluster with two nodes and get the
following exceptions:
H:\geornimo server2\bindeploy --user system --password manager --port 110
8 deploy --targets
org.apache.geronimo.configs/farming/2.1.1-SNAPSHOT/car?Servic
eModule=org.apache.geronimo.configs/farming/2.1.1-SNAPSHOT/car,j2eeType=Configur
ationStore,name=MasterConfigurationStore
f:\temp\servlet-examples-cluster-server
2.war f:\temp\servlet-examples-cluster-plan.xml
Using GERONIMO_BASE: H:\geornimo server2
Using GERONIMO_HOME: H:\geornimo server2
Using GERONIMO_TMPDIR: var\temp
Using JRE_HOME:C:\Program Files\IBM\Java50\jre
org.apache.geronimo.kernel.config.LifecycleException: start of
samples/servlet-e
xamples-cluster-server1/1.0/war failed
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
figuration(SimpleConfigurationManager.java:566)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon
figuration(SimpleConfigurationManager.java:530)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl
ectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
n.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
java:867)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
239)
at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342)
at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl
ectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
n.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
java:867)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
239)
at
org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBrid
ge.java:172)
at
com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImp
l.java:231)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM
BeanServerInterceptor.java:833)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802
)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnecti
onImpl.java:1423)
at
javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectio
nImpl.java:96)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run
[jira] Created: (GERONIMO-3952) Definition of GBeanInfo via annotations
Definition of GBeanInfo via annotations --- Key: GERONIMO-3952 URL: https://issues.apache.org/jira/browse/GERONIMO-3952 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: core Affects Versions: 2.1 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 Annotation based approach to create the GBeanInfo of a GBean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3952) Definition of GBeanInfo via annotations
[ https://issues.apache.org/jira/browse/GERONIMO-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3952. --- Resolution: Fixed This is now implemented. Definition of GBeanInfo via annotations --- Key: GERONIMO-3952 URL: https://issues.apache.org/jira/browse/GERONIMO-3952 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: core Affects Versions: 2.1 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 Annotation based approach to create the GBeanInfo of a GBean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3922) Addition of an AspectJ configuration enabling the load-time-weaving of aspects defined by children configurations
Addition of an AspectJ configuration enabling the load-time-weaving of aspects defined by children configurations - Key: GERONIMO-3922 URL: https://issues.apache.org/jira/browse/GERONIMO-3922 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Affects Versions: 2.1 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 Addition of a configuration that registers the AspectJ ClassPreProcessorAgentAdapter ClassFileTransformer with the Geronimo java agent so that aspects declared by children configurations through META-INF/aop.xml are load-time-woven. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3922) Addition of an AspectJ configuration enabling the load-time-weaving of aspects defined by children configurations
[ https://issues.apache.org/jira/browse/GERONIMO-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3922. --- Resolution: Fixed Committed. Addition of an AspectJ configuration enabling the load-time-weaving of aspects defined by children configurations - Key: GERONIMO-3922 URL: https://issues.apache.org/jira/browse/GERONIMO-3922 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.2 Addition of a configuration that registers the AspectJ ClassPreProcessorAgentAdapter ClassFileTransformer with the Geronimo java agent so that aspects declared by children configurations through META-INF/aop.xml are load-time-woven. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3772) Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
[ https://issues.apache.org/jira/browse/GERONIMO-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563827#action_12563827 ] Gianny Damour commented on GERONIMO-3772: - Hello, Sorry, I missed the first JIRA notification. I already fixed this bug (see the Files Changed for revision 613820). I believe this JIRA can be closed. Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor] --- Key: GERONIMO-3772 URL: https://issues.apache.org/jira/browse/GERONIMO-3772 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.1 Reporter: YunFeng Ma Assignee: Gianny Damour Priority: Critical Fix For: 2.1 Attachments: GERONIMO-3772-1.patch, GERONIMO-3772.patch Reproduce the error: 1. start the server 2. add a local plugin repository or click link Update Repository List 3. shutdown and restart the server and you should get hit by it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3772) Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
[ https://issues.apache.org/jira/browse/GERONIMO-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-3772: --- Assignee: Gianny Damour Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor] --- Key: GERONIMO-3772 URL: https://issues.apache.org/jira/browse/GERONIMO-3772 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.1 Reporter: YunFeng Ma Assignee: Gianny Damour Fix For: 2.1 Attachments: GERONIMO-3772.patch Reproduce the error: 1. start the server 2. add a local plugin repository or click link Update Repository List 3. shutdown and restart the server and you should get hit by it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3772) Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor]
[ https://issues.apache.org/jira/browse/GERONIMO-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3772. --- Resolution: Fixed Thanks for having raised this issue Yun Feng. As Geronimo has build-in support for the main Collection sub-classes, see org.apache.geronimo.common.propertyeditor package which is registered as a PropertyEditor search path, GBeanOverride should not write a propertyEditor attribute for attributes having the type of Collection sub-classes. Start failed, Cannot load property editor [org.apache.xbean.propertyeditor.ArrayListEditor] --- Key: GERONIMO-3772 URL: https://issues.apache.org/jira/browse/GERONIMO-3772 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.1 Reporter: YunFeng Ma Assignee: Gianny Damour Fix For: 2.1 Attachments: GERONIMO-3772.patch Reproduce the error: 1. start the server 2. add a local plugin repository or click link Update Repository List 3. shutdown and restart the server and you should get hit by it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3721) WADI modules prevent Geronimo from starting when offline
[ https://issues.apache.org/jira/browse/GERONIMO-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-3721: --- Assignee: Gianny Damour WADI modules prevent Geronimo from starting when offline Key: GERONIMO-3721 URL: https://issues.apache.org/jira/browse/GERONIMO-3721 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: Gianny Damour When offline the Geronimo server will not start becuase of failures in WADI modules. Once the WADI modules are disabled, the server starts up fine. This applies to both tomcat and jetty assemblies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-1410) Configuration geronimo/jetty/1.0-SNAPSHOT/car defines Spring Framework - Hibernate based Web-app do not work
[ https://issues.apache.org/jira/browse/GERONIMO-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-1410. --- Resolution: Invalid Assignee: Gianny Damour No more valid. Configuration geronimo/jetty/1.0-SNAPSHOT/car defines Spring Framework - Hibernate based Web-app do not work Key: GERONIMO-1410 URL: https://issues.apache.org/jira/browse/GERONIMO-1410 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 1.0 Reporter: Gianny Damour Assignee: Gianny Damour Priority: Critical Fix For: Wish List Spring Framework is defined by the base configuration geronimo/jetty/1.0-SNAPSHOT/car. This is an issue as Web-app leveraging the Hibernate integration provide by Spring cannot be deployed. Basically, Hibernate classes cannot be loaded from the configuration CL of geronimo/jetty/1.0-SNAPSHOT/car. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3721) WADI modules prevent Geronimo from starting when offline
[ https://issues.apache.org/jira/browse/GERONIMO-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour resolved GERONIMO-3721. - Resolution: Fixed Fix Version/s: 2.1 Assignee: Jarek Gawor (was: Gianny Damour) I believe this now fixed. Could you please give it a shot and close accordingly? WADI modules prevent Geronimo from starting when offline Key: GERONIMO-3721 URL: https://issues.apache.org/jira/browse/GERONIMO-3721 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 2.1 When offline the Geronimo server will not start becuase of failures in WADI modules. Once the WADI modules are disabled, the server starts up fine. This applies to both tomcat and jetty assemblies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3696) Tomcat Clustering over WADI
Tomcat Clustering over WADI --- Key: GERONIMO-3696 URL: https://issues.apache.org/jira/browse/GERONIMO-3696 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 Users should be able to cluster Tomcat web-applications the same way they are doing it with Jetty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3696) Tomcat Clustering over WADI
[ https://issues.apache.org/jira/browse/GERONIMO-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3696. --- Resolution: Fixed This is now implemented. Tomcat Clustering over WADI --- Key: GERONIMO-3696 URL: https://issues.apache.org/jira/browse/GERONIMO-3696 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 Users should be able to cluster Tomcat web-applications the same way they are doing it with Jetty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3669) Remote control of geronimo instances via gshell processes running on the boxes where the instances are hosted
Remote control of geronimo instances via gshell processes running on the boxes where the instances are hosted - Key: GERONIMO-3669 URL: https://issues.apache.org/jira/browse/GERONIMO-3669 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 Add a couple of gshell commands to simplify the remote control of servers. The commands being added are: * alias: used to alias a commond along with some options and arguments. etc/layout.xml provides a first aliasing mechanism: a hierarchical name is mapped to a command. alias suplements this first aliasing mechanism with the ability to alias a command along with its typical options and arguments. * unalias: to remove an alias * execute-alias: to execute an alias * remote/rsh to start an rsh client * remote/rsh-server to start an rsh-server * remote-control/server-control to control a server Samples for the aliasing commands: // create the alias 'st' for the quoted command alias st 'geronimo/start-server -G server.name=yellow -D property=value' // execute the alias 'st'. This executes the command in quote above excute-alias st // display defined aliases alias // remove the alias 'st' unalias st Samples for the remote server control commands: // start an rsh-server: remote/rsh-server tcp://localhost: // remote 'start' the server 'defaultServer' remote-control/server-control start defaultServer // remote 'stop' the server 'defaultServer' remote-control/server-control stop defaultServer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3669) Remote control of geronimo instances via gshell processes running on the boxes where the instances are hosted
[ https://issues.apache.org/jira/browse/GERONIMO-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3669. --- Resolution: Fixed This is now implemented. Remote control of geronimo instances via gshell processes running on the boxes where the instances are hosted - Key: GERONIMO-3669 URL: https://issues.apache.org/jira/browse/GERONIMO-3669 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 Add a couple of gshell commands to simplify the remote control of servers. The commands being added are: * alias: used to alias a commond along with some options and arguments. etc/layout.xml provides a first aliasing mechanism: a hierarchical name is mapped to a command. alias suplements this first aliasing mechanism with the ability to alias a command along with its typical options and arguments. * unalias: to remove an alias * execute-alias: to execute an alias * remote/rsh to start an rsh client * remote/rsh-server to start an rsh-server * remote-control/server-control to control a server Samples for the aliasing commands: // create the alias 'st' for the quoted command alias st 'geronimo/start-server -G server.name=yellow -D property=value' // execute the alias 'st'. This executes the command in quote above excute-alias st // display defined aliases alias // remove the alias 'st' unalias st Samples for the remote server control commands: // start an rsh-server: remote/rsh-server tcp://localhost: // remote 'start' the server 'defaultServer' remote-control/server-control start defaultServer // remote 'stop' the server 'defaultServer' remote-control/server-control stop defaultServer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3612) When no target configuration store is explicitly specified while installing a configuration, the configuration should be installed to a default configuration store
[ https://issues.apache.org/jira/browse/GERONIMO-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3612. --- Resolution: Fixed Fix Version/s: (was: 2.0.x) 2.1 This is now implemented. When no target configuration store is explicitly specified while installing a configuration, the configuration should be installed to a default configuration store --- Key: GERONIMO-3612 URL: https://issues.apache.org/jira/browse/GERONIMO-3612 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 When a configuration is installed, either via the command line or via various portlets, and no configuration store is explicitly selected, it is installed to all the configuration stores defined by the server. A more reasonable behavior is to install this configuration to a single configuration store, which is explicitly configured as the default configuration store. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3620) Remote deployment using command line deployer does not really work
[ https://issues.apache.org/jira/browse/GERONIMO-3620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544394 ] Gianny Damour commented on GERONIMO-3620: - Hi Vamsi. I fixed 1. a couple of days ago. Remote deployment using command line deployer does not really work -- Key: GERONIMO-3620 URL: https://issues.apache.org/jira/browse/GERONIMO-3620 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Remote deployment using command line deployer tool does not really work currently as the host has to be localhost. Here are my observations. 1. Deployer.getRemoteDeployUploadURL() is not checking if the contextPath starts with a '/' thus resulting in an incorrect URL like http://localhost:8080//remote-deploy/upload. 2. Using a remoteDeployAddress like http://localhost:8080 with hostname localhost is not useful at all. When the host we are deploying to is the local machine itself, RemoteDeploymentManager.isSameMachine() returns true and in this case the local files are used directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3612) When no target configuration store is explicitly specified while installing a configuration, the configuration should be installed to a default configuration store
When no target configuration store is explicitly specified while installing a configuration, the configuration should be installed to a default configuration store --- Key: GERONIMO-3612 URL: https://issues.apache.org/jira/browse/GERONIMO-3612 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.0.x When a configuration is installed, either via the command line or via various portlets, and no configuration store is explicitly selected, it is installed to all the configuration stores defined by the server. A more reasonable behavior is to install this configuration to a single configuration store, which is explicitly configured as the default configuration store. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3610) Allows the override of XML JavaBean attribute in config.xml
Allows the override of XML JavaBean attribute in config.xml --- Key: GERONIMO-3610 URL: https://issues.apache.org/jira/browse/GERONIMO-3610 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: management Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.0.x At the moment, it is not so easy to override an attribute defined by a JavaBean xml-attribute element in a configuration plan. It should be possible to override such JavaBean xml-attributes by specifying a custom property editor relying on the same xml-attribute processing to build JavaBeans and override an attribute. Also, users should be able to declare which JavaBean attributes need to be encrypted prior to write them in config.xml (replicate the handling of password attribute for GBean attribute overrides). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3610) Allows the override of XML JavaBean attribute in config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3610. --- Resolution: Fixed Now implemented. Allows the override of XML JavaBean attribute in config.xml --- Key: GERONIMO-3610 URL: https://issues.apache.org/jira/browse/GERONIMO-3610 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: management Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.0.x At the moment, it is not so easy to override an attribute defined by a JavaBean xml-attribute element in a configuration plan. It should be possible to override such JavaBean xml-attributes by specifying a custom property editor relying on the same xml-attribute processing to build JavaBeans and override an attribute. Also, users should be able to declare which JavaBean attributes need to be encrypted prior to write them in config.xml (replicate the handling of password attribute for GBean attribute overrides). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3597) Distribution and start/stop of clustered deployments
Distribution and start/stop of clustered deployments Key: GERONIMO-3597 URL: https://issues.apache.org/jira/browse/GERONIMO-3597 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Fix For: 2.1 Users should be able to distribute configurations to a kind of clustered repository, which is able to cascade this distribution to repositories hosted by remote Geronimo instances part of a cluster statically configured. Also, when a user distributes a configuration to this clustered repository, he should be able to start or stop a single configuration in order to have all the configurations distributed to these remote Geronimo instances started or stopped seamlessly at the same time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3597) Distribution and start/stop of clustered deployments
[ https://issues.apache.org/jira/browse/GERONIMO-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-3597: --- Assignee: Gianny Damour Distribution and start/stop of clustered deployments Key: GERONIMO-3597 URL: https://issues.apache.org/jira/browse/GERONIMO-3597 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 Users should be able to distribute configurations to a kind of clustered repository, which is able to cascade this distribution to repositories hosted by remote Geronimo instances part of a cluster statically configured. Also, when a user distributes a configuration to this clustered repository, he should be able to start or stop a single configuration in order to have all the configurations distributed to these remote Geronimo instances started or stopped seamlessly at the same time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3597) Distribution and start/stop of clustered deployments
[ https://issues.apache.org/jira/browse/GERONIMO-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3597. --- Resolution: Fixed This is now implemented. Distribution and start/stop of clustered deployments Key: GERONIMO-3597 URL: https://issues.apache.org/jira/browse/GERONIMO-3597 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 Users should be able to distribute configurations to a kind of clustered repository, which is able to cascade this distribution to repositories hosted by remote Geronimo instances part of a cluster statically configured. Also, when a user distributes a configuration to this clustered repository, he should be able to start or stop a single configuration in order to have all the configurations distributed to these remote Geronimo instances started or stopped seamlessly at the same time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3578) Delta Replication of HttpSessions - Jetty Clustered Web-Applications
Delta Replication of HttpSessions - Jetty Clustered Web-Applications Key: GERONIMO-3578 URL: https://issues.apache.org/jira/browse/GERONIMO-3578 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Fix For: 2.1 State stored in HttpSessions can now be replicated via a fine grained approach. More information is provided there: http://docs.codehaus.org/display/WADI/5.+Delta+Session+Replication -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3578) Delta Replication of HttpSessions - Jetty Clustered Web-Applications
[ https://issues.apache.org/jira/browse/GERONIMO-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3578. --- Resolution: Fixed Assignee: Gianny Damour Checked in. Delta Replication of HttpSessions - Jetty Clustered Web-Applications Key: GERONIMO-3578 URL: https://issues.apache.org/jira/browse/GERONIMO-3578 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.0.2 Reporter: Gianny Damour Assignee: Gianny Damour Fix For: 2.1 State stored in HttpSessions can now be replicated via a fine grained approach. More information is provided there: http://docs.codehaus.org/display/WADI/5.+Delta+Session+Replication -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3265) Spring stale version in 2.0-M6-rc1
[ https://issues.apache.org/jira/browse/GERONIMO-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509711 ] Gianny Damour commented on GERONIMO-3265: - I confirm that the cxf config pulls 2.0 Spring dependencies; also, Spring is not included for WADI as per Donald's comment. I have been able to run a Web-app depending on Spring dependencies having a version greater than 2.0 by: * reversing classloading; and * hidding NamespaceHandler implementation classes defined by cxf: Spring simply logs a debug message when a declared NamespaceHandler implementation class cannot be loaded. So, by adding this to your web-app geronimo DD, you can run your web-app: hidden-classes filterorg.apache.cxf/filter !-- -This can also be the exhaustive list of NamespaceHandler implementations declared by CXF - /hidden-classes inverse-classloading/ Spring stale version in 2.0-M6-rc1 -- Key: GERONIMO-3265 URL: https://issues.apache.org/jira/browse/GERONIMO-3265 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0-M6 Environment: Windows XP SP2, Sun JSDK 1.5.07, Geronimo (2.0-M6-rc1) obtained from: http://people.apache.org/~hogstrom/2.0-M6-rc1/geronimo-tomcat6-jee5-2.0-M6-rc1-bin.zip (2.0-M6-rc1) Reporter: Alexei Kozich 1. This Geronimo build includes spring-beans.jar, spring-context.jar and spring-core.jar of version 2.0. So as far as we know, version 2.0 does not fully support integration with JPA implementations. 2. We developed an enterprise application (ear) which utilizes Spring 2.0.2 and OpenJPA. OpenJPA comes with Geronimo. Deployment and start of this application fails, because of different versions of Spring (our application expects spring-beans.jar, spring-context.jar and spring-core.jar to be at least of version 2.0.2 but Geronimo contains libs of version 2.0 (the lack of some methods in version 2.0 is the problem here). 3. If we try to use inverse-classloading or hidden classes (org.springframework) in geronimo-web.xml and include all necesary libs in WEB-INF/lib following Exception is thrown during deployment and start of the application (see below). 4. We found temporary workaround: to replace spring-beans.jar, spring-context.jar and spring-core.jar of version 2.0 with jars of version 2.0.2 in Geronimo repository without using of inverse-classloading and hidden classes and everything looks fine. 5. So as far as I understand this out-of-the-box Geronimo build could not be used as Server for Spring-OpenJPA appications. At least Spring libs upgrade could solve this problem. 6. Another problem is following Exception when using hidden classes or inverse-classloading to load application jars first. ERROR [ContextLoader] Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/springAppContext.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface Caused by: java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.initHandlerMappings(DefaultNamespaceHandlerResolver.java:119) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:96) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:82) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createDefaultNamespaceHandlerResolver(XmlBeanDefinitionReader.java:526) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createReaderContext(XmlBeanDefinitionReader.java:515) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:495) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:340) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:317) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:125) at
[jira] Resolved: (GERONIMO-3147) Unable to deploy anything from the command line (trunk)
[ https://issues.apache.org/jira/browse/GERONIMO-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour resolved GERONIMO-3147. - Resolution: Fixed Fix Version/s: 2.0-M6 Assignee: Jay D. McHugh Many thanks for this patch Jay! Unable to deploy anything from the command line (trunk) --- Key: GERONIMO-3147 URL: https://issues.apache.org/jira/browse/GERONIMO-3147 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0-M6 Reporter: Jay D. McHugh Assigned To: Jay D. McHugh Fix For: 2.0-M6 Attachments: geronimo-3147-2.patch, geronimo-3147.patch The --uri and --user parameters are stepping on each other - So everytime you try to deploy anything, you get the message: Error: Unable to connect to server at system -- Could not get DeploymentManager; No registered DeploymentFactory handles this URI -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3112) WADI Clustering is missing dependency to org.apache.tomcat.juli
[ https://issues.apache.org/jira/browse/GERONIMO-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-3112: --- Assignee: Gianny Damour WADI Clustering is missing dependency to org.apache.tomcat.juli --- Key: GERONIMO-3112 URL: https://issues.apache.org/jira/browse/GERONIMO-3112 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.0-M3 Reporter: Kristian Koehler Assigned To: Gianny Damour Attachments: dependency.patch Hi the wadi-clustering config is missing a dependency to org.apache.tomcat.juli which causes an ClassNotFoundException when deploying a clustering-aware web-application. - 13:15:34,949 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/wadi-clustering/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/wadi-clustering/2.0-SNAPSHOT/car,j2 eType=GBean,name=DefaultDispatcherHolder java.lang.NoClassDefFoundError: org/apache/juli/logging/LogFactory at org.apache.catalina.tribes.group.ChannelInterceptorBase.clinit(ChannelInte rceptorBase.java:32) at org.codehaus.wadi.tribes.TribesCluster.init(TribesCluster.java:57) at org.codehaus.wadi.tribes.TribesDispatcher.init(TribesDispatcher.java:26) at org.apache.geronimo.clustering.wadi.TribesDispatcherHolder.doStart(TribesDis patcherHolder.java:65) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance .java:986) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanI nstanceState.java:267) -- Adding the juli dependency solved the problem for me. Kristian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3059) CLIs refactoring - options and arguments parsing should be done prior the boot of a Kernel to provide a quicker feedback to users if they are invalid
CLIs refactoring - options and arguments parsing should be done prior the boot of a Kernel to provide a quicker feedback to users if they are invalid - Key: GERONIMO-3059 URL: https://issues.apache.org/jira/browse/GERONIMO-3059 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: usability Affects Versions: 2.0-M4 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-M5 CLIs options and arguments are parsed after the boot of a Kernel. As the boot of a Kernel, and especially the loading of configurations, are time expensive, users have to wait an unacceptable time to receive a feedback from CLs if these options or arguments are invalid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3059) CLIs refactoring - options and arguments parsing should be done prior the boot of a Kernel to provide a quicker feedback to users if they are invalid
[ https://issues.apache.org/jira/browse/GERONIMO-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-3059: Attachment: GERONIMO-3059.patch Here is a patch to fix this problem: * Add a geronimo-cli JAR containing all the classes to perform options and arguments parsing. It is included in the lib/ folder and added to the Class-Path manifest entry of the deployer.jar, server.jar and client.jar runnable JARs; * Use commons-cli to perform the option parsing; and * add support for an extra verbose level, -vvv, and remap the verbose level as follows: -v - INFO, -vv - DEBUG, -vvv - TRACE. CLIs refactoring - options and arguments parsing should be done prior the boot of a Kernel to provide a quicker feedback to users if they are invalid - Key: GERONIMO-3059 URL: https://issues.apache.org/jira/browse/GERONIMO-3059 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: usability Affects Versions: 2.0-M4 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-M5 Attachments: GERONIMO-3059.patch CLIs options and arguments are parsed after the boot of a Kernel. As the boot of a Kernel, and especially the loading of configurations, are time expensive, users have to wait an unacceptable time to receive a feedback from CLs if these options or arguments are invalid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3020) Unable to deploy a web app to current trunk build of geronimo (rev 522077)
[ https://issues.apache.org/jira/browse/GERONIMO-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3020. --- Assignee: David Jencks (was: Gianny Damour) Regression: [Regression] Thanks for having fixed this issue David! I was not able to get time before today and M4. Frank, Rakesh, thanks for your investigations and patches. The commit log was not so clear with respect to the problem of the previous implementation: DeployTool, i.e. the deployer, depends on a DeploymentFactory, which is actually a DFwK. The static registration of a DFImpl instance by DFwK was an issue as two DF implementations were able to handle URIs starting with deployer:geronimo:: DFImpl and DFwK (DFwK is registered in ServerConnection.tryToConnect). DFwK is the implementation we want to use, and not DFimpl, as it has access to ModuleConfigurers. Hence, the refactoring. So, we want to register DFwK in DFwK. Unable to deploy a web app to current trunk build of geronimo (rev 522077) -- Key: GERONIMO-3020 URL: https://issues.apache.org/jira/browse/GERONIMO-3020 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M5 Environment: Linux - Java 1.5.0_08 Reporter: Jay D. McHugh Assigned To: David Jencks Priority: Blocker Fix For: 2.0-M4 Attachments: GERONIMO-3020-3.patch, J3020.patch, J3020_opt.patch, JIRA3020_useDFWithKernel.patch Trying to deploy a web app from the web based admin console causes a servlet exception. Deploying the same web app from the command line is successful. (ie: java -jar bin/deployer.jar --user system --password manager deploy simple.war) You should be able to duplicate by trying to deploy the simple.war file from geronimo-2786. Here is the stack trace: 15:12:20,342 ERROR [[Deployment]] Servlet.service() for servlet Deployment threw exception javax.servlet.ServletException at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:260) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:324) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at
[jira] Closed: (GERONIMO-3031) Install New Applications
[ https://issues.apache.org/jira/browse/GERONIMO-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-3031. --- Resolution: Fixed Fix Version/s: 2.0-M4 Assignee: David Jencks Regression: [Regression] Fixed by David J. Install New Applications Key: GERONIMO-3031 URL: https://issues.apache.org/jira/browse/GERONIMO-3031 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M4 Environment: Revision: 523021 Reporter: Hernan Cunico Assigned To: David Jencks Fix For: 2.0-M4 Attachments: jetty_error.txt, tomcat_error.txt Both Jetty and Tomcat fail to install web applications via the Console, deploying the same app from the command line works OK -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2983) Installation of plugins via the command line is broken
Installation of plugins via the command line is broken -- Key: GERONIMO-2983 URL: https://issues.apache.org/jira/browse/GERONIMO-2983 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0-M3 Reporter: Gianny Damour Assigned To: Gianny Damour installation of plugins via the command line, i.e. via the install-plugin command, is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2983) Installation of plugins via the command line is broken
[ https://issues.apache.org/jira/browse/GERONIMO-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2983. --- Resolution: Fixed Regression: [Regression] Now fixed. Installation of plugins via the command line is broken -- Key: GERONIMO-2983 URL: https://issues.apache.org/jira/browse/GERONIMO-2983 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M3 Reporter: Gianny Damour Assigned To: Gianny Damour installation of plugins via the command line, i.e. via the install-plugin command, is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2978) ClientCommandLine and Daemon improvement to reduce reliance on lib/
[ https://issues.apache.org/jira/browse/GERONIMO-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2978. --- Resolution: Fixed Fix Version/s: 2.0-beta1 This is now implemented. ClientCommandLine and Daemon improvement to reduce reliance on lib/ --- Key: GERONIMO-2978 URL: https://issues.apache.org/jira/browse/GERONIMO-2978 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.0-M3 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-beta1 ClientCommandLine and Daemon can be improved to leverage the MainBootstrapper boot approach in order to reduce reliance on lib/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2978) ClientCommandLine and Daemon improvement to reduce reliance on lib/
ClientCommandLine and Daemon improvement to reduce reliance on lib/ --- Key: GERONIMO-2978 URL: https://issues.apache.org/jira/browse/GERONIMO-2978 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: startup/shutdown Affects Versions: 2.0-M3 Reporter: Gianny Damour Assigned To: Gianny Damour ClientCommandLine and Daemon can be improved to leverage the MainBootstrapper boot approach in order to reduce reliance on lib/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2916) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478727 ] Gianny Damour commented on GERONIMO-2916: - Anita, this problem should now be fixed. PersistenceUnitBuilders were wrongly invoked by the EARConfigBuilder during the deployment of standalone modules. database creation pool wizzard fails to deploy -- Key: GERONIMO-2916 URL: https://issues.apache.org/jira/browse/GERONIMO-2916 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 2.0-M2, 2.0-M3 Environment: relates to GERONIMO-2686 Reporter: Hernan Cunico From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. Similar error conditions were reported in GERONIMO-2686 The terminal shows the following error: 15:07:55,562 ERROR [DatabasePoolPortlet] Unable to save connection pool javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer for module type: rar registered at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:343) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) 15:08:02,875 ERROR
[jira] Commented: (GERONIMO-2928) PersistenceUnit located in the EAR library directory is not yet implemented
[ https://issues.apache.org/jira/browse/GERONIMO-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478394 ] Gianny Damour commented on GERONIMO-2928: - PersistenceUnitBuilders are now invoked during the processing of EAR to discover persistence units located in the EAR library directory. It seems that some wirings are missings somewhere as they do not get bond to the ENC. Looking at this problem now. 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 Assigned To: 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.
[jira] Created: (GERONIMO-2928) PersistenceUnit located in the EAR library directory is not yet implemented
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 Assigned To: 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.
[jira] Closed: (GERONIMO-2912) Server can not be shutdown using bin\shutdown
[ https://issues.apache.org/jira/browse/GERONIMO-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2912. --- Resolution: Fixed Fix Version/s: (was: 2.0-M3) (was: 2.0-beta2) 2.0 Assignee: Gianny Damour (was: Anita Kulshreshtha) Regression: [Regression] Anita. Thanks for raising this problem. It has now been fixed. Server can not be shutdown using bin\shutdown - Key: GERONIMO-2912 URL: https://issues.apache.org/jira/browse/GERONIMO-2912 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M3, 2.0-beta2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Gianny Damour Fix For: 2.0 Attachments: GERONIMO-2912.patch The server gives the following error when shutdown is attempted using bin\shutdown.: Exception in thread main java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/cli/StopServer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2912) Server can not be shutdown using bin\shutdown
[ https://issues.apache.org/jira/browse/GERONIMO-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-2912: Attachment: GERONIMO-2912.patch Fix this problem. I have other changes in my local and, hence, I will commit this change as soon as I am convinced that it is the right change set to commit. Server can not be shutdown using bin\shutdown - Key: GERONIMO-2912 URL: https://issues.apache.org/jira/browse/GERONIMO-2912 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M3, 2.0-beta2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 2.0-M3, 2.0-beta2 Attachments: GERONIMO-2912.patch The server gives the following error when shutdown is attempted using bin\shutdown.: Exception in thread main java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/cli/StopServer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2823) System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies
System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies -- Key: GERONIMO-2823 URL: https://issues.apache.org/jira/browse/GERONIMO-2823 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: dependencies Affects Versions: 2.0-M1 Reporter: Gianny Damour Assigned To: Gianny Damour AbstractRepository.getDependencies loads the resource META-INF/geronimo-dependency.xml in order to retrieve the child dependencies of the provided Artifact. The system class loader should be excluded when this resource is loaded as it may result in an infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2823) System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2823. --- Resolution: Fixed Fix Version/s: 2.0-beta1 This is now fixed. System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies -- Key: GERONIMO-2823 URL: https://issues.apache.org/jira/browse/GERONIMO-2823 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.0-M1 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-beta1 AbstractRepository.getDependencies loads the resource META-INF/geronimo-dependency.xml in order to retrieve the child dependencies of the provided Artifact. The system class loader should be excluded when this resource is loaded as it may result in an infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2794) Improve online deployer to register ModuleConfigurers from the repository
Improve online deployer to register ModuleConfigurers from the repository - Key: GERONIMO-2794 URL: https://issues.apache.org/jira/browse/GERONIMO-2794 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0-M2 Reporter: Gianny Damour Assigned To: Gianny Damour ModuleConfigurers need to be registered with the DeploymentManager outside of a Geronimo server. The online deployer needs to be improved such that ModuleConfigurers can be easily discovered and registered with the DeploymentManager. As suggested by David J. the online deployer could start-up a Kernel and start a list of modules to perform this registration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2767) Minimize side effects of the offline deployer
[ https://issues.apache.org/jira/browse/GERONIMO-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2767. --- Resolution: Fixed This is now fixed. Minimize side effects of the offline deployer - Key: GERONIMO-2767 URL: https://issues.apache.org/jira/browse/GERONIMO-2767 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.1, 2.0 Environment: Offline deployment Reporter: Ted Kirby Assigned To: Gianny Damour Fix For: 1.1.2, 2.0 Minimize the side effects of using deployment commands in the offline mode. In the 1.1.1 release, offline deployment has the side effect of modifying the server configuration file to enable all of the modules that are listed in the file var/config/offline-deployer-list: geronimo/geronimo-gbean-deployer/1.1.1/car geronimo/j2ee-deployer/1.1.1/car geronimo/openejb-deployer/1.1.1/car geronimo/client-deployer/1.1.1/car geronimo/axis-deployer/1.1.1/car geronimo/tomcat-deployer/1.1.1/car This is undesirable, since an offline deployment should only modify the server configuration with respect to the deployed module, and not otherwise affect the configuration of the server. For example, because of this side effect is not practical to use the following commands to disable an old version of a module and enable the new version: $ bin/deploy.sh --offline stop moduleId $ bin/deploy.sh --offline start moduleId Also, the offline deployment feature appears to be broken in the current Geronimo-1.2 branch. Finally (and much less importantly), offline deployment appears to modify other files in the var directory besides the configuration files in var/config (e.g. server log files). This presumably happens because offline deployment actually executes geronimo in a limited way in order to perform the deployment. Removing this side effect is desirable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2794) Improve online deployer to register ModuleConfigurers from the repository
[ https://issues.apache.org/jira/browse/GERONIMO-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2794. --- Resolution: Fixed This is now fixed. Improve online deployer to register ModuleConfigurers from the repository - Key: GERONIMO-2794 URL: https://issues.apache.org/jira/browse/GERONIMO-2794 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M2 Reporter: Gianny Damour Assigned To: Gianny Damour ModuleConfigurers need to be registered with the DeploymentManager outside of a Geronimo server. The online deployer needs to be improved such that ModuleConfigurers can be easily discovered and registered with the DeploymentManager. As suggested by David J. the online deployer could start-up a Kernel and start a list of modules to perform this registration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2767) Minimize side effects of the offline deployer
[ https://issues.apache.org/jira/browse/GERONIMO-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour reassigned GERONIMO-2767: --- Assignee: Gianny Damour Minimize side effects of the offline deployer - Key: GERONIMO-2767 URL: https://issues.apache.org/jira/browse/GERONIMO-2767 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.1, 2.0 Environment: Offline deployment Reporter: Ted Kirby Assigned To: Gianny Damour Fix For: 1.1.2, 2.0 Minimize the side effects of using deployment commands in the offline mode. In the 1.1.1 release, offline deployment has the side effect of modifying the server configuration file to enable all of the modules that are listed in the file var/config/offline-deployer-list: geronimo/geronimo-gbean-deployer/1.1.1/car geronimo/j2ee-deployer/1.1.1/car geronimo/openejb-deployer/1.1.1/car geronimo/client-deployer/1.1.1/car geronimo/axis-deployer/1.1.1/car geronimo/tomcat-deployer/1.1.1/car This is undesirable, since an offline deployment should only modify the server configuration with respect to the deployed module, and not otherwise affect the configuration of the server. For example, because of this side effect is not practical to use the following commands to disable an old version of a module and enable the new version: $ bin/deploy.sh --offline stop moduleId $ bin/deploy.sh --offline start moduleId Also, the offline deployment feature appears to be broken in the current Geronimo-1.2 branch. Finally (and much less importantly), offline deployment appears to modify other files in the var directory besides the configuration files in var/config (e.g. server log files). This presumably happens because offline deployment actually executes geronimo in a limited way in order to perform the deployment. Removing this side effect is desirable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2764) Clustered HttpSessions are not properly destroyed during eviction
Clustered HttpSessions are not properly destroyed during eviction - Key: GERONIMO-2764 URL: https://issues.apache.org/jira/browse/GERONIMO-2764 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Clustering, Jetty Affects Versions: 2.0-M1 Reporter: Gianny Damour Assigned To: Gianny Damour ClusteredSession are not properly removed from ClusteredSessionManager when they are evicted after timing-out. SessionListener needs to provide a new method to be called when a Session is destroyed such that ClusteredSessionManager can receive a notification when a Session expired and properly remove it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2764) Clustered HttpSessions are not properly destroyed during eviction
[ https://issues.apache.org/jira/browse/GERONIMO-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2764. --- Resolution: Fixed Fix Version/s: 2.0-M2 This is implemented. Clustered HttpSessions are not properly destroyed during eviction - Key: GERONIMO-2764 URL: https://issues.apache.org/jira/browse/GERONIMO-2764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering, Jetty Affects Versions: 2.0-M1 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-M2 ClusteredSession are not properly removed from ClusteredSessionManager when they are evicted after timing-out. SessionListener needs to provide a new method to be called when a Session is destroyed such that ClusteredSessionManager can receive a notification when a Session expired and properly remove it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2677) HttpSession Relocation - Sticky load-balancing via HTTP Cookie
[ https://issues.apache.org/jira/browse/GERONIMO-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2677. --- Resolution: Fixed Fix Version/s: 2.0-M2 Sticky load-balancing is now working fine. HttpSession Relocation - Sticky load-balancing via HTTP Cookie -- Key: GERONIMO-2677 URL: https://issues.apache.org/jira/browse/GERONIMO-2677 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-M2 Attachments: GERONIMO-2677.patch, JETTY-2677.patch When an HttpSession is migrated from one node to another: * its id must be updated (the worker name suffix is to be set to the name of the node owning the HttpSession); and * the session cookie must be updated accordingly. The worker name suffix, which can be retrieved from the session cookie, can be leverage to configure sticky load-balancing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2677) HttpSession Relocation - Sticky load-balancing via HTTP Cookie
HttpSession Relocation - Sticky load-balancing via HTTP Cookie -- Key: GERONIMO-2677 URL: http://issues.apache.org/jira/browse/GERONIMO-2677 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour When an HttpSession is migrated from one node to another: * its id must be updated (the worker name suffix is to be set to the name of the node owning the HttpSession); and * the session cookie must be updated accordingly. The worker name suffix, which can be retrieved from the session cookie, can be leverage to configure sticky load-balancing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2677) HttpSession Relocation - Sticky load-balancing via HTTP Cookie
[ http://issues.apache.org/jira/browse/GERONIMO-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-2677: Attachment: GERONIMO-2677.patch JETTY-2677.patch HttpSession Relocation - Sticky load-balancing via HTTP Cookie -- Key: GERONIMO-2677 URL: http://issues.apache.org/jira/browse/GERONIMO-2677 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Attachments: GERONIMO-2677.patch, JETTY-2677.patch When an HttpSession is migrated from one node to another: * its id must be updated (the worker name suffix is to be set to the name of the node owning the HttpSession); and * the session cookie must be updated accordingly. The worker name suffix, which can be retrieved from the session cookie, can be leverage to configure sticky load-balancing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2677) HttpSession Relocation - Sticky load-balancing via HTTP Cookie
[ http://issues.apache.org/jira/browse/GERONIMO-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461613 ] Gianny Damour commented on GERONIMO-2677: - I attach two patches: * JETTY-2677.patch: Jetty6 patch in order to simplify the integration code. ** AbstractSessionManager.Session is updated such that its two constructors share the same logic with respect to the definition of the _id field. Also, the method initValues is added such that sub-classes can explicitly control the initialization of the _values field. ** SessionHandler.handle is refactored: the method setRequestedId has been extracted such that sub-classes can also share this behavior; and ** Request.getSession(boolean) is improved such that a session cookie is set against a session whose id has changed (following a migration). * GERONIMO-2677.patch: Geronimo patch to leverage the Jetty6 code base after having applied the Jetty6 patch. HttpSession Relocation - Sticky load-balancing via HTTP Cookie -- Key: GERONIMO-2677 URL: http://issues.apache.org/jira/browse/GERONIMO-2677 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Attachments: GERONIMO-2677.patch, JETTY-2677.patch When an HttpSession is migrated from one node to another: * its id must be updated (the worker name suffix is to be set to the name of the node owning the HttpSession); and * the session cookie must be updated accordingly. The worker name suffix, which can be retrieved from the session cookie, can be leverage to configure sticky load-balancing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2669) fix o.a.g.j.ClusteredSessionManager to match changes in Jetty AbstractSessionManager
[ http://issues.apache.org/jira/browse/GERONIMO-2669?page=all ] Gianny Damour closed GERONIMO-2669. --- Fix Version/s: 2.0-M2 (was: 2.0) Resolution: Fixed Thanks for having fixed the build and opened this JIRA David. I have reviewed and done some integration testings. Load-balancing and session replications are working with Jetty6. fix o.a.g.j.ClusteredSessionManager to match changes in Jetty AbstractSessionManager Key: GERONIMO-2669 URL: http://issues.apache.org/jira/browse/GERONIMO-2669 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0 Reporter: David Jencks Assigned To: Gianny Damour Fix For: 2.0-M2 Recent changes in jetty's AbstractSessionManager break the geronimo-jetty6 module build. I'm committing something that compiles and lets the console run (unclustered) but this needs some attention from someone who knows what is going on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2074) CMP Issues two selects for each CMP bean read operation
[ http://issues.apache.org/jira/browse/GERONIMO-2074?page=all ] Gianny Damour resolved GERONIMO-2074. - Resolution: Fixed Assignee: Matt Hogstrom (was: Gianny Damour) Fixed. CMP Issues two selects for each CMP bean read operation --- Key: GERONIMO-2074 URL: http://issues.apache.org/jira/browse/GERONIMO-2074 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Matt Hogstrom Assigned To: Matt Hogstrom Fix For: 1.2 Attachments: GERONIMO-2074.patch Number of executions = 84422 Statement text = SELECT Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ? Number of executions = 84464 Statement text = SELECT Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ? This is running the PrimitiveServlet2EntityLocal. In this primitive a CMP Entity bean is selected and all fields referenced. Performance would be greatly improved if we only did the full select and avoided the round trip of two queries. The difference in counts is beause of a bug I'm chasing with Jencks re: some Tx failing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2221) java.lang.ClassCastException while installing Servlet Examples
[ http://issues.apache.org/jira/browse/GERONIMO-2221?page=all ]
Gianny Damour updated GERONIMO-2221:
Summary: java.lang.ClassCastException while installing Servlet Examples
(was: java.lang.ClassCastException while installing Servlet Examples because
of Checksum file not found)
Component/s: (was: sample apps)
Description:
http://localhost:8080/ - Servlet Examples - click here (i.e.
http://localhost:8080/servlets-examples/?install=true) -
{code}
# Installed configuration
# id = geronimo/servlets-examples-tomcat/1.0/car
# location =
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car
10:57:46,031 WARN [ConfigurationStoreUtil] Checksum file not found:
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car\META
-INF\config.ser.sha1
10:57:46,046 ERROR [[servlet_sample_installer]] Servlet.service() for servlet
servlet_sample_installer threw exception
java.lang.ClassCastException
at
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.readConfigurationData(SerializedConfigurationMarshaler.java:57)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.readConfigurationData(ConfigurationUtil.java:167)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfiguration(RepositoryConfigurationStore.java:113)
{code}
It happens on Jetty, too.
The config.ser file of this example contains a raw GBeanInfo instead of a
ConfigurationData wrapping a GBeanInfo. It seems to me that the car file format
of this example is incorrect. I will investigate further a potential root cause.
was:
http://localhost:8080/ - Servlet Examples - click here (i.e.
http://localhost:8080/servlets-examples/?install=true) -
{code}
# Installed configuration
# id = geronimo/servlets-examples-tomcat/1.0/car
# location =
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car
10:57:46,031 WARN [ConfigurationStoreUtil] Checksum file not found:
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car\META
-INF\config.ser.sha1
10:57:46,046 ERROR [[servlet_sample_installer]] Servlet.service() for servlet
servlet_sample_installer threw exception
java.lang.ClassCastException
at
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.readConfigurationData(SerializedConfigurationMarshaler.java:57)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.readConfigurationData(ConfigurationUtil.java:167)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfiguration(RepositoryConfigurationStore.java:113)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore$$FastClassByCGLIB$$968bf00c.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
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.ConfigurationStore$$EnhancerByCGLIB$$a45644d1.loadConfiguration(generated)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:738)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:454)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:383)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCGLIB$$cebc327e.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
[jira] Closed: (GERONIMO-188) Entity instance caching
[ http://issues.apache.org/jira/browse/GERONIMO-188?page=all ] Gianny Damour closed GERONIMO-188. -- Fix Version/s: 1.1.1 (was: 1.x) Resolution: Fixed Thanks for this reminder Vamsi. This feature has been added some while back. Entity instance caching --- Key: GERONIMO-188 URL: http://issues.apache.org/jira/browse/GERONIMO-188 Project: Geronimo Issue Type: Task Components: OpenEJB Affects Versions: 1.0-M1 Reporter: Dain Sundstrom Assigned To: Gianny Damour Fix For: 1.1.1 OpenEJB 2.0M1 does not cache entity instances between method calls. This was useful to test entity life-cycle, but needs to be added for server efficiency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2221) java.lang.ClassCastException while installing Servlet Examples because of Checksum file not found
[
http://issues.apache.org/jira/browse/GERONIMO-2221?page=comments#action_12455636
]
Gianny Damour commented on GERONIMO-2221:
-
I am worried that backward compatibility of configuration serialization is
still not properly working: the CAR is a 1.0 one and the server is a
1.2-SNAPSHOT one. I will build the 1.1.1 branch and install one of its
configuration into a 1.2-SNAPSHOT server to try to reproduce.
java.lang.ClassCastException while installing Servlet Examples because of
Checksum file not found
-
Key: GERONIMO-2221
URL: http://issues.apache.org/jira/browse/GERONIMO-2221
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: sample apps, web
Affects Versions: 1.2
Environment: cygwin, java 1.4, Revision: 424964
Reporter: Jacek Laskowski
http://localhost:8080/ - Servlet Examples - click here (i.e.
http://localhost:8080/servlets-examples/?install=true) -
{code}
# Installed configuration
# id = geronimo/servlets-examples-tomcat/1.0/car
# location =
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car
10:57:46,031 WARN [ConfigurationStoreUtil] Checksum file not found:
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car\META
-INF\config.ser.sha1
10:57:46,046 ERROR [[servlet_sample_installer]] Servlet.service() for servlet
servlet_sample_installer threw exception
java.lang.ClassCastException
at
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.readConfigurationData(SerializedConfigurationMarshaler.java:57)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.readConfigurationData(ConfigurationUtil.java:167)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfiguration(RepositoryConfigurationStore.java:113)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore$$FastClassByCGLIB$$968bf00c.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
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.ConfigurationStore$$EnhancerByCGLIB$$a45644d1.loadConfiguration(generated)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:738)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:454)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:383)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCGLIB$$cebc327e.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
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.system.plugin.PluginInstaller$$EnhancerByCGLIB$$72bbc85c.install(generated)
at
org.apache.geronimo.welcome.AbsentSampleServlet.doInstall(AbsentSampleServlet.java:72)
at
org.apache.geronimo.welcome.AbsentSampleServlet.doGet(AbsentSampleServlet.java:52)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
[jira] Closed: (GERONIMO-2470) Add support for Session Replication
[ http://issues.apache.org/jira/browse/GERONIMO-2470?page=all ] Gianny Damour closed GERONIMO-2470. --- Fix Version/s: 1.2 Resolution: Fixed Assignee: Gianny Damour Replication has been hooked in. Add support for Session Replication --- Key: GERONIMO-2470 URL: http://issues.apache.org/jira/browse/GERONIMO-2470 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 1.2 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 1.2 Currently, the WADI clustering code only addresses load-balancing. WADI can also provides sync or async session replication. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2541) Priority order for GBeans
[ http://issues.apache.org/jira/browse/GERONIMO-2541?page=all ] Gianny Damour updated GERONIMO-2541: Attachment: GERONIMO-2541-KERNEL.patch SERIALIZATION_-1012491431781444074.ser geronimo-kernel patch to be applied after having rolled back updates to geronimo-kernel of the previous patch. The idea is to maintain backward compatibility and also to provide a mechanism to support future changes which will break backward compatibility. SERIALIZATIONxxx is to be put in modules/geronimo-kernel/src/test/data/gbeandata/. (This is a binary file and, hence, it cannot be included in the patch). Priority order for GBeans - Key: GERONIMO-2541 URL: http://issues.apache.org/jira/browse/GERONIMO-2541 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Attachments: GERONIMO-2541-KERNEL.patch, GERONIMO-2541.patch, SERIALIZATION_-1012491431781444074.ser Add a priority order to GBeanData to order attempted starts of GBeans. GBeanInfo can have a default. GBean dependencies will still override the priority, in that a priority ordering will determine the order in which we try to start gbeans, but one won't start until all its dependencies have started. This will probably be useful in several contexts but right now I need to get the PersistenceUnitGBean to start first so it can install the class enhancer before any classes are loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
