[jira] Assigned: (GERONIMO-827) Change CMR mapping name elements to descriptions
[ http://issues.apache.org/jira/browse/GERONIMO-827?page=all ] Gianny Damour reassigned GERONIMO-827: -- Assign To: Gianny Damour Change CMR mapping name elements to descriptions Key: GERONIMO-827 URL: http://issues.apache.org/jira/browse/GERONIMO-827 Project: Geronimo Type: Improvement Components: OpenEJB Versions: 1.0-M4 Reporter: Aaron Mulder Assignee: Gianny Damour Fix For: 1.0-M5 Change the ejb-relation-name and ejb-relationship-role-name elements in openejb-jar.xml at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ejb-relationship-role-name To be description elements instead, since they're not actually used by the server and are for documentation purposes only. -- 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-827) Support CMR mapping via ejb-relation-name and ejb-relationship-role-name
[ http://issues.apache.org/jira/browse/GERONIMO-827?page=all ] Gianny Damour updated GERONIMO-827: --- Summary: Support CMR mapping via ejb-relation-name and ejb-relationship-role-name (was: Change CMR mapping name elements to descriptions) Description: Use: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ejb-relationship-role-name to identify a relationship mapping. was: Change the ejb-relation-name and ejb-relationship-role-name elements in openejb-jar.xml at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ejb-relationship-role-name To be description elements instead, since they're not actually used by the server and are for documentation purposes only. Support CMR mapping via ejb-relation-name and ejb-relationship-role-name Key: GERONIMO-827 URL: http://issues.apache.org/jira/browse/GERONIMO-827 Project: Geronimo Type: Improvement Components: OpenEJB Versions: 1.0-M4 Reporter: Aaron Mulder Assignee: Gianny Damour Fix For: 1.0-M5 Use: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ejb-relationship-role-name to identify a relationship mapping. -- 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-827) Support CMR mapping via ejb-relation-name and ejb-relationship-role-name
[ http://issues.apache.org/jira/browse/GERONIMO-827?page=all ] Gianny Damour closed GERONIMO-827: -- Resolution: Fixed This is now implemented. Support CMR mapping via ejb-relation-name and ejb-relationship-role-name Key: GERONIMO-827 URL: http://issues.apache.org/jira/browse/GERONIMO-827 Project: Geronimo Type: Improvement Components: OpenEJB Versions: 1.0-M4 Reporter: Aaron Mulder Assignee: Gianny Damour Fix For: 1.0-M5 Use: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ejb-relationship-role-name to identify a relationship mapping. -- 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: Move console out of sandbox?
+1 to move it to the main build. Gianny On 5/08/2005 4:58 AM, Jeremy Boynes wrote: At the Geronimo BOF last night there was discussion about moving the web console out of the sandbox and into the main build - general consensus seem to be something was better than nothing :-) Any objection to moving it over? -- Jeremy
[jira] Closed: (GERONIMO-665) CMP - Prefetching of CMP and CMR fields
[ http://issues.apache.org/jira/browse/GERONIMO-665?page=all ] Gianny Damour closed GERONIMO-665: -- Fix Version: 1.0-M5 Resolution: Fixed This is now fully implemented. CMP - Prefetching of CMP and CMR fields --- Key: GERONIMO-665 URL: http://issues.apache.org/jira/browse/GERONIMO-665 Project: Geronimo Type: New Feature Components: OpenEJB Versions: 1.0-M4 Reporter: Gianny Damour Assignee: Gianny Damour Priority: Minor Fix For: 1.0-M5 The CMP engine needs to be improved to allow for the prefetching of CMP and CMR fields. When a CMP field needs to be fetched from the underlying database, it should be possible to specify a group of related CMP and CMR fields to be loaded at the same time (the current implementation fetches all the CMP fields and we have no mean to control this behavior). Also, when a CMR field is loaded as part of a group, it should also be possible to specify a group a CMP and CMR fields defined by the related EntityBean to be loaded at the same time. The same type of capability needs to be supported for CMR fields, finders and selects. -- 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: JMS configuration plans and config.list questions
Well I'm still feeling my way around the web console code, but it looks to me like they are expecting users to add more queues to the org/apache/geronimo/SystemJMS config. What should be be encouraging them to do ... that's the harder question. I'll look for somebody else to answer that one. :-) However, I'm looking at a problem that may end up being related to (or affected by) the configuration. The Web Console includes capabilities to manage JMS connection factories and destinations (adding/removing queues and topics). However, the portlet to manage the factories is currently failing with an exception because it assumes that there is a "state" attribute on the each factory GBean and this attribute doesn't exist on the DefaultActiveMQConnectionFactory. So I wonder if the portlet is in error looking for the wrong attribute or the factory GBean is in error for not defining the attribute. Of course, if we remove the queues and factory defined in SystemJMS then this eliminates the problem (at least on the DefaultActionMQConnectionFactory). - Joe [EMAIL PROTECTED] wrote: The org/apache/geronimo/SystemJMS config defines an ActiveMQ resource adapter ( and the DefaultActiveMQConnectionFactory ) , MDBTransferBeanOutQueue and SendReceiveQueue admin objects. Should the two queues be removed ( I assume they were there for testing in the past)? Are we expecting users of the web console ( I haven't played with yet) adding more queues to the org/apache/geronimo/SystemJMS config, or should we be encouraging them to use their own config? If we aren't expecting users to be able to add more queues to the org/apache/geronimo/SystemJMS config, then should the org/apache/geronimo/SystemJMS config be removed from the config.list and replaced with org/apache/geronimo/ActiveMQServer? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: JMS configuration plans and config.list questions
On Aug 5, 2005, at 6:32 AM, Joe Bohn wrote: Well I'm still feeling my way around the web console code, but it looks to me like they are expecting users to add more queues to the org/apache/geronimo/SystemJMS config. I don't think this is possible yet, although I think aaron is working on a way to make it possible shortly. I believe that each new queue is currently added to a new configuration. What should be be encouraging them to do ... that's the harder question. I'll look for somebody else to answer that one. :-) Allowing, yes, at least for mutable configurations. Encouraging, maybe. However, I'm looking at a problem that may end up being related to (or affected by) the configuration. The Web Console includes capabilities to manage JMS connection factories and destinations (adding/removing queues and topics). However, the portlet to manage the factories is currently failing with an exception because it assumes that there is a state attribute on the each factory GBean and this attribute doesn't exist on the DefaultActiveMQConnectionFactory. I believe this is due to the recent removal of the jsr-77 state manageable and similar attributes from the base gbean wrapper object. I think the intent was to move them to all gbeans that were exposed in jsr-77. Apparently not all of this proposal was implemented, which may possibly affect our compliance with the jsr-77 portion of the tck. thanks david jencks So I wonder if the portlet is in error looking for the wrong attribute or the factory GBean is in error for not defining the attribute. Of course, if we remove the queues and factory defined in SystemJMS then this eliminates the problem (at least on the DefaultActionMQConnectionFactory). - Joe [EMAIL PROTECTED] wrote: The org/apache/geronimo/SystemJMS config defines an ActiveMQ resource adapter ( and the DefaultActiveMQConnectionFactory ) , MDBTransferBeanOutQueue and SendReceiveQueue admin objects. Should the two queues be removed ( I assume they were there for testing in the past)? Are we expecting users of the web console ( I haven't played with yet) adding more queues to the org/apache/geronimo/SystemJMS config, or should we be encouraging them to use their own config? If we aren't expecting users to be able to add more queues to the org/apache/geronimo/SystemJMS config, then should the org/apache/geronimo/SystemJMS config be removed from the config.list and replaced with org/apache/geronimo/ActiveMQServer? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: JMS configuration plans and config.list questions
David, Thanks for your help ... see comments below. David Jencks wrote: On Aug 5, 2005, at 6:32 AM, Joe Bohn wrote: Well I'm still feeling my way around the web console code, but it looks to me like they are expecting users to add more queues to the org/apache/geronimo/SystemJMS config. I don't think this is possible yet, although I think aaron is working on a way to make it possible shortly. I believe that each new queue is currently added to a new configuration. You're right. I was mistakenly looking at the creation of new JMS Connection Factories which does in fact create new factories (and therefore configs) with a parent-id of org/apache/geronmio/SystemJMS. Of course this might not work now either without Aaron's changes ... but it looks like that is what the code is assuming. The creation of new queues (and therefore configs) is in fact based off a different parent (something like org/apache/geronimo/Console) ... but this does seem to be working. What should be be encouraging them to do ... that's the harder question. I'll look for somebody else to answer that one. :-) Allowing, yes, at least for mutable configurations. Encouraging, maybe. However, I'm looking at a problem that may end up being related to (or affected by) the configuration. The Web Console includes capabilities to manage JMS connection factories and destinations (adding/removing queues and topics). However, the portlet to manage the factories is currently failing with an exception because it assumes that there is a state attribute on the each factory GBean and this attribute doesn't exist on the DefaultActiveMQConnectionFactory. I believe this is due to the recent removal of the jsr-77 state manageable and similar attributes from the base gbean wrapper object. I think the intent was to move them to all gbeans that were exposed in jsr-77. Apparently not all of this proposal was implemented, which may possibly affect our compliance with the jsr-77 portion of the tck. I finally figured out that the state of a GBean is now maintained for each GBean by the kernel. Therefore, rather than getting the state attribute from the GBean I must call kernel.getGBeanState() for the particular GBean. I guess that means that it was implemented but just not reflected in the Console sandbox yet. thanks david jencks So I wonder if the portlet is in error looking for the wrong attribute or the factory GBean is in error for not defining the attribute. Of course, if we remove the queues and factory defined in SystemJMS then this eliminates the problem (at least on the DefaultActionMQConnectionFactory). - Joe [EMAIL PROTECTED] wrote: The org/apache/geronimo/SystemJMS config defines an ActiveMQ resource adapter ( and the DefaultActiveMQConnectionFactory ) , MDBTransferBeanOutQueue and SendReceiveQueue admin objects. Should the two queues be removed ( I assume they were there for testing in the past)? Are we expecting users of the web console ( I haven't played with yet) adding more queues to the org/apache/geronimo/SystemJMS config, or should we be encouraging them to use their own config? If we aren't expecting users to be able to add more queues to the org/apache/geronimo/SystemJMS config, then should the org/apache/geronimo/SystemJMS config be removed from the config.list and replaced with org/apache/geronimo/ActiveMQServer? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
[jira] Created: (GERONIMO-856) Exception in JMS Connector Factory Portlet
Exception in JMS Connector Factory Portlet --- Key: GERONIMO-856 URL: http://issues.apache.org/jira/browse/GERONIMO-856 Project: Geronimo Type: Bug Components: management Versions: 1.0-M4 Environment: Windows XP Reporter: Joe Bohn A Portlet Exception was being caught and thrown because the JMSConnectionFactoryManagerPortlet assumes that the retrieval of an attribute state from the GBean will be successful and not throw an attribute not found exception (which is what it is doing). It appears that the state of the GBean instead should be retrieved from the kernel for that GBean. -- 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-856) Exception in JMS Connector Factory Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-856?page=all ] Joe Bohn updated GERONIMO-856: -- Attachment: jmsPortlet.patch Patch with changes to get the GBean state in the JMSConnectionFactoryManagerPortlet Exception in JMS Connector Factory Portlet -- Key: GERONIMO-856 URL: http://issues.apache.org/jira/browse/GERONIMO-856 Project: Geronimo Type: Bug Components: management Versions: 1.0-M4 Environment: Windows XP Reporter: Joe Bohn Attachments: jmsPortlet.patch A Portlet Exception was being caught and thrown because the JMSConnectionFactoryManagerPortlet assumes that the retrieval of an attribute state from the GBean will be successful and not throw an attribute not found exception (which is what it is doing). It appears that the state of the GBean instead should be retrieved from the kernel for that GBean. -- 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-856) Exception in JMS Connector Factory Portlet Database Connections Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-856?page=all ] Joe Bohn updated GERONIMO-856: -- Summary: Exception in JMS Connector Factory Portlet Database Connections Portlet (was: Exception in JMS Connector Factory Portlet) Description: A Portlet Exception was being caught and thrown because the JMSConnectionFactoryManagerPortlet assumes that the retrieval of an attribute state from the GBean will be successful and not throw an attribute not found exception (which is what it is doing). It appears that the state of the GBean instead should be retrieved from the kernel for that GBean. This same error exists in the AbstractConnectionFactoryManagerPortlet was: A Portlet Exception was being caught and thrown because the JMSConnectionFactoryManagerPortlet assumes that the retrieval of an attribute state from the GBean will be successful and not throw an attribute not found exception (which is what it is doing). It appears that the state of the GBean instead should be retrieved from the kernel for that GBean. Exception in JMS Connector Factory Portlet Database Connections Portlet - Key: GERONIMO-856 URL: http://issues.apache.org/jira/browse/GERONIMO-856 Project: Geronimo Type: Bug Components: management Versions: 1.0-M4 Environment: Windows XP Reporter: Joe Bohn Attachments: jmsPortlet.patch A Portlet Exception was being caught and thrown because the JMSConnectionFactoryManagerPortlet assumes that the retrieval of an attribute state from the GBean will be successful and not throw an attribute not found exception (which is what it is doing). It appears that the state of the GBean instead should be retrieved from the kernel for that GBean. This same error exists in the AbstractConnectionFactoryManagerPortlet -- 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-856) Exception in JMS Connector Factory Portlet Database Connections Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-856?page=all ] Joe Bohn updated GERONIMO-856: -- Attachment: ConsoleState.patch New patch includes changes to AbstractConectionFactoryManager as well as JMSConnectionFactoryManagerPortlet Exception in JMS Connector Factory Portlet Database Connections Portlet - Key: GERONIMO-856 URL: http://issues.apache.org/jira/browse/GERONIMO-856 Project: Geronimo Type: Bug Components: management Versions: 1.0-M4 Environment: Windows XP Reporter: Joe Bohn Attachments: ConsoleState.patch, jmsPortlet.patch A Portlet Exception was being caught and thrown because the JMSConnectionFactoryManagerPortlet assumes that the retrieval of an attribute state from the GBean will be successful and not throw an attribute not found exception (which is what it is doing). It appears that the state of the GBean instead should be retrieved from the kernel for that GBean. This same error exists in the AbstractConnectionFactoryManagerPortlet -- 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: Move console out of sandbox?
I'd like to see the console moved to the main build. thanks david jencks On Aug 4, 2005, at 11:58 AM, Jeremy Boynes wrote: At the Geronimo BOF last night there was discussion about moving the web console out of the sandbox and into the main build - general consensus seem to be something was better than nothing :-) Any objection to moving it over? -- Jeremy
Console moved into main build
I moved the console over into the main build and added it into assembly so that it is started by default. The framework war currently relies on a pluto driver war downloaded from my home directory at apache. I will follow up with the pluto project about getting this from the main repository. -- Jeremy
Re: Console moved into main build
In the future, please give some advance notice of a package move -- I have some local changes that I would have preferred to finish before the move happened. I mean, it's not like I didn't know it was going to happen eventually based on the mail thread, but tomorrow at noon would have been nice. Aaron On Fri, 5 Aug 2005, Jeremy Boynes wrote: I moved the console over into the main build and added it into assembly so that it is started by default. The framework war currently relies on a pluto driver war downloaded from my home directory at apache. I will follow up with the pluto project about getting this from the main repository. -- Jeremy
[jira] Created: (GERONIMO-857) Console links are incorrect
Console links are incorrect --- Key: GERONIMO-857 URL: http://issues.apache.org/jira/browse/GERONIMO-857 Project: Geronimo Type: Bug Versions: 1.0-M5 Reporter: Jeremy Boynes Fix For: 1.0-M5 Links on the left hand side of the console have the form: http://localhost:8080/consolenull/server/server_info The null in the middle should be /portal -- 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-857) Console links are incorrect
[ http://issues.apache.org/jira/browse/GERONIMO-857?page=all ] Jeremy Boynes updated GERONIMO-857: --- Component: console Assign to console component Console links are incorrect --- Key: GERONIMO-857 URL: http://issues.apache.org/jira/browse/GERONIMO-857 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Jeremy Boynes Fix For: 1.0-M5 Links on the left hand side of the console have the form: http://localhost:8080/consolenull/server/server_info The null in the middle should be /portal -- 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: Console moved into main build
I just put a comment on the bug, but you have to switch back to Pluto 1.0.1-rc2 because all the navigation links and form taragets are broken in -rc3. Can you put the 1.0.1-rc2 JAR/WAR in your home directory or whatever the -rc3 stuff is? Thanks, Aaron On Fri, 5 Aug 2005, Jeremy Boynes wrote: I moved the console over into the main build and added it into assembly so that it is started by default. The framework war currently relies on a pluto driver war downloaded from my home directory at apache. I will follow up with the pluto project about getting this from the main repository. -- Jeremy
[jira] Commented: (GERONIMO-857) Console links are incorrect
[ http://issues.apache.org/jira/browse/GERONIMO-857?page=comments#action_12317829 ] Aaron Mulder commented on GERONIMO-857: --- This is an issue with Pluto 1.0.1-rc3. Reverting to -rc2 fixes the problem. Please put rc2 JAR/WAR on the maven site where you have -rc3 and then we can revert etc/project.properties. Pluto was supposed to have an -rc4 release by now, though I'm not sure whether the fix is in there. Console links are incorrect --- Key: GERONIMO-857 URL: http://issues.apache.org/jira/browse/GERONIMO-857 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Jeremy Boynes Fix For: 1.0-M5 Links on the left hand side of the console have the form: http://localhost:8080/consolenull/server/server_info The null in the middle should be /portal -- 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: Console moved into main build
Hmm. I switched to rc3 as that was the jar file in the repo and I thought we had switched - guess not. rc4 is released and should be posted today. I think the best course here is to upgrade to rc4 and fix any problem with the links in that version. I can't do it tonight but will get to it in the morning. -- Jeremy Aaron Mulder wrote: I just put a comment on the bug, but you have to switch back to Pluto 1.0.1-rc2 because all the navigation links and form taragets are broken in -rc3. Can you put the 1.0.1-rc2 JAR/WAR in your home directory or whatever the -rc3 stuff is? Thanks, Aaron On Fri, 5 Aug 2005, Jeremy Boynes wrote: I moved the console over into the main build and added it into assembly so that it is started by default. The framework war currently relies on a pluto driver war downloaded from my home directory at apache. I will follow up with the pluto project about getting this from the main repository. -- Jeremy
