Axis 2 into Geronimo ?
Hi all, Weare currently working on Axis 2. And we thought to integrate Axis 2 into Geronimo.Wearegoingto integrate axis 2 as the same way axis 1.x integrated. Any comments ? Regards, Anushka Kumar.
Contributing with Geronimo
Hi All, I'm really interesting in Geronimo.can i participating with ur development?how can i start? regards Gayan
Re: Contributing with Geronimo
On 9/14/05, Gayan Jayalathge [EMAIL PROTECTED] wrote: I'm really interesting in Geronimo.can i participating with ur development?how can i start? Gayan, Take a look through the list of JIRA issues for Geronimo, find something that fits/interests you and get started. Submitting patches for issues is a great way to get noticed. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
[discussion] How do we get help with testing?
I'd like to discuss how we might expand our efforts in the area of testing and QA. Now that we're getting into the habit of J2EE certified releases, we have a much bigger testing load - we want to have more testing happening continuously between releases, and then at release time have a wide matrix of tested platforms. All of this takes work, lots of work. The short answer is that we need more people interested in testing, and we need to find a place for them in the project. Right now, our policy is that committers are able to get access to the TCK and participate on the private TCK mail list. I'd like to maintain this concept - that people with access to these materials and discussion have a demonstrable tie to the project - but I think we should discuss something along the lines of a QA committer, someone who can begin their participation in the project focused on testing (and of course over time move to whatever they show interested an aptitude in. It's a big, serious job (far bigger and far more serious than I ever thought), and we certainly need the help. Comments? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Commented: (GERONIMO-1009) CMR One-Many Primitive in Trade is not working correctly.
[ http://issues.apache.org/jira/browse/GERONIMO-1009?page=comments#action_12324518 ] Gianny Damour commented on GERONIMO-1009: - This is a mapping problem. I attach an updated version of the DD. In a few words, only one ejb-relationship-role element must be specified for OTO and OTM relationships. I think that the implementation should be improved to detect when two ejb-relationship-role elements are specified for a OTO or OTM and warn that only one of them will be used. CMR One-Many Primitive in Trade is not working correctly. - Key: GERONIMO-1009 URL: http://issues.apache.org/jira/browse/GERONIMO-1009 Project: Geronimo Type: Bug Versions: 1.0-M5 Environment: All Reporter: Matt Hogstrom Priority: Critical Attachments: Table.ddl, dayTrader-plan.xml I have been testing Trade with Geronimo and had a problem with CMRs not appearing to work correctly. I have forwarded the required into to Gianny to re-create the problem. I got Trade Deployed on another non-WebSphere AppServer today and confirmed that it is work there as well. The steps to get Trade working are: Create the Derby Database: connect 'jdbc:derby://localhost:1527/tradedb;create=true'; run 'Table.ddl'; commit; deploy the year dayTrader.ear with plan dayTeader-plan.xml Go to configure and populate the database Then Select Primitives and run the PingServlet2CMROne2Many -- 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-1009) CMR One-Many Primitive in Trade is not working correctly.
[ http://issues.apache.org/jira/browse/GERONIMO-1009?page=all ] Gianny Damour updated GERONIMO-1009: Attachment: dayTrader-plan-fixed.xml CMR One-Many Primitive in Trade is not working correctly. - Key: GERONIMO-1009 URL: http://issues.apache.org/jira/browse/GERONIMO-1009 Project: Geronimo Type: Bug Versions: 1.0-M5 Environment: All Reporter: Matt Hogstrom Priority: Critical Attachments: Table.ddl, dayTrader-plan-fixed.xml, dayTrader-plan.xml I have been testing Trade with Geronimo and had a problem with CMRs not appearing to work correctly. I have forwarded the required into to Gianny to re-create the problem. I got Trade Deployed on another non-WebSphere AppServer today and confirmed that it is work there as well. The steps to get Trade working are: Create the Derby Database: connect 'jdbc:derby://localhost:1527/tradedb;create=true'; run 'Table.ddl'; commit; deploy the year dayTrader.ear with plan dayTeader-plan.xml Go to configure and populate the database Then Select Primitives and run the PingServlet2CMROne2Many -- 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: [discussion] How do we get help with testing?
here is my +1 really i'm just going to star my particpation with the project. i'd like to try with testing things also. Chin
Re: [discussion] How do we get help with testing?
1+ for me also. I am also interested in contributions. Regards Krishnakumar B On 9/14/05, Chinthaka Thilakarathna [EMAIL PROTECTED] wrote: here is my +1 really i'm just going to star my particpation with the project. i'd like to try with testing things also. Chin
Re: mirroring our downloads
Jeremy Boynes wrote: Brett Porter wrote: On 9/8/05, Brett Porter [EMAIL PROTECTED] wrote: For the old releases, once they appear in archive.apache.orghttp://archive.apache.org, you can probably delete them from www.apache.org http://www.apache.org(this will mean they aren't mirrored, but available from the archive). Can I ask that you delete the M2 and M3 POMs from java-repository? They aren't independantly valid or useful and Maven's repository management has started to squawk. Recent versions of the Maven artifact deployment plugin will properly resolve the variables in them to make them useful for future releases. Does anyone mind if I do this? Other than redeploying those releases using a newer version of the artifact plugin that resolves the entities and parent poms, I don't see an easy way to get these corrected. IMO, delete away - M2 and M3 are so old now they are not really relevant and should be removed. +1 - I don't think there is any need to keep them. John -- Jeremy
Re: subproject site
Requests are rolling in on where to pick up the binaries. Where exactly should I drop the image so I can make it available ASAP? Sachin. Sachin Patel wrote: I've updated the subproject page with a few basic sections and info. I'm ready to create a link to binary distribution to the eclipse plugin. Where do I need to drop the image to? Thanks. Sachin.
Re: Tomcat, logging, admin portlet, and GBeans
Having received no negative comments on this design I am in the process of implementing this design. I'm first just going to get Jetty log code updated under this new architecture. Then I'll deliver another JIRA to add in the tomcat support. The changes will include: - Introduction of a new interface called WebAccessLogHelper in org.apache.geronimo.management.geronimo. This is a container agnostic helper interface to interact with web logs. - Addition of a new method to the WebManager to return a reference to a WebAccesslogHelper for the appropriate container. - Introduction of a new class which is an implementation of WebAccessLogHelper called WebAccessLogHelperJettyImpl (I know ... kinda long) in org.apache.geronimo.management.geronimo - Introduction of a new class WebAccessLogCriteria which will be used to quality the content requested. - Update of the WebAccessLogViewerPortlet to utilize the new structure which will include instantiation of a WebAccessLogCriteria prior to queries. - Removal of console-standard classes for WebAccessLogHelper and WebAccessLogCriteria Joe Bohn wrote: Aaron Mulder wrote: In order to do this right, I think we should define an interface for web server request log access. That interface should have a method that searches the logs, like the server log GBean does, so rather than the console code asking the web server for log files and then opening files and scanning them, the console should pass a bunch of search parameters to the web server, and the web server should identify and search its own logs and just return the results to the console. If the web server has multiple logs, I guess it should have a method that gets a list of log file names, so the portlet can let you select the log to query, and the search method can take the log file name as a parameter. I have an outstanding task to rearrange the management interface works for the web containers and connectors, so part of that can be exposing the log manager or whatever we call the interface mentioned above. So after those changes, the code should look something like this: J2EEServer server = ... WebManager[] managers = ... server.getWebManagers(); (select Tomcat or Jetty WebManager to work with) RequestLogManager log = ... managers[i].getRequestLog(); (do log stuff such as: String[] logFiles = log.getLogFiles(); LogLine[] hits = log.searchLogs(logFile, start, end, maxRows, ...); ) To resurrect this item I would propose the following: - We continue to assume that there will be only 1 container and hence 1 Web Manager in an image (see my earlier question on this point). - As you suggest we add a mechanism to the WebManager to get access to logs. - Create an Interface (WebAccessLogHelper) with methods similar to the class methods on the current WebAccessLogHelper class. There will be some additions for handling multiple logs and some other changes (see below). - Create implementations of the WebAccessLogHelper for each supported container type. - Add a method to the WebManager to return a reference to the appropriate WebAccessLogHelper implementation for the container. - Have the portlet interact with the WebAccessLogHelper and in particular make queries via an enhanced WebAcessLogCriteria object (enhanced to include the log selection, max# of records to return, etc...). So the WebAccessLogViewerPortlet pseudo-code would look something like this: J2EEServer server = WebManager[] managerArray = server.getWebManagers(); WebManager manager = WebManagers[0]; // select the first manager in the set for now. If we support multiple managers we can enhance this for some user selection. WebAccessLogHelper logHelper = manager.getLogHelper(); // No need to query the container type .. that's hidden behind the implementation of the log helper interface. ArrayList logs = logHelper.getLogs() // to return a list of logs for display/selection (initially select the first log in the list) File[] files = logHelper.getFiles() // to return a list of files for display only (for those who would like to see the actual files and the locations). WebAccessLogCriteria = new WebAccessLogCriteria( criteria defaults .. including the selected log). ArrayList searchResults = WebAccessLogHelp.searchLogs( criteria); Criteria would include most of what there is is today with some minor changes: - selected Log (user can select from list if more than one). - Start date/time - End data/time - Host - authUser - method - URI - message - max # of messages to return - Starting record # (for displaying subsequent pages). To get started, perhaps you could propose an interface for the RequestLogManager or whatever we call it, and look at how we could implement that for Tomcat and Jetty. Thanks, Aaron On Wed, 31 Aug 2005, Joe Bohn wrote: I was investigating what is necessary to get the log management portlet in the console working for tomcat. It currently
Re: Axis 2 into Geronimo ?
Excellent! Please ask if you have any questions, I will be glad to help. Many thanks, david jencks On Sep 14, 2005, at 12:03 AM, Anushka Kumar wrote: Hi all, We are currently working on Axis 2. And we thought to integrate Axis 2 into Geronimo. We are going to integrate axis 2 as the same way axis 1.x integrated. Any comments ? Regards, Anushka Kumar.
Re: mirroring our downloads
On Sep 13, 2005, at 10:46 PM, John Sisson wrote: Jeremy Boynes wrote: Brett Porter wrote: On 9/8/05, Brett Porter [EMAIL PROTECTED] wrote: For the old releases, once they appear in archive.apache.orghttp://archive.apache.org, you can probably delete them from www.apache.org http://www.apache.org(this will mean they aren't mirrored, but available from the archive). Can I ask that you delete the M2 and M3 POMs from java-repository? They aren't independantly valid or useful and Maven's repository management has started to squawk. Recent versions of the Maven artifact deployment plugin will properly resolve the variables in them to make them useful for future releases. Does anyone mind if I do this? Other than redeploying those releases using a newer version of the artifact plugin that resolves the entities and parent poms, I don't see an easy way to get these corrected. IMO, delete away - M2 and M3 are so old now they are not really relevant and should be removed. +1 - I don't think there is any need to keep them. +1 me three david jencks
[jira] Assigned: (GERONIMO-956) Remove global JNDI space
[ http://issues.apache.org/jira/browse/GERONIMO-956?page=all ] David Jencks reassigned GERONIMO-956: - Assign To: David Jencks Remove global JNDI space -- Key: GERONIMO-956 URL: http://issues.apache.org/jira/browse/GERONIMO-956 Project: Geronimo Type: Improvement Components: connector, naming Versions: 1.0-M4 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 1.0 Geronimo has a global JNDI space under geronimo:. However: - it's only used by connectors, not EJBs - it's not visible outside the current VM It doesn't seem like this is really benefitting anyone. The effort necessary to make it behave like JNDI behaves in other popular app servers seems to be significant. After talking on IRC, David J and I are soliciting feedback on removing this feature entirely for now. Note: this is different than the JNDI space that OpenEJB uses to expose EJBs to remote clients, which takes EJBs only and is obviously accessible to remote clients. We are not proposing to change that at this time. -- 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-984) Console throws OutOfBoundsexception when app erroneously has a global-jndi/global-jndi tag
[ http://issues.apache.org/jira/browse/GERONIMO-984?page=all ] David Jencks updated GERONIMO-984: -- Component: connector Fix Version: 1.0-M5 Version: 1.0-M5 Assign To: David Jencks Console throws OutOfBoundsexception when app erroneously has a global-jndi/global-jndi tag -- Key: GERONIMO-984 URL: http://issues.apache.org/jira/browse/GERONIMO-984 Project: Geronimo Type: Bug Components: connector Versions: 1.0-M5 Reporter: Matt Hogstrom Assignee: David Jencks Fix For: 1.0-M5 Attachments: patch.diff In a deployment plan the datasource has a global-jndi/global-jndi specificed and it is being interpreted incorrectly. The jndi-name of is being set which is not expected in the rest of the infrastructure. Rather than taking an exception the user should be warned and the tag should be ignored. I have updated ConnectorModuleBuilder.java with the code to do this. The message issued is: 01:47:26,150 WARN [ConnectorModuleBuilder] Connector includes a definition for a global-jndi but specifies no value. The attribute is ignored. Update the attribute with the desired value or remove the tag to avoid this message. -- 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
cleanup sandbox?
Anyone have any objections of me deleting the eclipse plugin from the sandbox? Sachin
Re: cleanup sandbox?
go ahead, please thanks david jencks On Sep 14, 2005, at 12:59 PM, Sachin Patel wrote: Anyone have any objections of me deleting the eclipse plugin from the sandbox? Sachin
[jira] Created: (GERONIMO-1012) Tomcat integration does not set a subject in an unsecured web module in a secured ejb application
Tomcat integration does not set a subject in an unsecured web module in a secured ejb application - Key: GERONIMO-1012 URL: http://issues.apache.org/jira/browse/GERONIMO-1012 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M5 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.0-M5 In the jetty integration, in SecurityContextBeforeAfter, a request for an unsecured page results in the default subject being set in the ContextManager (line 288). This provides a way to call secured ejbs and also provides a source for credentials for calling secured web services. In tomcat, we don't do anything like that: in particular there is no source of credentials for secured web services. I think the simplest solution is to, if the app is secured, to add another valve after the standard tomcat security valve, that sets the default subject into the ContextManager if none is there already. -- 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: cleanup sandbox?
go for it On Sep 14, 2005, at 3:59 PM, Sachin Patel wrote: Anyone have any objections of me deleting the eclipse plugin from the sandbox? Sachin -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: cleanup sandbox?
Can't. don't seem have access to. svn: Commit failed (details follow): svn: MKACTIVITY of '/repos/asf/!svn/act/ce52050a-eb98-7e4d-b356-4423c850977c': 403 Forbidden (http://svn.apache.org) Geir Magnusson Jr wrote: go for it On Sep 14, 2005, at 3:59 PM, Sachin Patel wrote: Anyone have any objections of me deleting the eclipse plugin from the sandbox? Sachin --Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: cleanup sandbox?
On Sep 14, 2005, at 1:36 PM, Sachin Patel wrote: Wait, I think its because i didn't checkout using https. That would do it :-) Whats the trick to convert it? svn switch --relocate ... I can't figure out exactly what the rest of the command should be though. Do you have the svn book? david jencks Sachin Patel wrote: Can't. don't seem have access to. svn: Commit failed (details follow): svn: MKACTIVITY of '/repos/asf/!svn/act/ce52050a-eb98-7e4d-b356-4423c850977c': 403 Forbidden (http://svn.apache.org) Geir Magnusson Jr wrote: go for it On Sep 14, 2005, at 3:59 PM, Sachin Patel wrote: Anyone have any objections of me deleting the eclipse plugin from the sandbox? Sachin --Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: cleanup sandbox?
svn switch [URL] [path] David Jencks wrote: On Sep 14, 2005, at 1:36 PM, Sachin Patel wrote: Wait, I think its because i didn't checkout using https. That would do it :-) Whats the trick to convert it? svn switch --relocate ... I can't figure out exactly what the rest of the command should be though. Do you have the svn book? david jencks Sachin Patel wrote: Can't. don't seem have access to. svn: Commit failed (details follow): svn: MKACTIVITY of '/repos/asf/!svn/act/ce52050a-eb98-7e4d-b356-4423c850977c': 403 Forbidden (http://svn.apache.org) Geir Magnusson Jr wrote: go for it On Sep 14, 2005, at 3:59 PM, Sachin Patel wrote: Anyone have any objections of me deleting the eclipse plugin from the sandbox? Sachin --Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: cleanup sandbox?
If you can't get it to work, bellow and I can do it... On Sep 14, 2005, at 4:50 PM, Sachin Patel wrote: svn switch [URL] [path] David Jencks wrote: On Sep 14, 2005, at 1:36 PM, Sachin Patel wrote: Wait, I think its because i didn't checkout using https. That would do it :-) Whats the trick to convert it? svn switch --relocate ... I can't figure out exactly what the rest of the command should be though. Do you have the svn book? david jencks Sachin Patel wrote: Can't. don't seem have access to. svn: Commit failed (details follow): svn: MKACTIVITY of '/repos/asf/!svn/act/ce52050a-eb98-7e4d- b356-4423c850977c': 403 Forbidden (http://svn.apache.org) Geir Magnusson Jr wrote: go for it On Sep 14, 2005, at 3:59 PM, Sachin Patel wrote: Anyone have any objections of me deleting the eclipse plugin from the sandbox? Sachin --Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: cleanup sandbox?
Its done. Thanks. Geir Magnusson Jr wrote: If you can't get it to work, bellow and I can do it... On Sep 14, 2005, at 4:50 PM, Sachin Patel wrote: svn switch [URL] [path] David Jencks wrote: On Sep 14, 2005, at 1:36 PM, Sachin Patel wrote: Wait, I think its because i didn't checkout using https. That would do it :-) Whats the trick to convert it? svn switch --relocate ... I can't figure out exactly what the rest of the command should be though. Do you have the svn book? david jencks Sachin Patel wrote: Can't. don't seem have access to. svn: Commit failed (details follow): svn: MKACTIVITY of '/repos/asf/!svn/act/ce52050a-eb98-7e4d-b356-4423c850977c': 403 Forbidden (http://svn.apache.org) Geir Magnusson Jr wrote: go for it On Sep 14, 2005, at 3:59 PM, Sachin Patel wrote: Anyone have any objections of me deleting the eclipse plugin from the sandbox? Sachin --Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] --Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Created: (GERONIMO-1013) run-as for servlets in jetty is not implemented
run-as for servlets in jetty is not implemented --- Key: GERONIMO-1013 URL: http://issues.apache.org/jira/browse/GERONIMO-1013 Project: Geronimo Type: Bug Components: web Versions: 1.0-M5 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.0-M5 run-as for servlets in jetty is not implemented, oops -- 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-1013) run-as for servlets in jetty is not implemented
[ http://issues.apache.org/jira/browse/GERONIMO-1013?page=all ] David Jencks closed GERONIMO-1013: -- Resolution: Fixed Not exactly tested, but just needed to put the run-as element from the web.xml into the servlet holder. Sending modules/jetty/src/java/org/apache/geronimo/jetty/JettyServletHolder.java Deleting modules/jetty/src/test-resources/deployables/war3/WEB-INF/jetty-web.xml Sending modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java Transmitting file data .. Committed revision 289133. run-as for servlets in jetty is not implemented --- Key: GERONIMO-1013 URL: http://issues.apache.org/jira/browse/GERONIMO-1013 Project: Geronimo Type: Bug Components: web Versions: 1.0-M5 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0-M5 run-as for servlets in jetty is not implemented, oops -- 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-1012) Tomcat integration does not set a subject in an unsecured web module in a secured ejb application
[ http://issues.apache.org/jira/browse/GERONIMO-1012?page=comments#action_12329378 ] David Jencks commented on GERONIMO-1012: I've fixed this for web apps that have no security constraints but are part of a secured j2ee application. I don't see how to fix it for unsecured pages on web apps with constraints: it appears we'd have to rewrite/copy/modify the authentication valves. I'm leaving this open in the hopes someone can find a better solution. Sendingmodules/tomcat/project.xml Sending modules/tomcat/src/java/org/apache/geronimo/tomcat/GeronimoStandardContext.java Adding modules/tomcat/src/java/org/apache/geronimo/tomcat/valve/DefaultSubjectValve.java Sending modules/tomcat/src/java/org/apache/geronimo/tomcat/valve/PolicyContextValve.java Transmitting file data Committed revision 289136. Tomcat integration does not set a subject in an unsecured web module in a secured ejb application - Key: GERONIMO-1012 URL: http://issues.apache.org/jira/browse/GERONIMO-1012 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M5 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0-M5 In the jetty integration, in SecurityContextBeforeAfter, a request for an unsecured page results in the default subject being set in the ContextManager (line 288). This provides a way to call secured ejbs and also provides a source for credentials for calling secured web services. In tomcat, we don't do anything like that: in particular there is no source of credentials for secured web services. I think the simplest solution is to, if the app is secured, to add another valve after the standard tomcat security valve, that sets the default subject into the ContextManager if none is there already. -- 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-1012) Tomcat integration does not set a subject in an unsecured web module in a secured ejb application
[ http://issues.apache.org/jira/browse/GERONIMO-1012?page=all ] David Jencks reassigned GERONIMO-1012: -- Assign To: Jeff Genender (was: David Jencks) Jeff, can you think of a better way to do this? Tomcat integration does not set a subject in an unsecured web module in a secured ejb application - Key: GERONIMO-1012 URL: http://issues.apache.org/jira/browse/GERONIMO-1012 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M5 Reporter: David Jencks Assignee: Jeff Genender Fix For: 1.0-M5 In the jetty integration, in SecurityContextBeforeAfter, a request for an unsecured page results in the default subject being set in the ContextManager (line 288). This provides a way to call secured ejbs and also provides a source for credentials for calling secured web services. In tomcat, we don't do anything like that: in particular there is no source of credentials for secured web services. I think the simplest solution is to, if the app is secured, to add another valve after the standard tomcat security valve, that sets the default subject into the ContextManager if none is there already. -- 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-982) After GBean changes some JSR77 objects don't have a statisticsProvider attribute
[ http://issues.apache.org/jira/browse/GERONIMO-982?page=all ] Jeremy Boynes closed GERONIMO-982: -- Resolution: Fixed Resolved in various commits After GBean changes some JSR77 objects don't have a statisticsProvider attribute Key: GERONIMO-982 URL: http://issues.apache.org/jira/browse/GERONIMO-982 Project: Geronimo Type: Bug Components: management Reporter: Jeremy Boynes Assignee: Jeremy Boynes Priority: Blocker Fix For: 1.0-M5 Ones that I think may be affected are: javamailresource jcamanagedconnectionfactory jcaresource jtaresource resourceadapter jcaconnectionfactory statefulsessionbean statelesssessionbean -- 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-983) Memory used by proxies isn't released by dereferencing the proxy (I speculate)
[ http://issues.apache.org/jira/browse/GERONIMO-983?page=comments#action_12329382 ] Kevan Miller commented on GERONIMO-983: --- Aaron's diagnosis is correct... o.a.g.kernel.basic.BasicProxyManager.interceptors (an IdentityHashMap) is holding onto the Proxies (around 30 objects per 5 second sampling interval). o.a.g.console.Jsr77Lookup is gathering data to return Server statistics. Which is done by retrieving Domains, Servers, and JVMs from oag.console.util.KernelManagementHelper. KernelManagementHelper is calling createProxy() for these objects. However, users of KernelManagementHelper don't really know that they are retrieving proxies. Nor does it provide a method which would allow proxies to be destroyed. Since there is no caching of these objects, the process is repeated every n-seconds. I discussed with David Jencks on IRC. Options seem to be: 1. Update the console code to explicitly destroy the proxies 2. Implement a WeakIdentityHashMap (or is that an IdentityWeakHashMap?) that could be used by BasicProxyManager. 3. Use a WeakHashMap with keys that are suitably unique (i.e. they don't implement equals(Object); 2 and 3 are predicated on the requirement that the Callback object (or any objects that it refers to) cannot refer to the Proxy object (the key). Memory used by proxies isn't released by dereferencing the proxy (I speculate) -- Key: GERONIMO-983 URL: http://issues.apache.org/jira/browse/GERONIMO-983 Project: Geronimo Type: Bug Components: console, kernel Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: 1.0-M5 On Wed, 7 Sep 2005, Neal Sanche wrote: I compiled up a new Geronimo, and then I left it running with the Server Info page displayed so I could see the cool AJX work there... and then I forgot about it for a day or so. When I got back it was saying: 20:56:53,219 WARN [ThreadedServer] EXCEPTION java.lang.OutOfMemoryError: Java heap space On Wed, 7 Sep 2005, Neal Sanche wrote: Well, I did some profiling, and found that the predominant object that was being retained was: org.apache.geronimo.kernel.basic.RawGetAttributeInvoker There are also another slowly growing group of geronimo classes that seem to pile up, and they aren't getting garbage collected either: org.apache.geronimo.kernel.basic.ProxyMethodInterceptor and many internal classes of this class. The console uses lots of proxies and doesn't manually close them, just releases the references. Seems like this leaks memory. -- 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-956) Remove global JNDI space
[ http://issues.apache.org/jira/browse/GERONIMO-956?page=comments#action_12329386 ] David Jencks commented on GERONIMO-956: --- Along with removing the global-jndi-name tag I'm cleaning up the schema by: removing version=1.5 attribute removing connection-manager-ref element (this might theoretically be useful but it should use the gbean name component approach. I don't think anyone is very likely to implement their own connection manager. If they do we'll put it back) removing credential-interface element (not used) I'm going to commit the removal, check the tck, and then add some code in a day or two to strip the no-longer-valid elements out and warn the user. Remove global JNDI space -- Key: GERONIMO-956 URL: http://issues.apache.org/jira/browse/GERONIMO-956 Project: Geronimo Type: Improvement Components: connector, naming Versions: 1.0-M4 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 1.0 Geronimo has a global JNDI space under geronimo:. However: - it's only used by connectors, not EJBs - it's not visible outside the current VM It doesn't seem like this is really benefitting anyone. The effort necessary to make it behave like JNDI behaves in other popular app servers seems to be significant. After talking on IRC, David J and I are soliciting feedback on removing this feature entirely for now. Note: this is different than the JNDI space that OpenEJB uses to expose EJBs to remote clients, which takes EJBs only and is obviously accessible to remote clients. We are not proposing to change that at this time. -- 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] Assigned: (GERONIMO-1012) Tomcat integration does not set a subject in an unsecured web module in a secured ejb application
I don't think we need another valve, could we not do this in one of the existing valves? Jeff David Jencks (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1012?page=all ] David Jencks reassigned GERONIMO-1012: -- Assign To: Jeff Genender (was: David Jencks) Jeff, can you think of a better way to do this? Tomcat integration does not set a subject in an unsecured web module in a secured ejb application - Key: GERONIMO-1012 URL: http://issues.apache.org/jira/browse/GERONIMO-1012 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M5 Reporter: David Jencks Assignee: Jeff Genender Fix For: 1.0-M5 In the jetty integration, in SecurityContextBeforeAfter, a request for an unsecured page results in the default subject being set in the ContextManager (line 288). This provides a way to call secured ejbs and also provides a source for credentials for calling secured web services. In tomcat, we don't do anything like that: in particular there is no source of credentials for secured web services. I think the simplest solution is to, if the app is secured, to add another valve after the standard tomcat security valve, that sets the default subject into the ContextManager if none is there already. -- Jeff Genender http://geronimo.apache.org
Re: [jira] Assigned: (GERONIMO-1012) Tomcat integration does not set a subject in an unsecured web module in a secured ejb application
Never mind...I didn't read the other emails...I'll have a look. Jeff Jeff Genender wrote: I don't think we need another valve, could we not do this in one of the existing valves? Jeff David Jencks (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1012?page=all ] David Jencks reassigned GERONIMO-1012: -- Assign To: Jeff Genender (was: David Jencks) Jeff, can you think of a better way to do this? Tomcat integration does not set a subject in an unsecured web module in a secured ejb application - Key: GERONIMO-1012 URL: http://issues.apache.org/jira/browse/GERONIMO-1012 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0-M5 Reporter: David Jencks Assignee: Jeff Genender Fix For: 1.0-M5 In the jetty integration, in SecurityContextBeforeAfter, a request for an unsecured page results in the default subject being set in the ContextManager (line 288). This provides a way to call secured ejbs and also provides a source for credentials for calling secured web services. In tomcat, we don't do anything like that: in particular there is no source of credentials for secured web services. I think the simplest solution is to, if the app is secured, to add another valve after the standard tomcat security valve, that sets the default subject into the ContextManager if none is there already.
