[jira] Created: (GERONIMO-4944) Deploying an EAR with security tries to create a new JACCManager
Deploying an EAR with security tries to create a new JACCManager Key: GERONIMO-4944 URL: https://issues.apache.org/jira/browse/GERONIMO-4944 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment, Plugins, security Affects Versions: 2.2 Reporter: Quintin Beukes Fix For: 2.2 When deploying an EAR with security configured, the following happens, though security isn't affected: 2009-10-30 21:49:56,687 INFO [config] Enterprise application "net.kunye/KunyeEAR/1.0/ear" loaded. 2009-10-30 21:50:07,781 ERROR [EjbModuleBuilder] GeronimoSecurityBuilderImpl.addGBeans() failed: JACC manager gbean already present org.apache.geronimo.common.DeploymentException: JACC manager gbean already present at org.apache.geronimo.security.deployment.GeronimoSecurityBuilderImpl.buildJaccManager(GeronimoSecurityBuilderImpl.java:224) at org.apache.geronimo.security.deployment.GeronimoSecurityBuilderImpl.addGBeans(GeronimoSecurityBuilderImpl.java:150) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.addGBeans(EjbModuleBuilder.java:825) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:652) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:136) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1426) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1264) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1366) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.geronimo.kernel.GBeanAlreadyExistsException: net.kunye/KunyeEAR/1.
[jira] Updated: (GERONIMO-4937) Geronimo Testsuite Test for Singletons
[ https://issues.apache.org/jira/browse/GERONIMO-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4937: - Attachment: testsuite-singleton.patch Attached the patch to update the testsuite as well as create new files. If new files are preferred in an archive, just let me know. > Geronimo Testsuite Test for Singletons > -- > > Key: GERONIMO-4937 > URL: https://issues.apache.org/jira/browse/GERONIMO-4937 > Project: Geronimo > Issue Type: Test > Security Level: public(Regular issues) > Components: OpenEJB, testsuite >Affects Versions: 2.2 >Reporter: Quintin Beukes > Fix For: 2.2 > > Attachments: testsuite-singleton.patch > > > Created a Singleton test in the ejb-tests test suite. > Tests local + remote invocations. > Tests @Startup, @DependsOn and @PostConstruct annotations. > Tests Remote invocations through InitialContext > Tests Local invocations through injected beans in a Servlet and in another > Singleton EJB. > Patch was generated from branches/2.2 by doing "svn add" on all the new > files, and then doing: > svn diff testsuite/enterprise-testsuite/ejb-tests > Tested the patch on a clean checkout, by running from the root of the the > branches/2.2 working copy: > patch -i testsuite-singleton.patch > It asked for "paths to file" on 2 of the entries, for which I just > copied/pasted the exact path it suggests. From here I did a "mvn clean > install" on the test suite and all tests succeeded. > Validated the changes to the tests by changed some of the code to ensure > tests fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4937) Geronimo Testsuite Test for Singletons
Geronimo Testsuite Test for Singletons -- Key: GERONIMO-4937 URL: https://issues.apache.org/jira/browse/GERONIMO-4937 Project: Geronimo Issue Type: Test Security Level: public (Regular issues) Components: OpenEJB, testsuite Affects Versions: 2.2 Reporter: Quintin Beukes Fix For: 2.2 Attachments: testsuite-singleton.patch Created a Singleton test in the ejb-tests test suite. Tests local + remote invocations. Tests @Startup, @DependsOn and @PostConstruct annotations. Tests Remote invocations through InitialContext Tests Local invocations through injected beans in a Servlet and in another Singleton EJB. Patch was generated from branches/2.2 by doing "svn add" on all the new files, and then doing: svn diff testsuite/enterprise-testsuite/ejb-tests Tested the patch on a clean checkout, by running from the root of the the branches/2.2 working copy: patch -i testsuite-singleton.patch It asked for "paths to file" on 2 of the entries, for which I just copied/pasted the exact path it suggests. From here I did a "mvn clean install" on the test suite and all tests succeeded. Validated the changes to the tests by changed some of the code to ensure tests fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used
[ https://issues.apache.org/jira/browse/GERONIMO-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4918: - Attachment: singleton-deploy-type.patch The commit didn't include the SINGLETON type in plugins/openejb/geronimo-openejb-builder/src/main/java/org/apache/geronimo/openejb/deployment/EjbDeploymentBuilder.java Without it you receive the following when deploying a Singleton EJB: org.apache.geronimo.common.DeploymentException: Unable to deploy KunyeEAR-ear.ear: Unknown enterprise bean type org.apache.openejb.jee.SingletonBean There are 2 places to update for a bean type, this one and plugins/openejb/geronimo-openejb-builder/src/main/java/org/apache/geronimo/openejb/deployment/BasicEjbDeploymentGBeanNameBuilder.java. It looks like the SingletonDeploymentGBean.java file has been created though, so the patch should do it. > Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 > is used > > > Key: GERONIMO-4918 > URL: https://issues.apache.org/jira/browse/GERONIMO-4918 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.2 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > Attachments: GERONIMO-4918.patch, > geronimo-singleton-support-geronimo.patch, LoadOnStartupGBean.java, > singleton-deploy-type.patch, SingletonDeploymentGBean.java > > > The singleton support hasn't been completely implemented, so it's impossible > to deploy an singleton session bean (EJB). > I added the support, recompiled + tested and it's working. > The patch requires creating a new file, so both need to be applied. > The patch was made from the root of the svn checkout of branches/2.2. > The new files path from the same root is: > plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4871) Something blocking 'kill -3' signals?
[ https://issues.apache.org/jira/browse/GERONIMO-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770583#action_12770583 ] Quintin Beukes commented on GERONIMO-4871: -- Unless I imagined things, it looks like Geronimo is now capturing stdout/stderr and sending it to the geronimo.log instead of geronimo.out. And also depending on the output type it prints a progress bar. This wasn't the case in 2.1. I had to look at all my System.out.println() statements in geronimo.out, where the other day I found they were being sent to geronimo.log after the server completed starting. If this is programmatically, maybe it's related to this. It comes back to my previous comment. Maybe it IS doing the thread dump, you just can't find to where, or the pipe is broken and it goes into nothingness. > Something blocking 'kill -3' signals? > - > > Key: GERONIMO-4871 > URL: https://issues.apache.org/jira/browse/GERONIMO-4871 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Kevan Miller > Fix For: 2.2.1 > > > I occasionally use 'kill -3' to cause a java process to dump all thread > stacks. For some reason, this isn't working on Geronimo 2.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-4871) Something blocking 'kill -3' signals?
[ https://issues.apache.org/jira/browse/GERONIMO-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770581#action_12770581 ] Quintin Beukes commented on GERONIMO-4871: -- One final note. Perhaps the logging level is configured differently. Try setting the log levels to trace on the Geronimo logging and the JRE logging - in fact, on all logging frameworks accessible. Maybe somehow it logs to another file somewhere. I had a look around on google, and it does seem like there are cases where people had to change their logging levels in order to see the thread dumps. > Something blocking 'kill -3' signals? > - > > Key: GERONIMO-4871 > URL: https://issues.apache.org/jira/browse/GERONIMO-4871 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Kevan Miller > Fix For: 2.2.1 > > > I occasionally use 'kill -3' to cause a java process to dump all thread > stacks. For some reason, this isn't working on Geronimo 2.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-4871) Something blocking 'kill -3' signals?
[ https://issues.apache.org/jira/browse/GERONIMO-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770576#action_12770576 ] Quintin Beukes commented on GERONIMO-4871: -- Check if the -Xrs option is specified perhaps, by echoing the final command used to start the JVM. -Xrs disables this. Further, try adding a shutdown hook and the doing a SIGTERM. Check if the shutdown hooks execute, but the thread dump doesn't work, or if neither work. Q > Something blocking 'kill -3' signals? > - > > Key: GERONIMO-4871 > URL: https://issues.apache.org/jira/browse/GERONIMO-4871 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Kevan Miller > Fix For: 2.2.1 > > > I occasionally use 'kill -3' to cause a java process to dump all thread > stacks. For some reason, this isn't working on Geronimo 2.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-4871) Something blocking 'kill -3' signals?
[ https://issues.apache.org/jira/browse/GERONIMO-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770567#action_12770567 ] Quintin Beukes commented on GERONIMO-4871: -- It has to be something that changed between that 2. I'm sure that part is obvious for anyone reading this. It has to also be something the 2 does different. Perhaps related to a JavaAgent or JMX? Something else that captures the signal? Have you tried echoing the command geronimo.sh uses to start and then running it manually, removing arguments until you find on that could possibly trigger this? Does the same happen when you run the minimal server? Have you tried to remove modules until you could perhaps find one, which without it everything works? If I had a Mac I would have a look at it, but ... :> > Something blocking 'kill -3' signals? > - > > Key: GERONIMO-4871 > URL: https://issues.apache.org/jira/browse/GERONIMO-4871 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Kevan Miller > Fix For: 2.2.1 > > > I occasionally use 'kill -3' to cause a java process to dump all thread > stacks. For some reason, this isn't working on Geronimo 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4928) In the JPA persistence.xml loading code, exclude-unlisted-classes handling not compliant with JPA3.0 spec
[
https://issues.apache.org/jira/browse/GERONIMO-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4928:
-
Description:
{panel:title=EJB 3.0 JPA spec FR, section 6.2.1.6}
The set of managed persistence classes that are managed by a persistence unit
is defined by using one or
more of the following:[41]
• One or more object/relational mapping XML files
• One or more jar files that will be searched for classes
• An explicit list of the classes
• The annotated managed persistence classes contained in the root of the
persistence unit (unless
the exclude-unlisted-classes element is specified)
{panel}
{panel:title=further on in the same section}
All classes must be on the classpath to ensure that entity managers from
different persistence units that
map the same class will be accessing the same identical class.
{panel}
This says that if exclude-unlisted-classes is specified as true, then only the
classes listed in elements must be used in the PU. If it is specified
as false, then the annotated classes must be included. It's the only thing that
exclude-unlisted-classes affects. It doesn't affect classes from other units,
and if false it doesn't say that must be ignored, which is what the
following code does in PersistenceUnitBuilder.java:
{code:title=PersistenceUnitBuilder.java line 310|borderStyle=solid}
if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
} else {
gbeanData.clearAttribute("managedClassNames");
}
{code}
I removed the else block to leave:
{code:title=PersistenceUnitBuilder.java Patched|borderStyle=solid}
if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
}
{code}
Without this Geronimo isn't JavaEE 5 compliant.
was:
According to the final release of the EJB 3.0 JPA spec, section 6.2.1.6:
The set of managed persistence classes that are managed by a persistence unit
is defined by using one or
more of the following:[41]
• One or more object/relational mapping XML files
• One or more jar files that will be searched for classes
• An explicit list of the classes
• The annotated managed persistence classes contained in the root of the
persistence unit (unless
the exclude-unlisted-classes element is specified)
... further on...
All classes must be on the classpath to ensure that entity managers from
different persistence units that
map the same class will be accessing the same identical class.
This says that if exclude-unlisted-classes is specified as true, then only the
classes listed in elements must be used in the PU. If it is specified
as false, then the annotated classes must be included. It's the only thing that
exclude-unlisted-classes affects. It doesn't affect classes from other units,
and if false it doesn't say that must be ignored, which is what the
following code does in PersistenceUnitBuilder.java:
if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
} else {
gbeanData.clearAttribute("managedClassNames");
}
I removed the else block to leave:
if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
}
Without this Geronimo isn't JavaEE 5 compliant.
Edited the JIRA to add some formatting for readability.
> In the JPA persistence.xml loading code, exclude-unlisted-classes handling
> not compliant with JPA3.0 spec
> -
>
> Key: GERONIMO-4928
> URL: https://issues.apache.org/jira/browse/GERONIMO-4928
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: deployment, persistence
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
> Fix For: 2.1.4, 2.2, 3.0
>
> Attachments: external-jpa-entity-reference.patch
>
>
> {panel:title=EJB 3.0 JPA spec FR, section 6.2.1.6}
> The set of managed persistence classes that are managed by a persistence unit
> is defined by using one or
> more of the following:[41]
> • One or more object/relational mapping XML files
> • One or more jar files that will be searched for classes
> • An explicit list of the classes
> • The annotated managed persistence classes contained in the root of the
> persistence unit (unless
> the exclude-unlisted-classes element is specified)
> {panel}
> {panel:title=further on in the same section}
> All classes must be on the classpath to ensure that entity managers from
> different persistence units that
> map the same class will be accessing the same identical class.
> {panel}
> This says that if exclude-unlisted-classes is specified as true, then only
> the classes listed in elements must be used in the PU. If it
[jira] Updated: (GERONIMO-4928) In the JPA persistence.xml loading code, exclude-unlisted-classes handling not compliant with JPA3.0 spec
[
https://issues.apache.org/jira/browse/GERONIMO-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4928:
-
Attachment: external-jpa-entity-reference.patch
Changes the handling of exclude-unlisted-classes
> In the JPA persistence.xml loading code, exclude-unlisted-classes handling
> not compliant with JPA3.0 spec
> -
>
> Key: GERONIMO-4928
> URL: https://issues.apache.org/jira/browse/GERONIMO-4928
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: deployment, persistence
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
> Fix For: 2.1.4, 2.2, 3.0
>
> Attachments: external-jpa-entity-reference.patch
>
>
> According to the final release of the EJB 3.0 JPA spec, section 6.2.1.6:
> The set of managed persistence classes that are managed by a persistence unit
> is defined by using one or
> more of the following:[41]
> • One or more object/relational mapping XML files
> • One or more jar files that will be searched for classes
> • An explicit list of the classes
> • The annotated managed persistence classes contained in the root of the
> persistence unit (unless
> the exclude-unlisted-classes element is specified)
> ... further on...
> All classes must be on the classpath to ensure that entity managers from
> different persistence units that
> map the same class will be accessing the same identical class.
> This says that if exclude-unlisted-classes is specified as true, then only
> the classes listed in elements must be used in the PU. If it is
> specified as false, then the annotated classes must be included. It's the
> only thing that exclude-unlisted-classes affects. It doesn't affect classes
> from other units, and if false it doesn't say that must be ignored,
> which is what the following code does in PersistenceUnitBuilder.java:
> if (excludeUnlistedClasses) {
> gbeanData.clearAttribute("jarFileUrls");
> } else {
> gbeanData.clearAttribute("managedClassNames");
> }
> I removed the else block to leave:
> if (excludeUnlistedClasses) {
> gbeanData.clearAttribute("jarFileUrls");
> }
> Without this Geronimo isn't JavaEE 5 compliant.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4928) In the JPA persistence.xml loading code, exclude-unlisted-classes handling not compliant with JPA3.0 spec
In the JPA persistence.xml loading code, exclude-unlisted-classes handling not
compliant with JPA3.0 spec
-
Key: GERONIMO-4928
URL: https://issues.apache.org/jira/browse/GERONIMO-4928
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: deployment, persistence
Affects Versions: 2.1.4
Reporter: Quintin Beukes
Fix For: 2.2, 3.0, 2.1.4
According to the final release of the EJB 3.0 JPA spec, section 6.2.1.6:
The set of managed persistence classes that are managed by a persistence unit
is defined by using one or
more of the following:[41]
• One or more object/relational mapping XML files
• One or more jar files that will be searched for classes
• An explicit list of the classes
• The annotated managed persistence classes contained in the root of the
persistence unit (unless
the exclude-unlisted-classes element is specified)
... further on...
All classes must be on the classpath to ensure that entity managers from
different persistence units that
map the same class will be accessing the same identical class.
This says that if exclude-unlisted-classes is specified as true, then only the
classes listed in elements must be used in the PU. If it is specified
as false, then the annotated classes must be included. It's the only thing that
exclude-unlisted-classes affects. It doesn't affect classes from other units,
and if false it doesn't say that must be ignored, which is what the
following code does in PersistenceUnitBuilder.java:
if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
} else {
gbeanData.clearAttribute("managedClassNames");
}
I removed the else block to leave:
if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
}
Without this Geronimo isn't JavaEE 5 compliant.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used
[ https://issues.apache.org/jira/browse/GERONIMO-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4918: - Attachment: SingletonDeploymentGBean.java LoadOnStartupGBean.java geronimo-singleton-support-geronimo.patch Updated the patch and files. These new ones include the following: 1. Support to deploy Singleton beans 2. Fixes a wording error in an exception in plugins/openejb/geronimo-openejb-builder/src/main/java/org/apache/geronimo/openejb/deployment/EjbDeploymentBuilder.java 3. Fixes a deadlock when an EJB is annotated with @Startup Now Singleton beans can deploy and startup, with @DependsOn requirements and @PostConstruct methods executed. Beans can also be referenced remotely as well as locally. All necessary EJBs/resources/PU/etc are injected. I tested it with simple test EJB jars, as well as our software's relatively complex JARs which contain Singletons. Some jars had @Startup annotations, some didn't. Everything worked the same. Still depends on OPENEJB-1092 > Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 > is used > > > Key: GERONIMO-4918 > URL: https://issues.apache.org/jira/browse/GERONIMO-4918 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.2 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > Attachments: geronimo-singleton-support-geronimo.patch, > LoadOnStartupGBean.java, SingletonDeploymentGBean.java > > > The singleton support hasn't been completely implemented, so it's impossible > to deploy an singleton session bean (EJB). > I added the support, recompiled + tested and it's working. > The patch requires creating a new file, so both need to be applied. > The patch was made from the root of the svn checkout of branches/2.2. > The new files path from the same root is: > plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used
[ https://issues.apache.org/jira/browse/GERONIMO-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4918: - Attachment: (was: SingletonDeploymentGBean.java) > Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 > is used > > > Key: GERONIMO-4918 > URL: https://issues.apache.org/jira/browse/GERONIMO-4918 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.2 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > > The singleton support hasn't been completely implemented, so it's impossible > to deploy an singleton session bean (EJB). > I added the support, recompiled + tested and it's working. > The patch requires creating a new file, so both need to be applied. > The patch was made from the root of the svn checkout of branches/2.2. > The new files path from the same root is: > plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used
[ https://issues.apache.org/jira/browse/GERONIMO-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4918: - Attachment: (was: geronimo-singleton-support-geronimo.patch) > Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 > is used > > > Key: GERONIMO-4918 > URL: https://issues.apache.org/jira/browse/GERONIMO-4918 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.2 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > > The singleton support hasn't been completely implemented, so it's impossible > to deploy an singleton session bean (EJB). > I added the support, recompiled + tested and it's working. > The patch requires creating a new file, so both need to be applied. > The patch was made from the root of the svn checkout of branches/2.2. > The new files path from the same root is: > plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used
[ https://issues.apache.org/jira/browse/GERONIMO-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4918: - Attachment: (was: singleton.patch) > Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 > is used > > > Key: GERONIMO-4918 > URL: https://issues.apache.org/jira/browse/GERONIMO-4918 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.2 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > Attachments: geronimo-singleton-support-geronimo.patch, > SingletonDeploymentGBean.java > > > The singleton support hasn't been completely implemented, so it's impossible > to deploy an singleton session bean (EJB). > I added the support, recompiled + tested and it's working. > The patch requires creating a new file, so both need to be applied. > The patch was made from the root of the svn checkout of branches/2.2. > The new files path from the same root is: > plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used
[ https://issues.apache.org/jira/browse/GERONIMO-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4918: - Attachment: geronimo-singleton-support-geronimo.patch Replaces the previous singleton.patch. This still depends on the SingletonDeploymentGBean.java to be created. This patch adds the support (same as singleton.patch), but also fixes a deadlock when the @Startup annotation is used on a @Singleton session bean. This patch also depends on OPENEJB-1092. > Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 > is used > > > Key: GERONIMO-4918 > URL: https://issues.apache.org/jira/browse/GERONIMO-4918 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.2 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > Attachments: geronimo-singleton-support-geronimo.patch, > singleton.patch, SingletonDeploymentGBean.java > > > The singleton support hasn't been completely implemented, so it's impossible > to deploy an singleton session bean (EJB). > I added the support, recompiled + tested and it's working. > The patch requires creating a new file, so both need to be applied. > The patch was made from the root of the svn checkout of branches/2.2. > The new files path from the same root is: > plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used
[ https://issues.apache.org/jira/browse/GERONIMO-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4918: - Attachment: SingletonDeploymentGBean.java singleton.patch Apply "singleton.patch" to branches/2.2. Commit SingletonDeploymentGBean.java to branches/2.2/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java > Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 > is used > > > Key: GERONIMO-4918 > URL: https://issues.apache.org/jira/browse/GERONIMO-4918 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.2 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > Attachments: singleton.patch, SingletonDeploymentGBean.java > > > The singleton support hasn't been completely implemented, so it's impossible > to deploy an singleton session bean (EJB). > I added the support, recompiled + tested and it's working. > The patch requires creating a new file, so both need to be applied. > The patch was made from the root of the svn checkout of branches/2.2. > The new files path from the same root is: > plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used
Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used Key: GERONIMO-4918 URL: https://issues.apache.org/jira/browse/GERONIMO-4918 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 2.2 Reporter: Quintin Beukes Fix For: 2.2, 3.0 The singleton support hasn't been completely implemented, so it's impossible to deploy an singleton session bean (EJB). I added the support, recompiled + tested and it's working. The patch requires creating a new file, so both need to be applied. The patch was made from the root of the svn checkout of branches/2.2. The new files path from the same root is: plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4915) SVN urls on the site is outdated/wrong
[ https://issues.apache.org/jira/browse/GERONIMO-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4915: - Description: Currently on the page: http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html The subversion URLs give 404 errors for these 3: http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin I'm not sure what they should be, as I have never seen the source and can't verify if this is in fact the correct URL, though it seems like it should be (in the same order): http://svn.apache.org/viewvc/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ http://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ https://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ was: Currently on the page: http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html The subversion URLs give 404 errors for these 3: http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin I'm not sure what they should be, as I have never seen the source and can't verify if this is in fact the correct URL, though it seems like it should be (in the same order): http://svn.apache.org/viewvc/geronimo/devtools/maven-plugins/trunk/ http://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/ https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/ Updated the URLs to the correct ones. > SVN urls on the site is outdated/wrong > -- > > Key: GERONIMO-4915 > URL: https://issues.apache.org/jira/browse/GERONIMO-4915 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: geronimo-maven-plugin >Reporter: Quintin Beukes > > Currently on the page: > http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html > The subversion URLs give 404 errors for these 3: > http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin > http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin > geronimo-maven-plugin > https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin > geronimo-maven-plugin > I'm not sure what they should be, as I have never seen the source and can't > verify if this is in fact the correct URL, though it seems like it should be > (in the same order): > http://svn.apache.org/viewvc/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ > http://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ > https://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4915) SVN urls on the site is outdated/wrong
SVN urls on the site is outdated/wrong -- Key: GERONIMO-4915 URL: https://issues.apache.org/jira/browse/GERONIMO-4915 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: geronimo-maven-plugin Reporter: Quintin Beukes Currently on the page: http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html The subversion URLs give 404 errors for these 3: http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin I'm not sure what they should be, as I have never seen the source and can't verify if this is in fact the correct URL, though it seems like it should be (in the same order): http://svn.apache.org/viewvc/geronimo/devtools/maven-plugins/trunk/ http://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/ https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4906) DB connection problem
[ https://issues.apache.org/jira/browse/GERONIMO-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765975#action_12765975 ] Quintin Beukes commented on GERONIMO-4906: -- I remember now that I was using c3p0 with Hibernate. These were the options I was referring to: http://www.mchange.com/projects/c3p0/index.html#configuring_connection_testing > DB connection problem > - > > Key: GERONIMO-4906 > URL: https://issues.apache.org/jira/browse/GERONIMO-4906 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: databases >Affects Versions: 2.0.1 > Environment: Geronimo running on Windows server 2003 (Virtual Machine) > Oracle 10g > Driver jdbc 10.2.0.1 > Spring-Version: 2.0.2 > Hibernate-Version: 3.2.0.cr4 >Reporter: Jean-Jacques Parent > Attachments: config.xml, Errors_samples.txt > > > Your expertise on my problem will be helpful. > Once a week, I get a DB connectivity problem with my application. > No new DB transaction can be open. After a few minutes, the situation can > come back as normal, if not the Geronimo server has to be restarted. > I ask our technicians about connectivity and performance, but they found > nothing wrong. > I give you the stack trace in attachment with the different kind of error > message. > You will see that it looks like a network problem, but maybe this could also > be due to a jdbc, timeout...? > My pool configuration is as follow > Pool Min Size:25 > The minimum number of connections in the pool. The default is 0. > Pool Max Size:140 > The maximum number of connections in the pool. The default is 10. > Blocking Timeout: 5000 (in milliseconds) > The length of time a caller will wait for a connection. The default is > 5000. > Idle Timeout: 5(in minutes) > How long a connection can be idle before being closed. The default is > 15. > Any help will be appreciate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4906) DB connection problem
[ https://issues.apache.org/jira/browse/GERONIMO-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765973#action_12765973 ] Quintin Beukes commented on GERONIMO-4906: -- I remember dealing with a similar problem once. I've been trying to think which pool manager this was, but am unable. Though I do remember how it was solved. It was an an option (possible 2 separate once - not sure) which routinely tested the actual connection, and if closed would remove it from the pool. Also, before the connection is given to a requesting client it would also be tested to ensure it's active, if not it would be removed and another connection tried - until one could be found. If none could be found an exception is raised. Maybe such an option is available? And if not, I definitely recommend it be added. If this isn't available yet, the code that requests the connection could perhaps (even temporarily) wrap the request in a method which has the above behavior (testing the connection and requesting a new one if the test fails). The pool should automatically remove it when an exception is raised, so I don't think this wrapper needs to worry about that. > DB connection problem > - > > Key: GERONIMO-4906 > URL: https://issues.apache.org/jira/browse/GERONIMO-4906 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: databases >Affects Versions: 2.0.1 > Environment: Geronimo running on Windows server 2003 (Virtual Machine) > Oracle 10g > Driver jdbc 10.2.0.1 > Spring-Version: 2.0.2 > Hibernate-Version: 3.2.0.cr4 >Reporter: Jean-Jacques Parent > Attachments: config.xml, Errors_samples.txt > > > Your expertise on my problem will be helpful. > Once a week, I get a DB connectivity problem with my application. > No new DB transaction can be open. After a few minutes, the situation can > come back as normal, if not the Geronimo server has to be restarted. > I ask our technicians about connectivity and performance, but they found > nothing wrong. > I give you the stack trace in attachment with the different kind of error > message. > You will see that it looks like a network problem, but maybe this could also > be due to a jdbc, timeout...? > My pool configuration is as follow > Pool Min Size:25 > The minimum number of connections in the pool. The default is 0. > Pool Max Size:140 > The maximum number of connections in the pool. The default is 10. > Blocking Timeout: 5000 (in milliseconds) > The length of time a caller will wait for a connection. The default is > 5000. > Idle Timeout: 5(in minutes) > How long a connection can be idle before being closed. The default is > 15. > Any help will be appreciate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4903) Jetty Advanced Integration Test Failure
[
https://issues.apache.org/jira/browse/GERONIMO-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765961#action_12765961
]
Quintin Beukes commented on GERONIMO-4903:
--
If GERONIMO-4907 is applied, it could become an option to revert revision
#824389 and #824390.
> Jetty Advanced Integration Test Failure
> ---
>
> Key: GERONIMO-4903
> URL: https://issues.apache.org/jira/browse/GERONIMO-4903
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: connector
>Affects Versions: 2.2
>Reporter: Quintin Beukes
>Assignee: Donald Woods
> Fix For: 2.2, 3.0
>
> Attachments: jetty-advanced-test-failure.patch
>
>
> Hey,
> I found the cause of the test failure.
> In the file: {src
> root}/plugins/jetty7/geronimo-jetty7/./src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java
> Line: 289
> It reads: new String[]{"host", "port", "minThreads", "maxThreads",
> "bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
> "lingerMillis", "protocol", "redirectPort", "connectUrl",
> "maxIdleTimeMs"},
> Change to: new String[]{"host", "port", "minThreads", "maxThreads",
> "bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
> "lingerMillis", "redirectPort", "maxIdleTimeMs"},
> Basically removing the "protocol" and "connectUrl" attributes from the
> persistent interface attributes fixes the problem.
> "protocol" is static for Jetty BIO connector, so it doesn't need to be
> saved, or can't be specified.
> "connectUrl" is generated on the fly through getConnectUrl(), so can't
> be saved either.
> So unless my understanding of what persistentAttributes are is
> incorrect, this seems to be the correct solution? Please correct me if
> I'm wrong.
> What caused the problem is that the JettyConnector class doesn't have
> a setter for these attributes, so when XBean searches all the
> specified attributes' setters, it fails when it can't find these. This
> caused the test to fail, because the connector doesn't start again
> after being edited (enters the failed state).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
[ https://issues.apache.org/jira/browse/GERONIMO-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765962#action_12765962 ] Quintin Beukes commented on GERONIMO-4907: -- If this is applied, GERONIMO-4903 could possibly be reversed. > GBeanInstance to Ignore Missing Setters > --- > > Key: GERONIMO-4907 > URL: https://issues.apache.org/jira/browse/GERONIMO-4907 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > Attachments: ignore-missing-accessors.patch > > > Related to GERONIMO-4903 > I submitted a patch which fixes the problem by removing the attributes which > don't have setters. > After reading the OpenEJB source I noticed an XBean feature which would be a > more correct fix for the problem. > Instead of removing the attributes which won't have setters in the class > being instantiated as a GBean, configure the ObjectRecipe to rather ignore > those properties which don't have setters. This has 2 benefits > 1) Those properties can still be included for "read" access > 2) If such a property exists for any other GBean, or is added in the future, > this will help that those don't possibly create fatal bugs - which the > JettyConnector bug almost was (you couldn't edit a connector - ever). > This is achieved by adding the following line after the ObjectRecipe was > created: > objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); > This permissions merely removes the property from the list of properties to > "create the object with", if the accessor wasn't found. > Since those properties are still available, they can be accessed by the GBean > API, and thus it doesn't become a requirement to have setter accessors for > all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
[ https://issues.apache.org/jira/browse/GERONIMO-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4907: - Attachment: ignore-missing-accessors.patch Attached patch to add the IGNORE_MISSING_ACCESSOR option to the ObjectRecipe. > GBeanInstance to Ignore Missing Setters > --- > > Key: GERONIMO-4907 > URL: https://issues.apache.org/jira/browse/GERONIMO-4907 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 >Reporter: Quintin Beukes > Fix For: 2.2, 3.0 > > Attachments: ignore-missing-accessors.patch > > > Related to GERONIMO-4903 > I submitted a patch which fixes the problem by removing the attributes which > don't have setters. > After reading the OpenEJB source I noticed an XBean feature which would be a > more correct fix for the problem. > Instead of removing the attributes which won't have setters in the class > being instantiated as a GBean, configure the ObjectRecipe to rather ignore > those properties which don't have setters. This has 2 benefits > 1) Those properties can still be included for "read" access > 2) If such a property exists for any other GBean, or is added in the future, > this will help that those don't possibly create fatal bugs - which the > JettyConnector bug almost was (you couldn't edit a connector - ever). > This is achieved by adding the following line after the ObjectRecipe was > created: > objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); > This permissions merely removes the property from the list of properties to > "create the object with", if the accessor wasn't found. > Since those properties are still available, they can be accessed by the GBean > API, and thus it doesn't become a requirement to have setter accessors for > all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
GBeanInstance to Ignore Missing Setters --- Key: GERONIMO-4907 URL: https://issues.apache.org/jira/browse/GERONIMO-4907 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Reporter: Quintin Beukes Fix For: 2.2, 3.0 Related to GERONIMO-4903 I submitted a patch which fixes the problem by removing the attributes which don't have setters. After reading the OpenEJB source I noticed an XBean feature which would be a more correct fix for the problem. Instead of removing the attributes which won't have setters in the class being instantiated as a GBean, configure the ObjectRecipe to rather ignore those properties which don't have setters. This has 2 benefits 1) Those properties can still be included for "read" access 2) If such a property exists for any other GBean, or is added in the future, this will help that those don't possibly create fatal bugs - which the JettyConnector bug almost was (you couldn't edit a connector - ever). This is achieved by adding the following line after the ObjectRecipe was created: objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); This permissions merely removes the property from the list of properties to "create the object with", if the accessor wasn't found. Since those properties are still available, they can be accessed by the GBean API, and thus it doesn't become a requirement to have setter accessors for all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4885) Configure default max heap and max permsize
[ https://issues.apache.org/jira/browse/GERONIMO-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4885: - Attachment: default-memory-options.patch To summarize the patch: Adds a -Xmx128m and -XX:MaxPermGen=128m as a default to bin/geronimo.sh, bin/geronimo.bat and etc/rc.d/start-server,default.groovy. For the groovy file it's only done for non Sun JRE 6 profiles. > Configure default max heap and max permsize > --- > > Key: GERONIMO-4885 > URL: https://issues.apache.org/jira/browse/GERONIMO-4885 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.2 >Reporter: Kevan Miller > Fix For: 2.2 > > Attachments: default-memory-options.patch > > > It seems that the amount of PermGen space being used by Geronimo 2.2. I think > users are more likely to run into OutOfMemoryErrors as a result. Even on > small to medium size apps. Setting a default max heap and max perm size > should help avoid this... > Looks like a 2.2 server is using the following: > 50 MB heap > 80 MB PermGen > I'd suggest setting the max for both options to 128M. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4885) Configure default max heap and max permsize
[ https://issues.apache.org/jira/browse/GERONIMO-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4885: - Attachment: (was: default-memory-options.patch) > Configure default max heap and max permsize > --- > > Key: GERONIMO-4885 > URL: https://issues.apache.org/jira/browse/GERONIMO-4885 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.2 >Reporter: Kevan Miller > Fix For: 2.2 > > > It seems that the amount of PermGen space being used by Geronimo 2.2. I think > users are more likely to run into OutOfMemoryErrors as a result. Even on > small to medium size apps. Setting a default max heap and max perm size > should help avoid this... > Looks like a 2.2 server is using the following: > 50 MB heap > 80 MB PermGen > I'd suggest setting the max for both options to 128M. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4885) Configure default max heap and max permsize
[ https://issues.apache.org/jira/browse/GERONIMO-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4885: - Attachment: default-memory-options.patch Also updates the etc/rc.d/start-server,default.groovy to put the permgen=128m default to a Java5 execution. > Configure default max heap and max permsize > --- > > Key: GERONIMO-4885 > URL: https://issues.apache.org/jira/browse/GERONIMO-4885 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.2 >Reporter: Kevan Miller > Fix For: 2.2 > > Attachments: default-memory-options.patch > > > It seems that the amount of PermGen space being used by Geronimo 2.2. I think > users are more likely to run into OutOfMemoryErrors as a result. Even on > small to medium size apps. Setting a default max heap and max perm size > should help avoid this... > Looks like a 2.2 server is using the following: > 50 MB heap > 80 MB PermGen > I'd suggest setting the max for both options to 128M. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4885) Configure default max heap and max permsize
[ https://issues.apache.org/jira/browse/GERONIMO-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4885: - Attachment: (was: default-memory-options.patch) > Configure default max heap and max permsize > --- > > Key: GERONIMO-4885 > URL: https://issues.apache.org/jira/browse/GERONIMO-4885 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.2 >Reporter: Kevan Miller > Fix For: 2.2 > > > It seems that the amount of PermGen space being used by Geronimo 2.2. I think > users are more likely to run into OutOfMemoryErrors as a result. Even on > small to medium size apps. Setting a default max heap and max perm size > should help avoid this... > Looks like a 2.2 server is using the following: > 50 MB heap > 80 MB PermGen > I'd suggest setting the max for both options to 128M. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4885) Configure default max heap and max permsize
[ https://issues.apache.org/jira/browse/GERONIMO-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4885: - Attachment: default-memory-options.patch The patch is for both the geronimo.bat and geronimo.sh and sets JAVA_OPTS="-Xmx128m -XX:MaxPermSize=128m" if JAVA_OPTS is empty/unset. Does so after setJavaEnv.bat and setjavaenv.sh has been callled (respectively). > Configure default max heap and max permsize > --- > > Key: GERONIMO-4885 > URL: https://issues.apache.org/jira/browse/GERONIMO-4885 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.2 >Reporter: Kevan Miller > Fix For: 2.2 > > Attachments: default-memory-options.patch > > > It seems that the amount of PermGen space being used by Geronimo 2.2. I think > users are more likely to run into OutOfMemoryErrors as a result. Even on > small to medium size apps. Setting a default max heap and max perm size > should help avoid this... > Looks like a 2.2 server is using the following: > 50 MB heap > 80 MB PermGen > I'd suggest setting the max for both options to 128M. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4871) Something blocking 'kill -3' signals?
[ https://issues.apache.org/jira/browse/GERONIMO-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765170#action_12765170 ] Quintin Beukes commented on GERONIMO-4871: -- Works for me on Ubuntu 8.04 with Java6 as well (also started with "sudo geronimo.sh start"). > Something blocking 'kill -3' signals? > - > > Key: GERONIMO-4871 > URL: https://issues.apache.org/jira/browse/GERONIMO-4871 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Kevan Miller > Fix For: 2.2 > > > I occasionally use 'kill -3' to cause a java process to dump all thread > stacks. For some reason, this isn't working on Geronimo 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4903) Jetty Advanced Integration Test Failure
[
https://issues.apache.org/jira/browse/GERONIMO-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4903:
-
Attachment: jetty-advanced-test-failure.patch
attached the patch to fix the issue
> Jetty Advanced Integration Test Failure
> ---
>
> Key: GERONIMO-4903
> URL: https://issues.apache.org/jira/browse/GERONIMO-4903
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: connector
>Reporter: Quintin Beukes
> Fix For: 2.2
>
> Attachments: jetty-advanced-test-failure.patch
>
>
> Hey,
> I found the cause of the test failure.
> In the file: {src
> root}/plugins/jetty7/geronimo-jetty7/./src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java
> Line: 289
> It reads: new String[]{"host", "port", "minThreads", "maxThreads",
> "bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
> "lingerMillis", "protocol", "redirectPort", "connectUrl",
> "maxIdleTimeMs"},
> Change to: new String[]{"host", "port", "minThreads", "maxThreads",
> "bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
> "lingerMillis", "redirectPort", "maxIdleTimeMs"},
> Basically removing the "protocol" and "connectUrl" attributes from the
> persistent interface attributes fixes the problem.
> "protocol" is static for Jetty BIO connector, so it doesn't need to be
> saved, or can't be specified.
> "connectUrl" is generated on the fly through getConnectUrl(), so can't
> be saved either.
> So unless my understanding of what persistentAttributes are is
> incorrect, this seems to be the correct solution? Please correct me if
> I'm wrong.
> What caused the problem is that the JettyConnector class doesn't have
> a setter for these attributes, so when XBean searches all the
> specified attributes' setters, it fails when it can't find these. This
> caused the test to fail, because the connector doesn't start again
> after being edited (enters the failed state).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4903) Jetty Advanced Integration Test Failure
Jetty Advanced Integration Test Failure
---
Key: GERONIMO-4903
URL: https://issues.apache.org/jira/browse/GERONIMO-4903
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: connector
Reporter: Quintin Beukes
Fix For: 2.2
Attachments: jetty-advanced-test-failure.patch
Hey,
I found the cause of the test failure.
In the file: {src
root}/plugins/jetty7/geronimo-jetty7/./src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java
Line: 289
It reads: new String[]{"host", "port", "minThreads", "maxThreads",
"bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
"lingerMillis", "protocol", "redirectPort", "connectUrl",
"maxIdleTimeMs"},
Change to: new String[]{"host", "port", "minThreads", "maxThreads",
"bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
"lingerMillis", "redirectPort", "maxIdleTimeMs"},
Basically removing the "protocol" and "connectUrl" attributes from the
persistent interface attributes fixes the problem.
"protocol" is static for Jetty BIO connector, so it doesn't need to be
saved, or can't be specified.
"connectUrl" is generated on the fly through getConnectUrl(), so can't
be saved either.
So unless my understanding of what persistentAttributes are is
incorrect, this seems to be the correct solution? Please correct me if
I'm wrong.
What caused the problem is that the JettyConnector class doesn't have
a setter for these attributes, so when XBean searches all the
specified attributes' setters, it fails when it can't find these. This
caused the test to fail, because the connector doesn't start again
after being edited (enters the failed state).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4861) Deployment Plan XML Parsing - Not add generated namespace names to closing tags
[
https://issues.apache.org/jira/browse/GERONIMO-4861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4861:
-
Regression: [Regression]
> Deployment Plan XML Parsing - Not add generated namespace names to closing
> tags
> ---
>
> Key: GERONIMO-4861
> URL: https://issues.apache.org/jira/browse/GERONIMO-4861
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: deployment
>Affects Versions: 2.2
>Reporter: Quintin Beukes
>Priority: Minor
>
> When creating a deployment plan and using more than one namespace, but not
> implicitly specifying the namespaces in all elements, the namespace names are
> added to the temporary XML file. Though it doesn't add them correctly. I
> included my original openejb-jar.xml, the error I get through deploy.sh, and
> the generated XML file (which I reformatted to make it more readable).
> You will notice the problem are in the last 2 closing tags of the ns7 (ie.
> security-2.0) namespace. The ns7 namespace prefix wasn't added to them, and
> this generates the validator error.
> {code:xml|title=original-openejb-jar.xml}
>
> http://openejb.apache.org/xml/ns/openejb-jar-2.2";
> xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
> xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0";
> xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";>
>
>
> kms
> KMSPlatform-ejb
> 1.0
> jar
>
>
>
> console.dbpool
> jdbc_kmsPool
> 1.0
> rar
>
>
> console.realm
> KMSRealm
> 1.0
> car
>
>
> org.springframework
> spring-core
> 2.5.6
> jar
>
>
> org.springframework
> spring-beans
> 2.5.6
> jar
>
>
> org.springframework
> spring-context
> 2.5.6
> jar
>
>
> org.slf4j
> slf4j-api
> 1.5.5
> jar
>
>
>
> hibernate
> core
> 3.3
> jar
>
>
> hibernate
> annotations
> 3.4
> jar
>
>
> hibernate
> antlr
> 2.7.6
> jar
>
>
> hibernate
> commons-annotations
> 3.4
> jar
>
>
> hibernate
> commons-collections
> 3.1
> jar
>
>
> hibernate
> dom4j
> 1.6.1
> jar
>
>
> hibernate
> entitymanager
> 3.4
> jar
>
>
> hibernate
> javassist
> 3.9.0.GA
> jar
>
>
> hibernate
> jpa
> 3.0
> jar
>
>
> hibernate
> jta
> 1.1
> jar
>
>
> hibernate
> GeronimoTransactionManager
> 1.0
> jar
>
>
>
>
>
>
> class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
> name="Admin"/>
>
>
> class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
> name="Standard User"/>
>
>
>
>
> {code}
> {code:title=Deployment Error}
> 2009-09-10 11:43:04,602 ERROR [DeployTool] Error:
> org.apache.geronimo.common.DeploymentException: Unable to deploy
> KMSPlatform-ejb.jar: Error parsing geronimo-openejb.xml with xmlbeans.
> For debug purposes, XML content written to:
> /opt/kms/server/geronimo-2.2-20090908/var/temp/openejb-jar-1373120338936693638.xml
> error: does not close tag .
> does not close tag .
> at
> org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(CommandDeploy.java:45)
> at
> org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:149)
> at
> org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:125)
> at
> org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:168)
> at
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
> at
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
> at
> org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
> {code}
> {code:xml|title=reformatted
> /opt/kms/server/geronimo-2.2-20090908/var/temp/openejb-jar-1373120338936693638.xml}
>
> http://geronimo.apache.org/xml/ns/deployment-1.2";
> xmlns:ns2="http://geronimo.apache.org/xml/ns
[jira] Created: (GERONIMO-4867) Compared to 2.1, 2.2 doesn't handle security realms created through the console the same
Compared to 2.1, 2.2 doesn't handle security realms created through the console the same Key: GERONIMO-4867 URL: https://issues.apache.org/jira/browse/GERONIMO-4867 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, security Affects Versions: 2.2 Reporter: Quintin Beukes Fix For: 2.2 In 2.1, when adding a security realm through the console, they were created as Global realms. So you could log in via OpenEJB remotely without problems. If you were to upgrade to 2.2, you can't continue doing this if you deploy the old realm file, because in 2.2 there is a "Global" parameter for a security realm which defaults to false. So "upgrading" to 2.2, means deploying the same application, and when doing this your application won't work if you use this functionality. You would get a "No LoginModules defined for realm XXX" exception, which means the realm isn't found. So this would create problems for people. I Suggest two options 1. If the global attribute is absent, default to "true" 2. When doing a remote login via OpenEJB, treat all realms as global. In other words a remote login as access to all realms. People upgrading will still get the same behaviour, and their old deploy plans will still allow their applications to work. This seems fine, because there isn't a way for you to define dependencies on a remote client anyway, so treating all realms as global seems fine. This might be considered bad practice, since the global attribute is meant to close of realms from other people. Not really sure what the philosophies are around this, so I can't say which is best. I would personally prefer the first option, as it allows one to still isolate realms. And if you find that a realm is global, which you wouldn't have wanted so, it's as easy as redeploying it to fix it. I definitely suggest that this be addressed before 2.2's release, as it will create bad first impressions. One should always provide for all scenarios to make the end user experience as comfortable as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4861) Deployment Plan XML Parsing - Not add generated namespace names to closing tags
Deployment Plan XML Parsing - Not add generated namespace names to closing tags
---
Key: GERONIMO-4861
URL: https://issues.apache.org/jira/browse/GERONIMO-4861
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: deployment
Affects Versions: 2.2
Reporter: Quintin Beukes
Priority: Minor
When creating a deployment plan and using more than one namespace, but not
implicitly specifying the namespaces in all elements, the namespace names are
added to the temporary XML file. Though it doesn't add them correctly. I
included my original openejb-jar.xml, the error I get through deploy.sh, and
the generated XML file (which I reformatted to make it more readable).
You will notice the problem are in the last 2 closing tags of the ns7 (ie.
security-2.0) namespace. The ns7 namespace prefix wasn't added to them, and
this generates the validator error.
{code:xml|title=original-openejb-jar.xml}
http://openejb.apache.org/xml/ns/openejb-jar-2.2";
xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0";
xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";>
kms
KMSPlatform-ejb
1.0
jar
console.dbpool
jdbc_kmsPool
1.0
rar
console.realm
KMSRealm
1.0
car
org.springframework
spring-core
2.5.6
jar
org.springframework
spring-beans
2.5.6
jar
org.springframework
spring-context
2.5.6
jar
org.slf4j
slf4j-api
1.5.5
jar
hibernate
core
3.3
jar
hibernate
annotations
3.4
jar
hibernate
antlr
2.7.6
jar
hibernate
commons-annotations
3.4
jar
hibernate
commons-collections
3.1
jar
hibernate
dom4j
1.6.1
jar
hibernate
entitymanager
3.4
jar
hibernate
javassist
3.9.0.GA
jar
hibernate
jpa
3.0
jar
hibernate
jta
1.1
jar
hibernate
GeronimoTransactionManager
1.0
jar
{code}
{code:title=Deployment Error}
2009-09-10 11:43:04,602 ERROR [DeployTool] Error:
org.apache.geronimo.common.DeploymentException: Unable to deploy
KMSPlatform-ejb.jar: Error parsing geronimo-openejb.xml with xmlbeans.
For debug purposes, XML content written to:
/opt/kms/server/geronimo-2.2-20090908/var/temp/openejb-jar-1373120338936693638.xml
error: does not close tag .
does not close tag .
at
org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(CommandDeploy.java:45)
at
org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:149)
at
org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:125)
at
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:168)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
{code}
{code:xml|title=reformatted
/opt/kms/server/geronimo-2.2-20090908/var/temp/openejb-jar-1373120338936693638.xml}
http://geronimo.apache.org/xml/ns/deployment-1.2";
xmlns:ns2="http://geronimo.apache.org/xml/ns/j2ee/application-1.2";
xmlns:ns3="http://geronimo.apache.org/xml/ns/openejb-clustering-wadi-1.2";
xmlns:ns4="http://geronimo.apache.org/xml/ns/naming-1.2";
xmlns:ns5="http://openejb.apache.org/xml/ns/openejb-jar-2.2";
xmlns:ns6="http://geronimo.apache.org/xml/ns/j2ee/ejb/openejb-2.0";
xmlns:ns7="http://geronimo.apache.org/xml/ns/security-2.0";
xmlns:ns8="http://java.sun.com/xml/ns/persistence";
xmlns:ns9="http://openejb.apache.org/xml/ns/pkgen-2.1";>
kms
KMSPlatform-ejb
1.0
jar
console.dbpool
jdbc_kmsPool
1.0
rar
console.realm
KMSRealm
1.0
car
org.springframework
spring-core
2.5.6
jar
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
[
https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4848:
-
Attachment: OpenejbRemoteLoginModule.java-2.2
login-retries-2.2.patch
Geronimo 2.2 doesn't use Commons Logging anymore, so this is the same
modification as above, except with the slf4j logger change applied.
>From 2.1.4 to 2.2 this file hasn't changed, so it should be fine to apply it.
Explanation:
OpenejbRemoteLoginModule.java-2.2 - a full .java for Geronimo 2.2
login-retries-2.2.patch - A patch to transform Geronimo 2.2's login module
adding the login-retries.
> Application Client Login Retries
>
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries-2.2.patch, login-retries.patch,
> OpenejbRemoteLoginModule.java, OpenejbRemoteLoginModule.java-2.2
>
>
> When an application client is configured to authenticate with a JAAS realm
> and a CallbackHandler, the login is performed before the application's main
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional
> extra "option", which can be specified in the gbean configuration, like so:
> ...
>
> remote-openejb-realm
>
> net.kunye.platform.security.auth.ApplicationClientLoginModule
> KMSRealm
> ejbd://localhost:4201
> 3
>
> ...
> - If you omit this option, it will default to the current behaviour of "1"
> try.
> - If you supply an invalid value for an option (any value that would raise a
> NumberFormatException when calling "Integer.parseInt()"), it will default to
> the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given
> amount of tries. If no successful authentication occurred during these tries
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a
> successful authentication or the user cancelled. The cancel is detected by
> setting either the NameCallback or PasswordCallback's value to null. This is
> quite unintuitive and might make it more difficult to find bugs in your code
> where the values are unintentionally null, so an alternative way might be
> better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a
> single TextOutputCallback which contains an INFORMATION type message "Login
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single
> TextOutputCallback which contains an ERROR type message "Login failed for
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the
> application client is to have more direct access to the CallbackHandler, so
> as to send the "Login Failed" and "Login canceled" messages. Also the fact
> that certain types of login modules might be used which don't support the
> "concept" of a retry, like host based authentication modules. So doing
> retries in the application client layer didn't seem logical. This way you can
> also extend the class or build your own and ship it with your application,
> and so be able to customize the retry behaviour, instead of relying on a
> fixed retry strategy in the application client layer (which could only be
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4860) WebManagerPortlet doesn't complete remove a connector - leads to inability to start server
[
https://issues.apache.org/jira/browse/GERONIMO-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4860:
-
Description:
When removing a connector, it removes the connector from tomcat's server.xml,
but not the GBean from config.xml, so when stopping and again start the server,
the server fails to start with:
{code:title=geronimo.log}2009-09-10 10:45:28,076 ERROR [GBeanInstanceState]
Error while starting; GBean is now in the FAILED state:
abstractName="org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car"
org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans must be
specified with a GBeanInfo
configuration=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car
gbeanName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car,j2eeType=GBean,name=testConnector1
at
org.apache.geronimo.system.configuration.LocalAttributeManager.applyOverrides(LocalAttributeManager.java:185)
at
org.apache.geronimo.kernel.config.Configuration.(Configuration.java:297)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:910)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:524)
at
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:359)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:163)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:302)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815)
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$$55935236.loadConfiguration()
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:158)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30){code}
Config.xml still contains:
{code:xml|title=config.xml}
4096
0
8443
ISO-8859-1
false
false
false
0.0.0.0
2048
text/html,text/xml,text/plain
off
-1
6
6
true
4096
100
40
10
100
802
null
9000
true
5
{code}
was:
When removing a connector, it removes the connector from tomcat's server.xml,
but not the GBean from config.xml, so when stopping and again start the server,
the server fails to start with:
{code:title=geronim
[jira] Updated: (GERONIMO-4860) WebManagerPortlet doesn't complete remove a connector - leads to inability to start server
[
https://issues.apache.org/jira/browse/GERONIMO-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4860:
-
Description:
When removing a connector, it removes the connector from tomcat's server.xml,
but not the GBean from config.xml, so when stopping and again start the server,
the server fails to start with:
{code:title=geronimo.log}2009-09-10 10:45:28,076 ERROR [GBeanInstanceState]
Error while starting; GBean is now in the FAILED state:
abstractName="org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car"
org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans must be
specified with a GBeanInfo
configuration=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car
gbeanName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car,j2eeType=GBean,name=testConnector1
at
org.apache.geronimo.system.configuration.LocalAttributeManager.applyOverrides(LocalAttributeManager.java:185)
at
org.apache.geronimo.kernel.config.Configuration.(Configuration.java:297)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:910)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:524)
at
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:359)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:163)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:302)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815)
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$$55935236.loadConfiguration()
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:158)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30){code}
Config.xml still contains:
{code:xml}
4096
0
8443
ISO-8859-1
false
false
false
0.0.0.0
2048
text/html,text/xml,text/plain
off
-1
6
6
true
4096
100
40
10
100
802
null
9000
true
5
{code}
was:
When removing a connector, it removes the connector from tomcat's server.xml,
but not the GBean from config.xml, so when stopping and again start the server,
the server fails to start with:
{{2009-09-10 10:45:28,076 ERROR [GBeanInstanceS
[jira] Updated: (GERONIMO-4860) WebManagerPortlet doesn't complete remove a connector - leads to inability to start server
[
https://issues.apache.org/jira/browse/GERONIMO-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4860:
-
Description:
When removing a connector, it removes the connector from tomcat's server.xml,
but not the GBean from config.xml, so when stopping and again start the server,
the server fails to start with:
{{2009-09-10 10:45:28,076 ERROR [GBeanInstanceState] Error while starting;
GBean is now in the FAILED state:
abstractName="org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car"
org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans must be
specified with a GBeanInfo
configuration=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car
gbeanName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car,j2eeType=GBean,name=testConnector1
at
org.apache.geronimo.system.configuration.LocalAttributeManager.applyOverrides(LocalAttributeManager.java:185)
at
org.apache.geronimo.kernel.config.Configuration.(Configuration.java:297)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:910)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:524)
at
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:359)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:163)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:302)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815)
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$$55935236.loadConfiguration()
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:158)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)}}
Config.xml still contains:
{{
4096
0
8443
ISO-8859-1
false
false
false
0.0.0.0
2048
text/html,text/xml,text/plain
off
-1
6
6
true
4096
100
40
10
100
802
null
9000
true
5
}}
was:
When removing a connector, it removes the connector from tomcat's server.xml,
but not the GBean from config.xml, so when stopping and again start the server,
the server fails to start with:
2009-09-10 10:45:28,076 ERROR [GBeanInstanceState] Error while starting; GBean
is now
[jira] Created: (GERONIMO-4860) WebManagerPortlet doesn't complete remove a connector - leads to inability to start server
WebManagerPortlet doesn't complete remove a connector - leads to inability to start server -- Key: GERONIMO-4860 URL: https://issues.apache.org/jira/browse/GERONIMO-4860 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector, console Affects Versions: 2.2 Reporter: Quintin Beukes Fix For: 2.2 When removing a connector, it removes the connector from tomcat's server.xml, but not the GBean from config.xml, so when stopping and again start the server, the server fails to start with: 2009-09-10 10:45:28,076 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName="org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car" org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans must be specified with a GBeanInfo configuration=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car gbeanName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car,j2eeType=GBean,name=testConnector1 at org.apache.geronimo.system.configuration.LocalAttributeManager.applyOverrides(LocalAttributeManager.java:185) at org.apache.geronimo.kernel.config.Configuration.(Configuration.java:297) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952) at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:910) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:524) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:359) at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:163) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:302) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271) at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815) 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$$55935236.loadConfiguration() at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:158) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30) Config.xml still contains: 4096 0 8443 ISO-8859-1 false false false 0.0.0.0 2048 text/html,text/xml,text/plain off -1 6 6 true 4096 100 40 10 100 802 null 9000 true 5
[jira] Commented: (GERONIMO-4852) Fail to connect to a new created Tomcat BIO HTTPS Connector network listener
[ https://issues.apache.org/jira/browse/GERONIMO-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753101#action_12753101 ] Quintin Beukes commented on GERONIMO-4852: -- Was there perhaps a restart in between where it worked and where it doesn't? See if you are able to connect to port 8443. This could be related to but: https://issues.apache.org/jira/browse/GERONIMO-4852 > Fail to connect to a new created Tomcat BIO HTTPS Connector network listener > > > Key: GERONIMO-4852 > URL: https://issues.apache.org/jira/browse/GERONIMO-4852 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 2.2 > Environment: winxp sp3, jdk 1.6 >Reporter: Shiny Cheng > Fix For: 2.2 > > > When I created a new Tomcat BIO HTTPS Connector network listener, I set > keystoreFile as ../security/keystores/geronimo-default, port as 8444 (also > tried other ones not equal to 8443), algorithm as Default, keystorePass as > secret. > Following these settings, I successed once, i.e. I can smoothly connect to > the port. However, other times, I always failed to connect to the listener. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4858) Geronimo 2.2 doesn't ad
Geronimo 2.2 doesn't ad --- Key: GERONIMO-4858 URL: https://issues.apache.org/jira/browse/GERONIMO-4858 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector, console Affects Versions: 2.2, 3.0 Reporter: Quintin Beukes Priority: Critical Fix For: 2.2 OK. So I extract the 2009-09-08 nightly snapshot (tomcat binary), and deploy some repository JARs, a datasource and a security realm. Then I goto Web Server portlet and create a new Tomcat BIO connector. I enter a name, and for port I enter 80. This is a rough of the steps I took from a clean install. So the bug is that when you add a connector, it immediately starts it on the correct port (as can be seen with netstat), but it saves to var/catalina/server.xml with port 8080. So once you restart the server you receive a port conflict if you have another 8080, and if you don't it would be like you never made the change, with your connector reverting to 8080. Here is a snippet of what it saves after adding a port "801" BIO connector: Q -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
[
https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4848:
-
Description:
When an application client is configured to authenticate with a JAAS realm and
a CallbackHandler, the login is performed before the application's main method
is called, thus outside the context of the client application itself.
This all works, except a failed login isn't retried and there is no way for the
application to even detect this (nor a cancel if such an option existed).
The attached patch is a modification of
org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
- It introduces a login retry facility. It does so by supplying an optional
extra "option", which can be specified in the gbean configuration, like so:
...
remote-openejb-realm
net.kunye.platform.security.auth.ApplicationClientLoginModule
KMSRealm
ejbd://localhost:4201
3
...
- If you omit this option, it will default to the current behaviour of "1" try.
- If you supply an invalid value for an option (any value that would raise a
NumberFormatException when calling "Integer.parseInt()"), it will default to
the current behaviour of "1" try.
- If you specify an integer great or equal to 0, it will perform the given
amount of tries. If no successful authentication occurred during these tries it
will fail with the FailedLoginException (as it does currently).
- If you specify 0 login tries, then it will keep trying until either a
successful authentication or the user cancelled. The cancel is detected by
setting either the NameCallback or PasswordCallback's value to null. This is
quite unintuitive and might make it more difficult to find bugs in your code
where the values are unintentionally null, so an alternative way might be
better.
Note: The "cancel" check works for all logins, including the first try.
- Further, if a "cancel" is detected, the callback handler is invoked with a
single TextOutputCallback which contains an INFORMATION type message "Login
cancelled by user.".
- If authentication failed, the callback handler is invoked with a single
TextOutputCallback which contains an ERROR type message "Login failed for user:
${USER}", where USER is the username of the last NameCallback.
The justification of implementing this in the LoginModule and not the
application client is to have more direct access to the CallbackHandler, so as
to send the "Login Failed" and "Login canceled" messages. Also the fact that
certain types of login modules might be used which don't support the "concept"
of a retry, like host based authentication modules. So doing retries in the
application client layer didn't seem logical. This way you can also extend the
class or build your own and ship it with your application, and so be able to
customize the retry behaviour, instead of relying on a fixed retry strategy in
the application client layer (which could only be changed by recompiling the
plugin).
Any suggestions/requests, just let me know and I'll implement them.
was:
When an application client is configured to authenticate with a JAAS realm and
a CallbackHandler, the login is performed before the application's main method
is called, thus outside the context of the client application itself.
This all works, except a failed login isn't retried and there is no way for the
application to even detect this (nor a cancel if such an option existed).
The attached patch is a modification of
org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
- It introduces a login retry facility. It does so by supplying an optional
extra "option", which can be specified in the gbean configuration, like so:
...
remote-openejb-realm
net.kunye.platform.security.auth.ApplicationClientLoginModule
KMSRealm
ejbd://localhost:4201
3
...
- If you omit this option, it will default to the current behaviour of "1" try.
- If you specify an integer great or equal to 0, it will perform the given
amount of tries. If no successful authentication occurred during these tries it
will fail with the FailedLoginException (as it does currently).
- If you specify 0 login tries, then it will keep trying until either a
successful authentication or the user cancelled. The cancel is detected by
setting either the NameCallback or PasswordCallback's value to null. This is
quite unintuitive and might make it more difficult to find bugs in your code
where the values are unintentionally null, so an alternative way might be
better.
Note: The "cancel" check works for all logins, including the first try.
- Further, if a "cancel" is detected, the callback handler is invoked with a
single TextOutputCallback which contains an INFORMATION type message "Login
cancelled by user.".
- If authentication failed
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
[
https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4848:
-
Comment: was deleted
(was: Patch for the new login module, as well as the complete class for those
who wish to view it without having to first apply the patch.)
> Application Client Login Retries
>
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm
> and a CallbackHandler, the login is performed before the application's main
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional
> extra "option", which can be specified in the gbean configuration, like so:
> ...
>
> remote-openejb-realm
>
> net.kunye.platform.security.auth.ApplicationClientLoginModule
> KMSRealm
> ejbd://localhost:4201
> 3
>
> ...
> - If you omit this option, it will default to the current behaviour of "1"
> try.
> - If you specify an integer great or equal to 0, it will perform the given
> amount of tries. If no successful authentication occurred during these tries
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a
> successful authentication or the user cancelled. The cancel is detected by
> setting either the NameCallback or PasswordCallback's value to null. This is
> quite unintuitive and might make it more difficult to find bugs in your code
> where the values are unintentionally null, so an alternative way might be
> better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a
> single TextOutputCallback which contains an INFORMATION type message "Login
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single
> TextOutputCallback which contains an ERROR type message "Login failed for
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the
> application client is to have more direct access to the CallbackHandler, so
> as to send the "Login Failed" and "Login canceled" messages. Also the fact
> that certain types of login modules might be used which don't support the
> "concept" of a retry, like host based authentication modules. So doing
> retries in the application client layer didn't seem logical. This way you can
> also extend the class or build your own and ship it with your application,
> and so be able to customize the retry behaviour, instead of relying on a
> fixed retry strategy in the application client layer (which could only be
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
[
https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4848:
-
Attachment: login-retries.patch
OpenejbRemoteLoginModule.java
Patch as described in the issue's description as well as the full class to read
the code without having to patch an older version.
> Application Client Login Retries
>
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm
> and a CallbackHandler, the login is performed before the application's main
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional
> extra "option", which can be specified in the gbean configuration, like so:
> ...
>
> remote-openejb-realm
>
> net.kunye.platform.security.auth.ApplicationClientLoginModule
> KMSRealm
> ejbd://localhost:4201
> 3
>
> ...
> - If you omit this option, it will default to the current behaviour of "1"
> try.
> - If you specify an integer great or equal to 0, it will perform the given
> amount of tries. If no successful authentication occurred during these tries
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a
> successful authentication or the user cancelled. The cancel is detected by
> setting either the NameCallback or PasswordCallback's value to null. This is
> quite unintuitive and might make it more difficult to find bugs in your code
> where the values are unintentionally null, so an alternative way might be
> better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a
> single TextOutputCallback which contains an INFORMATION type message "Login
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single
> TextOutputCallback which contains an ERROR type message "Login failed for
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the
> application client is to have more direct access to the CallbackHandler, so
> as to send the "Login Failed" and "Login canceled" messages. Also the fact
> that certain types of login modules might be used which don't support the
> "concept" of a retry, like host based authentication modules. So doing
> retries in the application client layer didn't seem logical. This way you can
> also extend the class or build your own and ship it with your application,
> and so be able to customize the retry behaviour, instead of relying on a
> fixed retry strategy in the application client layer (which could only be
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-4848) Application Client Login Retries
[
https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751590#action_12751590
]
Quintin Beukes edited comment on GERONIMO-4848 at 9/4/09 12:47 PM:
---
I named the option "FailedLoginTries". It was actually renamed from
"FailedLoginRetries", but after I changed it's purpose, I changed to "Tries",
but didn't realize that the name is deceiving.
I changed the option to "LoginAttempts", so the attached patch and class will
use "LoginAttempts" instead.
was (Author: quin...@last.za.net):
I named the option "FailedLoginTries". It was actually renamed from
"FailedLoginRetries", but after I changed it's purpose, I changed to "Tries",
but didn't realize that the name is deceiving.
A better name might be "LoginAttempts".
> Application Client Login Retries
>
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm
> and a CallbackHandler, the login is performed before the application's main
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional
> extra "option", which can be specified in the gbean configuration, like so:
> ...
>
> remote-openejb-realm
>
> net.kunye.platform.security.auth.ApplicationClientLoginModule
> KMSRealm
> ejbd://localhost:4201
> 3
>
> ...
> - If you omit this option, it will default to the current behaviour of "1"
> try.
> - If you specify an integer great or equal to 0, it will perform the given
> amount of tries. If no successful authentication occurred during these tries
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a
> successful authentication or the user cancelled. The cancel is detected by
> setting either the NameCallback or PasswordCallback's value to null. This is
> quite unintuitive and might make it more difficult to find bugs in your code
> where the values are unintentionally null, so an alternative way might be
> better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a
> single TextOutputCallback which contains an INFORMATION type message "Login
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single
> TextOutputCallback which contains an ERROR type message "Login failed for
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the
> application client is to have more direct access to the CallbackHandler, so
> as to send the "Login Failed" and "Login canceled" messages. Also the fact
> that certain types of login modules might be used which don't support the
> "concept" of a retry, like host based authentication modules. So doing
> retries in the application client layer didn't seem logical. This way you can
> also extend the class or build your own and ship it with your application,
> and so be able to customize the retry behaviour, instead of relying on a
> fixed retry strategy in the application client layer (which could only be
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
[
https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4848:
-
Attachment: (was: OpenejbRemoteLoginModule.java)
> Application Client Login Retries
>
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
>
> When an application client is configured to authenticate with a JAAS realm
> and a CallbackHandler, the login is performed before the application's main
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional
> extra "option", which can be specified in the gbean configuration, like so:
> ...
>
> remote-openejb-realm
>
> net.kunye.platform.security.auth.ApplicationClientLoginModule
> KMSRealm
> ejbd://localhost:4201
> 3
>
> ...
> - If you omit this option, it will default to the current behaviour of "1"
> try.
> - If you specify an integer great or equal to 0, it will perform the given
> amount of tries. If no successful authentication occurred during these tries
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a
> successful authentication or the user cancelled. The cancel is detected by
> setting either the NameCallback or PasswordCallback's value to null. This is
> quite unintuitive and might make it more difficult to find bugs in your code
> where the values are unintentionally null, so an alternative way might be
> better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a
> single TextOutputCallback which contains an INFORMATION type message "Login
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single
> TextOutputCallback which contains an ERROR type message "Login failed for
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the
> application client is to have more direct access to the CallbackHandler, so
> as to send the "Login Failed" and "Login canceled" messages. Also the fact
> that certain types of login modules might be used which don't support the
> "concept" of a retry, like host based authentication modules. So doing
> retries in the application client layer didn't seem logical. This way you can
> also extend the class or build your own and ship it with your application,
> and so be able to customize the retry behaviour, instead of relying on a
> fixed retry strategy in the application client layer (which could only be
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
[
https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4848:
-
Attachment: (was: login-retries.patch)
> Application Client Login Retries
>
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
>
> When an application client is configured to authenticate with a JAAS realm
> and a CallbackHandler, the login is performed before the application's main
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional
> extra "option", which can be specified in the gbean configuration, like so:
> ...
>
> remote-openejb-realm
>
> net.kunye.platform.security.auth.ApplicationClientLoginModule
> KMSRealm
> ejbd://localhost:4201
> 3
>
> ...
> - If you omit this option, it will default to the current behaviour of "1"
> try.
> - If you specify an integer great or equal to 0, it will perform the given
> amount of tries. If no successful authentication occurred during these tries
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a
> successful authentication or the user cancelled. The cancel is detected by
> setting either the NameCallback or PasswordCallback's value to null. This is
> quite unintuitive and might make it more difficult to find bugs in your code
> where the values are unintentionally null, so an alternative way might be
> better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a
> single TextOutputCallback which contains an INFORMATION type message "Login
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single
> TextOutputCallback which contains an ERROR type message "Login failed for
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the
> application client is to have more direct access to the CallbackHandler, so
> as to send the "Login Failed" and "Login canceled" messages. Also the fact
> that certain types of login modules might be used which don't support the
> "concept" of a retry, like host based authentication modules. So doing
> retries in the application client layer didn't seem logical. This way you can
> also extend the class or build your own and ship it with your application,
> and so be able to customize the retry behaviour, instead of relying on a
> fixed retry strategy in the application client layer (which could only be
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4848) Application Client Login Retries
[
https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751590#action_12751590
]
Quintin Beukes commented on GERONIMO-4848:
--
I named the option "FailedLoginTries". It was actually renamed from
"FailedLoginRetries", but after I changed it's purpose, I changed to "Tries",
but didn't realize that the name is deceiving.
A better name might be "LoginAttempts".
> Application Client Login Retries
>
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm
> and a CallbackHandler, the login is performed before the application's main
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional
> extra "option", which can be specified in the gbean configuration, like so:
> ...
>
> remote-openejb-realm
>
> net.kunye.platform.security.auth.ApplicationClientLoginModule
> KMSRealm
> ejbd://localhost:4201
> 3
>
> ...
> - If you omit this option, it will default to the current behaviour of "1"
> try.
> - If you specify an integer great or equal to 0, it will perform the given
> amount of tries. If no successful authentication occurred during these tries
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a
> successful authentication or the user cancelled. The cancel is detected by
> setting either the NameCallback or PasswordCallback's value to null. This is
> quite unintuitive and might make it more difficult to find bugs in your code
> where the values are unintentionally null, so an alternative way might be
> better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a
> single TextOutputCallback which contains an INFORMATION type message "Login
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single
> TextOutputCallback which contains an ERROR type message "Login failed for
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the
> application client is to have more direct access to the CallbackHandler, so
> as to send the "Login Failed" and "Login canceled" messages. Also the fact
> that certain types of login modules might be used which don't support the
> "concept" of a retry, like host based authentication modules. So doing
> retries in the application client layer didn't seem logical. This way you can
> also extend the class or build your own and ship it with your application,
> and so be able to customize the retry behaviour, instead of relying on a
> fixed retry strategy in the application client layer (which could only be
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4848) Application Client Login Retries
[
https://issues.apache.org/jira/browse/GERONIMO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quintin Beukes updated GERONIMO-4848:
-
Attachment: OpenejbRemoteLoginModule.java
login-retries.patch
Patch for the new login module, as well as the complete class for those who
wish to view it without having to first apply the patch.
> Application Client Login Retries
>
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm
> and a CallbackHandler, the login is performed before the application's main
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional
> extra "option", which can be specified in the gbean configuration, like so:
> ...
>
> remote-openejb-realm
>
> net.kunye.platform.security.auth.ApplicationClientLoginModule
> KMSRealm
> ejbd://localhost:4201
> 3
>
> ...
> - If you omit this option, it will default to the current behaviour of "1"
> try.
> - If you specify an integer great or equal to 0, it will perform the given
> amount of tries. If no successful authentication occurred during these tries
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a
> successful authentication or the user cancelled. The cancel is detected by
> setting either the NameCallback or PasswordCallback's value to null. This is
> quite unintuitive and might make it more difficult to find bugs in your code
> where the values are unintentionally null, so an alternative way might be
> better.
> Note: The "cancel" check works for all logins, including the first try.
> - Further, if a "cancel" is detected, the callback handler is invoked with a
> single TextOutputCallback which contains an INFORMATION type message "Login
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single
> TextOutputCallback which contains an ERROR type message "Login failed for
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the
> application client is to have more direct access to the CallbackHandler, so
> as to send the "Login Failed" and "Login canceled" messages. Also the fact
> that certain types of login modules might be used which don't support the
> "concept" of a retry, like host based authentication modules. So doing
> retries in the application client layer didn't seem logical. This way you can
> also extend the class or build your own and ship it with your application,
> and so be able to customize the retry behaviour, instead of relying on a
> fixed retry strategy in the application client layer (which could only be
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4848) Application Client Login Retries
Application Client Login Retries
Key: GERONIMO-4848
URL: https://issues.apache.org/jira/browse/GERONIMO-4848
Project: Geronimo
Issue Type: New Feature
Security Level: public (Regular issues)
Components: application client, security
Affects Versions: 2.1.4
Reporter: Quintin Beukes
Priority: Minor
When an application client is configured to authenticate with a JAAS realm and
a CallbackHandler, the login is performed before the application's main method
is called, thus outside the context of the client application itself.
This all works, except a failed login isn't retried and there is no way for the
application to even detect this (nor a cancel if such an option existed).
The attached patch is a modification of
org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
- It introduces a login retry facility. It does so by supplying an optional
extra "option", which can be specified in the gbean configuration, like so:
...
remote-openejb-realm
net.kunye.platform.security.auth.ApplicationClientLoginModule
KMSRealm
ejbd://localhost:4201
3
...
- If you omit this option, it will default to the current behaviour of "1" try.
- If you specify an integer great or equal to 0, it will perform the given
amount of tries. If no successful authentication occurred during these tries it
will fail with the FailedLoginException (as it does currently).
- If you specify 0 login tries, then it will keep trying until either a
successful authentication or the user cancelled. The cancel is detected by
setting either the NameCallback or PasswordCallback's value to null. This is
quite unintuitive and might make it more difficult to find bugs in your code
where the values are unintentionally null, so an alternative way might be
better.
Note: The "cancel" check works for all logins, including the first try.
- Further, if a "cancel" is detected, the callback handler is invoked with a
single TextOutputCallback which contains an INFORMATION type message "Login
cancelled by user.".
- If authentication failed, the callback handler is invoked with a single
TextOutputCallback which contains an ERROR type message "Login failed for user:
${USER}", where USER is the username of the last NameCallback.
The justification of implementing this in the LoginModule and not the
application client is to have more direct access to the CallbackHandler, so as
to send the "Login Failed" and "Login canceled" messages. Also the fact that
certain types of login modules might be used which don't support the "concept"
of a retry, like host based authentication modules. So doing retries in the
application client layer didn't seem logical. This way you can also extend the
class or build your own and ship it with your application, and so be able to
customize the retry behaviour, instead of relying on a fixed retry strategy in
the application client layer (which could only be changed by recompiling the
plugin).
Any suggestions/requests, just let me know and I'll implement them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4847) HTTP 500 error from exception when adding a repository resource which already exists
[ https://issues.apache.org/jira/browse/GERONIMO-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4847: - Description: Adding a repository resource which already exists gives an HTTP 500 (from exception) error. It should instead prompt to override or show a friendlier message. An example stack trace is: java.lang.IllegalArgumentException: Destination /opt/kms/server/geronimo-2.1.4/repository/kms/GeronimoLoginModule/1.0/GeronimoLoginModule-1.0.jar already exists! org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:213) org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:189) org.apache.geronimo.console.repository.RepositoryViewPortlet.processAction(RepositoryViewPortlet.java:169) org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:167) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:125) was: Adding a resource which already exists gives an HTTP 500 (from exception) error. It should instead prompt to override or show a friendlier message. An example stack trace is: java.lang.IllegalArgumentException: Destination /opt/kms/server/geronimo-2.1.4/repository/kms/GeronimoLoginModule/1.0/GeronimoLoginModule-1.0.jar already exists! org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:213) org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:189) org.apache.geronimo.console.repository.RepositoryViewPortlet.processAction(RepositoryViewPortlet.java:169) org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:167) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:125) Summary: HTTP 500 error from exception when adding a repository resource which already exists (was: HTTP 500 error from exception when adding a resource which already exists) > HTTP 500 error from exception when adding a repository resource which already > exists > > > Key: GERONIMO-4847 > URL: https://issues.apache.org/jira/browse/GERONIMO-4847 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.4 >Reporter: Quintin Beukes > > Adding a repository resource which already exists gives an HTTP 500 (from > exception) error. It should instead prompt to override or show a friendlier > message. > An example stack trace is: > java.lang.IllegalArgumentException: Destination > /opt/kms/server/geronimo-2.1.4/repository/kms/GeronimoLoginModule/1.0/GeronimoLoginModule-1.0.jar > already exists! > > org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:213) > > org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:189) > > org.apache.geronimo.console.repository.RepositoryViewPortlet.processAction(RepositoryView
[jira] Created: (GERONIMO-4847) HTTP 500 error from exception when adding a resource which already exists
HTTP 500 error from exception when adding a resource which already exists - Key: GERONIMO-4847 URL: https://issues.apache.org/jira/browse/GERONIMO-4847 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1.4 Reporter: Quintin Beukes Adding a resource which already exists gives an HTTP 500 (from exception) error. It should instead prompt to override or show a friendlier message. An example stack trace is: java.lang.IllegalArgumentException: Destination /opt/kms/server/geronimo-2.1.4/repository/kms/GeronimoLoginModule/1.0/GeronimoLoginModule-1.0.jar already exists! org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:213) org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:189) org.apache.geronimo.console.repository.RepositoryViewPortlet.processAction(RepositoryViewPortlet.java:169) org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:167) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:125) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
