[jira] Commented: (GERONIMO-2584) Hot deploy module/server restart, throws IllegalArgumentException if application deployed using hotdeployment
[ http://issues.apache.org/jira/browse/GERONIMO-2584?page=comments#action_12456145 ] Vamsavardhana Reddy commented on GERONIMO-2584: --- I have tried the patch on branches\1.1 (not 1.2) in combination with the fix for GERONIMO-2402. Verified that the fix works fine and no exceptions are thrown at startup. Hot deploy module/server restart, throws IllegalArgumentException if application deployed using hotdeployment - Key: GERONIMO-2584 URL: http://issues.apache.org/jira/browse/GERONIMO-2584 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Hot Deploy Dir Affects Versions: 1.2 Environment: Windows XP, but should be valid for all platforms Reporter: Rakesh Midha Fix For: 1.2 Attachments: hotdepoystartup.patch This is a problem similar to one reported in https://issues.apache.org/jira/browse/GERONIMO-2402, the server restart or hot-deploy module restart fails with followng error if in a previous run you deployed an application using hot deployment. The exception trace is : 00:54:43,008 ERROR [DirectoryMonitor] Unable to scan file C:\geronimo\geronimobu ild\geronimo-tomcat-j2ee-1.2-SNAPSHOT\deploy\sampleHello during initialization java.lang.IllegalArgumentException: Invalid id: sampleHello at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:4 9) at org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment Time(DirectoryHotDeployer.java:216) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(Direct oryMonitor.java:233) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMoni tor.java:206) at java.lang.Thread.run(Thread.java:534) 00:54:47,014 INFO [DirectoryHotDeployer] Deploying sampleHello 00:54:51,350 WARN [TomcatModuleBuilder] Web application . does not contain a WE B-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depen ding on whether you have things like resource references that need to be resolve d. You can also give the deployer a separate deployment plan file on the comman d line. 00:54:51,841 ERROR [GBeanInstance] Problem in doFail of default/sampleHello/1163 964291070/war?J2EEApplication=null,j2eeType=WebModule,name=default/sampleHello/1 163964291070/war java.lang.RuntimeException: java.lang.NullPointerException at org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContai ner.java:339) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b07 3.invoke(generated) ... 31 more 00:54:51,841 ERROR [GBeanInstanceState] Error while starting; GBean is now in th e FAILED state: abstractName=default/sampleHello/1163964291070/war?J2EEApplicat ion=null,j2eeType=WebModule,name=default/sampleHello/1163964291070/war java.lang.IllegalArgumentException: addChild: Child name '/sampleHello' is not unique at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:749) Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuratio n default/sampleHello/1163964291070/war failed to start due to the following rea sons: The service J2EEApplication=null,j2eeType=WebModule,name=default/sampleHello/1 163964291070/war did not start because the doStart method threw an exception. java.lang.IllegalArgumentException: addChild: Child name '/sampleHello' is not unique at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:749) Steps to recreate: 1. Start server 2. Deploy sample application, by placing sampleApp folder in deploy directory 3. Application will be deployed and runs fine. 4. Restart server, or restart hot-deploy module 5. The above mentioned exception is thrown. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Need Contributor Access to JIRA
Shiva, Please provide your JIRA id. --vamsi On 12/6/06, Shiva Kumar H R [EMAIL PROTECTED] wrote: Hello, I have been working on enhancing Geronimo Eclipse Plug-in for quite sometime now (http://www.mail-archive.com/dev@geronimo.apache.org/msg35865.html ) and want to start contributing to the source. Hence request to provide me with Contributor Access to JIRA. Thanks, Shiva
[jira] Commented: (GERONIMO-188) Entity instance caching
[ http://issues.apache.org/jira/browse/GERONIMO-188?page=comments#action_12455562 ] Vamsavardhana Reddy commented on GERONIMO-188: -- Anything happening on this JIRA? It is one year to date since anyone had any comments!! Entity instance caching --- Key: GERONIMO-188 URL: http://issues.apache.org/jira/browse/GERONIMO-188 Project: Geronimo Issue Type: Task Components: OpenEJB Affects Versions: 1.0-M1 Reporter: Dain Sundstrom Assigned To: Gianny Damour Fix For: 1.x OpenEJB 2.0M1 does not cache entity instances between method calls. This was useful to test entity life-cycle, but needs to be added for server efficiency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-282) servlet calls ejb: class not found at deployment and run time
[ http://issues.apache.org/jira/browse/GERONIMO-282?page=all ] Vamsavardhana Reddy closed GERONIMO-282. Resolution: Fixed From the comments, it looks like this issue is resolved. Reopen if it is still a problem. servlet calls ejb: class not found at deployment and run time --- Key: GERONIMO-282 URL: http://issues.apache.org/jira/browse/GERONIMO-282 Project: Geronimo Issue Type: Bug Components: web Affects Versions: 1.0-M2 Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Reporter: toby cabot Fix For: 1.x I'm trying to deploy a servlet that calls an EJB. I can deploy the EJB and call if from a command-line Java client, so I think that part works, thanks to the dev list for help with JNDI. I did the usual stuff in the servlet, but when I add ejb-ref ejb-ref-nameg6o/SSEJB/ejb-ref-name ejb-ref-typeSession/ejb-ref-type homeg6o.ejbclient.StatelessSessionHome/home remoteg6o.ejbclient.StatelessSession/remote /ejb-ref to web.xml I get a stack trace when I run the deploy tool. org.apache.geronimo.deployment.DeploymentException: Remote interface class not found: g6o.ejbclient.StatelessSession at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.assureInterface(JettyModuleBuilder.java:593) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.assureEJBObjectInterface(JettyModuleBuilder.java:573) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addEJBRefs(JettyModuleBuilder.java:491) etc... I've got the EJB interfaces in a jar in the war file's WEB-INF/lib directory, but I also tried putting the jar with the EJB interfaces in geronimo's lib directory with the same result. Copying my ejb client jar to geronimo's repository and adding an element to geronimo-jetty.xml: dependency urig6o-ejb-client.jar/uri /dependency ...allows the deployment to get farther, but then I get a message about how references that aren't ejb-link are not implemented, so I cut the ejb-ref element out of web.xml to make the deployment work, and when my servlet tries to look up the EJB I get: 13:19:22,715 ERROR [Daemon] Exception caught during kernel configuration, starting kernel shutdown org.apache.geronimo.kernel.config.InvalidConfigException: Invalid GBean configuration for geronimo.config:name=g6o/web at org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:274) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:146) Caused by: javax.servlet.ServletException: Naming exception in servlet init: Cannot lookup /g6o/SSEJB: Received error: Error while communicating with server: ; nested exception is: java.rmi.RemoteException: Cannot read the response from the server. The class for an object being returned is not located in this system:; nested exception is: java.lang.ClassNotFoundException: g6o.ejbclient.StatelessSessionHome at g6o.servlet.Servlet.init(Servlet.java:64) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:226) at org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:390) at org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:287) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:421) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:198) at org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:593) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:479
Re: Unable to find jetty 5.1.12
I have a successful build of branches\1.2. Build completed a few minutes ago. I can send you the jetty jar if you want me to. --vamsi On 12/5/06, Rick McGuire [EMAIL PROTECTED] wrote: I'm getting an unresolved dependency on the current 1.2 branch for Jetty 5.1.12. I haven't had any luck locating this artifact. Is there someplace I can download it manually? Rick
[jira] Commented: (GERONIMO-411) Add Hash Password Rewrite to File Realm
[
http://issues.apache.org/jira/browse/GERONIMO-411?page=comments#action_12455584
]
Vamsavardhana Reddy commented on GERONIMO-411:
--
Now that PropertiesFileLoginModule and SQLLoginModule support a digest option
(See GERONIMO-1880), is this Hash Password Rewrite feature required?
Add Hash Password Rewrite to File Realm
---
Key: GERONIMO-411
URL: http://issues.apache.org/jira/browse/GERONIMO-411
Project: Geronimo
Issue Type: Improvement
Components: security
Affects Versions: 1.0-M2
Reporter: Aaron Mulder
Priority: Minor
Fix For: Wish List
It would be nice if the properties file realm could rewrite your properties
file with hashed passwords when it reads it. We would need to be able to
recognize hashed vs. unhashed entries and perhaps even different algorithms.
Perhaps it could go like this:
user1=plaintext
user2=MD5{...}
user3=SHA1{...}
Anyway, the idea is that this could be a reasonably secure alternative, but
you still wouldn't need to manually hash things to add or update entries --
just put a plain text entry in and the next time the server reads the file it
would hash it for you.
I guess we'd need to synchronize on the hash operation to avoid threading
problems if multiple apps or whatever use the same properties file, but it
shouldn't be bad if we only rewrite the file if we find any plain text
entries.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1367) Shutdown JAR should use deployer stored username/password
[ http://issues.apache.org/jira/browse/GERONIMO-1367?page=all ] Vamsavardhana Reddy updated GERONIMO-1367: -- Priority: Minor (was: Critical) Shutdown JAR should use deployer stored username/password - Key: GERONIMO-1367 URL: http://issues.apache.org/jira/browse/GERONIMO-1367 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0 Reporter: Aaron Mulder Priority: Minor Fix For: Wish List Attachments: GERONIMO-1367.patch It would be nice if the shutdown script used the username and password saved by the deployer so you didn't need to specify them or re-enter them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1389) About and Logout icons on top of console not visible without lots of scrolling to the right on server logs page
[ http://issues.apache.org/jira/browse/GERONIMO-1389?page=all ] Vamsavardhana Reddy closed GERONIMO-1389. - Resolution: Duplicate GERONIMO-2613 includes this and more. About and Logout icons on top of console not visible without lots of scrolling to the right on server logs page --- Key: GERONIMO-1389 URL: http://issues.apache.org/jira/browse/GERONIMO-1389 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, usability Affects Versions: 1.0 Reporter: John Sisson Priority: Minor Fix For: Wish List I viewed the server logs in the console and found that due to the long entries in the Web Access Log Viewer the About and Logout icons were not visible without me scrolling pages to the right. Would it be possible to have the top of the screen where the Geronimo logo and the About and Logout icons are fixed and the screen below it scrollable so the About and Logout icons are always visible? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1398) ConnectorGBean is creating an attribute 'address' with value /0.0.0.0
[ http://issues.apache.org/jira/browse/GERONIMO-1398?page=all ] Vamsavardhana Reddy closed GERONIMO-1398. - Resolution: Fixed Examined the return value from connector.getAttribute(address) in ConnectorGBean.getHost(). Do not notice this problem in server built from branches\1.2 rev 482525. Please reopen the issue if the problem still exists. ConnectorGBean is creating an attribute 'address' with value /0.0.0.0 --- Key: GERONIMO-1398 URL: http://issues.apache.org/jira/browse/GERONIMO-1398 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.0-M5 Environment: All Reporter: Anita Kulshreshtha Priority: Minor ConnectorGBean is creating an attribute 'address' with value /0.0.0.0 . This creates bad objectNames for catalina MBeans. This explains the following results viewed via the war attached to G-1293. Note that this happens only for HTTP and HTPPS connector and not for AJP. OK - Number of results: 3 Name: Geronimo:type=Connector,port=8009,address=0.0.0.0 modelerType: org.apache.catalina.mbeans.ConnectorMBean address: 0.0.0.0 allowTrace: false bufferSize: 2048 emptySessionPath: false enableLookups: false maxPostSize: 2097152 port: 8009 protocol: AJP/1.3 protocolHandlerClassName: org.apache.jk.server.JkCoyoteHandler proxyPort: 0 redirectPort: 443 scheme: http secure: false useBodyEncodingForURI: false xpoweredBy: false Name: Geronimo:type=Connector,port=8443,address=%2F0.0.0.0 modelerType: org.apache.catalina.mbeans.ConnectorMBean acceptCount: 100 address: /0.0.0.0 algorithm: SunX509 allowTrace: false bufferSize: 2048 clientAuth: false compression: off connectionLinger: -1 connectionTimeout: 6 connectionUploadTimeout: 30 disableUploadTimeout: true emptySessionPath: false enableLookups: false keystoreFile: D:\anita\geronimo\geronimom6\geronimo-1.0\var\security\keystore keystorePass: secret maxHttpHeaderSize: 8192 maxKeepAliveRequests: 100 maxPostSize: 2097152 maxSpareThreads: 75 maxThreads: 150 minSpareThreads: 25 port: 8443 protocol: HTTP/1.1 protocolHandlerClassName: org.apache.coyote.http11.Http11Protocol proxyPort: 0 redirectPort: 443 scheme: https secure: true sslProtocol: TLS strategy: lf tcpNoDelay: true threadPriority: 5 useBodyEncodingForURI: false xpoweredBy: false Name: Geronimo:type=Connector,port=8080,address=%2F0.0.0.0 modelerType: org.apache.catalina.mbeans.ConnectorMBean acceptCount: 100 address: /0.0.0.0 allowTrace: false bufferSize: 2048 compression: off connectionLinger: -1 connectionTimeout: 2 connectionUploadTimeout: 30 disableUploadTimeout: true emptySessionPath: false enableLookups: false maxHttpHeaderSize: 8192 maxKeepAliveRequests: 100 maxPostSize: 2097152 maxSpareThreads: 75 maxThreads: 150 minSpareThreads: 25 port: 8080 protocol: HTTP/1.1 protocolHandlerClassName: org.apache.coyote.http11.Http11Protocol proxyPort: 0 redirectPort: 443 scheme: http secure: false strategy: lf tcpNoDelay: true threadPriority: 5 useBodyEncodingForURI: false xpoweredBy: false -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1427) Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction
[ http://issues.apache.org/jira/browse/GERONIMO-1427?page=comments#action_12455627 ] Vamsavardhana Reddy commented on GERONIMO-1427: --- Now that we have minimal assemblies, can this issue be closed? Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction --- Key: GERONIMO-1427 URL: http://issues.apache.org/jira/browse/GERONIMO-1427 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: general Affects Versions: 1.2 Reporter: Bruce Snyder Attachments: separate-openejb-2.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2625) Geronimo Console: login page prevents using username, password longer than 25 characters for login
Geronimo Console: login page prevents using username, password longer than 25 characters for login -- Key: GERONIMO-2625 URL: http://issues.apache.org/jira/browse/GERONIMO-2625 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1, 1.0, 1.1.2, 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.1.2, 1.2, 2.0 Console login.jsp prevents using username, password longer than 25 characters for login. This is due to the maxlength attribute in the input tags for username and passwords. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2625) Geronimo Console: login page prevents using username, password longer than 25 characters for login
[ http://issues.apache.org/jira/browse/GERONIMO-2625?page=all ] Vamsavardhana Reddy closed GERONIMO-2625. - Resolution: Fixed Removed the maxlength attribute in the username and password form input tags in login.jsp. Fixed in rev 482669 (branches\1.1), rev 482672 (branches\1.2) and rev 482673 (trunk). Geronimo Console: login page prevents using username, password longer than 25 characters for login -- Key: GERONIMO-2625 URL: http://issues.apache.org/jira/browse/GERONIMO-2625 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.0, 1.1.2, 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.1.2, 1.2, 2.0 Console login.jsp prevents using username, password longer than 25 characters for login. This is due to the maxlength attribute in the input tags for username and passwords. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Problem compiling javamail code?
May be there are some jars in the repo that are being used at assembly time instead of the jars created when you build javamail. Why don't you remove the corresponding jars from the repo and build javamail afresh and then G. --vamsi On 12/5/06, Jason Warner [EMAIL PROTECTED] wrote: That is a thought I had and I just checked again to confirm that I was editing the right files and that they were getting saved. I probably should have mentioned that it did work for a while, which I thought was odd. It reached a certain point though when the changes stopped taking effect after compiling. On 12/5/06, David Jencks [EMAIL PROTECTED] wrote: On Dec 5, 2006, at 12:07 AM, Jason Warner wrote: Hey all, In working with the javamail code I've come across a strange issue. It might not be for javamail only, but this is where I am working with the code. I am finding that after I make changes to the code in eclipse and then save, when I run mvn in the javamail/ trunk directory none of my changes seem to be picked up. When I go to run javamail after building, nothing has changed. I have done things that should result in an obvious change such as changing a println statement that is definitely being printed out or changing the functionality of the code such that it should undoubtedly do the change I made but to no avail. Is there something wrong with my build/test process that's resulting in this? I've done an mvn clean on all applicable directories just in case, but that had no effect either. Any suggestions? cat file you think you modifed will tell you pretty quickly if eclipse actually saved your changes where you think it did. It sounds to me as if eclipse is working on different files than maven, or is not saving anything. thanks david jencks Jason
[jira] Commented: (GERONIMO-1496) purge the dependency of cookie for admin console login
[ http://issues.apache.org/jira/browse/GERONIMO-1496?page=comments#action_12455674 ] Vamsavardhana Reddy commented on GERONIMO-1496: --- I really don't understand what this JIRA is about. Can someone please explain? Thanks. purge the dependency of cookie for admin console login -- Key: GERONIMO-1496 URL: http://issues.apache.org/jira/browse/GERONIMO-1496 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0 Reporter: Gao Yong Pan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1501) Daytrader: remove hardcoded dependency versions in project.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1501?page=comments#action_12455678 ] Vamsavardhana Reddy commented on GERONIMO-1501: --- I think this JIRA should actually belong to http://issues.apache.org/jira/browse/DAYTRADER. Daytrader: remove hardcoded dependency versions in project.xml --- Key: GERONIMO-1501 URL: http://issues.apache.org/jira/browse/GERONIMO-1501 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Environment: winxp Reporter: Lin Sun Priority: Minor Attachments: G1501-ejb.patch, G1501-streamer.patch, G1501-web.patch, G1501-wsappclient.patch In daytrader, there are quite a few places that have hardcoded dependency projects' version number in project.xml. They can be replaced with the versions specified in etc/project.properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1499) Daytrader: uncomment the drop table statements in daytrader.sql
[ http://issues.apache.org/jira/browse/GERONIMO-1499?page=comments#action_12455680 ] Vamsavardhana Reddy commented on GERONIMO-1499: --- I think this JIRA should actually belong to http://issues.apache.org/jira/browse/DAYTRADER. Daytrader: uncomment the drop table statements in daytrader.sql Key: GERONIMO-1499 URL: http://issues.apache.org/jira/browse/GERONIMO-1499 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.0 Environment: winxp, Reporter: Lin Sun Priority: Minor Attachments: G1499-daytrader-sql.patch If the daytrader.sql is executed the 2nd time, you will see many errors like index already exisited...because the tables are not dropped.I think it is better to uncomment the drop table statements in daytrader/derby/src/sql/daytrader.sql. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1519) ResourceException.toString() can return null
[ http://issues.apache.org/jira/browse/GERONIMO-1519?page=all ]
Vamsavardhana Reddy updated GERONIMO-1519:
--
Component/s: specs
Fix Version/s: 1.1.2
1.2
2.0
Affects Version/s: 1.1
1.1.2
1.2
2.0
ResourceException.toString() can return null
Key: GERONIMO-1519
URL: http://issues.apache.org/jira/browse/GERONIMO-1519
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: connector, specs
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
Reporter: Jörg Heinicke
Priority: Minor
Fix For: 1.1.2, 1.2, 2.0
javax.resource.ResourceException overwrites toString() like the following:
public String toString() {
return getMessage();
}
Instantiating ResourceException without parameter getMessage() will return
null - and this leads to NPEs in nearly every environment when the stacktrace
is printed:
java.lang.NullPointerException
at java.io.PrintWriter.write(PrintWriter.java:247)
at java.io.PrintWriter.print(PrintWriter.java:392)
at java.io.PrintWriter.println(PrintWriter.java:529)
at java.lang.Throwable.printStackTrace(Throwable.java:509)
So I propose to either remove the toString() implemenation
(java.lang.Throwable implements it correctly) or to implement it correctly in
ResourceException, i.e. not returning null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1519) ResourceException.toString() can return null
[ http://issues.apache.org/jira/browse/GERONIMO-1519?page=all ]
Vamsavardhana Reddy reassigned GERONIMO-1519:
-
Assignee: Vamsavardhana Reddy
ResourceException.toString() can return null
Key: GERONIMO-1519
URL: http://issues.apache.org/jira/browse/GERONIMO-1519
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: connector, specs
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
Reporter: Jörg Heinicke
Assigned To: Vamsavardhana Reddy
Priority: Minor
Fix For: 1.1.2, 1.2, 2.0
javax.resource.ResourceException overwrites toString() like the following:
public String toString() {
return getMessage();
}
Instantiating ResourceException without parameter getMessage() will return
null - and this leads to NPEs in nearly every environment when the stacktrace
is printed:
java.lang.NullPointerException
at java.io.PrintWriter.write(PrintWriter.java:247)
at java.io.PrintWriter.print(PrintWriter.java:392)
at java.io.PrintWriter.println(PrintWriter.java:529)
at java.lang.Throwable.printStackTrace(Throwable.java:509)
So I propose to either remove the toString() implemenation
(java.lang.Throwable implements it correctly) or to implement it correctly in
ResourceException, i.e. not returning null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1519) ResourceException.toString() can return null
[ http://issues.apache.org/jira/browse/GERONIMO-1519?page=all ]
Vamsavardhana Reddy closed GERONIMO-1519.
-
Resolution: Fixed
Fixes toString() to return non-null string.
Fixed in rev 482713.
ResourceException.toString() can return null
Key: GERONIMO-1519
URL: http://issues.apache.org/jira/browse/GERONIMO-1519
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: connector, specs
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
Reporter: Jörg Heinicke
Assigned To: Vamsavardhana Reddy
Priority: Minor
Fix For: 1.1.2, 1.2, 2.0
javax.resource.ResourceException overwrites toString() like the following:
public String toString() {
return getMessage();
}
Instantiating ResourceException without parameter getMessage() will return
null - and this leads to NPEs in nearly every environment when the stacktrace
is printed:
java.lang.NullPointerException
at java.io.PrintWriter.write(PrintWriter.java:247)
at java.io.PrintWriter.print(PrintWriter.java:392)
at java.io.PrintWriter.println(PrintWriter.java:529)
at java.lang.Throwable.printStackTrace(Throwable.java:509)
So I propose to either remove the toString() implemenation
(java.lang.Throwable implements it correctly) or to implement it correctly in
ResourceException, i.e. not returning null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1534) Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db
[ http://issues.apache.org/jira/browse/GERONIMO-1534?page=comments#action_12455699 ] Vamsavardhana Reddy commented on GERONIMO-1534: --- Does this belong to http://issues.apache.org/jira/browse/DAYTRADER too?? Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db - Key: GERONIMO-1534 URL: http://issues.apache.org/jira/browse/GERONIMO-1534 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.0 Environment: WinXP, Reporter: Lin Sun Priority: Minor Attachments: G1534-daytrader.patch In daytrader plan it contains the following ejb-ql-compiler-factory elements: !-- For DB2 database users uncomment the following line. ejb-ql-compiler-factoryorg.tranql.ejbcompiler.DB2EJBQLCompilerFactory/ejb-ql-compiler-factory db-syntax-factoryorg.tranql.sql.db2.DB2DBSyntaxFactory/db-syntax-factory -- If you uncomment the following line and configure daytrader with DB2, you will see a classloader problem when deploying daytrader. This should be changed to ejbqlcompiler instead of ejbcompiler: ejb-ql-compiler-factoryorg.tranql.ejbqlcompiler.DB2EJBQLCompilerFactory/ejb-ql-compiler-factory db-syntax-factoryorg.tranql.sql.db2.DB2DBSyntaxFactory/db-syntax-factory Same problem with Oracle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1594) deployment of a simple (only one jsp) web project failed
[ http://issues.apache.org/jira/browse/GERONIMO-1594?page=all ] Vamsavardhana Reddy updated GERONIMO-1594: -- Fix Version/s: Verification Required deployment of a simple (only one jsp) web project failed Key: GERONIMO-1594 URL: http://issues.apache.org/jira/browse/GERONIMO-1594 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Environment: windows xp SP2 with jsdk 1.4.2_10, geronimo 1.0, eclipse Version: 3.1.1 Build id: M20050929-0840, st 1.0.0, geronimo plugin 1.0.0 (build of 25.01) Reporter: Mark Mauerwerk Fix For: Verification Required following the instructions of the ibm article deployment of a simple (only one jsp) web project failed Despite geronimo management console displays web app as running, my test jsp is not there. I did not found any error message in the console window, but in .log (see below) !ENTRY org.apache.geronimo.devtools.eclipse.core 4 0 2006-02-05 19:16:45.78 !MESSAGE Starting of configuration failed. See .log for details. !STACK 0 java.lang.Exception: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) java.rmi.UnmarshalException: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source) at sun.rmi.server.UnicastRef.invoke(Unknown Source) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(Unknown Source) at org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:339) at org.apache.geronimo.kernel.jmx.KernelDelegate.getGBeanState(KernelDelegate.java:121) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:64) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(Unknown Source) at sun.rmi.server.LoaderHandler.loadClass(Unknown Source) at java.rmi.server.RMIClassLoader$2.loadClass(Unknown Source) at java.rmi.server.RMIClassLoader.loadClass(Unknown Source) at sun.rmi.server.MarshalInputStream.resolveClass(Unknown Source) at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source) at java.io.ObjectInputStream.readClassDesc(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) ... 9 more at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:352) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:299) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:241) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:225) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:658) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:738) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:596) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:799) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1614) Installer - Console portal servlet fails to load properly after install
[ http://issues.apache.org/jira/browse/GERONIMO-1614?page=all ] Vamsavardhana Reddy closed GERONIMO-1614. - Resolution: Fixed Installer - Console portal servlet fails to load properly after install --- Key: GERONIMO-1614 URL: http://issues.apache.org/jira/browse/GERONIMO-1614 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: installer Affects Versions: 1.2, 1.1 Reporter: erik daughtrey Attachments: installer-console-textline-fix.patch The FixTextLines function fixes all CRLFs in xml and other file types across the Geronimo install tree. Apparently, the version of the Pluto portal being used does not appreciate its XML files being adjusted. The fix will cause FixTextLines to bypass the config-store directory when fixing line endings. Additionally the fix blends in some new error/trace logging functionality which may be enabled with -DTRACE=true on the installer command line. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1621) [Daytrader] TradeWSAction class is not a Servlet
[ http://issues.apache.org/jira/browse/GERONIMO-1621?page=all ] Vamsavardhana Reddy closed GERONIMO-1621. - Resolution: Won't Fix Closed as requested by the reporter. One less JIRA to worry about :o) [Daytrader] TradeWSAction class is not a Servlet Key: GERONIMO-1621 URL: http://issues.apache.org/jira/browse/GERONIMO-1621 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.0 Reporter: Vincent Massol When trying to deploy the web/ module to Jetty I'm getting the following error: Servlet class org.apache.geronimo.samples.daytrader.TradeWSAction is not a javax.servlet.Servlet Indeed, looking at the TradeWSAction.java class reveals that it's not a Servlet and thus it shouldn't be declared as a Servlet in web.xml: servlet id=Servlet_30 display-nameorg_apache_geronimo_samples_daytrader_TradeWSAction/display-name servlet-nameorg_apache_geronimo_samples_daytrader_TradeWSAction/servlet-name servlet-classorg.apache.geronimo.samples.daytrader.TradeWSAction/servlet-class /servlet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1652) EJBModuleImpl.getEJBs() always return an empty array
[ http://issues.apache.org/jira/browse/GERONIMO-1652?page=comments#action_12455708 ] Vamsavardhana Reddy commented on GERONIMO-1652: --- Chris, can you take a look at this issue? EJBModuleImpl.getEJBs() always return an empty array Key: GERONIMO-1652 URL: http://issues.apache.org/jira/browse/GERONIMO-1652 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, OpenEJB Affects Versions: 1.2 Reporter: Christopher M. Cardona Attachments: EJBModuleImpl.java Calling EJBModuleImpl.getEJBs() always returns an empty String[] because of a wrong generated query. Here is an example query: geronimo.server:J2EEServer=geronimo,J2EEApplication=geronimo/daytrader-derby-tomcat/1.1-SNAPSHOT/car,EJBModule=null,j2eeType=EntityBean,* The correct query should have been: geronimo.server:J2EEServer=geronimo,J2EEApplication=geronimo/daytrader-derby-tomcat/1.1-SNAPSHOT/car,EJBModule=daytrader-ejb-1.1-SNAPSHOT.jar,j2eeType=EntityBean,* -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1657) CommandSupport doesn't bubble up the exception. Prints stacktrace.
[ http://issues.apache.org/jira/browse/GERONIMO-1657?page=all ] Vamsavardhana Reddy updated GERONIMO-1657: -- Fix Version/s: 1.1.2 1.2 2.0 Affects Version/s: 1.1.2 1.2 2.0 Assignee: Vamsavardhana Reddy CommandSupport doesn't bubble up the exception. Prints stacktrace. -- Key: GERONIMO-1657 URL: http://issues.apache.org/jira/browse/GERONIMO-1657 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.2, 1.2, 2.0 Reporter: Prasad Kashyap Assigned To: Vamsavardhana Reddy Fix For: 1.1.2, 1.2, 2.0 Attachments: command.patch, Command.patch C:\Apache\geronimo\modules\deploy-jsr88\src\java\org\apache\geronimo\deployment\plugin\local\ CommandSupport.addWebURLs() prints the stacktrace of an exception. It should be bubbled up to determine the correct status of the deploy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1711) WebServer Connectors portlet should provide a restart option for connectors
[ http://issues.apache.org/jira/browse/GERONIMO-1711?page=all ] Vamsavardhana Reddy reassigned GERONIMO-1711: - Assignee: Vamsavardhana Reddy WebServer Connectors portlet should provide a restart option for connectors - Key: GERONIMO-1711 URL: http://issues.apache.org/jira/browse/GERONIMO-1711 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.2 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Priority: Minor Fix For: Wish List WebServer Connectors portlet currently provides start, stop, edit and delete options. It does not provide a restart option for connectors that is already running. If any properties are edited, the changes are not reflected until the connector is stopped and started again. If one has to depend on this stop and start options clicked in succession, the admin console may not be accessible as soon as the connector is stopped and there is no way of issuing a start from admin console. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1749) Server Logs portlet - Web Access Log Viewer improvements
[ http://issues.apache.org/jira/browse/GERONIMO-1749?page=all ] Vamsavardhana Reddy reassigned GERONIMO-1749: - Assignee: Vamsavardhana Reddy Server Logs portlet - Web Access Log Viewer improvements Key: GERONIMO-1749 URL: http://issues.apache.org/jira/browse/GERONIMO-1749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.1, 1.2 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: Wish List Web Access Log Viewer portlet improvements: 1. Request Method field provides only ANY, GET and POST values. It should provide search based on other Request Methods as well. In my opinion, PUT and DELETE are more important than GET and POST for an administrator searching thru webserver logs. 2. Provide Filter Max Results and Line range. Currently 1001 lines are displayed from the results and there is no way to browse all the results. 3. Dates and Date range should be validated and a message should be displyed if From date falls after To date. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1911) HTTPS algorithm=Default is not preserved after the server is started
[ http://issues.apache.org/jira/browse/GERONIMO-1911?page=all ] Vamsavardhana Reddy closed GERONIMO-1911. - Fix Version/s: (was: 1.x) Resolution: Invalid HTTPS algorithm=Default is not preserved after the server is started Key: GERONIMO-1911 URL: http://issues.apache.org/jira/browse/GERONIMO-1911 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.0, 1.1, 1.2 Environment: Sun or IBM 1.4.2 JDK Reporter: Donald Woods Priority: Minor Attachments: Geronimo-1911.patch During the first run of the server, the algorithm=Default attribute on the TomcatWebSSLConnector in config.xml is updated to match the current JVM being used. This causes problems for people switching between Sun and IBM JRE/JDK when using Eclipse. The fix, is to update HttpsConnectorGBean.java to not set the algorithm variable to getDefaultAlgorithm() when Default was set, but to just set the connector attribute. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-657) Running configurations not saved on shutdown
[ http://issues.apache.org/jira/browse/GERONIMO-657?page=all ] Vamsavardhana Reddy closed GERONIMO-657. Running configurations not saved on shutdown Key: GERONIMO-657 URL: http://issues.apache.org/jira/browse/GERONIMO-657 Project: Geronimo Issue Type: Bug Reporter: Dain Sundstrom Assigned To: Aaron Mulder Fix For: 1.0-M4 When the server shuts down the current running configuration should be saved to var/config/config.list but it doesn't look like this code works anymore. It would be nice if there were a test case for this functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-436) JSR-88: Targets Ignored
[ http://issues.apache.org/jira/browse/GERONIMO-436?page=all ] Vamsavardhana Reddy closed GERONIMO-436. JSR-88: Targets Ignored --- Key: GERONIMO-436 URL: http://issues.apache.org/jira/browse/GERONIMO-436 Project: Geronimo Issue Type: Bug Components: deployment Affects Versions: 1.0-M2 Reporter: Aaron Mulder Assigned To: Aaron Mulder Priority: Critical Fix For: 1.1 The current JSR-88 deployer (JMXDeploymentManager) may potentially provide a list of targets for getTargets() -- one per config store. However, all the methods that take an array of Target or TargetModuleID objects ignore the specified Targets. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-515) GeronimoPolicyConfigurationFactory does not always return same instance
[ http://issues.apache.org/jira/browse/GERONIMO-515?page=all ]
Vamsavardhana Reddy closed GERONIMO-515.
GeronimoPolicyConfigurationFactory does not always return same instance
---
Key: GERONIMO-515
URL: http://issues.apache.org/jira/browse/GERONIMO-515
Project: Geronimo
Issue Type: Bug
Components: security
Affects Versions: 1.0-M3
Reporter: David Jencks
Assigned To: Alan Cabrera
From javadoc for getPolicyConfiguration(String contextID, boolean remove)
* For a given value of policy context identifier, this method must always
* return the same instance of PolicyConfiguration and there must be at
* most one actual instance of a PolicyConfiguration with a given policy
* context identifier (during a process context). p
*
* To preserve the invariant that there be at most one PolicyConfiguration
* object for a given policy context, it may be necessary for this method
* to be thread safe.
From our implementation:
if (configuration == null || remove) {
configuration = new PolicyConfigurationGeneric(contextID);
configurations.put(contextID, configuration);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SVK
Tim, I have been adding $Rev$ $Date$ to any of the files that are getting modified and that don't already have these tags. Is this causing any trouble? One other question... Is it better to commit related changes to branches\1.2 and trunk in a single revision? Does it help in any manner? --vamsi On 12/6/06, Tim McConnell [EMAIL PROTECTED] wrote: Jason, since you've done this before make you can help me understand to what degree we should strive to keep these files in sync. I notice that many of the differences between Trunk and the new 1.2 Branch are related to omissions of $Rev and $Date in various java, js, jsp, and properties files. Are these entries being added automatically by either SVN or an IDE, and should we bother syncing files with only these differences ?? Thanks Tim Jason Dillon wrote: Yes, this is the best way... merge from 1.2 to trunk, as *most* of those changes will be fairly simple to apply, and automatic with SVK (well, up until the point when we rearrange trunk, but until then). But some minor changes may also need to go the other way. SVK should be able to handle this. When I was working with SVK for the m2 migration branch, I was keeping all svn notifications I got, then when they buffered up enough, I would use SVK to merge each change, limiting the path to either file or src/main/java for the modules affected to avoid pulling in unwanted changes. In the case of the m2 migration, unwanted changes would be stuff in a pom. You could do a merge from the branch root, then cherry pick the changes, but that is not much fun when there are a bunch of changes. Anyways... IMO its best to try to only merge from 1.2 to trunk, and if needed only merge from trunk to 1.2 on a per-file basis. That means if you are working on fixing a bug, its best to fix it in 1.2. But experience has shown that people will work off of trunk and merge into branches more often than desired. But, if you are careful about the merge then no major problems should pop up. I also recommend, when using svk smerge, that you first run with -C to see what it wants to do first. Limit the changes pulled in to one merge if possible to avoid picking up something you did not want. And when you do the merge, use the -I flag to include the original text of the commit into the merge automatically, this makes it easier to track... and more automated... as if there are not conflicts, the merge will not require any user interaction. When you initially setup the svk config you will need to use --baseless on the first smerge, but only for the first... all afterwards SVK should have enough details to find the base, not sure what will happen if you keep using --baseless, so I don't recommend it. And if you run into anything strange, unlikely but might happen, hope in #svk on freenode and ask, they have been very helpful to me. --jason On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote: Ok, I'm setting up SVK so that we can keep changes between the new 1.2 Branch and Trunk in sync. I don't mean to be too simplistic but I would like to verify these assumptions on my part are correct (before I do anything untoward): 1. The primary intent will be to ensure that changes made in the 1.2 Branch will get merged into Trunk. Ideally these will be fixes and/or enhancements that have been made to the 1.2 Branch that must also be ported into Trunk as well. 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This should pretty much be business as usual (it would be very difficult to try to identify just code fixes in Trunk that have to be retrofitted back into the 1.2 Branch). This seem reasonable to everyone ?? Thanks much Tim
Re: [DISCUSS] G 2.0 M1 Content
2.0 followed by 2.0-geronimo-developer :o) --vamsi On 12/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: On Dec 5, 2006, at 2:41 PM, Jason Dillon wrote: On Dec 5, 2006, at 11:34 AM, Sachin Patel wrote: I don't see the confusion at all, as long as the Mn is preceded by the final release version (ex. geronimo-2.0-M1). Yes, but already Matt is referring to M1 with no 2.0 prefix. Anyways... I don't like it... but I don't have the energy to debate it. My bad. I meant 2.0-M1...I'll correct that omission in the future. I now understand the confusion. What other suffix do you think would be appropriate? I don't care if its 2.0-frog1. Following an evolutionary theme we could have: 2.0-proteinStrand 2.0-singleCellOrganism 2.0-fish 2.0-frog 2.0-chimp 2.0-homosapien 2.0 :) --jason Matt Hogstrom [EMAIL PROTECTED]
[jira] Commented: (GERONIMO-1135) Keystore password in System.properties
[ http://issues.apache.org/jira/browse/GERONIMO-1135?page=comments#action_12455876 ] Vamsavardhana Reddy commented on GERONIMO-1135: --- I think the SystemProperties GBean definition can be eliminate altogether from configs\rmi-naming\src\plan\plan.xml . Keystore password in System.properties -- Key: GERONIMO-1135 URL: http://issues.apache.org/jira/browse/GERONIMO-1135 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: 1.2 If you look at the System properties, the keystore and trust store passwords are in there. I'm not sure who puts them in there, but we need to find a way to stop that -- or else prevent applications from reading them? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2610) Build error due to
[ http://issues.apache.org/jira/browse/GERONIMO-2610?page=all ] Vamsavardhana Reddy closed GERONIMO-2610. - Resolution: Invalid From the patches submitted, it looks likes the user had unresolved conflicts at svn update and there is no problem as such. Build error due to -- Key: GERONIMO-2610 URL: http://issues.apache.org/jira/browse/GERONIMO-2610 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: Linux Reporter: Kanchana Welagedara Assigned To: Kanchana Welagedara Fix For: 1.2 Attachments: GERONIMO-2610.patch, geronimo-web-1.2.xsd Build is failing due to org.apache.maven.lifecycle.LifecycleExecutionException: XmlBeans compile failed: xml Error/home/kanchana/Geronimo/svn/server/modules/geronimo-web-builder/src/main/schema/geronimo-web-1.2.xsd:39: error: Unexpected character encountered (lex state 9): '' xml ErrorLoading config file /home/kanchana/Geronimo/svn/server/modules/geronimo-web-builder/src/main/schema/xmlconfig.xml In this issue created for the error org.apache.maven.lifecycle.LifecycleExecutionException: XmlBeans compile failed: xml Error/home/kanchana/Geronimo/svn/server/modules/geronimo-web-builder/src/main/schema/geronimo-web-1.2.xsd:39: error: Unexpected character encountered (lex state 9): '' Line no.39 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2481) WebServers portlet: Create/Edit Tomcat Connectors should support editing of all supported connector attributes
[ http://issues.apache.org/jira/browse/GERONIMO-2481?page=all ] Vamsavardhana Reddy updated GERONIMO-2481: -- Fix Version/s: 1.x 2.0 (was: 1.2) Affects Version/s: 2.0 Assignee: Vamsavardhana Reddy WebServers portlet: Create/Edit Tomcat Connectors should support editing of all supported connector attributes -- Key: GERONIMO-2481 URL: http://issues.apache.org/jira/browse/GERONIMO-2481 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0, 1.2 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.x, 2.0 Thanks to GERONIMO-2390 Tomcat connectors missing several attributes, we now have tomcat connectors supporting all possible attributes. In the same line, the webservers portlet should support all the attributes in creating/editing tomcat connectors. editHttp and editHttps pages may become long with this addition, but then we can group the commonly used attributes at the top and may be show the uncommon attributes upon checking an Advanced or so checkbox. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type
[ http://issues.apache.org/jira/browse/GERONIMO-2015?page=all ] Vamsavardhana Reddy updated GERONIMO-2015: -- Fix Version/s: 2.0 (was: 1.2) Let's replace JKS to PKCS12 key store type -- Key: GERONIMO-2015 URL: http://issues.apache.org/jira/browse/GERONIMO-2015 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Reporter: Nikolay Chugunov Fix For: 2.0 Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java, jksToPKCS12.patch, keystore Hello Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key store and Geronimo may not work on non-Sun VMs. To fix this problem I have created the patch for Geronimo sources. In brief the patch (attached) replaces JKS to PKCS12 key store type in configurations files. PKCS12 format of key store file is not java-specific and can be created and read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is Sun specific key store and does not exist in Bouncy Castle. Also it is needed to replace JKS to PKCS12 keystore file (attached) to assemblies/j2ee-tomcat-server/src/var/security, assemblies/j2ee-installer/src/var/security, assemblies/j2ee-jetty-server/src/var/security directories. Key store file was generating using JKSToPKCS12 class (attached). This class transfers key and certificate of Geronimo from JKS to PKCS12. After I apply this patch to Geronimo 1.0 sources and build Geronimo I can login to Geronimo console over https. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1907) Deploy command should redeploy if the app is already deployed
[ http://issues.apache.org/jira/browse/GERONIMO-1907?page=comments#action_12455889 ] Vamsavardhana Reddy commented on GERONIMO-1907: --- I think we should retain both deploy and redeploy commands as they are right now and provide an override option so that deploy command redeploys and redeploy command deploys if necessary. Deploy command should redeploy if the app is already deployed - Key: GERONIMO-1907 URL: http://issues.apache.org/jira/browse/GERONIMO-1907 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment, usability Affects Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: 1.2 Attachments: redeploy.patch Attached patch, and changing fix version to 1.2. Also unassigning so that committers can review and update. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2601) Remove the Old Keystore portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2601?page=all ] Vamsavardhana Reddy closed GERONIMO-2601. - Resolution: Fixed Fixed in rev 482109 (branches\1.2) and rev 482113 (trunk). Remove the Old Keystore portlet - Key: GERONIMO-2601 URL: http://issues.apache.org/jira/browse/GERONIMO-2601 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 I don't think the Old Keystore portlet is needed any more. Better to remove it and cleanup the codebase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (GERONIMO-2601) Remove the Old Keystore portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2601?page=all ] Vamsavardhana Reddy reopened GERONIMO-2601: --- Previous commit broke the Console Realm portlet. Remove the Old Keystore portlet - Key: GERONIMO-2601 URL: http://issues.apache.org/jira/browse/GERONIMO-2601 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 I don't think the Old Keystore portlet is needed any more. Better to remove it and cleanup the codebase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2601) Remove the Old Keystore portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2601?page=all ] Vamsavardhana Reddy closed GERONIMO-2601. - Resolution: Fixed Removed ObjectNameConstants.KEYSTORE_OBJ_NAME missed in earlier commit. Fixed in rev 482142 (branches\1.2) and rev 482143 (trunk). Remove the Old Keystore portlet - Key: GERONIMO-2601 URL: http://issues.apache.org/jira/browse/GERONIMO-2601 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 I don't think the Old Keystore portlet is needed any more. Better to remove it and cleanup the codebase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Duplicate jars in geronimo distribution
The following jars in lib\endorsed directory 1,010,675 xercesImpl-2.6.2.jar 124,724 xmlParserAPIs-2.6.2.jar 1,831,743 yoko-spec-corba-1.0-incubating-M2-SNAPSHOT.jar and the following jars in lib directory 326,319 backport-util-concurrent-2.2.jar 324,238 cglib-nodep-2.1_3.jar 38,015 commons-logging-1.0.4.jar 41,547 geronimo-common-1.2-SNAPSHOT.jar 71,025 geronimo-deploy-jsr88-1.2-SNAPSHOT.jar 63,991 geronimo-deploy-tool-1.2-SNAPSHOT.jar 75,342 geronimo-deployment-1.2-SNAPSHOT.jar 27,568 geronimo-j2ee-deployment_1.1_spec-1.0.1.jar 356,733 geronimo-kernel-1.2-SNAPSHOT.jar 285,442 geronimo-system-1.2-SNAPSHOT.jar 259,893 geronimo-util-1.2-SNAPSHOT.jar 358,180 log4j-1.2.13.jar 408,051 mx4j-3.0.1.jar 93,395 xpp3-1.1.3.3.jar 261,710 xstream-1.1.3.jar in the geronimo distribution are also in the repository. May not be all but some of these jars could be eliminated from being placed in two locations in the distribution file and it would bring down the footprint of the distribution further.
[jira] Commented: (GERONIMO-2221) java.lang.ClassCastException while installing Servlet Examples because of Checksum file not found
[
http://issues.apache.org/jira/browse/GERONIMO-2221?page=comments#action_12455296
]
Vamsavardhana Reddy commented on GERONIMO-2221:
---
Happens with other Examples too. It is not nice to see these examples fail to
install.
java.lang.ClassCastException while installing Servlet Examples because of
Checksum file not found
-
Key: GERONIMO-2221
URL: http://issues.apache.org/jira/browse/GERONIMO-2221
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: web, sample apps
Affects Versions: 1.2
Environment: cygwin, java 1.4, Revision: 424964
Reporter: Jacek Laskowski
http://localhost:8080/ - Servlet Examples - click here (i.e.
http://localhost:8080/servlets-examples/?install=true) -
{code}
# Installed configuration
# id = geronimo/servlets-examples-tomcat/1.0/car
# location =
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car
10:57:46,031 WARN [ConfigurationStoreUtil] Checksum file not found:
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car\META
-INF\config.ser.sha1
10:57:46,046 ERROR [[servlet_sample_installer]] Servlet.service() for servlet
servlet_sample_installer threw exception
java.lang.ClassCastException
at
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.readConfigurationData(SerializedConfigurationMarshaler.java:57)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.readConfigurationData(ConfigurationUtil.java:167)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfiguration(RepositoryConfigurationStore.java:113)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore$$FastClassByCGLIB$$968bf00c.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.ConfigurationStore$$EnhancerByCGLIB$$a45644d1.loadConfiguration(generated)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:738)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:454)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:383)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCGLIB$$cebc327e.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.system.plugin.PluginInstaller$$EnhancerByCGLIB$$72bbc85c.install(generated)
at
org.apache.geronimo.welcome.AbsentSampleServlet.doInstall(AbsentSampleServlet.java:72)
at
org.apache.geronimo.welcome.AbsentSampleServlet.doGet(AbsentSampleServlet.java:52)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178
Re: Exception Handling in Console
Hi Rakesh, Even I noticed this lack of error reporting in console. So, I tried to make it some what better in the newly added CA Portlet. We definitely need something uniform across all the portlets. Why don't you create a JIRA for this? --vamsi On 12/1/06, Rakesh Midha [EMAIL PROTECTED] wrote: Hello In case I get any exception or error condition in Console, the nothing is printed on web console and huge stack trace is printed on server console. Only thing done in the name of Exception handling in all the portlets is throw PortletException I somehow don't like this behavior of console. As a console user I don't want to go and see server stacktrace, if there is some error I should atleast be informed in console. I think everytime there is a error or exception in console, it should be printed in either exception page in webconsole, or in header of portlet view page. This is done to some extent in configManager and CA part of console. But not in uniform way. This is what I am proposing for Exception handling in console : 1. Create a ConsoleException.java which extends PortletException, this class will have overridden printStackTrace(PrintWriter), which will set attribute required in _ConsoleException.jsp apart from printing the stack on PrintWriter. 2. Create _ConsoleException.jsp which should be included in all portlet, this jsp will be responsible to print a short message and long stack trace. (with a toggle button to view and hide long stack trace) 3. All Portlet classes should throw ConsoleException instead of PortletException I think this will be nice and cleaner way to handle the console problems. I am working on https://issues.apache.org/jira/browse/GERONIMO-2578 to solve the same problem in deploy new app portlet. Once don't I will supply the patch and open another JIRA to do this activity for all the portlets. Please let me know if I am thinking right or missing something. Your views and comments will be appreciated. Thanks Rakesh
[jira] Assigned: (GERONIMO-2601) Remove the Old Keystore portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2601?page=all ] Vamsavardhana Reddy reassigned GERONIMO-2601: - Assignee: Vamsavardhana Reddy Remove the Old Keystore portlet - Key: GERONIMO-2601 URL: http://issues.apache.org/jira/browse/GERONIMO-2601 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 I don't think the Old Keystore portlet is needed any more. Better to remove it and cleanup the codebase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: build error in branches\1.2 in configs\dojo-jetty
I have the latest code from branches\1.2, rev 480846. What revision do you have? --vamsi On 11/30/06, Rakesh Midha [EMAIL PROTECTED] wrote: Hello Vamsi I think I have seen this before. I am not sure what was the cause of this exception, but getting latest code in branch 1.2 solves this problem. I think some change JettyModuleBuilder.java solves it. thanks Rakesh On 11/30/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Build is failing with a NullPointerException. Console output given below: [INFO] Packaging module configuration: C:\G1.2\configs\dojo-jetty\target\plan\pl an.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] java.lang.NullPointerException [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: java.lang.NullPointerExc eption at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced( Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode( Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: java.lang.NullPointer Exception at org.apache.geronimo.genesis.MojoSupport.execute( MojoSupport.java:137) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.geronimo.common.DeploymentException: java.lang.NullPointer Exception at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java :383) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.i nvoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance. java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke( BasicKernel.java: 239) at org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(Packa geMojo.java:639) at org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage (Package Mojo.java:460) at org.apache.geronimo.mavenplugins.car.PackageMojo.doExecute (PackageMoj o.java:290) at org.apache.geronimo.genesis.MojoSupport.execute( MojoSupport.java:122) ... 18 more Caused by: java.lang.NullPointerException at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.createModule( JettyModuleBuilder.java:262) at org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.createMod ule(AbstractWebModuleBuilder.java:154) at org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$$FastClas sByCGLIB$$459e0cc.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance. java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke( RawInvoker.java:5 7
[jira] Commented: (GERONIMO-1602) Switching from Tomcat causes error in JAAS module: Unable to instantiate login module
[
http://issues.apache.org/jira/browse/GERONIMO-1602?page=comments#action_12454590
]
Vamsavardhana Reddy commented on GERONIMO-1602:
---
In continuation to my previous comment, I tried loading MyPrincipal in the same
classloader as GeronimoUserPrincipal. Even that didn't help :o( I am sure it
is a classloader problem. The code where the principals are to be matched has
problems. I have put a println() in MyPrincipal.equals() method but it was
never called. I think the principal is getting rejected even before the name
is to be compared.
Switching from Tomcat causes error in JAAS module: Unable to instantiate
login module
---
Key: GERONIMO-1602
URL: http://issues.apache.org/jira/browse/GERONIMO-1602
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat
Affects Versions: 1.0
Environment: Windows XP Prof, JDK 1.5.0_06, Geronimo 1.0 (Tomcat,
.zip)
Reporter: Karsten Voges
Fix For: 1.1.x
Attachments: geronimo-JAAS-login-error.txt
I have a problem with porting a Tomcat application to Geronimo. The error
stacktrace is attached.
I deployed the war without any deployment plan and the app seams to be
working (JSPs work and the startup-servlet works as well)
But the JAASLoginModule was missing, so I could not log in. - so far no
Problem!
Afterwards I configured a security realm with the console and after a restart
my app does not complain about a missing LoginModule but throws the attached
error stacktrace.
For Tomcat I do the following:
in catalina.properties I set
###JAAS
java.security.auth.login.config=${catalina.base}/conf/login.config
and the login.config looks like this:
MyApp {
de.jato.security.auth.module.JatoServletLoginModule Sufficient
loginServlet=/login/login.jsp;
};
I tried to use a special geronimo-web.xml where I set the
context-priority-classloadertrue/context-priority-classloader
But I still get the same error:
javax.security.auth.login.LoginException:
org.apache.geronimo.common.GeronimoSecurityException: Unable to instantiate
login module
Caused by: java.lang.ClassNotFoundException:
de.jato.security.auth.module.JatoServletLoginModule
Am I doing something wrong? The class is in the war I deployed, and
everything works fine in Tomcat.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Build failure in branches\1.2 in modules\geronimo-persistence-jpa10
Joe, I have not build with a clean repo. If not with an empty repo, I will cleanup some of the jars and build again. --vamsi On 11/30/06, Joe Bohn [EMAIL PROTECTED] wrote: Vamsi, It sure sounds like you might be picking up a 1.4 version of the class. I just did a fresh checkout of 1.2 and a complete build (starting with an empty m2repo) and I didn't have any build problems. I'm building on windows with Sun JDK 1.5.0_06. Joe Vamsavardhana Reddy wrote: I am using Sun JDK 1.5.0_10. Vamsi On 11/30/06, *Rakesh Midha* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Vamsi What version of JDK are you using? I have seen this problem when I build with JDK 1.4, (not clean build). and earlier I had build the tree with JDK 1.5. Forward uncompatibilty in JDK 1.4 and 1.5 Thanks Rakesh On 11/30/06, *Vamsavardhana Reddy* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Console output given below. [INFO] Surefire report directory: C:\G1.2\modules\geronimo-persistence-jpa10\tar get\surefire-reports org.apache.maven.surefire.booter.SurefireExecutionException: org/apache/geronimo /persistence/CMPEntityManagerTest (Unsupported major.minor version 49.0); nested exception is java.lang.UnsupportedClassVersionError: org/apache/geronimo/persis tence/CMPEntityManagerTest (Unsupported major.minor version 49.0 ) java.lang.UnsupportedClassVersionError: org/apache/geronimo/persistence/CMPEntit yManagerTest (Unsupported major.minor version 49.0) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass (Isolat edClassLoader.java:100) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTest Sets(AbstractDirectoryTestSuite.java:84) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition (Surefire .java:147) at org.apache.maven.surefire.Surefire.run(Surefire.java :108) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main( SurefireBooter.j ava:747)
Re: Build failure in branches\1.2 in modules\geronimo-persistence-jpa10
I am using Sun JDK 1.5.0_10. Vamsi On 11/30/06, Rakesh Midha [EMAIL PROTECTED] wrote: Hi Vamsi What version of JDK are you using? I have seen this problem when I build with JDK 1.4, (not clean build). and earlier I had build the tree with JDK 1.5. Forward uncompatibilty in JDK 1.4 and 1.5 Thanks Rakesh On 11/30/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Console output given below. [INFO] Surefire report directory: C:\G1.2\modules\geronimo-persistence-jpa10\tar get\surefire-reports org.apache.maven.surefire.booter.SurefireExecutionException: org/apache/geronimo /persistence/CMPEntityManagerTest (Unsupported major.minor version 49.0); nested exception is java.lang.UnsupportedClassVersionError: org/apache/geronimo/persis tence/CMPEntityManagerTest (Unsupported major.minor version 49.0) java.lang.UnsupportedClassVersionError: org/apache/geronimo/persistence/CMPEntit yManagerTest (Unsupported major.minor version 49.0) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(Isolat edClassLoader.java:100) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTest Sets(AbstractDirectoryTestSuite.java:84) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition (Surefire .java:147) at org.apache.maven.surefire.Surefire.run(Surefire.java:108) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main( SurefireBooter.j ava:747)
[jira] Commented: (GERONIMO-2283) Common libs portlet guesses wrong group ID, gives no usage advice
[ http://issues.apache.org/jira/browse/GERONIMO-2283?page=comments#action_12454303 ] Vamsavardhana Reddy commented on GERONIMO-2283: --- Each of the repository entries listed on the Common Libs page is made a link which shows usage help upon clicking. Fixed in rev 480561 (branches\1.1), rev 480564 (branches\1.2) and rev 480565 (trunk). Common libs portlet guesses wrong group ID, gives no usage advice - Key: GERONIMO-2283 URL: http://issues.apache.org/jira/browse/GERONIMO-2283 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2, 1.1.x, 2.0 When selecting a file for the repository portlet, it selected the version number as the group ID. It should probably default to a blank group ID and make the user enter it -- the best it can select from the file name is probably the artifact, version, and type. Also, it should have an option where you pick a JAR and it gives you the dependency syntax you need to add that JAR to the classpath for an application or other Geronimo module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2283) Common libs portlet guesses wrong group ID, gives no usage advice
[ http://issues.apache.org/jira/browse/GERONIMO-2283?page=comments#action_12454305 ] Vamsavardhana Reddy commented on GERONIMO-2283: --- Regarding the groupId part of the issue, I am noticing on Windows that the groupId filled in upon selecting a file is the directory name in which the jar file is located. I don't see much of a problem with that. The problem I notice is with the artifactId and version. When I select a file like utils-1-r118.jar, the filled in artifactId is utils-1 and version is r118. Common libs portlet guesses wrong group ID, gives no usage advice - Key: GERONIMO-2283 URL: http://issues.apache.org/jira/browse/GERONIMO-2283 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2, 1.1.x, 2.0 When selecting a file for the repository portlet, it selected the version number as the group ID. It should probably default to a blank group ID and make the user enter it -- the best it can select from the file name is probably the artifact, version, and type. Also, it should have an option where you pick a JAR and it gives you the dependency syntax you need to add that JAR to the classpath for an application or other Geronimo module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2283) Common libs portlet guesses wrong group ID, gives no usage advice
[ http://issues.apache.org/jira/browse/GERONIMO-2283?page=all ] Vamsavardhana Reddy updated GERONIMO-2283: -- Fix Version/s: 1.2 2.0 Common libs portlet guesses wrong group ID, gives no usage advice - Key: GERONIMO-2283 URL: http://issues.apache.org/jira/browse/GERONIMO-2283 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2, 1.1.x, 2.0 When selecting a file for the repository portlet, it selected the version number as the group ID. It should probably default to a blank group ID and make the user enter it -- the best it can select from the file name is probably the artifact, version, and type. Also, it should have an option where you pick a JAR and it gives you the dependency syntax you need to add that JAR to the classpath for an application or other Geronimo module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
build error in branches\1.2 in configs\dojo-jetty
Build is failing with a NullPointerException. Console output given below: [INFO] Packaging module configuration: C:\G1.2\configs\dojo-jetty\target\plan\pl an.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] java.lang.NullPointerException [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: java.lang.NullPointerExc eption at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: java.lang.NullPointer Exception at org.apache.geronimo.genesis.MojoSupport.execute(MojoSupport.java :137) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.geronimo.common.DeploymentException: java.lang.NullPointer Exception at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:383) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.i nvoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance. java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke( BasicKernel.java: 239) at org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer (Packa geMojo.java:639) at org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage (Package Mojo.java:460) at org.apache.geronimo.mavenplugins.car.PackageMojo.doExecute (PackageMoj o.java:290) at org.apache.geronimo.genesis.MojoSupport.execute(MojoSupport.java :122) ... 18 more Caused by: java.lang.NullPointerException at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.createModule( JettyModuleBuilder.java:262) at org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.createMod ule(AbstractWebModuleBuilder.java:154) at org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$$FastClas sByCGLIB$$459e0cc.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance. java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke( RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (Pro xyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4 21aae74.createModule(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModu le(SwitchingModuleBuilder.java:94) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClass ByCGLIB$$d0c31844.invoke(generated) at
Re: Building the new trunk
Donald, I tried building trunk using IBM JDK 1.5.0 sometime ago and ran into problems in the following modules/apps and assemblies. modules\geronimo-connector modules\geronimo-j2ee-builder applications\geronimo-uddi-db assemblies\geronimo-boilerplate-minimal assemblies\geronimo-boilerplate-j2ee assemblies\geronimo-framework assemblies\geronimo-tomcat-j2ee assemblies\geronimo-tomcat-minimal assemblies\geronimo-jetty-j2ee assemblies\geronimo-jetty-minimal modules\geronimo-connector gives compilation errors like C:\GTRUNK\modules\geronimo-connector\src\main\java\org\apache\geronimo\connector\outbound\GeronimoConnectionEventListener.java:[28,34] package org.apache.commons.logging does not exist. I got past this error by commenting out the following in pom.xml exclusions exclusion groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId /exclusion /exclusions modules\geronimo-j2ee-builder gave the following error. [INFO] Executing tasks [mkdir] Created dir: C:\GTRUNK\modules\geronimo-j2ee-builder\target\test-ear-j2ee_1.4- unpacked.ear [unzip] Expanding: C:\GTRUNK\modules\geronimo-j2ee-builder\target\test-ear-j2ee_1.4.ear into C:\GTRUNK\modules\geronimo-j2ee-builder\target\test-ear-j2ee_1.4- unpacked.ear [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error executing ant tasks Embedded error: Error while expanding C:\GTRUNK\modules\geronimo-j2ee-builder\target\test-ear-j2ee_1.4.ear C:\GTRUNK\modules\geronimo-j2ee-builder\target\test-ear-j2ee_1.4.ear (The system cannot find the file specified.) applications\geronimo-uddi-db gave the following error. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error executing ant tasks Embedded error: Unable to delete file C:\GTRUNK\applications\geronimo-uddi-db\target\classes\META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck assemblies gave the following error [INFO] Executing tasks [mkdir] Created dir: C:\GTRUNK\assemblies\geronimo-boilerplate-minimal\target\ classes\schema [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error executing ant tasks Embedded error: C:\GTRUNK\assemblies\geronimo-boilerplate-minimal\target\scratch\s chema not found. --vamsi On 11/28/06, Donald Woods [EMAIL PROTECTED] wrote: I finally got Rev479804 to build on WinXP with a clean m2 repo, using Sun Java 1.5.0_09, Maven 2.0.4 with the default .m2 location and the source was on a NTFS drive with a path of e:\g20\server\ I'll have to investigate why building with the IBM 1.5.0 SR3 SDK fails and generates a lot of Maven warnings like the following - [WARNING] Component returned which is not the same manager. Ignored. component= [EMAIL PROTECTED] [WARNING] Component returned which is not the same manager. Ignored. component= [EMAIL PROTECTED] -Donald Christopher M. Cardona wrote: FYI, I was able to build trunk (rev. 478237) successfully this morning: mvn clean install Best wishes, chris anita kulshreshtha wrote: Did you get past this problem? I and others have not encountered this problem.. Thanks Anita --- Donald Woods [EMAIL PROTECTED] wrote: I'm getting the following j2ee-builder error with a clean repo and using the following cmdline to build trunk Rev477664 from this morning. mvn -Dstage=bootstrap -Dmaven.test.skip=true clean install [INFO] [INFO] Building Geronimo :: J2EE :: Builder [INFO]task-segment: [clean, install] [INFO] Downloading: http://repository.codehaus.org/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.pom [WARNING] Unable to get resource from repository codehaus (http://repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.pom 2K downloaded Downloading: http://repository.codehaus.org/org/codehaus/mojo/mojo/5/mojo-5.pom [WARNING] Unable to get resource from repository codehaus (http://repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/mojo/5/mojo-5.pom 4K downloaded Downloading: http://repository.codehaus.org/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.jar [WARNING] Unable to get resource from repository codehaus (http://repository.cod ehaus.org) Downloading:
Re: 1.2 Fit and Finish
Kevan, I have looked at all the files modified in the revision 389206. All the functionality from that revision is intact in trunk and branches\1.2. That revision is no longer relevant and all_changes.log can now be removed. --vamsi On 11/28/06, Kevan Miller [EMAIL PROTECTED] wrote: On Nov 18, 2006, at 2:41 AM, Jason Dillon wrote: Is anyone gonna look at this? I'd really like to nuke this branch and the all_changes.log (and pending-merge-log.sh). Lets not go another week with this unresolved... plz. --jason On Nov 9, 2006, at 1:12 PM, Paul McMahan wrote: I went thru all_changes.log and for each remaining item marked Not Merged I verified that it is either already in trunk or is unnecessary. I marked r389206 as merged because I think all the parts that trunk needs are there but if someone has a min could you please double check it? Vamsi, Looks like you recently hit a lot of the files that 389206 updated. Perhaps you could have a look to verify everything looks good? --kevan
[jira] Updated: (GERONIMO-1930) Make security realm types into GBeans so they can be added in new/updated configurations
[ http://issues.apache.org/jira/browse/GERONIMO-1930?page=all ] Vamsavardhana Reddy updated GERONIMO-1930: -- Fix Version/s: (was: 1.1.2) Make security realm types into GBeans so they can be added in new/updated configurations Key: GERONIMO-1930 URL: http://issues.apache.org/jira/browse/GERONIMO-1930 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security, console Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1892) Make JMS Provider Properties a GBean
[ http://issues.apache.org/jira/browse/GERONIMO-1892?page=all ] Vamsavardhana Reddy updated GERONIMO-1892: -- Fix Version/s: 1.x (was: 1.1.2) Make JMS Provider Properties a GBean Key: GERONIMO-1892 URL: http://issues.apache.org/jira/browse/GERONIMO-1892 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Aaron Mulder Priority: Minor Fix For: 1.x It would be great to declare an interface and GBean for the JMS provider properties. Then the portlet could look up all matching GBeans by interface. So, if you want to add another JMS provider, you just include that GBean in your JMS server module and it's immediately available in the console. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2458) MapEditor does not work
[ http://issues.apache.org/jira/browse/GERONIMO-2458?page=all ]
Vamsavardhana Reddy updated GERONIMO-2458:
--
Fix Version/s: 2.0
Assignee: Vamsavardhana Reddy
MapEditor does not work
---
Key: GERONIMO-2458
URL: http://issues.apache.org/jira/browse/GERONIMO-2458
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: common
Affects Versions: 1.1.1, 1.2
Environment: 1.2-SNAPSHOT
Reporter: Vamsavardhana Reddy
Assigned To: Vamsavardhana Reddy
Fix For: 1.2, 1.1.2, 2.0
Attachments: GERONIMO-2458.patch
MapEditor.getAsText() is returning map.toString() which is not in sync with
setAsText() that expects input in the form name1=value1 on separate lines.
Bottom line...
MapEditor.getAsText() returns
{name1=value1, name2=value2}
where as MapEditor.setAsText() expects
name1=value1
name=value2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2458) MapEditor does not work
[ http://issues.apache.org/jira/browse/GERONIMO-2458?page=all ]
Vamsavardhana Reddy closed GERONIMO-2458.
-
Resolution: Fixed
Use PropertiesEditor. Replace null keys and values with empty string.
Fixed in rev 479580 (branches\1.1), rev 479585 (branches\1.2) and rev 479586
(trunk).
MapEditor does not work
---
Key: GERONIMO-2458
URL: http://issues.apache.org/jira/browse/GERONIMO-2458
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: common
Affects Versions: 1.1.1, 1.2
Environment: 1.2-SNAPSHOT
Reporter: Vamsavardhana Reddy
Assigned To: Vamsavardhana Reddy
Fix For: 1.1.2, 1.2, 2.0
Attachments: GERONIMO-2458.patch
MapEditor.getAsText() is returning map.toString() which is not in sync with
setAsText() that expects input in the form name1=value1 on separate lines.
Bottom line...
MapEditor.getAsText() returns
{name1=value1, name2=value2}
where as MapEditor.setAsText() expects
name1=value1
name=value2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r479586 - /geronimo/server/trunk/modules/geronimo-common/src/main/java/org/apache/geronimo/common/propertyeditor/MapEditor.java
Hi Jason,
Sometime ago I had difficulty in figuring out what revision(s) fixed a
particular JIRA and vice versa. So, I have made it a practice to include
the JIRA number in the change log and svn revision numbers in the JIRA
comments so that someone investigating the JIRA or the svn revision will be
able to figureout what is happening either from the JIRA or the svn change
log without much difficulty. I thought this is complete sufficient and is
definitely an improvement on what was followed earlier. For those revisions
that are not related to a JIRA, I have included a description of the change
in the change log itself. Since no one had any complaints on this, I have
followed it till now. Adding full details (or a summary) of the change to
the change log would not be much of a overhead and it amounts to one more
Copy+Paste. I agree that adding a summary of changes along with a link to
where full details can be found (like the JIRA number) is definitely a
further improvement and will be followed from now on. After all, all our
efforts are to improve things and make life easy (for a lot of others).
--vamsi
On 11/28/06, Jason Dillon [EMAIL PROTECTED] wrote:
Please... please... please... put more context into the commit log.
MapEditor does not work tells me nothing about what was actually
changed. When auditing changes it helps to have some context to the
change in the commit log so that its easy to comprehend what the
change was, with out having to dig around, or bounce into JIRA, etc.
I've mentioned this a few times before... while its is good to
include the JIRA issue ID, only including that ID, or in this case
the ID and the issue subject, in the SVN commit message is not
sufficient.
Please... please... please... try to put some more meaningful context
into commit messages.
Thanks,
--jason
On Nov 27, 2006, at 2:54 AM, [EMAIL PROTECTED] wrote:
Author: vamsic007
Date: Mon Nov 27 02:54:38 2006
New Revision: 479586
URL: http://svn.apache.org/viewvc?view=revrev=479586
Log:
GERONIMO-2458 MapEditor does not work
Modified:
geronimo/server/trunk/modules/geronimo-common/src/main/java/org/
apache/geronimo/common/propertyeditor/MapEditor.java
Modified: geronimo/server/trunk/modules/geronimo-common/src/main/
java/org/apache/geronimo/common/propertyeditor/MapEditor.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-common/src/main/java/org/apache/geronimo/common/
propertyeditor/MapEditor.java?view=diffrev=479586r1=479585r2=479586
==
--- geronimo/server/trunk/modules/geronimo-common/src/main/java/org/
apache/geronimo/common/propertyeditor/MapEditor.java (original)
+++ geronimo/server/trunk/modules/geronimo-common/src/main/java/org/
apache/geronimo/common/propertyeditor/MapEditor.java Mon Nov 27
02:54:38 2006
@@ -19,17 +19,22 @@
import java.io.ByteArrayInputStream;
import java.io.IOException;
+import java.util.Iterator;
import java.util.Properties;
import java.util.Map;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+
/**
- * A property editor for [EMAIL PROTECTED] java.util.Properties}.
+ * A property editor for [EMAIL PROTECTED] java.util.Map}.
*
* @version $Rev$ $Date$
*/
public class MapEditor
extends TextPropertyEditorSupport
{
+private static final Log log = LogFactory.getLog
(MapEditor.class);
/**
*
* @throws PropertyEditorException An IOException occured.
@@ -50,11 +55,30 @@
Map map = (Map) getValue();
if (!(map instanceof Properties)) {
Properties p = new Properties();
-if (map != null) {
-p.putAll(map);
+if(map != null) {
+if(!map.containsKey(null) !map.containsValue
(null)) {
+p.putAll(map);
+} else {
+// Map contains null keys or values. Replace
null with empty string.
+log.warn(Map contains null keys or values.
Replacing null values with empty string.);
+for(Iterator itr = map.entrySet().iterator();
itr.hasNext(); ) {
+Map.Entry entry = (Map.Entry) itr.next();
+Object key = entry.getKey();
+Object value = entry.getValue();
+if(key == null) {
+key = ;
+}
+if(value == null) {
+value = ;
+}
+p.put(key, value);
+}
+}
+map = p;
}
-map = p;
}
-return map.toString();
+PropertiesEditor pe = new PropertiesEditor();
+pe.setValue(map);
+return pe.getAsText();
}
}
Re: svn commit: r479586 - /geronimo/server/trunk/modules/geronimo-common/src/main/java/org/apache/geronimo/common/propertyeditor/MapEditor.java
By copy+paste, I did not mean copying the JIRA content and pasting it into
the change log. I meant to say, anyway I am including the summary of
change in JIRA comment while resolving the JIRA. I will copy+paste the same
into svn change log.
--vamsi
On 11/28/06, Jason Dillon [EMAIL PROTECTED] wrote:
I don't think it is appropriate to simply copy/paste the jira content into
the svn change comment. I expect the jira issue to contain a lot more
details and some comments about the change, where I expect the svn change
comment to briefly explain the change.
--jason
On Nov 27, 2006, at 9:57 PM, Vamsavardhana Reddy wrote:
Hi Jason,
Sometime ago I had difficulty in figuring out what revision(s) fixed a
particular JIRA and vice versa. So, I have made it a practice to include
the JIRA number in the change log and svn revision numbers in the JIRA
comments so that someone investigating the JIRA or the svn revision will be
able to figureout what is happening either from the JIRA or the svn change
log without much difficulty. I thought this is complete sufficient and is
definitely an improvement on what was followed earlier. For those revisions
that are not related to a JIRA, I have included a description of the change
in the change log itself. Since no one had any complaints on this, I have
followed it till now. Adding full details (or a summary) of the change to
the change log would not be much of a overhead and it amounts to one more
Copy+Paste. I agree that adding a summary of changes along with a link to
where full details can be found (like the JIRA number) is definitely a
further improvement and will be followed from now on. After all, all our
efforts are to improve things and make life easy (for a lot of others).
--vamsi
On 11/28/06, Jason Dillon [EMAIL PROTECTED] wrote:
Please... please... please... put more context into the commit log.
MapEditor does not work tells me nothing about what was actually
changed. When auditing changes it helps to have some context to the
change in the commit log so that its easy to comprehend what the
change was, with out having to dig around, or bounce into JIRA, etc.
I've mentioned this a few times before... while its is good to
include the JIRA issue ID, only including that ID, or in this case
the ID and the issue subject, in the SVN commit message is not
sufficient.
Please... please... please... try to put some more meaningful context
into commit messages.
Thanks,
--jason
On Nov 27, 2006, at 2:54 AM, [EMAIL PROTECTED] wrote:
Author: vamsic007
Date: Mon Nov 27 02:54:38 2006
New Revision: 479586
URL: http://svn.apache.org/viewvc?view=revrev=479586
Log:
GERONIMO-2458 MapEditor does not work
Modified:
geronimo/server/trunk/modules/geronimo-common/src/main/java/org/
apache/geronimo/common/propertyeditor/MapEditor.java
Modified: geronimo/server/trunk/modules/geronimo-common/src/main/
java/org/apache/geronimo/common/propertyeditor/MapEditor.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
geronimo-common/src/main/java/org/apache/geronimo/common/
propertyeditor/MapEditor.java?view=diffrev=479586r1=479585r2=479586
==
--- geronimo/server/trunk/modules/geronimo-common/src/main/java/org/
apache/geronimo/common/propertyeditor/MapEditor.java (original)
+++ geronimo/server/trunk/modules/geronimo-common/src/main/java/org/
apache/geronimo/common/propertyeditor/MapEditor.java Mon Nov 27
02:54:38 2006
@@ -19,17 +19,22 @@
import java.io.ByteArrayInputStream;
import java.io.IOException;
+import java.util.Iterator;
import java.util.Properties;
import java.util.Map;
+import org.apache.commons.logging.Log ;
+import org.apache.commons.logging.LogFactory;
+
/**
- * A property editor for [EMAIL PROTECTED] java.util.Properties}.
+ * A property editor for [EMAIL PROTECTED] java.util.Map}.
*
* @version $Rev$ $Date$
*/
public class MapEditor
extends TextPropertyEditorSupport
{
+private static final Log log = LogFactory.getLog
(MapEditor.class);
/**
*
* @throws PropertyEditorException An IOException occured.
@@ -50,11 +55,30 @@
Map map = (Map) getValue();
if (!(map instanceof Properties)) {
Properties p = new Properties();
-if (map != null) {
-p.putAll(map);
+if(map != null) {
+if(!map.containsKey(null) !map.containsValue
(null)) {
+p.putAll(map);
+} else {
+// Map contains null keys or values. Replace
null with empty string.
+log.warn(Map contains null keys or values.
Replacing null values with empty string.);
+for(Iterator itr = map.entrySet().iterator();
itr.hasNext(); ) {
+Map.Entry
Re: svn commit: r479586 - /geronimo/server/trunk/modules/geronimo-common/src/main/java/org/apache/geronimo/common/propertyeditor/MapEditor.java
Jason, Don't worry. I did not take it as personal. Infact I am glad that you commented on my practice and it will help in improving things. This discussion would be fruitful if we suggest some best practices for Geronimo. As I have already mentioned, all our efforts are to improve things and make life easy (for a lot of others). :o) --vamsi On 11/28/06, Jason Dillon [EMAIL PROTECTED] wrote: Aight... well, I still think that brief change context should be included in svn commits. I have said it before... and no doubt I will say it again sometime. Anyways, nothing personal, not picking on you... was just providing some comments to help improve the ability to provide oversight of svn via change log emails. --jason On Nov 27, 2006, at 10:08 PM, Vamsavardhana Reddy wrote: By copy+paste, I did not mean copying the JIRA content and pasting it into the change log. I meant to say, anyway I am including the summary of change in JIRA comment while resolving the JIRA. I will copy+paste the same into svn change log. --vamsi On 11/28/06, Jason Dillon [EMAIL PROTECTED] wrote: I don't think it is appropriate to simply copy/paste the jira content into the svn change comment. I expect the jira issue to contain a lot more details and some comments about the change, where I expect the svn change comment to briefly explain the change. --jason On Nov 27, 2006, at 9:57 PM, Vamsavardhana Reddy wrote: Hi Jason, Sometime ago I had difficulty in figuring out what revision(s) fixed a particular JIRA and vice versa. So, I have made it a practice to include the JIRA number in the change log and svn revision numbers in the JIRA comments so that someone investigating the JIRA or the svn revision will be able to figureout what is happening either from the JIRA or the svn change log without much difficulty. I thought this is complete sufficient and is definitely an improvement on what was followed earlier. For those revisions that are not related to a JIRA, I have included a description of the change in the change log itself. Since no one had any complaints on this, I have followed it till now. Adding full details (or a summary) of the change to the change log would not be much of a overhead and it amounts to one more Copy+Paste. I agree that adding a summary of changes along with a link to where full details can be found (like the JIRA number) is definitely a further improvement and will be followed from now on. After all, all our efforts are to improve things and make life easy (for a lot of others). --vamsi On 11/28/06, Jason Dillon [EMAIL PROTECTED] wrote: Please... please... please... put more context into the commit log. MapEditor does not work tells me nothing about what was actually changed. When auditing changes it helps to have some context to the change in the commit log so that its easy to comprehend what the change was, with out having to dig around, or bounce into JIRA, etc. I've mentioned this a few times before... while its is good to include the JIRA issue ID, only including that ID, or in this case the ID and the issue subject, in the SVN commit message is not sufficient. Please... please... please... try to put some more meaningful context into commit messages. Thanks, --jason On Nov 27, 2006, at 2:54 AM, [EMAIL PROTECTED] wrote: Author: vamsic007 Date: Mon Nov 27 02:54:38 2006 New Revision: 479586 URL: http://svn.apache.org/viewvc?view=revrev=479586 Log: GERONIMO-2458 MapEditor does not work Modified: geronimo/server/trunk/modules/geronimo-common/src/main/java/org/ apache/geronimo/common/propertyeditor/MapEditor.java Modified: geronimo/server/trunk/modules/geronimo-common/src/main/ java/org/apache/geronimo/common/propertyeditor/MapEditor.java URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-common/src/main/java/org/apache/geronimo/common/ propertyeditor/MapEditor.java?view=diffrev=479586r1=479585r2=479586 == --- geronimo/server/trunk/modules/geronimo-common/src/main/java/org/ apache/geronimo/common/propertyeditor/MapEditor.java (original) +++ geronimo/server/trunk/modules/geronimo-common/src/main/java/org/ apache/geronimo/common/propertyeditor/MapEditor.java Mon Nov 27 02:54:38 2006 @@ -19,17 +19,22 @@ import java.io.ByteArrayInputStream; import java.io.IOException; +import java.util.Iterator; import java.util.Properties; import java.util.Map; +import org.apache.commons.logging.Log ; +import org.apache.commons.logging.LogFactory; + /** - * A property editor for [EMAIL PROTECTED] java.util.Properties}. + * A property editor for [EMAIL PROTECTED] java.util.Map}. * * @version $Rev$ $Date$ */ public class MapEditor extends TextPropertyEditorSupport
[jira] Closed: (GERONIMO-2504) Allow all read-only operations on KeystoreInstance to be available to services
[ http://issues.apache.org/jira/browse/GERONIMO-2504?page=all ] Vamsavardhana Reddy closed GERONIMO-2504. - Allow all read-only operations on KeystoreInstance to be available to services -- Key: GERONIMO-2504 URL: http://issues.apache.org/jira/browse/GERONIMO-2504 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, security Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 1.2 Attachments: GERONIMO-2504.openejb.patch, GERONIMO-2504.openejb.patch, GERONIMO-2504.patch Currently, the only operations available to services are SSL factory creations. This is quite unsufficient when you need to use WS-Security for example to sign / crypt / encrypt messages. The attached patch has the following modifications: * add several methods to KeystoreInstance * all methods use a keystorePassword parameter used in the following way - write operations on keystore must be given a non-null password - read-only operations may be given a null password, in which case, the internal saved password will be used * all methods throw a KeystoreException existing exceptions have been refactored to inherit this exception * fix several keystore porlets problems: - password is not validated - some actions fail when the keystore is not unlocked for use -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2423) Unable to delete TomcatAJPConnector
[ http://issues.apache.org/jira/browse/GERONIMO-2423?page=all ] Vamsavardhana Reddy closed GERONIMO-2423. - Unable to delete TomcatAJPConnector --- Key: GERONIMO-2423 URL: http://issues.apache.org/jira/browse/GERONIMO-2423 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: Linux, Windows Reporter: Heinz Drews Even after deleting the default TomcatAJPConnector it is activated again after server restart. Next attempt to delete the connector results in message [TomcatManagerImpl] No such GBean 'geronimo/tomcat/1.1.1/car?ServiceModule=geronimo/tomcat/1.1.1/car,j2eeType=GBean,name=TomcatAJPConnector' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2347) JMS Resources don't work in the console for ActiveMQ
[ http://issues.apache.org/jira/browse/GERONIMO-2347?page=all ] Vamsavardhana Reddy closed GERONIMO-2347. - JMS Resources don't work in the console for ActiveMQ Key: GERONIMO-2347 URL: http://issues.apache.org/jira/browse/GERONIMO-2347 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Assigned To: Jason Dillon Fix For: 1.2 Attachments: GERONIMO-2347.bdudney.patch to see the bug click on JMS Resources then For ActiveMQ - exception in the log java.lang.IllegalArgumentException: Invalid id: geronimo/ge-activemq-rar//rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.console.util.PortletManager.getRepositoryEntry(PortletManager.java:358) at org.apache.geronimo.console.jmsmanager.wizard.JMSProviderData.loadRARData(JMSProviderData.java:212) at org.apache.geronimo.console.jmsmanager.wizard.JMSProviderData.getProviderData(JMSProviderData.java:200) at org.apache.geronimo.console.jmsmanager.wizard.ConfigureRAInstanceHandler.renderView(ConfigureRAInstanceHandler.java:44) Caused by the id - the patch fixes it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2346) DB Info in console does not work and shows 'java.sql.SQLException' in the log
[ http://issues.apache.org/jira/browse/GERONIMO-2346?page=all ] Vamsavardhana Reddy closed GERONIMO-2346. - DB Info in console does not work and shows 'java.sql.SQLException' in the log - Key: GERONIMO-2346 URL: http://issues.apache.org/jira/browse/GERONIMO-2346 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Jason Dillon Fix For: 1.2 Attachments: GERONIMO-2346.bdudney.patch to reproduce launch and go to the console, select DB Info, only the static info shows up and the log has simply 'java.sql.SQLException'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2360) Console: can not import a certificate into a keystore
[ http://issues.apache.org/jira/browse/GERONIMO-2360?page=all ] Vamsavardhana Reddy closed GERONIMO-2360. - Console: can not import a certificate into a keystore - Key: GERONIMO-2360 URL: http://issues.apache.org/jira/browse/GERONIMO-2360 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Yunfeng Ma Attachments: truststoreca.rar Perfom the following steps: 1. Open Keystore Configuratin portlet by clicking on Scurity-Keystores 2. Unlock a keystore file by clicking on the lock icon in the Editable column 3. Click on the unlocked keystore file 4. Click on the link Add Trust Certificate 5. Select the trust certificate file and enter the alias name 6. Click on the button Review Certificate Then will get different results on different platform: On Linux: The certificate can be imported into the keystore successfule. On Windows 2003: The following exceptions were throwed: 17:54:37,250 ERROR [MultiPagePortlet] Unable to render portlet java.io.FileNotFoundException: C: (Access is denied.) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:135) at java.io.FileInputStream.init(FileInputStream.java:95) at org.apache.geronimo.console.keystores.ConfirmCertificateHandler.renderView(ConfirmCertificateHandler.java:61) at org.apache.geronimo.console.MultiPagePortlet.doView(MultiPagePortlet.java:146) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:60) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112) at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:57) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112
[jira] Closed: (GERONIMO-2319) Unable to create a new OpenWire Listener from console
[ http://issues.apache.org/jira/browse/GERONIMO-2319?page=all ] Vamsavardhana Reddy closed GERONIMO-2319. - Unable to create a new OpenWire Listener from console - Key: GERONIMO-2319 URL: http://issues.apache.org/jira/browse/GERONIMO-2319 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, console Affects Versions: 1.1, 1.0 Environment: Geronimo 1.1 Reporter: Krishnakumar B Fix For: 1.2 I am unable to create a new openwire listener from console. I get the following exception 12:51:25,081 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/activemq-broker/1.1/car?JMSServer=ActiveMQ,ServiceModule=geronimo/activemq-broker/1.1/car,j2eeType=GBean,name=NewOpenWire javax.jms.JMSException: Could not load protocol: openwire. Reason: java.lang.ClassNotFoundException: org.activemq.transport.openwire.OpenWireTransportServerChannelFactory in classloader geronimo/activemq-broker/1.1/car at org.activemq.transport.TransportServerChannelProvider.createJMSexception(TransportServerChannelProvider.java:85) at org.activemq.transport.TransportServerChannelProvider.getFactory(TransportServerChannelProvider.java:79) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:83) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178
[jira] Closed: (GERONIMO-2317) Unable to create a new peer listener from console
[ http://issues.apache.org/jira/browse/GERONIMO-2317?page=all ] Vamsavardhana Reddy closed GERONIMO-2317. - Unable to create a new peer listener from console - Key: GERONIMO-2317 URL: http://issues.apache.org/jira/browse/GERONIMO-2317 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, console Affects Versions: 1.2 Environment: Geronimo 1.1 Reporter: Krishnakumar B I get the following exception when i create a new peer listener from console 12:48:47,655 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/activemq-broker/1.1/car?JMSServer=ActiveMQ,ServiceModule=geronimo/activemq-broker/1.1/car,j2eeType=GBean,name=NewPeer javax.jms.JMSException: Could not load protocol: peer. Reason: java.lang.ClassNotFoundException: org.activemq.transport.peer.PeerTransportServerChannelFactory in classloader geronimo/activemq-broker/1.1/car at org.activemq.transport.TransportServerChannelProvider.createJMSexception(TransportServerChannelProvider.java:85) at org.activemq.transport.TransportServerChannelProvider.getFactory(TransportServerChannelProvider.java:79) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:104) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke
[jira] Closed: (GERONIMO-2316) Unable to create a new Active IO listener from console
[ http://issues.apache.org/jira/browse/GERONIMO-2316?page=all ] Vamsavardhana Reddy closed GERONIMO-2316. - Unable to create a new Active IO listener from console -- Key: GERONIMO-2316 URL: http://issues.apache.org/jira/browse/GERONIMO-2316 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 1.2 Environment: Geronimo 1.1 Reporter: Krishnakumar B I get the following exception when i create a New Active IO Listener from console 12:46:13,784 ERROR [JMSConnectorPortlet] Unable to process portlet action java.lang.NoSuchMethodError: org.activeio.ChannelFactory.bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTransportServerChannelFactory.java:60) at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFactory.java:49) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:104) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext
[jira] Closed: (GERONIMO-2302) Unable to deploy from the console
[ http://issues.apache.org/jira/browse/GERONIMO-2302?page=all ] Vamsavardhana Reddy closed GERONIMO-2302. - Unable to deploy from the console - Key: GERONIMO-2302 URL: http://issues.apache.org/jira/browse/GERONIMO-2302 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Jason Dillon Fix For: 1.2 Attachments: 2302-console-deploy.patch the m2 build makes a server that is not able to deploy from the console The DeploymentFactoryImpl is never started. In the 1.1.1 package (built with m1) the DFI is started by the hot-deploy car, which is commented out in the 1.2 branch (i.e. trunk). Uncommenting that leads to a class not found problem. I added the jsr88 package to the dependencies in the configs/hot-deployer/pom.xml and uncommented the hot-deployer from the list of configs to include by default and things start working again. I have a patch that 'fixes' this (and will attach it) but I think the real problme is elsewhere. Could be that the car plugin is not including transitive dependencies (not sure cause I still don't grok car's). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2295) Web app security constraint ignored if url-pattern doesn't match servlet mapping exactly
[ http://issues.apache.org/jira/browse/GERONIMO-2295?page=all ]
Vamsavardhana Reddy closed GERONIMO-2295.
-
Web app security constraint ignored if url-pattern doesn't match servlet
mapping exactly
Key: GERONIMO-2295
URL: http://issues.apache.org/jira/browse/GERONIMO-2295
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: web, security
Affects Versions: 1.1
Reporter: Aaron Mulder
Assigned To: Alan Cabrera
Priority: Blocker
Fix For: 1.1.1, 1.2
Attachments: SecurityTest.war
If you have the following in your web.xml:
{noformat}
servlet-mapping
servlet-nameSecureServlet/servlet-name
url-pattern/secure/*/url-pattern
/servlet-mapping
login-config
...
/login-config
security-constraint
web-resource-collection
web-resource-nameSecurity Test/web-resource-name
url-pattern/secure/adminonly/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
/web-resource-collection
auth-constraint
role-nameadministrator/role-name
/auth-constraint
/security-constraint
{noformat}
Then the page /secure/adminonly is in fact completely unprotected -- a user
who's not logged in can see it!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2281) Deploy tool does not work (built from new m2 build)
[ http://issues.apache.org/jira/browse/GERONIMO-2281?page=all ] Vamsavardhana Reddy closed GERONIMO-2281. - Deploy tool does not work (built from new m2 build) --- Key: GERONIMO-2281 URL: http://issues.apache.org/jira/browse/GERONIMO-2281 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Jason Dillon Fix For: 1.2 Attachments: 2281-online-deployer.patch A fresh build of geronimo from trunk (with m2) does not have a working deployer. Tested only with the tomcat install but its likely a bug in all. To recreate; build with m2 (follow directions on wiki) install the g-tomcat-1.2-S.tar.gz start the server with bin/startup.sh deploy something with bin/deploy.sh fails to find class javax/enterprise/deploy/spi/status/ProgressListener.class patch adds to the manifest class path of deployer.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Name for administrative security realm
There was only one comment on the proposed name for administrative security realm. Addressing that comment, the new name is geronimo-admin. I hope there won't be any objections with this name. I will wait for 48 hours before committing the change and resolving this name thingy. --vamsi On 11/21/06, Heinz Drews [EMAIL PROTECTED] wrote: The -realm suffix for the name of a realm looks a little bit redundant. Heinz On 11/20/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: How about the name geronimo-admin-realm for administrative security realm? If there are no objections to this, I will apply the patch in 48 hours. --vamsi -- Forwarded message -- From: Vamsavardhana Reddy (JIRA) [EMAIL PROTECTED] Date: Nov 19, 2006 1:31 AM Subject: [jira] Updated: (GERONIMO-931) Rename administrative security realm To: [EMAIL PROTECTED] [ http://issues.apache.org/jira/browse/GERONIMO-931?page=all ] Vamsavardhana Reddy updated GERONIMO-931: - Attachment: GERONIMO-931.patch GERONIMO-931.patch : Renames administrative security realm to admin-realm. After building branches\1.2 with the patch applied, I have done the following verification: 1. Login to admin console successfully 2. Add a new user using Console Realm portlet and add this user to admin group 3. Deploy an application using command line deploy tool using the newly added user credentials 3. Redeploy the application using credentials system/manager Rename administrative security realm Key: GERONIMO-931 URL: http://issues.apache.org/jira/browse/GERONIMO-931 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console, security Affects Versions: 1.0-M4 Reporter: Aaron Mulder Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 Attachments: GERONIMO-931.patch It would be best if the administrative security realm (and login domain) was named AdminRealm or something so it would be more convenient to replace it. Currently it's called properties-login and geronimo-properties-realm and so on. Which makes it pretty awkward to replace it with a database-based realm, for example. This change needs to propogate to web apps including the console. I'm not sure how the remote JMX access handles authentication (as in, for the deploy tool), but presumably that would also need to be switched. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2363) Console: create new pool using wizard, cannot use show plan button for any XA database, even derby
[ http://issues.apache.org/jira/browse/GERONIMO-2363?page=all ] Vamsavardhana Reddy closed GERONIMO-2363. - Fix Version/s: 1.2 2.0 Resolution: Fixed This must have been fixed in rev 478240 (trunk) and rev 478243 (branches\1.2) for javascript validation of input fields in edit Database pools. Console: create new pool using wizard, cannot use show plan button for any XA database, even derby Key: GERONIMO-2363 URL: http://issues.apache.org/jira/browse/GERONIMO-2363 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 1.1.1, 1.2 Reporter: Ted Kirby Fix For: 1.2, 2.0 Attachments: dbwizard_edit.jsp.patch From admin console, click Database Pools, Create new pool using the wizard, choose an XA database type. If you select any driver jars, or none and click show plan, you don't get a plan (all blank), but you do get this traceback in the log/ on the console: 13:48:53,552 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.IllegalArgumentException: Invalid id: at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:899) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:340) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:419) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667
[jira] Updated: (GERONIMO-2566) Creating new listeners for ActiveMQ from JMS Server portlet fails
[ http://issues.apache.org/jira/browse/GERONIMO-2566?page=all ] Vamsavardhana Reddy updated GERONIMO-2566: -- Fix Version/s: 2.0 Assignee: Vamsavardhana Reddy Creating new listeners for ActiveMQ from JMS Server portlet fails - Key: GERONIMO-2566 URL: http://issues.apache.org/jira/browse/GERONIMO-2566 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Environment: sun java 1.5 Reporter: Paul McMahan Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 From the JMS Server portlet click Add new tcp listener. Provide name, host, and port. Click 'save'. The following stacktrace appears in the command window: 16:13:32,703 ERROR [JMSConnectorPortlet] Unable to process portlet action java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.getDeclaredMethods(Class.java:1763) at net.sf.cglib.core.ReflectUtils.addAllMethods(ReflectUtils.java:348) at net.sf.cglib.proxy.Enhancer.getMethods(Enhancer.java:426) at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:456) at net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorS trategy.java:25) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerato r.java:216) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317) at org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactor y.init(BasicProxyManager.java:202) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxyFactory (BasicProxyManager.java:78) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicP roxyManager.java:116) at org.apache.geronimo.console.util.KernelManagementHelper.getObject(Ker nelManagementHelper.java:368) at org.apache.geronimo.console.util.PortletManager.getJMSBroker(PortletM anager.java:274) at org.apache.geronimo.console.util.PortletManager.createJMSConnector(Po rtletManager.java:278) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.pro cessAction(JMSConnectorPortlet.java:80) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD ispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis patcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu bjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve. invoke(GeronimoStandardContext.java:326
[jira] Closed: (GERONIMO-2566) Creating new listeners for ActiveMQ from JMS Server portlet fails
[ http://issues.apache.org/jira/browse/GERONIMO-2566?page=all ] Vamsavardhana Reddy closed GERONIMO-2566. - Resolution: Fixed ClassNotFoundException is due to the classLoader in which the proxy is loaded. Once this is fixed, further investigation revealed problems in ActiveMQManagerGBean and TransportConnectorGBeanImpl. Fixed in rev 478875 (trunk) and rev 478878 (branches\1.2). Creating new listeners for ActiveMQ from JMS Server portlet fails - Key: GERONIMO-2566 URL: http://issues.apache.org/jira/browse/GERONIMO-2566 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2 Environment: sun java 1.5 Reporter: Paul McMahan Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 From the JMS Server portlet click Add new tcp listener. Provide name, host, and port. Click 'save'. The following stacktrace appears in the command window: 16:13:32,703 ERROR [JMSConnectorPortlet] Unable to process portlet action java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerService at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.getDeclaredMethods(Class.java:1763) at net.sf.cglib.core.ReflectUtils.addAllMethods(ReflectUtils.java:348) at net.sf.cglib.proxy.Enhancer.getMethods(Enhancer.java:426) at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:456) at net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorS trategy.java:25) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerato r.java:216) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317) at org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactor y.init(BasicProxyManager.java:202) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxyFactory (BasicProxyManager.java:78) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicP roxyManager.java:116) at org.apache.geronimo.console.util.KernelManagementHelper.getObject(Ker nelManagementHelper.java:368) at org.apache.geronimo.console.util.PortletManager.getJMSBroker(PortletM anager.java:274) at org.apache.geronimo.console.util.PortletManager.createJMSConnector(Po rtletManager.java:278) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.pro cessAction(JMSConnectorPortlet.java:80) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD ispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis patcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu bjectValve.java:56
[jira] Updated: (GERONIMO-2315) On Editing a database pool by changing the database name and restarting it fails to startup
[ http://issues.apache.org/jira/browse/GERONIMO-2315?page=all ] Vamsavardhana Reddy updated GERONIMO-2315: -- Fix Version/s: Verification Required (was: 1.2) (was: 1.1.x) On Editing a database pool by changing the database name and restarting it fails to startup --- Key: GERONIMO-2315 URL: http://issues.apache.org/jira/browse/GERONIMO-2315 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: All Supported Platforms Reporter: Manu T George Fix For: Verification Required Suppose I create an embedded derby Datasource pointing to an embedded DB TestDB and deploy it.It works w/o any problem. Now from the console if i edit the datasorce to point to another db and restart it fails with the exception below 12:31:32,231 ERROR [Servlet] Exception caught: javax.portlet.PortletException: Exception at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.proces sAction(ConfigManagerPortlet.java:107) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 ) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD ispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis patcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke rImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke rImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon tainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP ortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu bjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve. invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero nimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: 541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p rocessConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo int.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol lowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:684) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.geronimo.kernel.config.LifecycleException: start of consol e.dbpool/TestPool/1.0/rar failed
[jira] Updated: (GERONIMO-1383) Connector DConfigBeans don't load correctly from XML
[ http://issues.apache.org/jira/browse/GERONIMO-1383?page=all ] Vamsavardhana Reddy updated GERONIMO-1383: -- Fix Version/s: Verification Required (was: 1.2) Connector DConfigBeans don't load correctly from XML Key: GERONIMO-1383 URL: http://issues.apache.org/jira/browse/GERONIMO-1383 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector, deployment Affects Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: Verification Required When you load an existing geronimo-ra.xml plan using the connector DConfigBeans, most of the incoming data seems to be lost (e.g. there are no connection definition instances). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1880) To Allow configurable password digests during REALM Deployment.
[ http://issues.apache.org/jira/browse/GERONIMO-1880?page=all ] Vamsavardhana Reddy reassigned GERONIMO-1880: - Assignee: Vamsavardhana Reddy To Allow configurable password digests during REALM Deployment. --- Key: GERONIMO-1880 URL: http://issues.apache.org/jira/browse/GERONIMO-1880 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Affects Versions: 1.1 Environment: Geronimo1.1 Reporter: Phani Balaji Madgula Assigned To: Vamsavardhana Reddy Fix For: 1.2 Hi, I observed REALM deployments in TOMCAT, I feel to have same kind of flexibility in specifying password DIGESTs for realms. Tomcat allows password DIGEST to be specified while declaring REALM in server.xml. GlobalNamingResources Resource name=PhaniUserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users-1.xml / /GlobalNamingResources Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=PhaniUserDatabase digest=MD5/ /Engine Now, user can store MD5 digested passwords for the users in tomcat-users-1.xml file as follows. ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=role2/ role rolename=role4/ role rolename=role1/ role rolename=role3/ user username=nag password=9fdc8b3f3027472d64e26a8e88fa2727 roles=role3,role4/ user username=phani password=c49f410c89f1031f816031ba60215f50 roles=role1,role2/ user username=balaji password=e75c1a66ae406db7d2f451b216b10664 roles=role3,role4/ /tomcat-users If user accesses any web application that declared security constraints with role1,role2,role3,role4, Tomcat will challenge the user for authentication where the user needs to specify userid and clear text password. Tomcat will digest the supplied password and compare it with what is specified in the file. Can we have same kind of feature in Geronimo also? That is, to specify DIGEST in REALM deployment plan. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2205) SecurityRealms portlet does not list stopped security realms
[ http://issues.apache.org/jira/browse/GERONIMO-2205?page=all ] Vamsavardhana Reddy updated GERONIMO-2205: -- Fix Version/s: Wish List (was: 1.1.x) (was: 1.2) SecurityRealms portlet does not list stopped security realms Key: GERONIMO-2205 URL: http://issues.apache.org/jira/browse/GERONIMO-2205 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.1 Environment: WinXP, Sun JDK1.4.2_08 Reporter: Vamsavardhana Reddy Fix For: Wish List Security Realms portlet does not list stopped security realms. It lists only those realms running currently. If indeed this is the expected behaviour, there is no need for State column in the listing since it will show runnng for all entries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1880) To Allow configurable password digests during REALM Deployment.
[ http://issues.apache.org/jira/browse/GERONIMO-1880?page=all ] Vamsavardhana Reddy closed GERONIMO-1880. - Fix Version/s: 2.0 Resolution: Fixed PropertiesFileLoginModule and SQLLoginModule now support a digest option. Fixed in rev 478545 (trunk) and rev 478547 (branches\1.2). To Allow configurable password digests during REALM Deployment. --- Key: GERONIMO-1880 URL: http://issues.apache.org/jira/browse/GERONIMO-1880 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Affects Versions: 1.1 Environment: Geronimo1.1 Reporter: Phani Balaji Madgula Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 Hi, I observed REALM deployments in TOMCAT, I feel to have same kind of flexibility in specifying password DIGESTs for realms. Tomcat allows password DIGEST to be specified while declaring REALM in server.xml. GlobalNamingResources Resource name=PhaniUserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users-1.xml / /GlobalNamingResources Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=PhaniUserDatabase digest=MD5/ /Engine Now, user can store MD5 digested passwords for the users in tomcat-users-1.xml file as follows. ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=role2/ role rolename=role4/ role rolename=role1/ role rolename=role3/ user username=nag password=9fdc8b3f3027472d64e26a8e88fa2727 roles=role3,role4/ user username=phani password=c49f410c89f1031f816031ba60215f50 roles=role1,role2/ user username=balaji password=e75c1a66ae406db7d2f451b216b10664 roles=role3,role4/ /tomcat-users If user accesses any web application that declared security constraints with role1,role2,role3,role4, Tomcat will challenge the user for authentication where the user needs to specify userid and clear text password. Tomcat will digest the supplied password and compare it with what is specified in the file. Can we have same kind of feature in Geronimo also? That is, to specify DIGEST in REALM deployment plan. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2591) Database Pools portlet: Create new pool dependency jar selection problems
Database Pools portlet: Create new pool dependency jar selection problems - Key: GERONIMO-2591 URL: http://issues.apache.org/jira/browse/GERONIMO-2591 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 Jar selection in create new pool has problems. The jars selected keep on adding to the list with each pass to the selection page. Suppose you select a1/b1/1/jar in the first step and then revisit the jar selection page either due to an error or by clicking Edit Settings button and then clear a1/b1/1/jar and select something different say a2/b2/2/jar, the first jar still shows in the dependencies in the generated plan. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2591) Database Pools portlet: Create new pool dependency jar selection problems
[ http://issues.apache.org/jira/browse/GERONIMO-2591?page=all ] Vamsavardhana Reddy closed GERONIMO-2591. - Resolution: Fixed Fixed in rev 478218 (trunk) and rev 478219 (branches\1.2). Database Pools portlet: Create new pool dependency jar selection problems - Key: GERONIMO-2591 URL: http://issues.apache.org/jira/browse/GERONIMO-2591 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 Jar selection in create new pool has problems. The jars selected keep on adding to the list with each pass to the selection page. Suppose you select a1/b1/1/jar in the first step and then revisit the jar selection page either due to an error or by clicking Edit Settings button and then clear a1/b1/1/jar and select something different say a2/b2/2/jar, the first jar still shows in the dependencies in the generated plan. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2533) Password setup forms should use a confirmation field
[ http://issues.apache.org/jira/browse/GERONIMO-2533?page=comments#action_12451993 ] Vamsavardhana Reddy commented on GERONIMO-2533: --- Rev 478240 (trunk) and rev 478243 (branches\1.2) fixes edit Database Pool. Password setup forms should use a confirmation field Key: GERONIMO-2533 URL: http://issues.apache.org/jira/browse/GERONIMO-2533 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1, 1.2 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 Some of the functions in admin console (For e.g., in keystores portlet, create new keystore page has a password field) require the user to setup a password. These pages should use a confirm field and validate that the user enters the same input in password and confirm fields. Without this, the users will not know if they have setup a different password than the one they intended to use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Server startup fails with Sun JDK 1.5, xalan missing
Is this the message you thought it didn't make it to the dev-list? It came into my inbox more than 2 hours ago. --vamsi On 11/22/06, anita kulshreshtha [EMAIL PROTECTED] wrote: By setting the following property in geronimo.bat I can start the server (rev 477198, bytecode 1.4, JDK 1.5) without any exceptions. The required class is in rt.jar. This property is not set by default. -Djavax.xml.transform.TransformerFactory= com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl http://forum.java.sun.com/thread.jspa?tstart=30forumID=34threadID=542044trange=15 Thanks Anita I think we need to package xalan implementation with server build via repository, just like xerces and xmlparser. What do you guys say? or I am missing something here. Also notice, Sun JDK 1.4.2 is shipped with Xalan Java 2.4.1, and current version of Xalan available is 2.7, I think we should make Xalan transformet independent of JDK. Unless I'm missing something, either, I'm happy to include Xalan in Geronimo distro. The less we're dependent on a JVM version, the better. Sponsored Link Mortgage rates near 39yr lows. $510k for $1,698/mo. Calculate new payment! www.LowerMyBills.com/lre
Re: Branching trunk and creating 1.2
I know most of us would want to work on trunk. Whatever commits are done to branches\1.2 should also go into trunk. Should some commits done to trunk be considered for branches\1.2 depending on the relevance? --vamsi On 11/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Hi Vamsi, I'd like to try something different. Many of the JIRAs we've moved from release to release to release. I'd like to have people look at the JIRAs and if they are going to work on them then go ahead and assign them to 2.0. Otherwise we'll continue to push them around over, and over again. What do you think ? Other thoughts? On Nov 18, 2006, at 5:15 AM, Vamsavardhana Reddy wrote: Hi Matt, Now that branches\1.2 is created, I think we need to add 2.0 in the Fix version in all the JIRAs marked for 1.2 and 1.x so that they will not closed without merging the fix into the trunk. --vamsi On 11/17/06, Matt Hogstrom [EMAIL PROTECTED] wrote: All, We've been talking about moving 1.2 from trunk to a branch while the final touches are put on it as well as promoting trunk to 2.0- SNAPSHOT and starting the push to Java EE 5.0. At this point it looks like most of the activity that is underway in trunk is complete. Here is the outstanding issues I'm aware of. 1. Upgrade all the license headers and copyright notices to conform to the new ASF guidelines. 2. Need to get some issues with the connectors straightened out. Also, we're down from 200 JIRAs to 88 and still decreasing :) When we get these items straightened out I'd like to go ahead and make the branch tonight if we're good. Dain expressed his concerns about drift in the code base and having lived through the dead-1.2 branch muck he's spot on. We need to make sure that code doesn't get committed in one place and not another. Anyone want to volunteer to be the goat herder? Any other issues people can think of? Matt Hogstrom [EMAIL PROTECTED] When the clouds are full they pour the rain out on the earth; and whether a tree falls to the north, or it falls to the south, wherever the tree falls, there it lies. Matt Hogstrom [EMAIL PROTECTED] When the clouds are full they pour the rain out on the earth;and whether a tree falls to the north, or it falls to the south, wherever the tree falls, there is lies.
SecurityRealm plan generated by portlet
SecurityRealm portlet is currently generating a plan given below. There are no deployment errors. But then the new realm does not get listed in the portlet and the realm could not be used for authentication. What is wrong with this plan? module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; environment moduleId groupIdconsole.realm/groupId artifactIdmyrealm/artifactId version1.0/version typecar/type /moduleId dependencies dependency groupIdorg.apache.geronimo.configs/groupId artifactIdj2ee-security/artifactId typecar/type /dependency /dependencies /environment service name=myrealm class= org.apache.geronimo.security.realm.GenericSecurityRealm xsi:type=dep:gbeanType xmlns:dep= http://geronimo.apache.org/xml/ns/deployment-1.2; xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; attribute name=realmNamemyrealm/attribute reference name=ServerInfo nameServerInfo/name /reference reference name=LoginService nameJaasLoginService/name /reference xml-reference name=LoginModuleConfiguration log:login-config xmlns:log= http://geronimo.apache.org/xml/ns/loginconfig-1.2; log:login-module control-flag=REQUIRED server-side=true wrap-principals=false log:login-domain-namemyrealm/log:login-domain-name log:login-module-class org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule /log:login-module-class log:option name=usersURIvar/security/users.properties/log:option log:option name=groupsURIvar/security/groups.properties/log:option /log:login-module /log:login-config /xml-reference /service /module
[jira] Closed: (GERONIMO-2588) KeyStorePortlet: Locking and unlocking could use some error and info messages
[ http://issues.apache.org/jira/browse/GERONIMO-2588?page=all ] Vamsavardhana Reddy closed GERONIMO-2588. - Resolution: Fixed Fixed in rev 477278 (branches\1.2) and rev 477279 (trunk). KeyStorePortlet: Locking and unlocking could use some error and info messages - Key: GERONIMO-2588 URL: http://issues.apache.org/jira/browse/GERONIMO-2588 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Fix For: 1.2, 2.0 Pages for locking and unlocking of keystores and keys could use some information and error messages in the console. Currently the portlet throws some PortletExceptions and the user will have no clue if something has failed or succeeded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2587) FileKeystoreInstance.loadKeystoreData() results in inconsistent state if wrong password is supplied
FileKeystoreInstance.loadKeystoreData() results in inconsistent state if wrong password is supplied --- Key: GERONIMO-2587 URL: http://issues.apache.org/jira/browse/GERONIMO-2587 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Fix For: 1.2, 2.0 FileKeystoreInstance.loadKeystoreData() results in inconsistent state if the method is called with a wrong password. Though the method throws an exception if called with a wrong password, by the time the exception is thrown, damage is done to the keystore state. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2393) Maven eclipse plugin is generating invalid classpath entries in .classpath
[ http://issues.apache.org/jira/browse/GERONIMO-2393?page=all ] Vamsavardhana Reddy closed GERONIMO-2393. - Fix Version/s: (was: 1.2) Resolution: Invalid Looks like I am the only one who faced this problem. I don't know why this problem occurred. And I don't know how it got fixed. I do not see this problem now. Maven eclipse plugin is generating invalid classpath entries in .classpath -- Key: GERONIMO-2393 URL: http://issues.apache.org/jira/browse/GERONIMO-2393 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: WinXP, G TRUNK Reporter: Vamsavardhana Reddy Attachments: .classpath, .classpath I have run mvn eclipse:eclipse. Upon importing the projects into eclipse, I am noticing the the classpath entries generated have the first letter missing. Here is an example of some classpath entries in .classpath file. classpathentry kind=var path=M2_REPO/ommons-cli/commons-cli/1.0/commons-cli-1.0.jar/ classpathentry kind=var path=M2_REPO/tax/stax-api/1.0/stax-api-1.0.jar/ classpathentry kind=var path=M2_REPO/lassworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar/ classpathentry kind=var path=M2_REPO/rg/apache/maven/maven-repository-metadata/2.0.4/maven-repository-metadata-2.0.4.jar/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2533) Password setup forms should use a confirmation field
[ http://issues.apache.org/jira/browse/GERONIMO-2533?page=comments#action_12451647 ] Vamsavardhana Reddy commented on GERONIMO-2533: --- Rev 477664 (trunk) and rev 477669 (branches\1.2) takes care of the following pages: o KeystorePortlet - New Keystore o KeystorePortlet - Create Private Key o WebServer Portlet - Add/Edit HTTPS Connectors o SecurityRealms Portlet - Create SQL, LDAP Realms Password setup forms should use a confirmation field Key: GERONIMO-2533 URL: http://issues.apache.org/jira/browse/GERONIMO-2533 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1, 1.2 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 Some of the functions in admin console (For e.g., in keystores portlet, create new keystore page has a password field) require the user to setup a password. These pages should use a confirm field and validate that the user enters the same input in password and confirm fields. Without this, the users will not know if they have setup a different password than the one they intended to use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2533) Password setup forms should use a confirmation field
[ http://issues.apache.org/jira/browse/GERONIMO-2533?page=all ] Vamsavardhana Reddy updated GERONIMO-2533: -- Fix Version/s: (was: 1.1.x) Password setup forms should use a confirmation field Key: GERONIMO-2533 URL: http://issues.apache.org/jira/browse/GERONIMO-2533 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1, 1.2 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 Some of the functions in admin console (For e.g., in keystores portlet, create new keystore page has a password field) require the user to setup a password. These pages should use a confirm field and validate that the user enters the same input in password and confirm fields. Without this, the users will not know if they have setup a different password than the one they intended to use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2585) KeystorePortlet: Lock keystore throws NullPointerException
[ http://issues.apache.org/jira/browse/GERONIMO-2585?page=comments#action_12451334 ] Vamsavardhana Reddy commented on GERONIMO-2585: --- Typographic error in my previous comment. Fixed in rev 477190 (branches\1.2). This JIRA is NOT applicable to 1.1. KeystorePortlet: Lock keystore throws NullPointerException -- Key: GERONIMO-2585 URL: http://issues.apache.org/jira/browse/GERONIMO-2585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, console Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 In KeyStore portlet, lock keystore for Availability throws NullPointerException. To recreate the error: 1. Start the server and unlock any keystore for availability. 2. Restart the server 3. Unlock the keystore for availability. This error must have been introduced in rev 465702, fix for GERONIMO-2504. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Closed: (GERONIMO-2585) KeystorePortlet: Lock keystore throws NullPointerException
Thanks for pointing this out. It is a typo. This JIRA is not applicable to 1.1. --vamsi On 11/20/06, Donald Woods [EMAIL PROTECTED] wrote: Did you also check this into branches/1.2, since trunk is now 2.0-SNAPSHOT ? -Donald Vamsavardhana Reddy (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2585?page=all ] Vamsavardhana Reddy closed GERONIMO-2585. - Resolution: Fixed Fixed in rev 477190 (branches\1.1) and rev 477197 (trunk). KeystorePortlet: Lock keystore throws NullPointerException -- Key: GERONIMO-2585 URL: http://issues.apache.org/jira/browse/GERONIMO-2585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, console Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 In KeyStore portlet, lock keystore for Availability throws NullPointerException. To recreate the error: 1. Start the server and unlock any keystore for availability. 2. Restart the server 3. Unlock the keystore for availability. This error must have been introduced in rev 465702, fix for GERONIMO-2504.
[jira] Commented: (GERONIMO-2533) Password setup forms should use a confirmation field
[ http://issues.apache.org/jira/browse/GERONIMO-2533?page=comments#action_12451737 ] Vamsavardhana Reddy commented on GERONIMO-2533: --- Rev 477807 (trunk) and rev 477811 (branches\1.2) takes care of Database Pools portlet. Password setup forms should use a confirmation field Key: GERONIMO-2533 URL: http://issues.apache.org/jira/browse/GERONIMO-2533 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 1.1.1 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 Some of the functions in admin console (For e.g., in keystores portlet, create new keystore page has a password field) require the user to setup a password. These pages should use a confirm field and validate that the user enters the same input in password and confirm fields. Without this, the users will not know if they have setup a different password than the one they intended to use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Name for administrative security realm
How about the name geronimo-admin-realm for administrative security realm? If there are no objections to this, I will apply the patch in 48 hours. --vamsi -- Forwarded message -- From: Vamsavardhana Reddy (JIRA) [EMAIL PROTECTED] Date: Nov 19, 2006 1:31 AM Subject: [jira] Updated: (GERONIMO-931) Rename administrative security realm To: [EMAIL PROTECTED] [ http://issues.apache.org/jira/browse/GERONIMO-931?page=all ] Vamsavardhana Reddy updated GERONIMO-931: - Attachment: GERONIMO-931.patch GERONIMO-931.patch: Renames administrative security realm to admin-realm. After building branches\1.2 with the patch applied, I have done the following verification: 1. Login to admin console successfully 2. Add a new user using Console Realm portlet and add this user to admin group 3. Deploy an application using command line deploy tool using the newly added user credentials 3. Redeploy the application using credentials system/manager Rename administrative security realm Key: GERONIMO-931 URL: http://issues.apache.org/jira/browse/GERONIMO-931 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console, security Affects Versions: 1.0-M4 Reporter: Aaron Mulder Assigned To: Vamsavardhana Reddy Fix For: 1.2, 2.0 Attachments: GERONIMO-931.patch It would be best if the administrative security realm (and login domain) was named AdminRealm or something so it would be more convenient to replace it. Currently it's called properties-login and geronimo-properties-realm and so on. Which makes it pretty awkward to replace it with a database-based realm, for example. This change needs to propogate to web apps including the console. I'm not sure how the remote JMX access handles authentication (as in, for the deploy tool), but presumably that would also need to be switched. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2103) Console config declares dependency on Jetty/Tomcat JAR instead of Jetty/Tomcat CAR
[ http://issues.apache.org/jira/browse/GERONIMO-2103?page=all ] Vamsavardhana Reddy closed GERONIMO-2103. - Resolution: Fixed Neither dependency is needed. See previous comment by David Jencks. Reopen if this is still an issue. Console config declares dependency on Jetty/Tomcat JAR instead of Jetty/Tomcat CAR -- Key: GERONIMO-2103 URL: http://issues.apache.org/jira/browse/GERONIMO-2103 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem, console Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2586) KeystorePortlet: Unlock keystore for availability shows key aliases only when keystore is unlocked for edit
KeystorePortlet: Unlock keystore for availability shows key aliases only when keystore is unlocked for edit --- Key: GERONIMO-2586 URL: http://issues.apache.org/jira/browse/GERONIMO-2586 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.2, 2.0 Reporter: Vamsavardhana Reddy Fix For: 1.2, 2.0 When the keystore is in locked state for both edit and availability, and user attempts to unlock keystore for availability, the list of keys to be unlocked is empty irrespective of keystore contents. Keystore and key passwords used for editing and availability have been thoroughly intertwined. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Can anyone build 1.2?
I could build branches\1.2 successfully (though not in a single attempt). I have not encountered the build error you have hit. --vamsi On 11/22/06, Jason Dillon [EMAIL PROTECTED] wrote: I keep running into car problems, like: snip [INFO] Packaging module configuration: /Users/jason/ws/geronimo/ server-1.2/configs/system-database/target/plan/plan.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] load of org.apache.geronimo.configs/j2ee-deployer/1.2-SNAPSHOT/ car failed Configuration gbean failed to start org.apache.geronimo.configs/j2ee- deployer/1.2-SNAPSHOT/car /snip How useful is that error message... um... not very useful at all. After building openejb2 by hand, trunk appears to build fine... but I can't get 1.2 to build. Has anyone gotten 1.2 to build since the branch was made? --jason
