[jira] Created: (GERONIMO-3648) Keystores portlet should provide for changing keystore and key passwords
Keystores portlet should provide for changing keystore and key passwords Key: GERONIMO-3648 URL: https://issues.apache.org/jira/browse/GERONIMO-3648 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, management, security Affects Versions: 2.0.2, 2.0.1, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Currently it is not possible to change either a keystore password or a key password in Geronimo. Keystores portlet should provide a way to change these passwords. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
GShell 1.0-alpha-1 update
Folks, I've halted any significant changes to GShell so we can push out a stable release for Geronimo to consume in the next week or so. Right now it is pending some dependency releases: * plexus-cdc-anno * plexus-component-annotations * maven-remote-resources-plugin * groovy-maven-plugin * cobertura-maven-plugin I've got the ball rolling on each of those and with a wee bit of luck and probably a healthy dose of pestering folks, we should get all of these resolved to facilitate the first *official* GShell release... yay! I'm hoping to get GShell 1.0-alpha-1 out in the next week or so, really as soon as the deps are published I will start the ball moving. I could use a little help in the mean time for things like legal oversight and anything else I might have missed to help make the vote+release as smooth as possible, So if you have a few minutes spare it would be nice if you could build the tree and poke around a bit er something. Should be as easy as: svn co https://svn.apache.org/repos/asf/geronimo/gshell/trunk gshell cd gshell mvn install and to test the shell, something like: gunzip -c ./gshell-assembly/target/gshell-*-bin.tar.gz | tar xf - ./gshell-*/bin/gsh (and then just make sure that the 'help' command and 'exit' work should be sufficient probs). If ya find anything please file blocker issues for 1.1-alpha-1 here: * https://issues.apache.org/jira/browse/GSHELL And I'll get it sorted out ASAP * * * I've got a lot of plans to improve the plugability (and extensibility) of the shell as well as tidy up some of the GShell (BASH-like) syntax, get the remote shell muck stable and get some scripting examples up and running too... but I have to get this release out first before I can continue as those are relatively destabilizing changes. Lastly, a wee shout out to folks that have been in active with da'shell... * David Jencks - Your insight is, IMO, invaluable... and I really appreciate you taking to time to poke around and enjoy the bliss which is GShell :-P * Jason Warner - I really appreciate the extra pair of eyes (well, and patches too), don't be afraid to laid down some pimp ideas or rants, whatever, I don't bite, no matter what you might have heard :-P And... well, to the rest of you too. GShell has been a dream I've had er since back in the dark days, and its really starting to becoming something useful. So thanks for giving my vision a shot to thrive (and well, ya know... kick ass) :-) Aight, more to come later... Cheers, --jason
Re: Administering geronimo remotely
On Nov 28, 2007, at 5:50 PM, Anita Kulshreshtha wrote: I am trying to administer a geronimo instance remotely using admin console. I can install jars to remote g instance using Repository link, i.e. the jar files from local file system get installed in remote g repo as expected. I tried a car and was able to install it too! I'm not entirely clear what you are saying here did you use the plugins page install the car file or the add a jar to the repo page? I wouldn't expect the plugin page to work without additional infrastructure running, see below. This car (a J2EE Connector) showed up in stopped state, so I started it (using 'start' link on remote console). This caused a lifecycle operation failed ... org.apache.geronimo.kernel.config.NoSuchConfigException: error. Is this the expected behavior? if I select the local .m2 repo as plugin repository in plugins portlet, should I expect the selected plugin to be installed at the remote instance using jars/cars from the local files system? In order for this to work you'd need to have the local .m2 repository available on a web server to the remote machine and I think the plugins would generally have to say they are available from this web server in the geronimo-plugin.xml file. hope this helps... david jencks Thanks Anita __ __ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: GShell 1.0-alpha-1 update
On Nov 29, 2007 9:18 AM, Jason Dillon [EMAIL PROTECTED] wrote: gunzip -c ./gshell-assembly/target/gshell-*-bin.tar.gz | tar xf - I think you meant gunzip -c ./gshell-assembly/target/gshell-*-full.tar.gz | tar xf - The help and exit commands worked fine. The help command took a wee longer than I'd expected (almost 10 seconds) whereas the second time it only took a sec. Why is that? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: GShell 1.0-alpha-1 update
On Nov 29, 2007, at 12:58 AM, Jacek Laskowski wrote: On Nov 29, 2007 9:18 AM, Jason Dillon [EMAIL PROTECTED] wrote: gunzip -c ./gshell-assembly/target/gshell-*-bin.tar.gz | tar xf - I think you meant gunzip -c ./gshell-assembly/target/gshell-*-full.tar.gz | tar xf - Yup, I forgot I renamed the assembly... The help and exit commands worked fine. The help command took a wee longer than I'd expected (almost 10 seconds) whereas the second time it only took a sec. Why is that? 10 seconds? Hrm... thats odd. It returns right away for me :-\ Can you reproduce it? --jason
Re: Administering geronimo remotely
On Nov 29, 2007 2:24 PM, David Jencks [EMAIL PROTECTED] wrote: On Nov 28, 2007, at 5:50 PM, Anita Kulshreshtha wrote: I am trying to administer a geronimo instance remotely using admin console. I can install jars to remote g instance using Repository link, i.e. the jar files from local file system get installed in remote g repo as expected. I tried a car and was able to install it too! I'm not entirely clear what you are saying here did you use the plugins page install the car file or the add a jar to the repo page? If a car is added from Common Libs portlet, it should not show up as a configuration. But, this is a different problem. I wouldn't expect the plugin page to work without additional infrastructure running, see below. This car (a J2EE Connector) showed up in stopped state, so I started it (using 'start' link on remote console). This caused a lifecycle operation failed ... org.apache.geronimo.kernel.config.NoSuchConfigException: error. Is this the expected behavior? if I select the local .m2 repo as plugin repository in plugins portlet, should I expect the selected plugin to be installed at the remote instance using jars/cars from the local files system? In order for this to work you'd need to have the local .m2 repository available on a web server to the remote machine and I think the plugins would generally have to say they are available from this web server in the geronimo-plugin.xml file. hope this helps... david jencks Thanks Anita __ __ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
[jira] Assigned: (GSHELL-46) Add flag to show exception stacktraces
[ https://issues.apache.org/jira/browse/GSHELL-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner reassigned GSHELL-46: -- Assignee: Jason Warner Add flag to show exception stacktraces -- Key: GSHELL-46 URL: https://issues.apache.org/jira/browse/GSHELL-46 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: CLI Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Warner Priority: Trivial Fix For: 1.0-alpha-2 Add a flag to the main CLI to show exception stacktraces (like mvn -e) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Administering geronimo remotely
--- Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On Nov 29, 2007 2:24 PM, David Jencks [EMAIL PROTECTED] wrote: On Nov 28, 2007, at 5:50 PM, Anita Kulshreshtha wrote: I am trying to administer a geronimo instance remotely using admin console. I can install jars to remote g instance using Repository link, i.e. the jar files from local file system get installed in remote g repo as expected. I tried a car and was able to install it too! I'm not entirely clear what you are saying here did you use the plugins page install the car file No or the add a jar to the repo page? Yes, It is called the Repository Viewer page on console. We could rename it to avoid confusion. If a car is added from Common Libs portlet, it should not show up as a configuration. But, this is a different problem. I wouldn't expect the plugin page to work without additional infrastructure running, see below. The only thing I had to make sure was that the needed jars were already installed on remote g. This car (a J2EE Connector) showed up in stopped state, so I started it (using 'start' link on remote console). This caused a lifecycle operation failed ... org.apache.geronimo.kernel.config.NoSuchConfigException: error. Is this the expected behavior? This error was due to a problem with car-maven-plugin(?) and should probably be discussed in another thread. The generated car (zip) had a different version than the one used in the unpacked car. This can be reproduced by building sandbox/monitoring/mrc-server/mrc-ds-car. After renaming (2.1-SANPSHOT to 1.0-SNAPSHOT) the car(zip) and installing it to remote g using add a jar to repo page, I was able to start it too! if I select the local .m2 repo as plugin repository in plugins portlet, should I expect the selected plugin to be installed at the remote instance using jars/cars from the local files system? In order for this to work you'd need to have the local .m2 repository available on a web server to the remote machine and I think the plugins would generally have to say they are available from this web server in the geronimo-plugin.xml file. Yes, this is the standard plugin repository mechanism. Thanks Anita hope this helps... david jencks Thanks Anita __ __ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/
Re: Inserting a filter into the web container
I guess you could write a ModuleBuilderExtension that modified web.xml to add the filter and appropriate filter mapping. I think you'd need to do the work in the initContext method. I'm not sure if I'd call this method good or not but its all I can think of right now. In the createModule method you can add the jar containing your filter to the dependencies so the web app can actually find the filter... hope this helps david jencks On Nov 29, 2007, at 9:05 AM, Aaron Mulder wrote: Is there some good way to insert a filter/interceptor into the web container request processing chain that would work for both Tomcat and Jetty? For example, let's say you wanted to apply some particular request validation/auditing functionality to every application, without changing the application configuration (e.g. without updating web.xml). It would be easy to write a little request filter or interceptor to do it -- I'm just not sure what the best way is to hook that in so it gets executed, and whether we have common filters/interceptors for Tomcat and Jetty or whether you'd have to do something different for each. Thanks, Aaron
[jira] Created: (GERONIMO-3649) monitoring client needs to have links on the side fixed
monitoring client needs to have links on the side fixed --- Key: GERONIMO-3649 URL: https://issues.apache.org/jira/browse/GERONIMO-3649 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: monitoring Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Need to fix the links on the side for Server Edit and View Server pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3649) monitoring client needs to have links on the side fixed
[ https://issues.apache.org/jira/browse/GERONIMO-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3649: --- Attachment: geronimo-3649.patch monitoring client needs to have links on the side fixed --- Key: GERONIMO-3649 URL: https://issues.apache.org/jira/browse/GERONIMO-3649 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Attachments: geronimo-3649.patch Need to fix the links on the side for Server Edit and View Server pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Inserting a filter into the web container
OK, after an IRC chat, it seems like an alternative would be: For Tomcat, update the base web app configuration to add a servlet filter to the default config. For Jetty, a similar default filter and default filter mapping feature was planned but not yet finished. That could be finished and then a similar thing could be done for Jetty. That way, the code would be the same, it would just be the web container configuration to invoke it that would be different. On the other hand, it's not yet clear how to get the JAR with the filter into the class path for the web app. For example, changing the base web app in Tomcat might take affect soon (say, next restart), but any previously-deployed apps wouldn't have the JAR on their class path, which could cause the app to fail. In any case, apps to be deployed in the future could use a modified deployer default environment to add the JAR. So... some more investigation necessary, but a promising start. Thanks, Aaron On Nov 29, 2007 12:20 PM, David Jencks [EMAIL PROTECTED] wrote: I guess you could write a ModuleBuilderExtension that modified web.xml to add the filter and appropriate filter mapping. I think you'd need to do the work in the initContext method. I'm not sure if I'd call this method good or not but its all I can think of right now. In the createModule method you can add the jar containing your filter to the dependencies so the web app can actually find the filter... hope this helps david jencks On Nov 29, 2007, at 9:05 AM, Aaron Mulder wrote: Is there some good way to insert a filter/interceptor into the web container request processing chain that would work for both Tomcat and Jetty? For example, let's say you wanted to apply some particular request validation/auditing functionality to every application, without changing the application configuration (e.g. without updating web.xml). It would be easy to write a little request filter or interceptor to do it -- I'm just not sure what the best way is to hook that in so it gets executed, and whether we have common filters/interceptors for Tomcat and Jetty or whether you'd have to do something different for each. Thanks, Aaron
[jira] Reopened: (GERONIMO-3618) when redirected via status code 30x, the original query is incorrectly appended to the location
[ https://issues.apache.org/jira/browse/GERONIMO-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee reopened GERONIMO-3618: --- I found another issue related with redirect that was not completely fixed by the first fix. One can specify query parameters via HttpRequestMessage.setParameter(). These parameters are kept separate from HttpRequestMessage.getUrl(), and these query parameters get added to the URL or to the post body when the request is encoded by HttpRequestEncoder. The call to add the original query from the getUrl() was removed, but the query parameters still remain, and they get added right back to the redirecting request. The fix should clear all the query parameters when you send the request. In addition, the request method should also be reset to GET if it is not GET. Essentially a redirecting request should be a brand new GET request with the URL specified by the Location header. I have a patch available which I'll upload shortly... when redirected via status code 30x, the original query is incorrectly appended to the location --- Key: GERONIMO-3618 URL: https://issues.apache.org/jira/browse/GERONIMO-3618 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: HttpIoHandler.patch, patch.zip If you're redirected via status code 30x (302, 301, ...), the code that handles following redirects (HttpIoHandler.messageRecieved()) tries to append the original query from the first request to the URL obtained from the Location header of the response. This is incorrect per HTTP specification. The spec says the value of the Location header is an absoluteURI which is a full URL that includes the proper query if any: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. The query from the original request should not be part of the second URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3618) when redirected via status code 30x, the original query is incorrectly appended to the location
[ https://issues.apache.org/jira/browse/GERONIMO-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3618: -- Attachment: patch.zip a more complete fix when redirected via status code 30x, the original query is incorrectly appended to the location --- Key: GERONIMO-3618 URL: https://issues.apache.org/jira/browse/GERONIMO-3618 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: HttpIoHandler.patch, patch.zip If you're redirected via status code 30x (302, 301, ...), the code that handles following redirects (HttpIoHandler.messageRecieved()) tries to append the original query from the first request to the URL obtained from the Location header of the response. This is incorrect per HTTP specification. The spec says the value of the Location header is an absoluteURI which is a full URL that includes the proper query if any: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. The query from the original request should not be part of the second URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3640) Eliminate UPCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546819 ] Vamsavardhana Reddy commented on GERONIMO-3640: --- I am afraid this JIRA is not about NamedUPCredentialLoginModule, but about UPCredentialLoginModule which has the exact same function as GeronimoPasswordCredentialLoginModule. Is there any need to retain UPCredentialLoginModule? Eliminate UPCredentialLoginModule - Key: GERONIMO-3640 URL: https://issues.apache.org/jira/browse/GERONIMO-3640 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 UPCredentialLoginModule seems to serve the same purpose as GeronimoPasswordCredentialLoginModule. Searching the codebase for references to UPCredentialLoginModule yields no results. Also GeronimoPasswordCredentialLoginModule is the one used by Security realms portlet. It may be a good idea to eliminate UPCredentialLoginModule and related classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo 2.1 dependencies on SNAPSHOTs
On Nov 26, 2007 2:36 PM, Kevan Miller [EMAIL PROTECTED] wrote: commons-dbcp 1.3-SNAPSHOT This looks like an openejb server dependency (i.e. not a container dependency). Why would we need it? Here's the change that introduced that dependency in OpenEJB: http://svn.apache.org/viewvc/openejb/trunk/openejb3/server/openejb-ejbd/src/main/java/org/apache/openejb/server/ejbd/JndiRequestHandler.java?r1=570629r2=581127 Maybe we can get away with switching to 1.2.2 version as it seems to have the same BasicDataSource API. Jarek
Re: Inserting a filter into the web container
To me, AOP seems like it would be better if the application were doing it, rather than trying to do it at the server configuration level. Thanks, Aaron On Nov 29, 2007 1:48 PM, Jeff Genender [EMAIL PROTECTED] wrote: Have you considered AOP? Jeff Aaron Mulder wrote: Is there some good way to insert a filter/interceptor into the web container request processing chain that would work for both Tomcat and Jetty? For example, let's say you wanted to apply some particular request validation/auditing functionality to every application, without changing the application configuration (e.g. without updating web.xml). It would be easy to write a little request filter or interceptor to do it -- I'm just not sure what the best way is to hook that in so it gets executed, and whether we have common filters/interceptors for Tomcat and Jetty or whether you'd have to do something different for each. Thanks, Aaron
Re: Inserting a filter into the web container
Have you considered AOP? Jeff Aaron Mulder wrote: Is there some good way to insert a filter/interceptor into the web container request processing chain that would work for both Tomcat and Jetty? For example, let's say you wanted to apply some particular request validation/auditing functionality to every application, without changing the application configuration (e.g. without updating web.xml). It would be easy to write a little request filter or interceptor to do it -- I'm just not sure what the best way is to hook that in so it gets executed, and whether we have common filters/interceptors for Tomcat and Jetty or whether you'd have to do something different for each. Thanks, Aaron
[jira] Commented: (GERONIMO-3650) Review ConfiguredIdentityNamedUsernamePasswordLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546847 ] Vamsavardhana Reddy commented on GERONIMO-3650: --- Completed: At revision: 599552 o logout() should destroy credentials when the subject is read-only. o Changes to bring ConfiguredIdentityNamedUsernamePasswordLoginModule in line with http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/JAASLMDevGuide.html **: This commit can use a thorough revision. Review ConfiguredIdentityNamedUsernamePasswordLoginModule - Key: GERONIMO-3650 URL: https://issues.apache.org/jira/browse/GERONIMO-3650 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review ConfiguredIdentityNamedUsernamePasswordLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3650) Review ConfiguredIdentityNamedUsernamePasswordLoginModule
Review ConfiguredIdentityNamedUsernamePasswordLoginModule - Key: GERONIMO-3650 URL: https://issues.apache.org/jira/browse/GERONIMO-3650 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review ConfiguredIdentityNamedUsernamePasswordLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3652) Review CallerIdentityPasswordCredentialLoginModule
Review CallerIdentityPasswordCredentialLoginModule -- Key: GERONIMO-3652 URL: https://issues.apache.org/jira/browse/GERONIMO-3652 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: connector Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review CallerIdentityPasswordCredentialLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Inserting a filter into the web container
Aaron Mulder wrote: To me, AOP seems like it would be better if the application were doing it, rather than trying to do it at the server configuration level. Yeah..but looking at the response by DJ, looks like the app server is gonna have to do it anyways ;-) My answer was similar to DJs in that an AOP adapter could pick something up from a JAR that it recognizes...just a different take on the same problem ;-) Jeff Thanks, Aaron On Nov 29, 2007 1:48 PM, Jeff Genender [EMAIL PROTECTED] wrote: Have you considered AOP? Jeff Aaron Mulder wrote: Is there some good way to insert a filter/interceptor into the web container request processing chain that would work for both Tomcat and Jetty? For example, let's say you wanted to apply some particular request validation/auditing functionality to every application, without changing the application configuration (e.g. without updating web.xml). It would be easy to write a little request filter or interceptor to do it -- I'm just not sure what the best way is to hook that in so it gets executed, and whether we have common filters/interceptors for Tomcat and Jetty or whether you'd have to do something different for each. Thanks, Aaron
[jira] Commented: (GERONIMO-3645) Monitoring plugins build fails
[ https://issues.apache.org/jira/browse/GERONIMO-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546857 ] Erik B. Craig commented on GERONIMO-3645: - Progress committed in rev 599543. Currently getting issues with org.apache.openejb.assembler.classic.EjbJarInfo when building mrc-server-car when built from clean repo, fine if full geronimo is built first. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Unable to create configuration for deployment org.apache.openejb.assembler.classic.EjbJarInfo; local class incompatible: stream classdesc serialVersionUID = -8904515837280852856, local class serialVersionUID = 1906133465287957899 continuing to work on this... Monitoring plugins build fails -- Key: GERONIMO-3645 URL: https://issues.apache.org/jira/browse/GERONIMO-3645 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Reporter: Erik B. Craig Assignee: Erik B. Craig Monitoring plugins build fails when there is a clean (empty) local maven repository due to lack of the artifacts org.apache.geronimo.modules:modules and org.apache.geronimo.configs:configs Need to sift through poms and clean up to prevent this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3652) Review CallerIdentityPasswordCredentialLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546862 ] Vamsavardhana Reddy commented on GERONIMO-3652: --- Completed: At revision: 599565 o logout() should remove principals and credentials when the subject is not read-only. o Changes to bring CallerIdentityPasswordCredentialLoginModule in line with http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/JAASLMDevGuide.html **: This commit can use a thorough review. Review CallerIdentityPasswordCredentialLoginModule -- Key: GERONIMO-3652 URL: https://issues.apache.org/jira/browse/GERONIMO-3652 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: connector Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Review CallerIdentityPasswordCredentialLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GShell 1.0-alpha-1 update
On Nov 29, 2007 10:25 AM, Jason Dillon [EMAIL PROTECTED] wrote: 10 seconds? Hrm... thats odd. It returns right away for me :-\ Can you reproduce it? No, I can't. It might've been that I was doing something in parallel that occupied the laptop. Doesn't gsh download or copy anything that could cause it? If not, forget about it...until it's reported again. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: GShell 1.0-alpha-1 update
Nope, GShell ATM does not do any dependency downloading. The only delay I know of is when the shell boots up, which may vary depending on what is included in the classpath ala classworlds. The 'help' command should defs not take 10 seconds though, so I'd guess your CPU or disk was busy causing I/O wait. If you can reproduce it lemme know. --jason On Nov 29, 2007, at 12:21 PM, Jacek Laskowski wrote: On Nov 29, 2007 10:25 AM, Jason Dillon [EMAIL PROTECTED] wrote: 10 seconds? Hrm... thats odd. It returns right away for me :-\ Can you reproduce it? No, I can't. It might've been that I was doing something in parallel that occupied the laptop. Doesn't gsh download or copy anything that could cause it? If not, forget about it...until it's reported again. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Commented: (GSHELL-46) Add flag to show exception stacktraces
[
https://issues.apache.org/jira/browse/GSHELL-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546896
]
Jason Dillon commented on GSHELL-46:
Sure, could use preferences too, or both...
Though the point of this issue is to add something like the {{mvn -e}} muck to
make the GShell cli display full stacks. and for cases like you might be
thinking, of embedding GShell or something, I'd not expect the GShell cli to be
used at all, so you can do whatever you like with the exceptions, just catch
them.
I would like to get these modal options to read from user prefs for defaults,
and then allow the cli to override. Like some folks might want GShell to
always dump stacks (er like me) so I can flip that preference and it will stick.
Add flag to show exception stacktraces
--
Key: GSHELL-46
URL: https://issues.apache.org/jira/browse/GSHELL-46
Project: GShell
Issue Type: New Feature
Security Level: public(Regular issues)
Components: CLI
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Priority: Trivial
Fix For: 1.0-alpha-2
Add a flag to the main CLI to show exception stacktraces (like mvn -e)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3649) monitoring client needs to have links on the side fixed
[ https://issues.apache.org/jira/browse/GERONIMO-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546892 ] Erik B. Craig commented on GERONIMO-3649: - Works great, thanks Viet. Committed revision 599573. monitoring client needs to have links on the side fixed --- Key: GERONIMO-3649 URL: https://issues.apache.org/jira/browse/GERONIMO-3649 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Environment: windows Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen Attachments: geronimo-3649.patch Need to fix the links on the side for Server Edit and View Server pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo 2.1 dependencies on SNAPSHOTs
On Nov 29, 2007 7:26 PM, Jarek Gawor [EMAIL PROTECTED] wrote: Maybe we can get away with switching to 1.2.2 version as it seems to have the same BasicDataSource API. +1. I'm building openejb with 1.2.2 so I'll post the results in a moment. If it passes openejb's tests I downgrade it to it. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Commented: (GERONIMO-3651) gshell should make it dead simple to run geronimo with remote debugging
[ https://issues.apache.org/jira/browse/GERONIMO-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546898 ] Jason Dillon commented on GERONIMO-3651: Any suggestions on how it should work? I'm thinking that something similar to the rc.d/* scripts can be used for this. So that there is a debug Groovy config which can tweak the params, and users can change it easily by updating the script. Might work kinda like a Mvn profile, where the launcher takes some command-line flags one could be for profiles, and then it will load the scripts for that profile if they exist. But please tell me what would be ideal for you, so I can balance out my own ideas with some reality... :-) gshell should make it dead simple to run geronimo with remote debugging --- Key: GERONIMO-3651 URL: https://issues.apache.org/jira/browse/GERONIMO-3651 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: David Jencks Assignee: Jason Dillon we need some options for start-server so g. starts up with debugging. I think we should be able to set the port and suspend as persistent options in the environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3651) gshell should make it dead simple to run geronimo with remote debugging
[ https://issues.apache.org/jira/browse/GERONIMO-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546903 ] David Jencks commented on GERONIMO-3651: I don't understand how the rd.d stuff works... what I was thinking of was something like ./bin/gsh geronimo/start-server --debug:port=5005,suspend=y and it would stash the port and suspend setting in the environment so next time you said --debug it would use the same port/suspend. I'd be happy with just about anything vaguely similar to this. gshell should make it dead simple to run geronimo with remote debugging --- Key: GERONIMO-3651 URL: https://issues.apache.org/jira/browse/GERONIMO-3651 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: David Jencks Assignee: Jason Dillon we need some options for start-server so g. starts up with debugging. I think we should be able to set the port and suspend as persistent options in the environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3651) gshell should make it dead simple to run geronimo with remote debugging
[ https://issues.apache.org/jira/browse/GERONIMO-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546906 ] Jason Dillon commented on GERONIMO-3651: The rc.d stuff simply executes a Groovy script (if it exists) for the given command. That script is passed in some context to allow it to augment the sysprops, cl options and other muck as well as do any custom logic/processing. But for the basic use, the rc.d scripts simply append flags to the JVM, or to the process and/or set properties for the target JVM. So its very similar to what is needed to setup the debug muck only thing is right now there is no control over when a script is executed... if its there and has the right name its run. To make this stuff work, we need to augment it a little to allow the user to pass in one or more additional scripts to execute (ie. profiles) and then you cab have a profile for debug, another for optimization, maybe another for assertions, etc. Lemme ponder this tonight and I'll see what I can do tomorrow to make this a reality. gshell should make it dead simple to run geronimo with remote debugging --- Key: GERONIMO-3651 URL: https://issues.apache.org/jira/browse/GERONIMO-3651 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: David Jencks Assignee: Jason Dillon we need some options for start-server so g. starts up with debugging. I think we should be able to set the port and suspend as persistent options in the environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-84) Create GBean(s) to launch a GShell instance in a Geronimo server
Create GBean(s) to launch a GShell instance in a Geronimo server Key: GSHELL-84 URL: https://issues.apache.org/jira/browse/GSHELL-84 Project: GShell Issue Type: New Feature Security Level: public (Regular issues) Reporter: Jason Dillon Fix For: 1.0-alpha-2 Need a GBean (or two) to launch a GShell instance (or more than one if desired) inside of a Geronimo server. Needs to have some configuration for options and an initial set of commands to execute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3624) Update start-server rc.d/ handling to prevent problems with ':' on Windows
[ https://issues.apache.org/jira/browse/GERONIMO-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GERONIMO-3624: --- Fix Version/s: 2.1 Summary: Update start-server rc.d/ handling to prevent problems with ':' on Windows (was: svn: Can't move source to dest on Windows) Update start-server rc.d/ handling to prevent problems with ':' on Windows -- Key: GERONIMO-3624 URL: https://issues.apache.org/jira/browse/GERONIMO-3624 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Environment: Windows Reporter: Hernan Cunico Assignee: Jason Dillon Priority: Blocker Fix For: 2.1 Issue brought up by Jarek on dev@, I'm having the same problem too. Windows users cannot check out trunk from SVN because of unsupported characters (: and ,) in file names. See svn log below svn: In directory 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d' svn: Can't move source to dest svn: Can't move 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/tmp/prop-base/geronimo-commands:start-server,default.groovy.svn-base' to 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/prop-base/geronimo-commands:start-server,default.groovy.svn-base': No such file or directory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3651) gshell should make it dead simple to run geronimo with remote debugging
[ https://issues.apache.org/jira/browse/GERONIMO-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GERONIMO-3651: --- Priority: Blocker (was: Major) Fix Version/s: 2.1 gshell should make it dead simple to run geronimo with remote debugging --- Key: GERONIMO-3651 URL: https://issues.apache.org/jira/browse/GERONIMO-3651 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: David Jencks Assignee: Jason Dillon Priority: Blocker Fix For: 2.1 we need some options for start-server so g. starts up with debugging. I think we should be able to set the port and suspend as persistent options in the environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-85) Create portles to allow GShell instances in a Geronimo server to be configured via the Web UI
Create portles to allow GShell instances in a Geronimo server to be configured via the Web UI - Key: GSHELL-85 URL: https://issues.apache.org/jira/browse/GSHELL-85 Project: GShell Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Jason Dillon Fix For: 1.0-alpha-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo 2.1 dependencies on SNAPSHOTs
On Nov 29, 2007 10:18 PM, Jacek Laskowski [EMAIL PROTECTED] wrote: On Nov 29, 2007 7:26 PM, Jarek Gawor [EMAIL PROTECTED] wrote: Maybe we can get away with switching to 1.2.2 version as it seems to have the same BasicDataSource API. +1. I'm building openejb with 1.2.2 so I'll post the results in a moment. If it passes openejb's tests I downgrade it to it. It can't be done yet. With 1.2.2 it failed with the following errors: [INFO] Compiling 462 source files to C:\oss\openejb3\container\openejb-core\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[27,75] package org.apache.commons.dbcp.managed does not exist C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[29,15] cannot find symbol symbol : variable super location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[33,8] cannot find symbol symbol : variable super location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[37,15] cannot find symbol symbol : variable super location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[41,8] cannot find symbol symbol : variable super location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[45,15] cannot find symbol symbol : variable super location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[49,8] cannot find symbol symbol : variable super location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[53,12] cannot find symbol symbol : variable dataSource location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[54,19] cannot find symbol symbol : variable dataSource location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[58,74] cannot find symbol symbol : method getUrl() location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[62,18] configure(org.apache.commons.dbcp.BasicDataSource) in org.apach e.openejb.resource.jdbc.DataSourcePlugin cannot be applied to (org.apache.openejb.resource.jdbc.BasicManagedDataSource) C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[67,19] cannot find symbol symbol : variable super location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource C:\oss\openejb3\container\openejb-core\src\main\java\org\apache\openejb\resource\jdbc\BasicManagedDataSource.java:[76,27] cannot find symbol symbol : variable super location: class org.apache.openejb.resource.jdbc.BasicManagedDataSource [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 3 minutes 8 seconds [INFO] Finished at: Thu Nov 29 22:24:05 CET 2007 [INFO] Final Memory: 42M/254M [INFO] Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Created: (GERONIMO-3653) Getting java.lang.NoClassDefFoundError while starting geronimo as windows service
Getting java.lang.NoClassDefFoundError while starting geronimo as windows service -- Key: GERONIMO-3653 URL: https://issues.apache.org/jira/browse/GERONIMO-3653 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: startup/shutdown Affects Versions: 2.0.2 Environment: Windows XP, geronimo-tomcat6-jee5-2.0.2, wrapper-windows-x86-32-3.2.3,Sun java 1.5.0_14 Reporter: H.T I am getting the following error while starting geronimo as a windows service. I am referring the following link. http://cwiki.apache.org/GMOxDOC20/configuring-geronimo-as-a-windows-service.html Geronimo-tomcat6-jee5-2.0.1 startes well as a windows service, but with Geronimo-tomcat6-jee5-2.0.2, following error occurs. wrapper | -- Wrapper Started as Console wrapper | Launching a JVM... jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. jvm 1| jvm 1| Booting Geronimo Kernel (in Java 1.5.0_11)... jvm 1| Starting Geronimo Application Server v2.0.2 jvm 1| jvm 1| [*] 0% 0s Loading jvm 1| [*- ] 0% 0s Loading org.apach... jvm 1| [*- ] 0% 1s Loading org.apach... jvm 1| [* ] 6% 1s Loading org.apach... jvm 1| [* ] 6% 1s Starting org.apach... jvm 1| [* ] 6% 2s Starting org.apach... jvm 1| [** ] 8% 2s Starting org.apach... jvm 1| [**- ] 8% 2s Loading org.apach... jvm 1| [** ] 9% 2s Loading org.apach... jvm 1| [*** ] 10% 2s Starting org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [***- ] 10% 2s Loading org.apach... jvm 1| [*** ] 11% 2s Loading org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [*** ] 11% 3s Starting org.apach... jvm 1| [ ] 13% 3s Starting org.apach... jvm 1| [-] 13% 3s Loading org.apach... jvm 1| [] 14% 3s Loading org.apach... jvm 1| [*] 15% 3s Starting org.apach... jvm 1| [*- ] 15% 3s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 4s Loading org.apach... jvm 1| [*- ] 15% 5s Loading org.apach... jvm 1| [* ] 17% 5s Loading org.apach... jvm 1| [* ] 17% 5s Starting org.apach... jvm 1| [** ] 18% 5s Starting org.apach... jvm 1| [**- ] 18% 5s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [**- ] 18% 6s Loading org.apach... jvm 1| [** ] 19% 6s Loading org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 7s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 8s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 9s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1| [** ] 19% 10s Starting org.apach... jvm 1| [** ] 19% 11s Starting org.apach... jvm 1| [** ] 19% 11s Starting org.apach... jvm 1| [** ] 19% 12s Starting org.apach... jvm 1| [** ] 19% 12s Starting org.apach... jvm 1| [** ] 19% 13s Starting org.apach... jvm 1| [** ] 19% 13s Starting org.apach... jvm 1| [** ] 19% 14s Starting org.apach... jvm 1| [**
automatic builds
FYI, I just changed the automatic builds (for trunk and branches/2.0) to run the testsuites with both containers (before it was tested with Tomcat only). So now a build will be successful if the testsuites pass with both containers. Jarek
[BUILD] 2.0: Failed for Revision: 599664
Geronimo Revision: 599664 built with tests included See the full build-1947.log file at http://people.apache.org/~prasad/binaries/2.0/20071129/build-1947.log Download the binaries from http://people.apache.org/~prasad/binaries/2.0/20071129 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 28 minutes 11 seconds [INFO] Finished at: Thu Nov 29 20:23:51 EST 2007 [INFO] Final Memory: 264M/856M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/~prasad/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071129/logs-1947-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/~prasad/binaries/2.0/20071129/logs-1947-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 140.528 sec FAILURE!
[jira] Commented: (GERONIMO-3523) java.io.IOException: FULL head
[ https://issues.apache.org/jira/browse/GERONIMO-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547018 ] Jarek Gawor commented on GERONIMO-3523: --- I ported the fixes to branches/2.0 as the same problem occurred in 2.0.2 (revision 599705). java.io.IOException: FULL head -- Key: GERONIMO-3523 URL: https://issues.apache.org/jira/browse/GERONIMO-3523 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.x Reporter: Jarek Gawor Assignee: Paul McMahan Fix For: 2.1 On Jetty the testsuite/console-testsuite/advanced tests usually fail with strange errors while the same works fine on Tomcat. On the server I see the following errors: 16:22:43,046 WARN [log] handle failed java.io.IOException: FULL head at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:276) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) The tests fail with different errors e.g. (it changes from run to run): testNewJMSResource(org.apache.geronimo.testsuite.console.JMSResourcesTest) Time elapsed: 7.86 sec FAILURE! com.thoughtworks.selenium.SeleniumException: ERROR: Element //[EMAIL PROTECTED]'Add Destination'] not found at com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java:73) at com.thoughtworks.selenium.DefaultSelenium.click(DefaultSelenium.java:82) at org.apache.geronimo.testsuite.console.JMSResourcesTest.testNewJMSResource(JMSResourcesTest.java:47) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers
David Jencks suggested that we move org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers package. I intend to do the following. 1. svn copy org.apache.geronmio.security.jaas.NamedUPCredentailLoginModuleto org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule 2. Make org.apache.geronmio.security.jaas.NamedUPCredentailLoginModuleextend org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule. 3. Mark org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule as deprecated. 4. Change all references from org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule Does anyone see this coming in the way of compatibility? I do not intend to change the option name org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name as this will surely break compatibility. Whether or not this move breaks compatibility, should we consider this move only in trunk and not in branches\2.0. ++Vamsi
[jira] Created: (GERONIMO-3654) Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers
Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers --- Key: GERONIMO-3654 URL: https://issues.apache.org/jira/browse/GERONIMO-3654 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: security Affects Versions: 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 David Jencks suggested that we move org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers package. I intend to do the following. 1. svn copy org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule 2. Make org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule extend org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule. 3. Mark org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule as deprecated. 4. Change all references from org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule Does anyone see this coming in the way of compatibility? I do not intend to change the option name org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name as this will surely break compatibility. Whether or not the move breaks compatibility, should we consider this move only in trunk and not in branches\2.0? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Moving o.a.g.s.jaas.NamedUPCredentailLoginModule to o.a.g.s.realm.providers
Created a JIRA https://issues.apache.org/jira/browse/GERONIMO-3654 for this. ++Vamsi On Nov 30, 2007 12:41 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: David Jencks suggested that we move org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers package. I intend to do the following. 1. svn copy org.apache.geronmio.security.jaas.NamedUPCredentailLoginModuleto org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule 2. Make org.apache.geronmio.security.jaas.NamedUPCredentailLoginModuleextend org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule. 3. Mark org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule as deprecated. 4. Change all references from org.apache.geronmio.security.jaas.NamedUPCredentailLoginModule to org.apache.geronimo.security.realm.providers.NamedUPCredentailLoginModule Does anyone see this coming in the way of compatibility? I do not intend to change the option name org.apache.geronimo.jaas.NamedUPCredentialLoginModule.Name as this will surely break compatibility. Whether or not this move breaks compatibility, should we consider this move only in trunk and not in branches\2.0. ++Vamsi
