Re: Does J2EE 1.5/5.0 include JBI?
Geir, Sorry to bring this up again, i just got a bit of breathing room and want to put this to bed. (I don't want anyone to tell me later why did you not speak up earlier?) Can we please plan in public? I don't see any emails in the pmc@ or on dev@ proposing that we do this formally or planning about doing this. Could we talk about it here? Could you please drive the public decision making process?. My concern is that there not even a single line of code in Geronimo (or Apache for that matter) that implements JBI and we are trying to do this without any input at all from anyone. I did see the thread where you asked about TCK for JBI (http://marc.theaimsgroup.com/?l=geronimo-devm=112118579826582w=2) and James' reply that it is an optional module (http://marc.theaimsgroup.com/?l=geronimo-devm=112118724601223w=2). So i don't really see why we should be going out of the way to do this. If we do, should we start working with everyone else and start verifying them as well? (For example, ebXMLrr in sf.net - http://ebxmlrr.sourceforge.net/ has JAXR stuff). At the least we should have a policy about when we go out of the way to certify something that is not in the core. (for example ActiveMQ is fine because J2EE TCK tests it and we don't have to get another TCK for it). thanks, dims On 7/26/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Jul 25, 2005, at 10:58 PM, Davanum Srinivas wrote: Does anyone know if the J2EE 1.5 (now called 5.0) include JBI? No, it doesn't. Quote from http://radio.weblogs.com/0112098/2005/07/25.html#a532: Am looking forward to it passing the JBI TCK through the Geronimo project. The plan was to test Apache Geronimo with a JBI module backed by ServiceMix and certify *that*. Geronimo would be certified, not ServiceMix. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Move console out of sandbox?
Jeremy Boynes wrote, On 8/4/2005 11:58 AM: 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 +1 move to the main build. Regards, Alan
Re: Console moved into main build
Is there any effort underway to get them, the Pluto community, to generate a Jar in addition to a War? Regards, Alan Aaron Mulder wrote, On 8/5/2005 6:42 PM: 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
Re: Web Console - JVM portlet
Joe Bohn wrote, On 8/3/2005 5:58 AM: Do we need this type of detail about the JVM in an administrative portlet (see the JVM portlet under Server)? This seems to be a bit over the top. IMO this is especially true when listing the details on the OS, Sun (will this even work if we're not using the sun?) User, and Etc sections. I think this is all really useful data for us and possibly even for people building a server from the components of Geronimo. However, for the average user that is just going to pick up Geronimo, do some minor configuration, and deploy applications this seems a bit overwhelming. Also, it has been my experience that more extraneous information is not always a good thing to have which can easily be ignored. Some users look at this and decide that the server is too complicated for their needs. Perhaps it would be better to reference this information during initialization and save it off to a file for reference when debugging a problem. Thoughts? I don't see how it could hurt, even for unsophisticated users. It's not like we're making them go to that page, right? Regards, Alan
Re: Web Console - JVM portlet
I think the more information availble the better. I haven't looked at the page but perhaps we can organize it a bit better. Matt - Original Message - From: Alan D. Cabrera [EMAIL PROTECTED] To: dev@geronimo.apache.org Sent: Saturday, August 06, 2005 1:07 PM Subject: Re: Web Console - JVM portlet Joe Bohn wrote, On 8/3/2005 5:58 AM: Do we need this type of detail about the JVM in an administrative portlet (see the JVM portlet under Server)? This seems to be a bit over the top. IMO this is especially true when listing the details on the OS, Sun (will this even work if we're not using the sun?) User, and Etc sections. I think this is all really useful data for us and possibly even for people building a server from the components of Geronimo. However, for the average user that is just going to pick up Geronimo, do some minor configuration, and deploy applications this seems a bit overwhelming. Also, it has been my experience that more extraneous information is not always a good thing to have which can easily be ignored. Some users look at this and decide that the server is too complicated for their needs. Perhaps it would be better to reference this information during initialization and save it off to a file for reference when debugging a problem. Thoughts? I don't see how it could hurt, even for unsophisticated users. It's not like we're making them go to that page, right? Regards, Alan
Re: Console moved into main build
Alan D. Cabrera wrote: Is there any effort underway to get them, the Pluto community, to generate a Jar in addition to a War? Yes. The build now produces this jar (I think) but it is not included in the distribution as a standard artifact. I am currently talking to the Pluto folks. -- Jeremy
Re: Does J2EE 1.5/5.0 include JBI?
On Aug 6, 2005, at 9:27 AM, Davanum Srinivas wrote: Geir, Sorry to bring this up again, i just got a bit of breathing room and want to put this to bed. (I don't want anyone to tell me later why did you not speak up earlier?) Can we please plan in public? Yes Dims, we plan in public. I think you're firing first and then aiming - any conversations I've had about this have been here, and I think that you noted them in the links below. As JCP rep, I get TCKs for use on Apache projects. So if someone wants to certify an implementation of JBI on Geronimo that we will distribute, we can get the TCK for that. I don't see any emails in the pmc@ or on dev@ proposing that we do this formally or planning about doing this. Could we talk about it here? Could you please drive the public decision making process?. My concern is that there not even a single line of code in Geronimo (or Apache for that matter) that implements JBI and we are trying to do this without any input at all from anyone. Well, we don't implement EJB or JMS either :) I did see the thread where you asked about TCK for JBI (http://marc.theaimsgroup.com/?l=geronimo-devm=112118579826582w=2) and James' reply that it is an optional module (http://marc.theaimsgroup.com/?l=geronimo-devm=112118724601223w=2). So i don't really see why we should be going out of the way to do this. If we do, should we start working with everyone else and start verifying them as well? (For example, ebXMLrr in sf.net - http://ebxmlrr.sourceforge.net/ has JAXR stuff). At the least we should have a policy about when we go out of the way to certify something that is not in the core. (for example ActiveMQ is fine because J2EE TCK tests it and we don't have to get another TCK for it). If we produce a configuration for the server that is an implementation of a JCP specification, we are required to test it with the TCK. (J2EE 1.4 is an example) Therefore, if the Apache Geronimo project decides to distribute a configuration that implements JBI, we'll test it. So far, I don't see such a configuration, but figured it was just a matter of time given the interest shown in the thread you quoted... To be clear, we are not a source of TCKs for other projects. They are used only for the Apache project intended, and recipients are legally bound to do that as to the terms of the NDA. See point #3 : http://people.apache.org/~geirm/ApacheNDA.pdf geir thanks, dims On 7/26/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Jul 25, 2005, at 10:58 PM, Davanum Srinivas wrote: Does anyone know if the J2EE 1.5 (now called 5.0) include JBI? No, it doesn't. Quote from http://radio.weblogs.com/0112098/2005/07/25.html#a532: Am looking forward to it passing the JBI TCK through the Geronimo project. The plan was to test Apache Geronimo with a JBI module backed by ServiceMix and certify *that*. Geronimo would be certified, not ServiceMix. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Davanum Srinivas -http://blogs.cocoondev.org/dims/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[jira] Closed: (GERONIMO-857) Console links are incorrect
[ http://issues.apache.org/jira/browse/GERONIMO-857?page=all ] Jeremy Boynes closed GERONIMO-857: -- Resolution: Fixed Fix ConfigService properties to include the servlet mappings - this matches a change made in the old pluto-portal.jar file Sending applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties Transmitting file data . Committed revision 230572. 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: svn commit: r230572 - /geronimo/trunk/applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties
Just out of curiosity, how did you figure out that this was what was needed? I haven't had so much success with the Pluto docs. Thanks, Aaron On Sat, 6 Aug 2005 [EMAIL PROTECTED] wrote: Author: jboynes Date: Sat Aug 6 12:55:16 2005 New Revision: 230572 URL: http://svn.apache.org/viewcvs?rev=230572view=rev Log: fix for GERONIMO-857; add servlet mapping entries Modified: geronimo/trunk/applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties Modified: geronimo/trunk/applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties URL: http://svn.apache.org/viewcvs/geronimo/trunk/applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties?rev=230572r1=230571r2=230572view=diff == --- geronimo/trunk/applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties (original) +++ geronimo/trunk/applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties Sat Aug 6 12:55:16 2005 @@ -40,3 +40,5 @@ portletcontainer.entrance.impl = org.apache.pluto.PortletContainerImpl portletcontainer.entrance.wrapper.impl = org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl +servlet.insecure=/portal +servlet.secure=/secure
[jira] Created: (GERONIMO-858) Clean up dependencies in console application
Clean up dependencies in console application Key: GERONIMO-858 URL: http://issues.apache.org/jira/browse/GERONIMO-858 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Jeremy Boynes Fix For: 1.0-M5 The console application contains a LOT of dependencies that will be resolved by the parent configuration or by the WAR classloader. This is inefficient and may lead to unexpected classloading issues. These should be reduced to the minimum set. -- 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: r230572 - /geronimo/trunk/applications/console-framework/src/webapp/WEB-INF/config/services/ConfigService.properties
Aaron Mulder wrote: Just out of curiosity, how did you figure out that this was what was needed? I haven't had so much success with the Pluto docs. Inspection of the toString() method in PortalURL and comparison of the config files between Pluto HEAD and our module :-( -- Jeremy
[jira] Created: (GERONIMO-859) Remove SNAPSHOT dependency on Pluto
Remove SNAPSHOT dependency on Pluto --- Key: GERONIMO-859 URL: http://issues.apache.org/jira/browse/GERONIMO-859 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Jeremy Boynes Fix For: 1.0-M5 Replace the dependency on a SNAPSHOT version of Pluto with a release version. Currently using a SNAPSHOT version as that supports upload of its artifacts to a maven repo. -- 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: Web Console - JVM portlet
Matt Hogstrom wrote: I think the more information availble the better. I haven't looked at the page but perhaps we can organize it a bit better. How about renaming it to System Properties as that seems to be what it contains and then breaking the monolithic page down into one sub-page per section (e.g. Java, Sun (derived from JVM vendor id), Other) It would also help if the foramtting had a generic way of identifying paths and breaking them down by line. -- Jeremy
Framework Operations for StateManageable
I believe the Kernel Infrastructure used to handle J2EEManagedObject methods, which I assume include the methods of the StateManageable interface (start, startRecursive, stop, etc.). That was removed recently, which is mostly fine -- GBeans now can handle any of this stuff themselves. The one problem is with start and startRecursive. Normal operations can't be called on a GBean that's stopped, but obviously start and startRecursive are only applicable if the GBean is stopped. (The rest of the methods [getState, getStateInstance, getStartTime, and stop] have a less serious issue in that they require a GBean have a Kernel reference to implement, which spreads knowledge of the Kernel through otherwise ignorant GBeans, but at least it can be done.) Framework operations work on stopped GBeans, though. So in the change I'm now checking in, I made startRecursive and start Framework Operations in GBeanInstance -- that is, they are intercepted and the appropriate calls made on the kernel instead. The GBean still has to implement those methods in order to implement the StateManageable interface, so my GBean implementations methods just do nothing and have a note that the infrastructure will handle those calls. I would be happy to do the same with the rest of the StateManageable methods, since every GBean should have essentially the same implementation of those and it doesn't make sense to copy and paste into every one. But I'm unhappy either way we handle this. I want the management interfaces for the GBeans to include StateManageable so a client of the new management API can reference something as a StateManageable and call start or stop on it directly, and I definitely agree that all GBeans should implement their management interfaces. That just means that the GBeans need a bunch of empty methods saying the infrastructure will handle this. It's possible to make StateManageable the only recommended exception whereby a GBean would not have to implement it, but then none of the management interfaces can extend StateManageable, and client code would *always* have to cast a GBean to StateManageable before calling those methods on it. Perhaps this is the least onerous path in terms of not adding cruft to every GBean implementation, but it puts us right back where we started with the framework magically implementing an interface for the GBeans. Thoughts? You can see the effect on the Jetty stuff I'm just about to check in, where I made the container/connector management interfaces extend StateManageable and then put the implementation in JettyConnector and JettyContainerImpl (including the blanks for start and startRecursive). It's nice for clients (where you can call start and stop on any WebContainer or WebConnector), but not so nice for the GBeans. Thanks, Aaron
[jira] Created: (GERONIMO-860) Update console fully for Pluto 1.0.1-rc4
Update console fully for Pluto 1.0.1-rc4 Key: GERONIMO-860 URL: http://issues.apache.org/jira/browse/GERONIMO-860 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Aaron Mulder Assigned to: Jeremy Boynes Priority: Blocker Fix For: 1.0-M5 1) Provide pluto-portal-1.0.1-SNAPSHOT.jar (currently only the WAR is on Jeremy's home dir, but the build wants a JAR built from WEB-INF/classes in the WAR) 2) Investigate the following message: 14:31:22,763 WARN [Servlet] org.apache.pluto.portalImpl.Servlet#init(): Couldn't read property pluto.allowSetBufferSize from config file ConfigService.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] Updated: (GERONIMO-788) Improved look feel for web console
[ http://issues.apache.org/jira/browse/GERONIMO-788?page=all ] Aaron Mulder updated GERONIMO-788: -- Component: console (was: management) Improved look feel for web console Key: GERONIMO-788 URL: http://issues.apache.org/jira/browse/GERONIMO-788 Project: Geronimo Type: Improvement Components: console Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.0 Attachments: reflection.zip It would be great to apply a nicer look to the web 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-795) Extend Portlet skin capabilities to support minimize and maximize
[ http://issues.apache.org/jira/browse/GERONIMO-795?page=all ] Aaron Mulder updated GERONIMO-795: -- Component: console (was: management) Extend Portlet skin capabilities to support minimize and maximize - Key: GERONIMO-795 URL: http://issues.apache.org/jira/browse/GERONIMO-795 Project: Geronimo Type: Improvement Components: console Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Traditional portal applications support minimize and maximize as a feature on the skin in addition to help / view. We should add this feature into the admin console. It would be useful for items such as with Geronimo-794. -- 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 ] Aaron Mulder updated GERONIMO-856: -- Component: console (was: management) Assign To: Aaron Mulder This is also part of the larger issue of how to deal with StateManageable for GBeans, though the patch allows us to avoid the issue for now. 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: console Versions: 1.0-M4 Environment: Windows XP Reporter: Joe Bohn Assignee: Aaron Mulder 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
[jira] Updated: (GERONIMO-794) List only installed applications that are not part of Geronimo itself
[ http://issues.apache.org/jira/browse/GERONIMO-794?page=all ] Aaron Mulder updated GERONIMO-794: -- Component: console (was: management) Assign To: Aaron Mulder List only installed applications that are not part of Geronimo itself - Key: GERONIMO-794 URL: http://issues.apache.org/jira/browse/GERONIMO-794 Project: Geronimo Type: Improvement Components: console Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Assignee: Aaron Mulder Attachments: console.diff A user should only see applications that they installed when accessing the list of installed applications from the admin console. We can still show the system applications but under an additional portet that by default is minimized on the page. -- 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 Updated patch to account for console move from sandbox to main 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: console Versions: 1.0-M4 Environment: Windows XP Reporter: Joe Bohn Assignee: Aaron Mulder Attachments: ConsoleState.patch, 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
Portlet Best Practices [for web console]
One of the things I'm discovering is that I don't really know the best way to implement a portlet. It seems like we're kind of living in the past with the current implementation strategy. To give a more concrete example: There's a portlet that shows web connectors. It has several possible functions: - list available web connectors - display a form to configure a new connector - display a form to reconfigure an existing connector - process a new connector form submission - process an update connector form submission - confirm a remove connector request - process a confirmed remove connector submission - confirm a start or stop connector request - process a confirmed start or stop connector submission Right now, we have a single monolithic portlet handler class with all the controller logic for those. The views are broken down into separate JSPs, but the controllers are merged and fairly ugly -- it passes a mode around in a request parameter and hidden field, and for each mode it has to pick out separate properties from the request or server state and populate those in the model that gets passed to the view (currently by setting request attributes). Further, we don't handle render requests particularly well. On an action request, we pass parameters to the render request for that portlet. But for a render-only request, we revert the portlet to the default view and settings. In other words, when you interact with any one portlet on a page, all the other portlets on the page are reverted to their default state (e.g. the log portlet forgets your search criteria and shows the default 10 lines of WARN output again, while the web connector portlet reverts to the main list existing connectors screen). It's not clear how to do this well -- ideally, something would 'cache' the state of the portlet so it could redraw itself unchanged on subsequent requests, but the only thing I can think of to do is make all the portlets save their state in the portlet session, which seems a little unpleasant (as in, the session might get quite large as there's no hook for a portlet to clear its state from the session if you leave the page it's on). I guess I think it would be nice if there were some portletized web frameworks we can use -- like Struts for Portlets, or whatever. (FWIW, it seems like several portal servers provide their own struts for portlet adapters, but I don't see a standard one.) Maybe there are such frameworks and I'm just not aware of it. It could be great if we could break up the controllers, provide better render behavior, and standardize it across all portlets that go into the web console. Any thoughts? Thanks, Aaron
Re: Web Console - JVM portlet
Jeremy Boynes wrote: Matt Hogstrom wrote: I think the more information availble the better. I haven't looked at the page but perhaps we can organize it a bit better. How about renaming it to System Properties as that seems to be what it contains and then breaking the monolithic page down into one sub-page per section (e.g. Java, Sun (derived from JVM vendor id), Other) It would also help if the foramtting had a generic way of identifying paths and breaking them down by line. I like this approach. Where the information is available its better to expose it in the event it will be used. The classpaths themselves are useful but I agree on super long one is kind of ugly. Organization is better than elimination. -- Jeremy
Re: [jira] Created: (GERONIMO-860) Update console fully for Pluto 1.0.1-rc4
Aaron Please open individual issues for separate problems -- Jeremy Aaron Mulder (JIRA) wrote: Update console fully for Pluto 1.0.1-rc4 Key: GERONIMO-860 URL: http://issues.apache.org/jira/browse/GERONIMO-860 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Aaron Mulder Assigned to: Jeremy Boynes Priority: Blocker Fix For: 1.0-M5 1) Provide pluto-portal-1.0.1-SNAPSHOT.jar (currently only the WAR is on Jeremy's home dir, but the build wants a JAR built from WEB-INF/classes in the WAR) 2) Investigate the following message: 14:31:22,763 WARN [Servlet] org.apache.pluto.portalImpl.Servlet#init(): Couldn't read property pluto.allowSetBufferSize from config file ConfigService.properties
[jira] Created: (GERONIMO-861) Investigate warning from Pluto portal
Investigate warning from Pluto portal - Key: GERONIMO-861 URL: http://issues.apache.org/jira/browse/GERONIMO-861 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Jeremy Boynes Assigned to: Jeremy Boynes Priority: Blocker Fix For: 1.0-M5 1) Provide pluto-portal-1.0.1-SNAPSHOT.jar (currently only the WAR is on Jeremy's home dir, but the build wants a JAR built from WEB-INF/classes in the WAR) 2) Investigate the following message: 14:31:22,763 WARN [Servlet] org.apache.pluto.portalImpl.Servlet#init(): Couldn't read property pluto.allowSetBufferSize from config file ConfigService.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] Updated: (GERONIMO-807) Better handling for system log viewer portlet render requests
[ http://issues.apache.org/jira/browse/GERONIMO-807?page=all ] Aaron Mulder updated GERONIMO-807: -- Component: console (was: management) Better handling for system log viewer portlet render requests - Key: GERONIMO-807 URL: http://issues.apache.org/jira/browse/GERONIMO-807 Project: Geronimo Type: Bug Components: usability, console Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Minor If you interact with a different portal on the log page, the system log viewer portlet reverts to its default filter settings. It should instead default to the same values used previously (if there are previous search criteria and if none of the criteria were submitted in the request). See LogViewerPortlet.java:73 or so -- 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-860) Update console fully for Pluto 1.0.1-rc4
[ http://issues.apache.org/jira/browse/GERONIMO-860?page=all ] Jeremy Boynes closed GERONIMO-860: -- Resolution: Fixed Uploaded the JAR file - that's why two artifacts per project is a bad idea :-( Update console fully for Pluto 1.0.1-rc4 Key: GERONIMO-860 URL: http://issues.apache.org/jira/browse/GERONIMO-860 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Jeremy Boynes Priority: Blocker Fix For: 1.0-M5 1) Provide pluto-portal-1.0.1-SNAPSHOT.jar (currently only the WAR is on Jeremy's home dir, but the build wants a JAR built from WEB-INF/classes in the WAR) 2) Investigate the following message: 14:31:22,763 WARN [Servlet] org.apache.pluto.portalImpl.Servlet#init(): Couldn't read property pluto.allowSetBufferSize from config file ConfigService.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] Updated: (GERONIMO-861) Investigate warning from Pluto portal
[ http://issues.apache.org/jira/browse/GERONIMO-861?page=all ] Jeremy Boynes updated GERONIMO-861: --- Description: Investigate the following message: 14:31:22,763 WARN [Servlet] org.apache.pluto.portalImpl.Servlet#init(): Couldn't read property pluto.allowSetBufferSize from config file ConfigService.properties was: 1) Provide pluto-portal-1.0.1-SNAPSHOT.jar (currently only the WAR is on Jeremy's home dir, but the build wants a JAR built from WEB-INF/classes in the WAR) 2) Investigate the following message: 14:31:22,763 WARN [Servlet] org.apache.pluto.portalImpl.Servlet#init(): Couldn't read property pluto.allowSetBufferSize from config file ConfigService.properties Assign To: (was: Jeremy Boynes) Priority: Major (was: Blocker) Investigate warning from Pluto portal - Key: GERONIMO-861 URL: http://issues.apache.org/jira/browse/GERONIMO-861 Project: Geronimo Type: Bug Components: console Versions: 1.0-M5 Reporter: Jeremy Boynes Fix For: 1.0-M5 Investigate the following message: 14:31:22,763 WARN [Servlet] org.apache.pluto.portalImpl.Servlet#init(): Couldn't read property pluto.allowSetBufferSize from config file ConfigService.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
Re: Portlet Best Practices [for web console]
Aaron Mulder wrote: snip/ I guess I think it would be nice if there were some portletized web frameworks we can use -- like Struts for Portlets, or whatever. (FWIW, it seems like several portal servers provide their own struts for portlet adapters, but I don't see a standard one.) snip/ Any thoughts? On the framework side, there are a couple but the separation between action and render gives problems for some e.g. the Struts portlet framework originally double dispatched to the actions (not sure if that has been fixed yet). The other thing that seems ironic is that most of the portlets are probably going to be very small implementations and there is a good chance that the footprint of the framework will be far larger than that of the portlet itself. -- Jeremy
[jira] Closed: (GERONIMO-856) Exception in JMS Connector Factory Portlet Database Connections Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-856?page=all ] Aaron Mulder closed GERONIMO-856: - Fix Version: 1.0-M5 Resolution: Fixed 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: console Versions: 1.0-M4 Environment: Windows XP Reporter: Joe Bohn Assignee: Aaron Mulder Fix For: 1.0-M5 Attachments: ConsoleState.patch, 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
[jira] Updated: (GERONIMO-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
[ http://issues.apache.org/jira/browse/GERONIMO-846?page=all ] Joe Bohn updated GERONIMO-846: -- Attachment: logSettings.patch Updated patch to account for Web Console moving from sandbox to main Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed. - Key: GERONIMO-846 URL: http://issues.apache.org/jira/browse/GERONIMO-846 Project: Geronimo Type: Bug Components: management, common Versions: 1.0-M4 Environment: Windows XP Reporter: Joe Bohn Attachments: logSettings.diff, logSettings.patch Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed. I propose the following: 1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. This way we won't was time setting things that haven't changed. 2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval today). This will clean things up so that another object invoking this service unnecessarily doesn't create a similar problem. -- 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: Portlet Best Practices [for web console]
On Sat, 6 Aug 2005, Jeremy Boynes wrote: On the framework side, there are a couple but the separation between action and render gives problems for some e.g. the Struts portlet framework originally double dispatched to the actions (not sure if that has been fixed yet). Is there an official struts/portlet integration package? I didn't see one. Can you point me to it? The other thing that seems ironic is that most of the portlets are probably going to be very small implementations and there is a good chance that the footprint of the framework will be far larger than that of the portlet itself. Well, I'm not so sure that's true. I listed like 9 functions of the web server manager portlet, and the EJB server manager one will be nearly identical. I think the database, JMS, and application portlets are going to be similarly complex (list, deploy, configure, start/stop/undeploy, confirm action, view DDs, ...). CORBA and security realms seem likely to be fairly ugly too. Overall, I think cleaning up and standardizing the complex ones like that is worth almost any amount of overhead on the super-simple ones like the JVM system properties view. Aaron
[jira] Closed: (GERONIMO-794) List only installed applications that are not part of Geronimo itself
[ http://issues.apache.org/jira/browse/GERONIMO-794?page=all ] Aaron Mulder closed GERONIMO-794: - Fix Version: 1.0-M5 Resolution: Fixed I don't think we should go out of our way to suppress o/a/g modules, so I like the effect of the patch. We need more functionality on these pages, but that's a different issue. :) List only installed applications that are not part of Geronimo itself - Key: GERONIMO-794 URL: http://issues.apache.org/jira/browse/GERONIMO-794 Project: Geronimo Type: Improvement Components: console Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Assignee: Aaron Mulder Fix For: 1.0-M5 Attachments: console.diff A user should only see applications that they installed when accessing the list of installed applications from the admin console. We can still show the system applications but under an additional portet that by default is minimized on the page. -- 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: Portlet Best Practices [for web console]
Aaron Mulder wrote: On Sat, 6 Aug 2005, Jeremy Boynes wrote: On the framework side, there are a couple but the separation between action and render gives problems for some e.g. the Struts portlet framework originally double dispatched to the actions (not sure if that has been fixed yet). Is there an official struts/portlet integration package? I didn't see one. Can you point me to it? I don't think that there is a standard struts/portlet package (at least I'm not aware of one). JetSpeed has it listed in their roadmap but I don't know if that is something going into the next release or not. I would much rather find an implementation that we can include instead of creating from scratch. The other thing that seems ironic is that most of the portlets are probably going to be very small implementations and there is a good chance that the footprint of the framework will be far larger than that of the portlet itself. Well, I'm not so sure that's true. I listed like 9 functions of the web server manager portlet, and the EJB server manager one will be nearly identical. I think the database, JMS, and application portlets are going to be similarly complex (list, deploy, configure, start/stop/undeploy, confirm action, view DDs, ...). CORBA and security realms seem likely to be fairly ugly too. Overall, I think cleaning up and standardizing the complex ones like that is worth almost any amount of overhead on the super-simple ones like the JVM system properties view. Aaron If we think that the console itself is going to be fairly large then perhaps we should consider pulling in JetSpeed. So far it seems as if the cost of doing that is out of line with the benefits gained .. but if we are thinking about opening up the portlet container for others to use in the near future then it would make sense to get more involved with JetSpeed. -- 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-862) Remove HTTP/HTTPS manager portlets
Remove HTTP/HTTPS manager portlets -- Key: GERONIMO-862 URL: http://issues.apache.org/jira/browse/GERONIMO-862 Project: Geronimo Type: Improvement Components: console Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.0-M5 The AJP portlet has been converted to a generic web connector manager portlet. It now handles all the connector types. The HTTP and HTTPS portlets should be removed in favor of the new AJP one. There are a couple things that ought to be done first or at the same time: - The AJP one ought to be renamed to something more generic. - A copy of the editHTTP JSP should be created for HTTPS, with additional connector settings per what's in the SecureConnector interface. AJP doesn't need any special treatment (it can reuse the HTTP JSP for now). - The look and feel of the old HTTP connector list screen is nicer than the new unified connector list screen, so it should be migrated to the new portlet before the HTTP one is removed -- 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
